Windows コンソールのアクティビティの監視 (パート 1)

序章

インシデント対応の実行中に、Mandiant は侵害されたネットワーク上のシステムを積極的に使用している攻撃者に遭遇します。多くの場合、このアクティビティには、コマンド プロンプト、PowerShell、場合によってはカスタム コマンド アンド コントロール (C2) コンソール ツールなど、RDP を介した対話型コンソール プログラムの使用が含まれます。 Mandiant のイノベーションおよびカスタム エンジニアリング (ICE) チームは、エンドポイントでのこの攻撃者の活動を捕捉することがどれほど実現可能かを調査しました。

対象の Windows のバージョンによっては、ライブ システムでこのデータをキャプチャするのが難しい場合があります。さまざまなレベルの難易度は、過去 10 年間の仮想コンソールの Windows 実装の進化に直接関係しています。

このブログでは、過去の Windows コンソール アーキテクチャの実装について説明します。特に、最新バージョンの Windows に現在実装されているものに重点を置いています。

コンソール アプリケーションのレビュー

Windows PE ローダーは、PE オプション ヘッダーの「サブシステム」フィールドが IMAGE_SUBSYSTEM_WINDOWS_CUI に設定されている場合に、ファイルがコンソール アプリケーションであるかどうかを判断します。このフラグが設定されている場合、ローダーはプロセスにコンソール サーバーを割り当てます。コンソール サーバーの実装方法の詳細は、Windows のバージョンによって異なり、Windows XP から 3 つの主要な改訂が行われています。実装に関係なく、クライアント (cmd.exe、powershell.exe など) が実行されると、デフォルトでコンソール サーバー接続が通常 AllocConsole Win32 API を介して確立されます。サーバー プロセスは、プロセス間通信 (IPC) メカニズムを介してクライアント プロセスに転送されるコマンドを入力するときに、ユーザーが通常対話するものです。 1 つのコンソール サーバーで、1 つまたは複数のクライアントを同時にホストできます。

Windows コンソールの進化

Windows XP から Windows Vista では、クライアント/サーバー ランタイム サブシステム プロセス(CSRSS) が、ユーザー入力をキャプチャしてクライアント プロセスに送信する役割を果たしていました。クライアントと CSRSS は、ローカル プロシージャ コール (LPC) ポートを使用して通信し、キャプチャした入力を送信しました。図 1 は、Windows XP および Vista に実装されたクライアント/サーバー コンソール アーキテクチャを示しています。

このモデルは、クライアントが現在のユーザーとして実行されたため、権限昇格の脆弱性に悩まされていましたが、CSRSS サーバー プロセスはローカル システム アカウントとして実行されていました。攻撃者は、権限のないユーザーとして接続し、CSRSS の脆弱なコード パスをトリガーして、システム レベルのアクセス権を与えることで、CSRSS の公開された攻撃面を悪用する可能性があります。

このアーキテクチャの問題は、Windows 7 および Windows Server 2008 R2 のリリースで解決されました。システム上の唯一のコンソール サーバーである CSRSS の代わりに、コンソール入力スレッドをホストする新しいコンソール ホスト (conhost.exe) プロセスが導入されました。このプロセスはクライアントと同じコンテキストで実行されるようになり、この攻撃シナリオが削除されました。図 2 は、更新された Windows 7 コンソール アーキテクチャを示しています。

Windows 7 のコンソールが割り当てられると、CSRSS は conhost.exe プロセスの新しいインスタンスを実行します。 Advanced Local Procedure Call (ALPC) ポートは、RPC ControlConsoleLPC-<conhost_pid>-<random_number> という命名規則で作成されます。このポートは、クライアント プロセスとサーバー プロセスにマップされた共有セクション オブジェクトと共に使用されるため、コマンド ライン データを簡単に共有できます。さらに、RPC ControlConsoleEvent-<conhost_pid>-<random_number> という名前付けスキームでイベント オブジェクトが作成されます。このイベント オブジェクトは、新しいデータが存在する場合にクライアントとサーバーが相互に通知できるようにするために使用されます。図 3 の Windbg の出力に示すように、1 つの conhost.exe プロセスで複数のクライアント アプリケーションにサービスを提供できます。

この記事の執筆時点では、Windows 8 のリリースで最新のコンソール実装が導入されました。この新しいアーキテクチャは、クライアント プロセスとサーバー プロセス間のコンソール I/O を処理する専用のカーネル ドライバが存在するという点で、以前のアーキテクチャとは大きく異なります。この新しいドライバーは ConDrv.sys という名前で、システム上のすべてのコンソール通信を仲介します。これは、DeviceConDrv という名前のデバイス オブジェクトを使用して、ドライバーによってユーザー モード アプリケーションに公開されます。このデバイス オブジェクトは、サポートされている名前空間パラメーター(Connect、Server、Input、Output、Reference、CurrentIn、および CurrentOut) のリストを使用して、ユーザー モードから開かれます。これらは、アプリケーションのニーズに応じて開かれます。クライアント アプリケーションは、多くの場合、ドライバーが必要とする機能に応じて、コンソール ドライバーへの複数の開いているハンドルを持ちます。これを図 4 に示します。

コマンド ライン プロセスによってコンソールが割り当てられると、kernelbase.dll は DeviceConDrv へのハンドルを開き、新しい conhost.exe プロセスの作成を要求します。 ConDrv はカーネル モードからこのプロセスを実行し、メモリ記述子リスト (MDL) チェーンが割り当てられます。この MDL チェーンを使用して、Conhost プロセスとそのクライアントの間でメモリ ページをマップし、それらの間でデータを簡単に共有できるようにします。以前のバージョンで使用されていた LPC/ALPC ポートの代わりに、メッセージは通常、Fast I/O を使用してコンソール ドライバーに転送されるようになりました。高速 I/O を使用すると、アプリケーションは、要求ごとに I/O 要求パケット (IRP) を作成するオーバーヘッドなしでドライバーと通信できます。 IRP は、I/O データをデバイス ドライバーに配信するために使用されるオペレーティング システム構造です。これらの高速 I/O 要求は、コンソールへの読み取りと書き込みに使用され、ConDrv ドライバーによって仲介されます。

Windows 10 では、conhost.exe はほとんどがコンテナー プロセスです。メインの入力スレッドは、すべてのサーバー機能と共に ConhostV2.dll または ConhostV1.dll で実行されます。既定では、ConhostV2.dll が読み込まれ、Windows 10 ユーザーに新しいコンソール機能 (フル スクリーン コンソール ウィンドウなど) が提供されます。 ConhostV1.dll は、Windows 7 以前と同じようにコンソールを動作させる「レガシー モード」を実装しています。使用されているバージョンに関係なく、ConDrv.sys は、コンソール クライアントとサーバーの間でメッセージを転送するために使用されます。図 5 は、これらすべてがどのように組み合わされるかを示しています。

詳細については、フォローアップ投稿「 Windows コンソール アクティビティの監視 パート 2 」を参照してください。