LSASSという名の「パンドラの箱」：なぜWindowsは平文認証情報をメモリに保持し続けるのか
インシデントレスポンスの現場で、ランサムウェアの初期侵入からラテラルムーブメント（横展開）に至るタイムラインを再構築しているとき、最も絶望的な瞬間はいつか。それは、ドメインコントローラーや重要サーバーのメモリフォレンジック解析において、攻撃者が最初の踏み台を踏み破った直後に lsass.exe のプロセスダンプを取得し、数秒で特権管理者の平文パスワードやKerberosのTGT（Ticket Granting Ticket）を回収している痕跡を見つけた時だ。
Local Security Authority Subsystem Service (lsass.exe) は、Windowsセキュリティモデルの心臓部である。ユーザーのログオン検証、パスワード変更の強制、アクセス権の監査など、OSのセキュリティ境界を担保するすべての責務を負っている。しかし、このプロセスが抱える最大の構造的欠陥、そして攻撃者にとっての「エルドラド」は、認証プロトコル（NTLMやWDigestなど）の仕様上、あるいはレガシーな互換性の維持のために、クリアテキスト（平文）に近い形式の認証情報をメモリ上にキャッシュし続けざるを得ないという点にある。
本稿では、Mimikatzに代表されるツール群が、どのようにしてこのOSの核心を突くのかという低レイヤのメモリ挙動を解剖し、現代のWindowsアーキテクチャにおける究極の防衛策である「Credential Guard」の内部動作と、それを突破しようとする攻撃者の最新の暗闘について、現場の知見を交えて深く掘り下げていく。
—
Mimikatzのメカニズム：OpenProcess からセッション鍵の復元まで
攻撃者がリモートコード実行（RCE）の足がかりを得た後、最初に行うのはほぼ間違いなく「特権昇格（Privilege Escalation）」と「クレデンシャル・ダンピング」だ。Benjamin Delpy氏が開発したMimikatzは、単なるハッキングツールというよりも、Windowsのセキュリティサブシステムの脆弱な設計をあえて具現化した「教育的かつ破壊的な鏡」である。
LSASSからパスワードを抽出するプロセスは、大まかに以下の4つのステップで構成されている。
1. 特権の獲得: プロセスをオープンするためには、SeDebugPrivilege（デバッグ特権）が必要になる。Local System権限で動作していればデフォルトで保持しているが、管理者権限であってもこの特権を有効化（Enable）する必要がある。
2. プロセスハンドルの取得: Windows APIの OpenProcess を呼び出し、PROCESS_VM_READ および PROCESS_QUERY_INFORMATION 権限で lsass.exe へのハンドルを取得する。
3. メモリ空間の走査 (MiniDumpW / 自前パーサー): MiniDumpWriteDump APIを悪用してLSASSのプロセスイメージをごっそりファイルに書き出すか、あるいは独自のドライバやメモリ読み取りルーチンを用いてヒープ領域を直接スキャンする。
4. WDigest/SSPのパース: メモリ上にロードされている認証サポートプロバイダー（SSP）のモジュール（例：wdigest.dll や tspkg.dll）の内部構造体を走査し、暗号化されていない（あるいは弱い難読化が施されただけの）構造体から平文パスワードを復元する。
例えば、WDigestプロトコルは、初期のWindowsにおいてHTTPダイジェスト認証をサポートするために設計されたが、ここに保持されるパスワードは、かつては完全に平文でメモリ上に常駐していた。Microsoftはパッチ（KB2871997）を当ててデフォルトで平文キャッシュを無効化（UseLogonCredential レジストリを 0 に設定）したが、攻撃者は依然としてメモリ上のスクランブル解除や、Kerberosのセッション鍵（Ticket Encryption Key）を強奪してゴールデンチケット（Golden Ticket）攻撃の踏み台に利用し続けている。
—
脆弱性の根本原因：なぜEDRはLSASSへのアクセスを防ぎきれないのか
現代のエンドポイントセキュリティ（EDR / XDR）製品は、OpenProcess の呼び出しを監視し、lsass.exe に対して不審なアクセス試行（特に PROCESS_VM_READ 権限を要求するもの）を検知・ブロックするように設計されている。しかし、攻撃者も進化している。APIフックのバイパス、ダイレクトシステムコール（Direct System Calls）、さらにはカーネルモードドライバを用いたBYOVD（Bring Your Own Vulnerable Driver）攻撃によって、EDRの監視をすり抜けてLSASSのメモリに到達する手法が横行している。
低レイヤのメモリ挙動として、LSASSプロセスはプライベートな仮想アドレス空間上に巨大なヒープを構築している。そこに格納されるNTLMハッシュやKerberosの事前認証データ（Pre-authentication Data）は、暗号化されておらず、単にアクセス制御リスト（ACL）によって保護されたプロセス境界の向こう側に置かれているに過ぎない。つまり、「管理者権限＝LSASSメモリへの無制限のアクセス権」というWindowsの長年の設計思想そのものが、この問題の根本原因なのだ。
—
究極の防衛策：Credential Guardのアーキテクチャ設計
この構造的欠陥に対するMicrosoftの回答が、Virtualization-Based Security (VBS) を活用した Credential Guard である。
従来のWindowsでは、OSカーネル（Ring 0）がすべてのセキュリティ境界を管理していたため、カーネルが一旦侵害されると（ブルースクリーンやドライバ脆弱性を通じた特権昇格など）、LSASSのメモリを守るものは何もなかった。しかしVBSは、ハイパーバイザー（Hyper-V）の技術を利用して、OSカーネルよりもさらに一段低い特権レイヤ（Virtualization Secure Mode: VSM）を構築する。
仮想化ベースのセキュリティ（VBS）と分離
Credential Guardを有効化すると、認証情報の検証や秘密鍵の管理を行うLSASSのコンポーネント（厳密には lsaiso.exe として分離されたアイソレーションプロセス）は、通常のWindowsカーネルから完全に隔離されたセキュアエルクレーブ（Secure Kernel）内で実行される。
+-------------------------------------------------------+
| Normal World |
| [ User Mode ] (Apps, 일반 프로세스, 일부 EDR) |
| | |
| [ Ring 0 Kernel ] (Windows OS Kernel) |
+--------|----------------------------------------------+
| (Hypervisor Enforcement / SLAT)
+--------|----------------------------------------------+
| v Secure World (VSM) |
| [ Secure Kernel ] |
| | |
| [Isolated LSA / LsaIso.exe] <--- (LSASSの秘密情報を保護) |
+-------------------------------------------------------+仮に攻撃者がローカル管理者権限を取得し、さらにカーネルレベルの脆弱性をついてRing 0のコード実行権限を手に入れたとしても、ハイパーバイザーによって保護されたSecure World内のメモリ領域（lsaiso.exe が保持するNTLMハッシュやKerberosチケット）にアクセスすることは物理的（論理的）に不可能になる。Mimikatzを実行しても、返ってくるのは空のデータかエラーのみだ。
—
実務で直結する：Credential Guardの有効化と監査設定
セキュリティアーキテクトやテックリードがインフラ構築時に必ず担保すべきなのは、このCredential Guardを単に有効化するだけでなく、「確実に機能していること」を監査・維持する体制の構築である。
以下のPowerShellスクリプトを用いて、現在のシステムでVBSおよびCredential Guardが正しく稼働しているかを検証し、グループポリシーまたはIntuneで強制する設定を行う。
1. 状態の確認（インシデント前後の監査用）
# Windowsのデバイスガード（Device Guard / VBS）の稼働状態を低レイヤから取得する
$SystemInfo = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
[PSCustomObject]@{
"VirtualizationBasedSecurityStatus" = switch ($SystemInfo.SecurityServicesRunning) {
1 { "VBS稼働中" }
default { "VBS停止または無効" }
}
"CredentialGuardRunning" = if ($SystemInfo.SecurityServicesRunning -contains 1) { "有効" } else { "無効" }
} | Format-List2. レジストリおよびグループポリシーによる強制設定
物理的なハードウェア要件（Secure Boot、IOMMU / SLAT対応CPU、TPM 2.0）を満たしている前提で、レジストリを介して強制的にCredential Guardを有効化する設定スクリプト（インフラ構成管理ツールへの組み込みを想定）。
# デバイスガードおよびCredential Guardの有効化レジストリ設定
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard"
if (!(Test-Path $RegPath)) {
New-Item -Path $RegPath -Force | Out-Null
}
# VBSを有効化 (1: 有効, 0: 無効)
Set-ItemProperty -Path $RegPath -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord
# Credential Guardを有効化 (1: UEFIロック付きで有効, 2: UEFIロックなし)
Set-ItemProperty -Path $RegPath -Name "RequireSecurityCriteria" -Value 1 -Type DWord
Set-ItemProperty -Path $RegPath -Name "LsaCfgFlags" -Value 1 -Type DWord # LSASSのプロセス保護（PPL）の強制
Write-Host "[*] Credential GuardおよびLSA保護の設定が完了しました。変更を適用するにはシステムの再起動が必要です。" -ForegroundColor Green—
運用上の盲点：LSA保護（PPL）とサードパーティドライバの罠
ここで一つ、実務における現場の知見を共有しておこう。Credential Guardの導入ハードルが高い環境（古いレガシーアプリケーションが稼働している、特殊なハードウェアドライバを使用している等）において、次善の策として LSA保護（RunAsPPL: Protected Process Light） を有効化することがある。
LSA保護を有効にすると、lsass.exe は「保護プロセス」として起動されるため、たとえAdministrator権限であっても、通常のプロセスからの OpenProcess によるハンドル取得が拒絶される。しかし、ここに大きな罠がある。
「署名の古いサードパーティ製ドライバ」がシステムに存在する場合、LSA保護やCredential Guardと競合し、最悪の場合OSが起動不能（BSODループ）に陥るか、あるいはセキュリティ機能そのものが自動的に無効化される。
攻撃者はこの挙動を知り尽くしており、脆弱性を持つ正当な署名済みドライバ（前述のBYOVD）を持ち込んでセキュリティ製品のカーネルフックを無効化し、強制的にLSA保護のコンテキストを解除してからLSASSをダンプするという高度な手法をとる。したがって、DFIRの現場では、単にレジストリで設定を行うだけでなく、メモリ整合性（Memory Integrity / HVCI）が正常に機能しているかをイベントログ（Event ID 12 または System Guardの診断ログ）で常時監視し続けるアーキテクチャが不可欠となる。
—
結びにかえて
LSASSからの暗号鍵・パスワード抽出という脅威は、単なる「マルウェア対策ソフトの検知率の問題」ではない。それはOSのアーキテクチャの歴史的負債と、特権管理の境界線における根本的な設計思想の戦いである。
私たちセキュリティエンジニアが目指すべきは、エンドポイントの検出（Detection）だけに依存する脆弱な防衛ではなく、VBSとCredential Guardを土台とした「侵害を前提としたゼロトラスト・アーキテクチャ」の強制である。攻撃者がどれだけ洗練されたメモリダンプ手法を持ち込もうとも、ハードウェアとハイパーバイザーによって保護された領域には一歩も足を踏み入れられない――そんな堅牢な要塞を構築することこそが、現代のインシデントレスポンスにおける究極のゴールなのだ。
コメント