WMI 対 WMI: 悪意のあるアクティビティの監視

こんにちは、私の名前は WMI です。

WMI は、Windows 98 以降の Windows のコア コンポーネントですが、新しいボトルに入った古いワインではありません。 WMI は、1961 年のボルドー ワインのボトルによく似ています。 WMI は、システム管理と監査のための Web ベースのエンタープライズ管理 (WBEM) を Microsoft が解釈したものとして開発されました。ただし、攻撃者は、システム上に最初の足場を作成することから、環境およびその間のすべてからデータを盗むことまで、攻撃ライフサイクル (図 1 を参照) のすべての段階でそれを使用できます。調査の観点から見ると、WMI はごく最近になって選ばれた少数の攻撃者グループによって使用されただけであり、調査中に見落とされる可能性があるアーティファクトです。 WMI はデフォルトの詳細なトレース ログを提供しませんが、 [1] 実行または永続化アクティビティ。

このブログ投稿では、攻撃者が WMI をリモート実行ユーティリティとして、また永続化メカニズムとしてマルウェアを実行する方法と、企業規模でこのアクティビティを検出するためにできることについて説明します。

問題

私たちは最近、セキュリティ オペレーションの Red Teaming エンゲージメントのために現場にいました。そこでは、Red Team が WMI をリモート実行ユーティリティ (PsExec に類似) およびマルウェア永続化メカニズム (システム サービスに類似) として利用しました。クライアントのセキュリティ オペレーション センター (SOC) には、ネットワークとエンドポイントの両方の観点からこのアクティビティを検出する機能がないことにすぐに気付きました。そのため、レッド チーム活動を一時停止し、クライアントと協力してこの不足に対する解決策を特定することにしました。可視性の。

ソリューション

私たちは、防御の観点から問題を解決するために必要なことは、「大地を離れて暮らす」という攻撃者の格言に従うことだと判断しました。つまり、WMI を利用してそれ自体を監視し、WMI によって呼び出されたプロセスの作成と永続化のアクティビティをシステムのアプリケーション イベント ログに直接フィードしました。これにより、クライアントはこれらのログをエンドポイントから SIEM にフィードし、環境全体の可視性を高めることができました。

これを実現するために、WMI サブスクリプションを作成しました。サブスクリプションは、WMI 永続性に使用される用語であり、次の 3 つの項目で構成されます。

1. イベント コンシューマー: 対象のイベントのトリガー時に実行するアクション
2. イベント フィルタ: 関心のあるイベント
3. フィルターからコンシューマーへのバインディング: フィルターをコンシューマーにバインドする登録メカニズム

この WMI サブスクリプションは、攻撃者が永続化のために作成したサブスクリプションに似ています。ただし、別のタイプのアクションを実行するために、このメソッドを転用しています。システムのアップタイムが 200 秒に達したときなど、条件が満たされたときにマルウェアを実行する代わりに、新しく作成されたコンシューマーまたは WMI によって引き起こされたプロセスの実行をアプリケーション イベント ログに記録するように WMI に指示しています。 PowerShell を使用して、これらの新しい手順で WMI を構成しました。大まかに言えば、PowerShell スクリプトは次のことを実行します。

1. WMI クエリ言語 (WQL) を使用して以下を識別します。
を。最近作成された「__EventConsumer」イベント (持続メカニズム)
b. WMI ベースのプロセス実行

2. イベント フィルター (条件) を作成し、上記の WQL 条件のいずれかが true の場合にアクションを実行します。

3. イベント コンシューマ (アクション) を作成し、新しく作成された「__EventConsumer」または実行されたプロセスの詳細をログに記録します。
を。詳細をログに記録するには、「NTEventLogEventConsumer」WMI クラスを呼び出します。このクラスは、これが新しいイベント コンシューマーまたはプロセス作成であったかどうかに応じて、次の詳細を含むカスタム メッセージをアプリケーション イベント ログに記録します。

私。イベント コンシューマー名
ii.イベント コンシューマー コマンド
iii.プロセス呼び出し方法
iv。プロセス呼び出しコマンド

4. 条件をアクションに関連付けるバインディングを作成して登録します。

結果

図 2 は、アプリケーション イベント ログで「_EvilConsumer_」という適切な名前を付けた、新しく作成された WMI コンシューマの一般的な詳細を示しています。

図 3 は、新しい WMI コンシューマ「_EvilConsumer_」の作成のために実行されたコンシューマ名とコマンドを含むイベント ログの詳細ビューを示しています。

次の例は、別の一般的な使用例を示しており、攻撃者がリモート システムに対するプロセス実行に WMI を利用する方法を示しています。図 4 は、Windows Management Instrumentation コマンド ライン (WMIC) を使用してリモート PowerShell プロセスを実行するコマンド ラインの例を示しています。このコマンドは、「Invoke-Expression」（IEX）コマンドレットを使用して、リモート システム「WIN-RD35VEB5LRT」で HTTP 経由で「execPayload.ps1」スクリプトをダウンロードして実行しました。

PowerShell プロセスは最終的に WMI 経由で実行されたため、WMI 監視サブスクライバーはプロセス名とプロセス引数をログに記録しました。図 5 は、被害者のシステム「WIN-RD35VEB5LRT」のアプリケーション イベント ログに記録された WMI プロセス実行の一般的な詳細を示しています。

図 6 は、イベント ログの詳細ビューを示しています。このログには、WMI によって呼び出されたプロセスの作成から実行されたコマンド「powershell.exe」が含まれています。

企業での監視

新しく作成された Event Consumers と WMI を介して生成されたプロセスをログに記録できるようになったので、これをよりエンタープライズ向けにするための措置を講じることができます。クライアントの SOC は、サードパーティのユーティリティを使用してログ データを SIEM に挿入しました。クライアントは、新しく定義されたアプリケーション イベント ログを SIEM にフィードし、これらのイベントに関するアラートを送信して、フォローアップ分析を実行できるようになりました。あらゆる規模の環境で、次の同様の手順に従って、この WMI 永続性監視を実行し、新しいイベントについて警告することができます。

1. GPO、SCCM、またはその他のサード パーティ ユーティリティを介して、WMI 監視 PowerShell スクリプトをエンドポイントに展開します。これにより、エンドポイント システムで新しく作成されたイベント コンシューマを監視する永続的な WMI サブスクリプションが作成されます。
2. Snare または同様のユーティリティを使用して、WMI 永続性イベントまたはプロセス作成イベントに一致するアプリケーション イベント ログを SIEM にプッシュまたはプルします。
3. SIEM を介して、WMI の永続性またはプロセス作成ログに関するアラートを出します。注: 一部の環境では、システム管理のために WMI によって呼び出されるプロセスの作成を多用する場合があります。このような場合、IT チームと協力して WMI アクティビティのベースラインを確立し、「%SYSTEMDRIVE%WindowsTemp」からのプロセス作成などの異常なイベントのみを取り込むことをお勧めします。
4. 新しく作成された WMI イベント コンシューマまたはプロセス作成を使用して、システムでフォローアップ分析を実行します。

このプロセスは、エンドポイントのフォレンジックな収集と分析を実行する必要なく、企業向けに特定の WMI イベントをほぼリアルタイムで監視および検出する方法をクライアントに提供しました。

スクリプトをダウンロード

PowerShell スクリプトは、こちらの GitHub ページからダウンロードできます。注: スクリプトを使用する前に、管理者として PowerShell を実行する必要があります。このスクリプトには PowerShell バージョン 3 以降 (最新はバージョン 5) が必要であり、現在の状態で 2 つの個別の PowerShell 関数として実行されます。図 7 は、スクリプトからモジュールをインポートする方法と、各モジュールを実行する方法のスクリーンショットを示しています。

謝辞

侵入検知システムとしての Windows Management Instrumentation (WMI) の開発に協力してくれた Matt Graeber (@mattifestation) に感謝します。 Matt が最初に開発した 2 つの PowerShell スクリプトを組み合わせて変更し、WMI イベント コンシューマーとプロセスの作成について警告し、これらのイベントの詳細をアプリケーション イベント ログに直接出力しました。悪意のある WMI アクションを特定してログに記録するために使用した Matt Graeber の WMI の作業は、 こことここで見つけることができます。

[1] Windows 7 以降のオペレーティング システムには、WMI アクティビティ操作イベント ログが含まれていますが、これは、WMI 永続化に使用される、新しく作成されたコンシューマー、フィルター、またはバインディングの詳細を提供しません。