【テクニカル・上級編】 SMBプロトコルにおける横展開(Lateral Movement)の痕跡抽出 – インシデントレスポンス & フォレンジック(DFIR)防御ガイド

境界防御の終焉:SMB横展開という「死角」をメモリフォレンジックで暴く

境界防御が形骸化し、EDRがアラートの嵐で麻痺する現代において、攻撃者が最も好む「静かなる横展開」の主戦場は依然としてSMB(Server Message Block)だ。攻撃者は新しいエクスプロイトなど使わない。彼らは管理者権限が許容する正規のプロトコルを悪用し、正規のツールを走らせる。

PsExecによるサービスインストールやWMI(Windows Management Instrumentation)によるリモート実行は、ログ上では「いつもの管理作業」に擬態する。しかし、カーネルメモリの深層には、彼らがどれだけ隠蔽しようとも消せない「物理的な足跡」が残る。今回は、この泥沼のインシデントハンドリングを技術的視点から解剖する。

1. 攻撃者がSMBを「愛する」理由:プロトコル仕様の暗部

PsExecが用いるsvcctlパイプや、WMIが利用する135/tcp(RPC)およびランダムな動的ポートは、ネットワークトラフィックの相関分析において極めてノイズになりやすい。

攻撃者は、ターゲットのADMIN$共有に対してサービス実行バイナリを書き込み、CreateServiceを呼び出す。この際、SMBのネゴシエーション段階で、古いNTLM認証や署名なしのパケットを強制させる攻撃(SMB Relayなど)が組み合わされることが多い。

アーキテクトとして注目すべきは、「SMBセッションが確立された際のセッションキーのメモリ常駐」だ。Volatility 3等を用いてメモリダンプを解析する際、単にネットワーク接続を見るだけでは足りない。handlesプラグインで\Device\LanmanRedirectorをハンドルしているプロセスを抽出し、そこから攻撃者が注入した悪意のあるスレッドの入り口を探る必要がある。

2. メモリフォレンジックで特定する「PsExecの痕跡」

PsExecが実行される際、リモートホストのメモリ上には必ずと言っていいほど、以下のアーティファクトが刻まれる。

1. PSEXESVC.exeの痕跡: サービスとして登録されたバイナリのメモリ内イメージ。
2. 名前付きパイプの通信: \pipe\psexecという文字列が、カーネルオブジェクトのメモリ領域に浮遊する。

これを特定するためのVolatility 3でのアプローチ例を以下に示す。

# 特定のプロセスが保持している名前付きパイプを列挙する(攻撃者が作成したパイプを特定)
python3 vol.py -f memory.dmp windows.handles --pid [PID] | grep "Pipe"

# サービスとしてロードされた不審なDLLやバイナリのメモリマッピングを確認
python3 vol.py -f memory.dmp windows.ldrmodules --pid [PID]

ここで重要なのは、単にバイナリ名を見るのではなく、メモリ上のバイナリとディスク上のバイナリのハッシュ値を比較(またはmalfindによるインジェクション検知)することだ。攻撃者は正規のPsExecをリネームして使うこともあれば、メモリ内だけで完結するファイルレス手法を採用することもある。

3. 監査と防御のアーキテクチャ:ガードレイルの設計

インシデント発生時に「痕跡を抽出する」のは最後の手だ。真のアーキテクトは、横展開を物理的に阻害する構造を設計する。

A. 認証の強化:SMB署名と暗号化の強制

GPO(グループポリシー)において、以下の設定を徹底すること。これができていない組織は、横展開に対して無防備と言える。

  • Microsoft ネットワークサーバー: 通信にデジタル署名を行う (常に): 有効化
  • Microsoft ネットワークサーバー: 通信にデジタル署名を行う (クライアントが同意する場合): 無効化

B. EDRのフックを回避する攻撃への対抗

攻撃者は最近、NtCreateThreadExなどの低レイヤAPIを直接呼び出し、EDRのフックをすり抜ける。これに対抗するには、AMSI(Antimalware Scan Interface)のメモリバッファの動的解析が不可欠だ。

# PowerShellスクリプトの実行をメモリレベルで監視・ブロックする設定
Set-MpPreference -DisableScriptScanning $false
# 高度なメモリ監査を有効にする
Auditpol /set /subcategory:"Kernel Object" /success:enable /failure:enable

結論:ログの先にある「真実」を見る

インシデントレスポンスの現場では、SIEMに出力されるログはあくまで「事象の要約」に過ぎない。PsExecがどのパイプを使い、どの権限でSMBセッションを確立したか。その背後にあるカーネルメモリの動的な変化こそが、攻撃者の思考をトレースする唯一の手段だ。

耐量子暗号(PQC)の時代が到来すれば、現在のSMBの暗号化方式(AES-GCM/CCM)もいずれは危殆化する。その時、我々が守るべきは「通信の秘匿性」だけでなく、「プロトコル処理そのものの整合性」だ。

メモリフォレンジックは、単なる事後調査ツールではない。それは、OSの深層で何が起きているかを証明する「デジタルな顕微鏡」である。この技術を使いこなせるかどうかが、侵害を早期に収束させるか、あるいは組織全域にランサムウェアを蔓延させるかの分水嶺となる。

次のインシデントが起きたとき、ログを見終わった後に「メモリダンプを解析しよう」という選択肢が即座に出るか。それが、君がプロフェッショナルであるかどうかの試金石だ。

コメント

タイトルとURLをコピーしました