トラブルシューティングや開発を目的として設計されたレジストリ設定は、Autorunsなどのセキュリティツールでは検出されにくいという特性から、現在では隠蔽された永続化手段として利用されています。 ここでは、「Trace」や「Detect」を含むTaniumモジュールを活用し、この比較的知られていない永続化メカニズムの存在を迅速に特定するための3つの主要な方法をご紹介します。
（画像：Bruno Glätsch / Pixabay）
Twitterで一夜にして新しい永続化手法が報告されているのを見かけたら、どうしますか？ 一つのアイデアとして、Taniumを活用して現在の活動状況を素早く確認し、何かが発生した際に迅速にアラートが通知されるよう設定することをお勧めします。 すべて朝食の前です。
4月10日において、Oddvar Moe氏（@oddvarmoe）がTwitterで自身のブログ記事「 Persistence Using Globalflags in Image File Execution Options – Hidden from autoruns.exe」を共有しました。この記事では、レジストリ設定を用いた永続化メカニズムについて解説しており、これにより、監視対象のプロセスが終了した後も、別のプロセスが静かに実行される仕組みとなっています。 この方法は、現在、MicrosoftのSysinternals Autorunsによって列挙される保存先には含まれていません。
グローバルフラグを使用することで、開発者は、あるプロセスが終了した後に別のプロセスを起動することができるようになります。 Autoruns ではこれらの設定が列挙されないため、これは現時点での見落としポイントとなっています。 これらは、Microsoftの開発者向けツールに含まれるユーティリティ「gflag.exe」を使用して設定するか、管理者アカウントでレジストリを変更することで設定できます。
トラブルシューティングや開発作業のためにそのマシンが使用されている場合を除き、これらのレジストリ設定が存在することは極めて不審なため、調査を行う必要があります。 これについては以下で説明いたしますが、これは、新たに明らかになった詳細情報をいかに迅速に活用して、ご自身の環境を評価できるかを示す事例となります。
ここでは、Trace や Signals を含む Tanium モジュールを活用し、この比較的知られていない持続化メカニズムの存在を、以下の 3 つの主要な方法で迅速に特定する方法についてご紹介します：
- レジストリ設定の現在の状況を確認することで；
- Trace を使用してレジストリの変更履歴を調べることで、そして；
- 今後、これらのレジストリ設定に変更があった場合に、リアルタイムでアラートを発信する仕組みを構築することで。
この問題について
Moeさんのブログ記事では、監視対象のプロセスが終了するたびに別のプロセスを起動する実行トリガーを設定するための、3つのレジストリ変更について指摘されています。 さらに、監視対象のプロセスが終了すると、2つ目のプロセスが黙って起動されます。 つまり、グラフィカルインターフェースがある場合、それはバックグラウンドで起動します。 攻撃者は、この機能を利用して持続性を維持することができます。つまり、任意のプロセスが終了した後も、レジストリキーが削除されるまで、自身のコードを実行し続けることができるのです。
この Windows 機能の詳細については、Microsoft のドキュメント（ ）およびこちらのページ（）に記載されています。
テストのため、以下のスクリプトでは、notepad.exe が終了するたびに evil.exe が実行されるようにレジストリを変更します。
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe” /v GlobalFlag /t REG_DWORD /d 512 reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe” /v ReportingMode /t REG_DWORD /d 1 reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe” /v MonitorProcess /d "C:\temp\evil.exe"
現在の活動
Taniumを利用すれば、企業全体でこの手法がすでに導入されている兆候を探ることができます。
一部の環境では、この手法に正当な用途がある可能性もありますので、既存の設定が悪意のあるものか、あるいは無害なものかを判断するために、慎重な検証を行う必要があります。 まず、レジストリの「SilentProcessExit」ハイブを探してみるのが一つの手です。 ほとんどの環境では、このキーは空であるか、存在しないはずです。 この調査では、3つのセンサーが使用されます：
- レジストリキーのサブキー - 終了時に実行がトリガーされるプロセスが表示されます。 以下の図1では、SilentProcessExitの下にあるサブキーとして「notepad.exe」のみが表示されています。
- レジストリキーの値の名前 - どのサブキーが存在するかを示しています。 図1には、レジストリ値名として「MonitorProcess」と「ReportingMode」の2つのエントリが示されています。
- レジストリの値データ - このデータは、監視対象のプロセスが終了した際に起動するように設定されているプロセスを示しています。 図1には、2つのエントリに関するデータが示されています。
図1：本記事のテストに使用したエントリの例です。
以下の図 2では、「Tanium レジストリキーのサブキー」センサーにより、SilentProcessExit キーの下にある notepad.exe のサブキーエントリが表示されています。
図 2：レジストリキーのサブキーセンサーを使用して「SilentProcessExit」を検索する様子。
センサー：すべてのマシンにおけるレジストリキーのサブキー レジストリキーのサブキー [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit]
「レジストリキーのサブキー」センサーによって返されたサブキーについては、調査担当者は「KeyPath」の値をコピーし、それを「レジストリキーの値名」センサーのパラメータとして使用して、「MonitorProcess」エントリが存在することを確認する必要があります（図 3を参照）。 MonitorProcess エントリが存在する場合、ReportingMode エントリも存在している必要があります。
図 3：サブキーの検出に使用されるレジストリキーの値名「sensor」。
センサー：レジストリキーの値名 すべてのマシンからのレジストリキーの値名 [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe]
特定の「MonitorProcess」エントリに対してどのプロセスが実行されるかを特定するには、「レジストリキーのサブキー」センサーの出力から得られる「KeyPath」値と、「レジストリキーの値名」センサーの出力から得られる「値名」の両方を、「レジストリ値データ」センサーのパラメータとして指定する必要があります（図 4を参照してください）。
図 4：レジストリ値データセンサーの出力。
センサー：レジストリ値のデータ すべてのマシンからのレジストリ値のデータ [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe,MonitorProcess]
センサー出力から取得した「KeyPath」と「Value Name」を「Registry Value Data」センサーのパラメータとして指定すると、図 4に示すように、この「MonitorProcess」に関するデータエントリ（ディスク上のプロセスの保存先パスを含む）を確認できます。
また、図 4 では、代替データストリーム（ADS）内にプロセスのバイナリを隠蔽した例も確認できます。 ADSはNTFSファイルシステムの機能の一つであり、攻撃者はこれを利用してバイナリファイルを埋め込むことで、Windowsエクスプローラーや、cmd.exeおよびPowerShell.exeによる通常のディレクトリ一覧表示ではそのファイルが検出されないようにすることができます。 プロセスのバイナリ名に含まれる「:」にご注目ください。
この隠し実行ファイルは、C:\Windows フォルダまたは NTFS ディレクトリエントリ内に埋め込まれており、「cmd.exe」という名前が付けられています。
これまでの活動
Taniumのセンサーを使用すれば、数十万台に及ぶエンドポイント全体にわたって、これらの特定のレジストリの場所をわずか数秒で検索することが可能です。
しかし、最初の活動の後でレジストリエントリが削除されてしまった場合はどうなるのでしょうか？ 上記の「現在の状態」を示すセンサーは表示されません。 企業全体の履歴データを検索するために、Tanium Traceのデータを用いてレジストリを確認してみましょう。
まず、SilentProcessExit レジストリキーを確認し、SetRegistryKey イベントが記録されているかどうかを調べます（図 5 を参照してください）。
図 5：値センサーの出力に関するレジストリキーのトレース。
センサー：レジストリキーまたは値のトレース すべてのマシンからレジストリキーまたは値のトレースを取得します[無制限, 1523639748493|1523643347493, 0, 0, 10, 0, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit, , SetValueKey, , , ]
「key」列には、その実行ファイルが終了した際に、MonitorProcess 実行ファイルが起動するように設定されたエントリが含まれています。 展開されたキーの列データは以下の通りです： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe
Traceは値データを記録しないため、この時点では、あるプロセスが別のプロセスを起動するように設定されていたことは分かりますが、そのプロセスがどこにあるのかは分かりません。 ただし、「Trace」を介してライブ接続を開き、確認することは可能です。
アラート
Tanium Detect Signal は、企業の現在の状態や履歴データを検索するだけでなく、これらのレジストリキーが前述の方法で設定されている場合に、リアルタイムのアラートを発信することができます。
group(Registry.key_path に '\\SilentProcessExit\\' が含まれ、かつ Registry.value_name に 'MonitorProcess' が含まれるもの)
このシグナルをデプロイすると、いずれかのプロセスが「MonitorProcess」エントリを作成して「SilentProcessExit」キーの下に永続化を設定するたびに、Tanium Detect インターフェースでリアルタイムのアラートが発火し、これらのアラートは SIEM や通知システムに転送することができます。
他の Tanium Detect アラートと同様に、アラートを選択して「Trace Live Connection」に切り替えることで、そのアクティビティをさらに詳しく調査することができます（図 6 を参照してください）。 ここでは、プロセスアクティビティについて詳しく見ていきます。 このケースでは、悪意のあるプロセスが再びADSとして埋め込まれていますが、今回はC:\Systemディレクトリのエントリ内に埋め込まれています。
図 6：アラート表示と、Traceとのライブ接続を確立するオプション。
次に、Trace のプロセスツリービューが表示されます（図 7 を参照してください）。 なお、この悪意のあるプロセスの親プロセスは、Windows エラー報告サービスである WerFault.exe です。 また、この悪意のあるプロセスは、SYSTEM としてではなく、同じユーザーアカウントのコンテキストで起動される点にもご留意ください。
図 7：Traceにおけるプロセスの可視化。
プロセスハッシュが赤色で強調表示されており、これはTanium Reputationサービスがこのファイルを悪意のあるものとして分類したことを示しています。
それでは、ハッシュ値とファイルの詳細情報を基に、Tanium Protect へ移行し、このプロセスの今後の実行をブロックすることができます。 また、標準のTaniumアクションを使用して、レジストリのクリーンアップや、実行中のプロセスの強制終了を行うこともできます。
シグナルの例
以下に、この永続化メカニズムを有効にするさまざまな方法に対応する「Tanium Detect Signal」のアラートが示されています（図 8-13を参照）。
図 8：バッチファイルを使用してMonitorProcessエントリを追加する際の警告メッセージ。
図 9：バッチファイルを使用してGlobalFlagエントリを追加する際の警告メッセージ。
図 10：Regedit.exeのGUIを使用して「MonitorProcess」エントリを手動で追加する際の警告メッセージ。
図 11：PowerShellを使用してレジストリを変更する際の警告メッセージ。
図 12：設定変更が反映されたレジストリファイル。
図 13：図 12 のレジストリファイルをマージしたところ、このアラートが表示されました。
もう一点、補足です。 IOCアラートが表示されると、図 14に示すように、ハッシュカラーによる強調表示を含むADSが詳細ビューに表示されます。
図 14：ハッシュ値に基づいて、バイナリファイルに対してIOCスキャンがヒットしました。
サマリ
本記事で解説するプロセスでは、Taniumがレジストリ設定の現在の状態を確認し、Traceを使用してレジストリ変更の履歴を調査し、最終的にこれらのレジストリ設定に対する今後の変更に対してリアルタイムのアラート設定を行うことで、比較的知られていない永続化メカニズムの存在を迅速に特定する方法を示しています。 さらに詳しく知りたい方は、ぜひ「 」（）や「Tanium User Community」（）、および「 」にご参加いただき、一緒に話し合いましょう。
Taniumの実際の動作をご覧になりませんか？ の個別デモをご予約いただくか、毎週開催されているウェビナーにご参加ください。 「 」の今後のイベント（）にて、当社のTaniumエキスパートにご相談ください。
著者「」について：スコット・ランゲンドルフ氏は、Tanium EDRチームのディレクターを務めています。 彼は、国家主体のグループによる攻撃を受けていたあるグローバルなエンジニアリング企業でシニアマネージャーを務めた後、 2015 年の秋にタニウムに入社しました。 サイバーセキュリティ分野で8年の経験を持つスコット氏は、防御チームや脅威ハンティングチームにとって、エンドポイントの迅速な可視化、アラート機能、およびデータの俊敏性が重要であることを認識し、セキュリティ製品のさらなる発展に貢献するため、Taniumに入社しました。 また、NASAでは国際宇宙ステーションの電力システムに携わったほか、 APT1 が発見されたばかりの頃には、エネルギー分野でITマネージャーとして勤務していました。
