PowerShell ログによる可視性の向上

更新 (2 月 29 日): この投稿は、PowerShell 5 の 2 月 24 日の再リリースによる新しい構成の推奨事項で更新され、ユーザーが価値があると思われる解析スクリプトへのリンクが含まれています。

Table of contents

序章
バックグラウンド
インストール
ロギング構成
モジュールのロギング
スクリプトブロックのログ記録
転写
ログ設定
付録
参考文献

序章

Mandiant は、攻撃のすべての段階で PowerShell を利用する攻撃を継続的に調査しています。私たちが経験する一般的な問題は、攻撃者が PowerShell を使用して実行したアクションを適切に示す利用可能なログがないことです。これらの調査では、Mandiant は定期的に PowerShell ログの増加に関するガイダンスを提供し、調査員に悪意のあるアクティビティの検出メカニズムと、PowerShell がシステムでどのように使用されたかの履歴記録を提供します。このブログ投稿では、PowerShell のさまざまなログオプションと、PowerShell が関与する攻撃に適切に対応、調査、および修復するために必要な可視性を得るためにどのように役立つかについて詳しく説明しています。

バックグラウンド

侵入テストフレームワークの攻撃者と開発者は、ますます Windows PowerShell を利用して操作を実行しています。 PowerShell は、Microsoft Windows に組み込まれている非常に強力なコマンド環境およびスクリプト言語です。既定では、PowerShell はほとんどの Windows 環境で実行の多くの成果物を残しません。優れた機能性とステルス性の組み合わせにより、PowerShell を利用した攻撃は、企業のセキュリティチームにとって悪夢となっています。 [1]。

すべての Windows 7/2008 システムにインストールされている PowerShell 2.0 は、攻撃者の活動の証拠をほとんど提供しません。 Windows イベントログには、PowerShell が実行されたこと、セッションの開始時刻と終了時刻、およびセッションがローカルで実行されたかリモートで実行されたか (ConsoleHost または ServerRemoteHost) が表示されます。ただし、PowerShell で実行された内容については何も明らかにしていません。図 1 は、PowerShell 2.0 ログ Windows PowerShell.evtx に記録されたイベントログメッセージの例を示しています。

PowerShell Session Start in PowerShell 2.0 — 図 1: PowerShell 2.0 での PowerShell セッションの開始

Microsoft は、最近のバージョンで PowerShell のセキュリティの透明性を向上させるための措置を講じています。強化されたログ記録などの最も重要な機能強化は、PowerShell バージョン 5.0 でリリースされました。この強化されたログは、実行された PowerShell コマンドとスクリプト、難読化解除されたコード、出力、および攻撃者のアクティビティのトランスクリプトを記録します。強化された PowerShell のログ記録は、企業の監視とインシデント対応の両方にとって非常に貴重なリソースです。

PowerShell 5.0 は、Windows 7/2008 R2 以降の最新リリースです。 PowerShell 5.0 の強化されたログ機能の多くはバージョン 4.0 にバックポートされましたが、Mandiant はすべての Windows プラットフォームに PowerShell 5.0 をインストールすることを推奨しています。 PowerShell 5.0 には、疑わしいスクリプトブロックのログ記録など、4.0 では利用できない機能が含まれています。

インストール

Windows 10 では、強化された PowerShell ログをサポートするためにソフトウェアの更新は必要ありません。

Windows 7/8.1/2008/2012 の場合、PowerShell をアップグレードして PowerShell 5.0 で拡張ログを有効にする (推奨) には、次のものが必要です。

.NET 4.5
Windows Management Framework (WMF) 4.0 (Windows 7/2008 のみ)
Windows 管理フレームワーク (WMF) 5.0

Windows 7 および 2008 R2 は、WMF 5.0 をインストールする前に Windows Management Framework (WMF) 4.0 にアップグレードする必要があります。

Windows 7/8.1/2008/2012 の PowerShell 4.0 で拡張ログを有効にするには、次のものが必要です。

» .NET 4.5
» Windows 管理フレームワーク (WMF) 4.0
» 適切な WMF 4.0 アップデート
– 8.1/2012 R2 – KB3000850
– 2012 – KB3119938
– 2008 年 7 月 R2 SP1 – KB3109118

Microsoft からこれらの更新プログラムをダウンロードするには、自動化された要求プロセスの完了が必要になる場合があります。

ロギング構成

ロギングは、次のようにグループポリシーを使用して構成する必要があります。

管理用テンプレート → Windows コンポーネント → Windows PowerShell

PowerShell は、モジュールログ、スクリプトブロックログ、および文字起こしの 3 種類のログをサポートしています。 PowerShell イベントは、PowerShell 操作ログ Microsoft-Windows-PowerShell%4Operational.evtx に書き込まれます。

モジュールのロギング

モジュールログは、変数の初期化やコマンドの呼び出しなど、PowerShell の実行時にパイプラインの実行の詳細を記録します。モジュールのロギングは、スクリプトの一部、一部の難読化解除されたコード、および出力用にフォーマットされた一部のデータを記録します。このログは、他の PowerShell ログソースでは見逃された詳細をキャプチャしますが、実行されたコマンドを確実にキャプチャするとは限りません。モジュールログは、PowerShell 3.0 以降で利用できます。モジュールログイベントは、イベント ID (EID) 4103 に書き込まれます。

モジュールロギングは大量のイベントを生成しますが (一般的な Invoke-Mimikatz スクリプトの実行により 2,285 個のイベントが生成され、テスト中に 7 MB のログが生成されました)、これらのイベントは他のソースではキャプチャされない貴重な出力を記録します。

モジュールのログを有効にするには:

1. 「Windows PowerShell」GPO 設定で、「モジュールログを有効にする」を有効に設定します。
2. [オプション] ペインで、ボタンをクリックしてモジュール名を表示します。
3. [モジュール名] ウィンドウで、 *を入力してすべてのモジュールを記録します。
を。オプション: 特定のモジュールのみをログに記録するには、ここで指定します。 (注: これは推奨されません。)
4. 「モジュール名」ウィンドウで「OK」をクリックします。
5. 「Module Logging」ウィンドウで「OK」をクリックします。

または、次のレジストリ値を設定しても同じ効果があります。

» HKLMSOFTWAREWow6432NodePoliciesMicrosoftWindowsPowerShellModuleLogging → EnableModuleLogging = 1
» HKLMSOFTWAREWow6432NodePoliciesMicrosoftWindowsPowerShellModuleLoggingModuleNames → * = *

スクリプトブロックのログ記録

スクリプトブロックロギングは、PowerShell エンジンによって実行されるコードのブロックを記録するため、スクリプトやコマンドを含む、攻撃者によって実行されたコードの完全な内容をキャプチャします。スクリプトブロックロギングの性質上、実行時に難読化解除されたコードも記録されます。たとえば、元の難読化されたコードを記録することに加えて、スクリプトブロックロギングは、元の難読化されたコードに加えて、PowerShell の -EncodedCommand 引数で渡されたデコードされたコマンド、および XOR、Base64、ROT13、暗号化などで難読化されたコマンドを記録します。 .スクリプトブロックのログは、実行されたコードからの出力を記録しません。スクリプトブロックのログイベントは、EID 4104 に記録されます。イベントログメッセージの最大長を超えるスクリプトブロックは、複数のエントリに分割されます。スクリプトブロックのログを解析し、断片化されたブロックを再構築するためのスクリプトを使用できます (参考文献 5 を参照)。

PowerShell 4.0 では利用できませんが、PowerShell 5.0 は、スクリプトブロックのログ記録が有効になっていない場合でも、疑わしいコマンドまたはスクリプト手法のリストでブロックの内容が一致する場合、コードブロックを自動的にログに記録します。これらの疑わしいブロックは、スクリプトブロックのログ記録が明示的に無効にされていない限り、EID 4104 の「警告」レベルでログに記録されます。この機能により、ログが有効になっていない場合でも、既知の疑わしいアクティビティの一部のフォレンジックデータがログに記録されますが、Microsoft ではセキュリティ機能とは見なされていません。スクリプトブロックのログ記録を有効にすると、PowerShell プロセスによって疑わしいと見なされたブロックだけでなく、すべてのアクティビティがキャプチャされます。これにより、調査員は攻撃者の活動の全範囲を特定できます。疑わしいと見なされないブロックも EID 4104 に記録されますが、「詳細」または「情報」レベルで記録されます。

スクリプトブロックのログ記録は、モジュールのログ記録よりも少ないイベントを生成し (Invoke-Mimikatz は合計 5 MB の 116 イベントを生成)、SIEM またはログ監視プラットフォームでアラートを出すための貴重な指標を記録します。

グループポリシーには、「スクリプトブロック実行の開始/停止イベントをログに記録する」オプションもあります。このオプションは、スクリプトブロック ID ごとに、スクリプトブロックの開始と停止を EID 4105 と 4106 に記録します。このオプションは、PowerShell スクリプトが長期間にわたって実行される場合のように、追加のフォレンジック情報を提供する場合がありますが、非常に大きなファイルが生成されます。イベントの数 (96,458 イベント、Invoke-Mimikatz の実行ごとに合計 50 MB) であり、ほとんどの環境では推奨されません。

スクリプトブロックのログを有効にするには:

1. 「Windows PowerShell」GPO 設定で、「PowerShell スクリプトブロックログを有効にする」を有効に設定します。

または、次のレジストリ値を設定すると、ログが有効になります。

» HKLMSOFTWAREWow6432NodePoliciesMicrosoftWindowsPowerShellScriptBlockLogging → EnableScriptBlockLogging = 1

転写

転写は、すべての入力と出力を含むすべての PowerShell セッションの一意の記録を、セッションに表示されるとおりに作成します。トランスクリプトはテキストファイルに書き込まれ、ユーザーとセッションごとに分割されます。トランスクリプトには、分析を支援するために、各コマンドのタイムスタンプとメタデータも含まれています。ただし、トランスクリプションは、PowerShell ターミナルに表示される内容のみを記録します。これには、実行されたスクリプトの内容や、ファイルシステムなどの他の宛先に書き込まれた出力は含まれません。

PowerShell トランスクリプトには、衝突を防ぐために、「PowerShell_transcript」で始まる名前が自動的に付けられます。既定では、トランスクリプトはユーザーのドキュメントフォルダーに書き込まれますが、ローカルシステムまたはネットワーク上のアクセス可能な任意の場所に構成できます。ベストプラクティスは、トランスクリプトをリモートの書き込み専用ネットワーク共有に書き込むことです。ここでは、防御側がデータを簡単に確認でき、攻撃者がデータを簡単に削除できません (以下の参照 2 を参照)。トランスクリプトは非常にストレージ効率が高く (Invoke-Mimikatz の実行ごとに 6 KB 未満)、簡単に圧縮でき、grep などの標準ツールを使用して確認できます。

文字起こしを有効にするには:

1. 「Windows PowerShell」GPO 設定で、「PowerShell トランスクリプションを有効にする」を有効に設定します。
2. 実行された各コマンドのタイムスタンプを記録するために、[呼び出しヘッダーを含める] ボックスをオンにします。
3. 必要に応じて、集中トランスクリプト出力ディレクトリを設定します。

このディレクトリは、セキュリティ担当者がアクセスできる書き込み専用の制限付きネットワーク共有にする必要があります。出力ディレクトリが指定されていない場合、トランスクリプトファイルはユーザーのドキュメントディレクトリの下に作成されます。

または、次のレジストリ値を設定すると、ログが有効になります。

» HKLMSOFTWAREWow6432NodePoliciesMicrosoftWindowsPowerShellTranscription → EnableTranscripting = 1
» HKLMSOFTWAREWow6432NodePoliciesMicrosoftWindowsPowerShellTranscription → EnableInvocationHeader = 1
» HKLMSOFTWAREWow6432NodePoliciesMicrosoftWindowsPowerShellTranscription → OutputDirectory = “” (パスを入力。空 = デフォルト)

ログ設定

可能であれば、Mandiant は、モジュールログ、スクリプトブロックログ、およびトランスクリプションの 3 つのログソースをすべて有効にすることをお勧めします。これらの各ソースは、PowerShell アクティビティの分析に役立つ固有のデータを記録します。ログサイズを大幅に増やすことができない環境では、スクリプトブロックのログ記録と文字起こしを有効にすると、生成されるログデータの量を最小限に抑えながら、ほとんどのアクティビティが記録されます。少なくとも、攻撃者のコマンドとコードの実行を識別するために、スクリプトブロックのログ記録を有効にする必要があります。

理想的には、PowerShell イベントログ Microsoft-Windows-PowerShell%4Operational.evtx のサイズを 1 GB (または組織が許可する最大サイズ) に増やして、データが妥当な期間保持されるようにする必要があります。 PowerShell ログは、ログをすばやくロールする大量のデータを生成します (通常の管理者または攻撃者のアクティビティでは、1 分あたり最大 1 MB が観察されています)。

Windows リモート管理 (WinRM) ログ、Microsoft-Windows-WinRM%4Operational.evtx は、PowerShell リモート接続を含む、受信および送信 WinRM 接続を記録します。ログには、認証に使用されたユーザー名とともに、ソース (インバウンド接続) または宛先 (アウトバウンド接続) がキャプチャされます。この接続データは、PowerShell リモート処理を使用してラテラルムーブメントを追跡する際に役立ちます。理想的には、WinRM ログは、少なくとも 1 年間のデータを保存するのに十分なサイズに設定する必要があります。

PowerShell ログによって多数のイベントが生成されるため、組織はどのイベントをログアグリゲーターに転送するかを慎重に検討する必要があります。 PowerShell 5.0 を使用する環境では、組織は少なくとも、SIEM またはその他のログ監視ツールで、疑わしいスクリプトブロックのログイベント、EID 4104 をレベル「警告」で集約および監視することを検討する必要があります。これらのイベントは、最小限のデータセットを維持しながら侵害の証拠を特定する最良の機会を提供します。

付録

付録 A: モジュールのログには、 Invoke-Mimikatz PowerShell スクリプトの実行中に生成された 1 つのモジュールログイベントの内容が表示されます。
付録 B: スクリプトブロックロギングでは、 Invoke-Mimikatzスクリプトの実行中に生成された 1 つのスクリプトブロックロギングイベントの内容を示します。
付録 C: PowerShell Transcriptionには、 Invoke-Mimikatz の実行時に生成されるサンプルトランスクリプトが含まれています。

参考文献

Lee Holmes と Microsoft PowerShell チームに感謝します。

[1] Mandiant のコンサルタントである Matthew Dunwoody と Nick Carr による Shmoocon 2016 のプレゼンテーション「No Easy Breach」を参照して、PowerShell 攻撃を分析した経験に関する追加のコンテキストを確認してください: https://archive.org/details/No_Easy_Breach.

参照: https://www.mandiant.com/resources/blog/greater-visibilityt