残された攻撃の痕跡を追え！　～Post-Exploitationで起きていること～

先端技術部
エバンジェリスト　内山　史一    

こんにちは。先端技術部 エバンジェリストの内山です。

今回のコラムでは、Initial Access（初期侵入）以降の攻撃フェーズであるExecution（実行）、Credential Access（認証情報アクセス）、Lateral Movement（ネットワーク水平展開）が実行された際に、その存在を裏付ける痕跡を見つけるには、どのようなデータソースを確認すればよいか考えていきたいと思います。

MITRE ATT&CKで考えた際、Execution（実行）、Credential Access（認証情報アクセス）、Lateral Movement（ネットワーク水平展開）の各戦術には、多くのテクニックが存在します。ここでは、攻撃によく用いられる幾つかのテクニックに絞って、それらが実行された際の痕跡について見ていきます。

ちなみにFireEyeとMandiantが公開する年次レポートの「M-Trends 2021」[2]によると、2020年の侵害調査において、攻撃者が侵害を進めるためにPowerShellとリモート・デスクトップ（以下、RDP）をよく用いていることが明らかになっています。

これらを踏まえ、本コラムでは以下の表1に示すテクニックに絞ってご案内いたします。
なお、Credential Access（認証情報アクセス）については、定番のMimikatz[3]を使って、攻撃者がシステムのメモリから認証情報を窃取するといった前程にしております。

表1：Initial Access以降の攻撃によく用いられるテクニック（MITRE ATT&CK v9より）

Tactics	Technique : Sub-Technique	ID
Execution	Command and Scripting Interpreter：PowerShell	T1059.001
Credential Access	OS Credential Dumping: LSASS Memory	T1003.001
Lateral Movement	Remote Services: Remote Desktop Protocol	T1021.001

侵入後の攻撃の痕跡はどこに残されるのか

Command and Scripting Interpreter：
PowerShell (T1059.001)

アプリケーションとサービスログ > Microsoft > Windows > PowerShell > Operational

図1：イベントビューアーの閲覧結果（Powershell）

また、PowerShellが実行された結果は、図2のとおりPrefetchファイルとして記録されます。
前回のコラム(残された攻撃の痕跡を追え！　～初期侵入の痕跡が残るデータソース～)でもご案内した「WinPrefetchView」というツールを使って、Prefetchファイルを閲覧することができます。

 図2：Prefetchの閲覧結果（Powershell）

このように、PowerShellスクリプトの実行がないか調査する際は、このようなイベントログがないかご確認ください。

次に、攻撃者がLSASS(LSA Server Service)のメモリに保存されている認証情報にアクセスするパターンです。これは、内部に侵入した攻撃者が侵害範囲を広げるためにシステムの認証情報にアクセスし、管理者権限を取得するテクニックです。
本コラムでは、Mimikatzを使ってシステムの認証情報を窃取する前程としています。
図3はPowerShell版Mimikatzを実行した結果を表したものです。

 図3：PowerShell版Mimikatzの実行結果

PowerShell版Mimikatzが実行された痕跡はPowershell関連のWindowsイベントに残されます。イベントビューアーで確認する際は、以下をご確認ください。

アプリケーションとサービスログ > Microsoft > Windows > PowerShell > Operational
アプリケーションとサービスログ > Windows PowerShell
※PowerShell版Mimikatzを実行した検証環境の都合により、Windowsイベントのスクリーンショットを割愛しております。

監査ポリシーの追加設定やSysmon[4]を実装することによって、Mimikatzが残す更なる痕跡を確認することができます。詳細はJPCERT/CCの公開ドキュメントをご参照ください。[5]

こちらはLateral Movement（ネットワーク水平展開）でよく使われるRDPを利用する攻撃パターンです。Windows環境のクライアントやサーバーでは初期設定でRDP接続は許可されていませんが、システム運用・保守の関係でRDPを利用することが多いと思います。ただ、RDPが攻撃によく利用されているということは、本来不要なRDP接続を許可しているクライアントやサーバーが多いといった現状が考えられます。本コラムの冒頭で取り上げた「M-Trends 2021」[2]では、グローバルベースの侵害調査からRDPの悪用が多いとご案内しましたが、国内で発生した侵害事例においても同様の傾向が見受けられます。[6]

少し横道にそれましたが、RDPが実行された痕跡は、PrefetchファイルとWindowsイベントに残されます。具体的には以下のとおりです。

【接続元ホスト】
・Prefetchファイル
図4：Prefetchの閲覧結果（RDP-接続元ホスト）

・Windowsイベント
アプリケーションとサービスログ > Microsoft > Windows > TerminalServices-ClientActiveXCore > Microsoft-Windows-TerminalServices-RDPClient/Operational

図5：イベントビューアーの閲覧結果（RDP-接続元ホスト）

【接続先ホスト】
・Windowsイベント
アプリケーションとサービスログ > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational
 図6：イベントビューアーの閲覧結果-1（RDP-接続先ホスト）

アプリケーションとサービスログ > Microsoft > Windows > TerminalServices-RemoteConnectionManager > Operational
 図7：イベントビューアーの閲覧結果-2（RDP-接続先ホスト）

先程のMimikatz同様、監査ポリシーの追加設定やSysmon[4]を実装することによって、RDPが残す更なる痕跡を確認することができます。詳細はJPCERT/CCの公開ドキュメントをご参照ください。[5]

ここまで、ホストに残る痕跡について見てきましたので、最後にネットワークトラフィックに残る痕跡についても少しだけ触れたいと思います。攻撃者は初期侵入後に、マルウェアに感染させたホストを足掛かり、C&Cサーバーと通信し更なる侵害範囲の拡大を試みます。

C&C通信の痕跡は、一般的にはFW、IDS/IPS、Proxy、DNSのログに記録されています。次世代FWやIDS/IPSによるC&C通信の検知に頼りきるのも良いのですが、ここではThreat Huntingの観点より、能動的にC&C通信の疑いのあるものを探すことを前提に考えてみます。

例えば、Proxyのログより、C&C通信の痕跡を探す際の観点は以下のとおりです。[7]
(1) CONNECTメソッドで、80番・443番以外のポートへの通信が発生していないか
(2) 標準とは異なるUser-Agentによる通信が発生していないか
(3) 定期的に外部のサーバーと通信が発生していないか
(4) 業務時間外に通信が発生していないか
(5) 外部に大量のデータを送る通信が発生していないか

上記はいずれも、基本的には通常とは異なる点がないかという観点になります。
なお、(2)(3)(4)については、検知回避を目的に攻撃者が偽装し、通常の通信のようにみせている可能性があることは留意すべきです。

例えば、図8はペネトレーションテストツールでAgent（クライアント）と通信するListeners（C&C）のオプションを設定する画面ですが、検知回避するために以下のようなオプション設定があります。
・WorkingHours：9:00～17:00の間で通信する時間帯の設定
・DefaultProfile：URLパス、User-Agentの設定
・DefaultJitter：Agentとの通信間隔のゆらぎを設定

図8：ペネトレーションテストツールのオプション設定（画面はPowerShell Empire）

近年のWebトラフィックの殆どがSSL/TLSで暗号化される中、C&C通信の暗号化も当たり前のようになってきました。暗号化されたネットワークトラフィックを復号化しない限り、IDS/IPS等のセキュリティ機器による不正通信の検知ができないといった問題があります。

では、Threat Huntingによるネットワークトラフィックの調査は意味がないかというと、実はそうでもありません。ネットワークトラフィックが暗号化されていても、ドメインやIP、証明書、通信量等、少なからず調査に有用なメタデータを得ることができるのです。
そうです。Threat Hunting にとってネットワークトラフィックは、まだまだ調査に不可欠なデータソースなのです。

さて、次回のコラムがThreat Huntingを扱ったテーマとしては最後の予定です。
今までのまとめや、Threat Huntingで利用するツールについてご案内しようと考えています。

セキュリティ、おもしろいですね。
それでは、次のエントリーでお会いしましょう！

脚注および参考情報
[1] MITRE：ATT&CK
[2]FireEye：M-Trends 2021
[3] MITRE：ATT&CK > Software > Mimikatz
[4]Microsoft：Sysmon
[5]JPCERT/CC：インシデント調査のための攻撃ツール等の実行痕跡調査に関する報告書（第2版）公開（2017-11-09）
[6]Secureworks：日本国内で増加する 標的型ランサムウェアインシデント
[7] JPCERT/CC：高度サイバー攻撃への対処におけるログの活用と分析方法

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。