【実務・中級編】 メモリダンプからのパスワードおよび認証トークンの抽出(Mimikatz手法の検知) – インシデントレスポンス & フォレンジック(DFIR)防御ガイド

なぜ「lsass.exe」はハッカーにとっての宝の山なのか?メモリフォレンジックの最前線から

現場で侵害調査をしていると、攻撃者が侵入後に必ずと言っていいほど行う動作があります。それが「認証情報の窃取」です。彼らはシステムを破壊することよりも、まずはその環境の「鍵」を盗むことに全力を注ぎます。その最大の標的となるのが、Windowsの認証プロセスである lsass.exe(Local Security Authority Subsystem Service)です。

今日は、Mimikatzのようなツールがメモリ上のどこを突き、我々がどうやってその「毒」を検知・封じ込めるべきか、その泥臭い実務の話をしよう。

1. 攻撃者が狙う「盲点」:認証情報の溜まり場

lsass.exe は、ユーザーのログイン、パスワード変更、アクセス制御を司る心臓部です。Windowsは利便性のために、一度ログインしたユーザーの資格情報(NTLMハッシュやKerberosチケット)をメモリ上に保持し続けます。

攻撃者は lsass.exe のプロセスに不正にアクセスし、メモリダンプを採取するか、あるいは直接メモリを読み取って認証情報を引き抜きます。これが「Mimikatz」がやっていることの本質です。一度これが成功すれば、攻撃者はそのユーザーになりすまし、横展開(Lateral Movement)を開始します。

2. メモリフォレンジックで痕跡を追う

インシデント発生時、私たちはまずメモリダンプを採取します。Volatility Framework を使えば、何が起きたか一目瞭然です。

例えば、lsass プロセスに対して lsadump や sekurlsa といったモジュールが使われた痕跡を探す際、私たちは以下のプラグインを多用します。

  • windows.lsadump: メモリ上のパスワードハッシュを抽出する痕跡を追う
  • windows.malfind: lsass.exe 内に注入された不審なコード(DLLなど)がないかを確認する

もし lsass.exe のメモリ領域に対して、不自然な ReadProcessMemory APIの呼び出しや、権限の昇格(SeDebugPrivilege)が確認されたなら、それは既に手遅れに近い状態です。

3. 「そもそも盗ませない」ための防御戦略

「メモリから抜かれるなら、抜かれないようにすればいい」というのが結論です。現代のOSにおける防御の要は Credential Guard です。これは仮想化技術(VBS)を用いて lsass.exe を隔離し、たとえ管理者権限を持った攻撃者であってもメモリを直接読み取れないようにする仕組みです。

【設定】グループポリシー(GPO)によるCredential Guardの強制適用

この設定を適用するだけで、Mimikatzによるハッシュ抽出は無効化されます。

[設定手順]
1. コンピュータの構成 > 管理用テンプレート > システム > Device Guard を開く
2. 「仮想化ベースのセキュリティを有効にする」を「有効」に設定
3. 「構成」オプションで「Secure Launch」および「Credential Guard」を選択
4. 「再起動」を強制する

4. 開発者が意識すべき「横展開」の阻止

Webアプリ開発者が意識すべきは、サーバー上の認証情報をなるべく「使い捨て」にする設計です。もしあなたのWebサーバーが、ドメイン管理者権限で動くサービスアカウントでDBに接続していたら、それは攻撃者にとって「最高のごちそう」です。

【実装】最小権限でのDB接続(PHP + PDOの例)

Webアプリケーションは、特定のテーブルのみにアクセス可能な限定的権限を持つユーザーで運用すべきです。

<?php
// 環境変数からDB情報を読み込む(ハードコードは絶対NG)
$host = getenv('DB_HOST');
$db   = getenv('DB_NAME');
$user = getenv('DB_APP_USER'); // 管理者ではなく、限定権限ユーザーを使用
$pass = getenv('DB_APP_PASS');

try {
    // 接続時に必要最小限の権限のみを持つユーザーで認証する
    $dsn = "mysql:host=$host;dbname=$db;charset=utf8mb4";
    $pdo = new PDO($dsn, $user, $pass, [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        // SQLインジェクション防止のためにプリペアドステートメントを強制
        PDO::ATTR_EMULATE_PREPARES => false, 
    ]);
} catch (PDOException $e) {
    // エラー詳細を画面に出さない(攻撃者にヒントを与えない)
    error_log($e->getMessage());
    die('データベース接続に失敗しました。');
}
?>

最後に:セキュリティは「性悪説」で構築せよ

攻撃者は、OSが提供する便利な機能(LSASSのキャッシュやデバッグ機能)を悪用します。「まさか自分の環境でそんなことが」という油断が、最大の脆弱性です。

  • Credential Guardの有効化は必須
  • 不要な特権(SeDebugPrivilegeなど)をユーザーから剥奪する
  • EDR(Endpoint Detection and Response)を導入し、lsass.exe へのアクセスを監視する

現場で手を動かす君たちへ。技術は常に攻撃者に先回りされるものだが、防御のロジックさえ堅牢であれば、被害を最小限に抑え込むことは可能です。まずは自分の担当しているサーバーで、Credential Guardが有効になっているか、今すぐ確認することから始めてみてください。それが、インシデントレスポンスの第一歩です。

コメント

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