LSA ProtectionとCredential Guardとは？Pass-the-Hashが通じにくくなった理由を解説

「MimikatzでLSASSからハッシュを取ろうとしたら失敗した——なぜ？」

AD演習やペネトレーションテストの学習をしていると、こういう疑問にぶつかることがあります。数年前は通用していた手法が、今のWindows 11環境では通じなくなっている。その理由がLSA ProtectionとCredential Guardです。

本記事では「なぜハッシュ取得が難しくなったのか」を防御側の仕組みから解説します。攻撃手法の解説ではなく、Windowsがどうやって認証情報を守っているかを理解することが目的です。

KerberoastingやDCSync、Pass-the-Hashの仕組みについては「AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る」で詳しく解説しています。

lsassとは

lsassとは——Windowsの認証情報を一手に管理するプロセス

lsassとは、Windowsのログオン認証を処理し、認証情報をメモリ上に保持するシステムプロセスです。

lsass（Local Security Authority Subsystem Service） Windowsの認証基盤を担うシステムプロセス。ユーザーのログオン処理・パスワード変更・アクセストークンの生成などを担当する。プロセス名はlsass.exeで、タスクマネージャーでも確認できる。

lsassのメモリ上には以下の情報が格納されています。

なぜlsassが攻撃者に狙われるのか

lsassが攻撃者の最重要ターゲットになる理由は明確です。lsassのメモリを読み取れば、ログオン中のユーザーの認証情報がそのまま手に入るからです。

特にNTLMハッシュはクラックしなくてもそのままネットワーク認証に使えます（Pass-the-Hash）。KRBTGTのハッシュが手に入ればGolden Ticketの偽造も可能です。

Pass-the-Hash（PtH） NTLMハッシュをそのまま認証トークンとして使う攻撃手法。パスワードの平文が不要で、ハッシュを窃取するだけで他のシステムに横展開できる。NTLMの仕様上の弱点を突いた攻撃。

lsassを守ることは、ドメイン全体の認証情報を守ることと同義です。そのためにMicrosoftが実装したのがLSA ProtectionとCredential Guardです。

LSA Protectionとは

LSA Protectionとは——PPLでlsassを守る仕組み

LSA Protectionとは、lsass.exeをPPL（Protected Process Light）として動作させることで、外部プロセスからのメモリアクセスをブロックするセキュリティ機能です。

LSA Protection（Local Security Authority Protection） lsass.exeをPPLとして保護する機能。PPLプロセスへのアクセスはMicrosoftが署名した信頼済みプロセスのみに制限される。管理者権限を持つプロセスであっても、署名がなければlsassのメモリを読み取れなくなる。

PPL（Protected Process Light） Windowsのプロセス保護モデルの一つ。通常の管理者権限（SYSTEM権限含む）では、PPLプロセスへのデバッグやメモリ読み取りが制限される。PPLより低い保護レベルのプロセスからはアクセスできない仕組み。

LSA Protectionが有効な状態では、Mimikatzなどのツールがlsassプロセスにアタッチしてメモリを読み取ろうとしても、アクセスが拒否されます。管理者権限やSYSTEM権限を持っていても、署名のないプロセスからはlsassのメモリに触れません。

Windows 11 22H2でデフォルト有効になった背景

LSA Protectionは以前からレジストリで有効化できましたが、Windows 11 22H2からHVCI対応デバイスでデフォルト有効になりました。

HVCI（Hypervisor-Protected Code Integrity） Windowsのカーネルコードの整合性をHypervisor（仮想化技術）で保護する機能。カーネルドライバーのメモリ改ざんを防ぐ。現代のIntel・AMDプロセッサー搭載のデバイスであれば多くが対応している。

これにより、最新のWindows 11環境では追加設定なしにLSA Protectionが機能するようになりました。AD演習Vol.4でもCLIENT01（Windows 11評価版）へのローカルLSASSダンプが失敗したのも、この保護が有効だったためでした。

LSA Protectionの有効状態を確認する

# LSA Protectionの有効状態をレジストリで確認する
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name "RunAsPPL" -ErrorAction SilentlyContinue

# イベントログで確認する（イベントID 12）
Get-WinEvent -LogName "Microsoft-Windows-LSA/Operational" |
    Where-Object { $_.Id -eq 12 } |
    Select-Object TimeCreated, Message -First 5

RunAsPPLの値が1または2であれば有効です。値が存在しないか0の場合は無効になっています。

手動で有効化する場合はGPOから設定します。

コンピューターの構成
　└── 管理用テンプレート
　　　└── システム
　　　　　└── Local Security Authority
　　　　　　　└── LSAをPPLとして実行するよう設定する：有効

Credential Guardとは

Credential Guardとは——VBSでハッシュを仮想環境に隔離する仕組み

Credential Guardとは、NTLMハッシュやKerberosチケットをVBS（仮想化ベースのセキュリティ）で保護された独立した環境に隔離し、OSが侵害されても認証情報にアクセスできなくする機能です。

Credential Guard VBSを使ってlsassを「通常のOS領域」と「保護された仮想環境（LSAIso）」に分離するセキュリティ機能。NTLMハッシュやKerberosのTGTは保護された仮想環境内にのみ格納される。OSカーネルが侵害されても、仮想環境内の認証情報には直接アクセスできない。

VBS（Virtualization-Based Security：仮想化ベースのセキュリティ） CPUの仮想化機能（Intel VT-x / AMD-V）を使い、通常のOSから独立した保護された実行環境を作る技術。この環境内で動くコードはOSカーネルからも改ざんできない。Credential GuardはこのVBS環境内でlsassの一部を動かす。

通常のOSが侵害されてカーネルレベルのアクセスを得た攻撃者でも、VBS環境の外からは認証情報にアクセスできません。LSA Protectionが「lsassのプロセスを守る」のに対し、Credential Guardは「認証情報そのものを仮想環境に隔離する」という、より深い層での保護です。

LSA ProtectionとCredential Guardの役割の違い

この2つは似ているようで、守る対象と仕組みが異なります。

2つの機能は補完関係にあります。LSA ProtectionとCredential Guardを両方有効にすることで、多層的な認証情報の保護が実現されます。

Credential Guardの有効状態を確認する

# Credential Guardの有効状態を確認する
Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object SecurityServicesRunning, SecurityServicesConfigured

# Device Guardの状態をまとめて確認する
msinfo32
# 「システム情報」→「システムの要約」→
# 「仮想化ベースのセキュリティサービス実行中」を確認

SecurityServicesRunningの値に1が含まれていればCredential Guardが動作しています。

NTLMの終わりに向けて——Microsoftのロードマップ

LSA ProtectionとCredential Guardによる保護強化と並行して、MicrosoftはNTLMそのものの段階的廃止を進めています。

2023年以降、Microsoftは以下の方針を公表しています。

• Windows 11ではNTLMの使用状況を監視する機能を追加
• 将来的にNTLMをデフォルト無効化する方向で検討中
• Kerberos認証への完全移行を推奨

NTLM（NT LAN Manager） Windowsが長年使ってきたチャレンジ・レスポンス型の認証プロトコル。Pass-the-Hashなどの攻撃に対して脆弱なため、Microsoftは段階的な廃止を進めている。現在も後方互換性のために残っているが、可能な限りKerberos認証に切り替えることが推奨されている。

NTLMが廃止されると、Pass-the-Hash攻撃そのものが成立しなくなります。ただし完全廃止まではまだ時間がかかります。それまでの間は、LSA ProtectionとCredential Guardによる保護が重要な役割を担います。

gMSAによるサービスアカウントのパスワード自動管理と組み合わせることで、ハッシュ攻撃への耐性がさらに高まります。gMSAについては「gMSAの設定手順ガイド」で詳しく解説しています。

現場でよくある見落とし

① HVCI非対応デバイスでデフォルト有効化されていない

LSA ProtectionとCredential Guardのデフォルト有効化はHVCI対応デバイスが前提です。古いハードウェアや仮想環境によってはHVCIが無効になっており、デフォルト有効化の対象外になっています。現在の環境で有効になっているかを必ず確認してください。

② 古いアプリケーションがCredential Guardと非互換

Credential Guardを有効化すると、一部の古いアプリケーションや認証システムが動作しなくなることがあります。特にNTLMに強く依存したシステムや、仮想化環境でネストした構成を取っている場合は事前に互換性を確認してください。

③ LSA Protectionを無効にしたまま放置している

「アプリが動かなくなった」という理由でLSA Protectionを無効にして、そのまま忘れているケースがあります。無効にした理由と影響範囲を記録し、可能であれば代替手段を検討して再度有効化することを推奨します。

④ Credential Guardが有効でもNTLMを無効化していない

Credential Guardはハッシュを守りますが、NTLMプロトコル自体を無効化しているわけではありません。環境によってはNTLMを明示的に無効化またはAuditモードで監視することも検討してください。

チェックリスト

LSA Protectionの確認

• RunAsPPLレジストリ値が1または2になっている
• GPOでLSA Protectionの設定が管理されている
• イベントID 12でLSA Protectionの有効化が記録されている

Credential Guardの確認

• SecurityServicesRunningに1（Credential Guard）が含まれている
• HVCIが有効なデバイスで運用している
• 既存アプリケーションとの互換性を確認済みである

NTLM管理の確認

• 環境内でNTLMの使用状況を把握している
• 不要なNTLMの使用を制限または監査している
• Kerberos認証への移行計画がある

まとめ

今日確認すべきことは1つです。管理している端末でLSA ProtectionとCredential Guardが有効になっているか確認してください。

PowerShellでGet-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL"を実行して値が1以上であること、Get-CimInstance -ClassName Win32_DeviceGuardでSecurityServicesRunningに1が含まれていることを確認してください。

LSA ProtectionとCredential Guardは、Pass-the-Hashをはじめとするハッシュ攻撃に対する現時点での最も効果的な防御手段です。Windows 11環境ではデフォルト有効化が進んでいますが、古いデバイスや特定の仮想環境では手動での確認と設定が必要です。

ハッシュ攻撃への多層防御を完成させるには、本記事の内容にLAPSによるローカル管理者パスワードの自動ローテーションを組み合わせることが効果的です。LAPSについては次回の記事で詳しく解説します。

あわせてご覧ください

• KerberoastingとDCSyncの仕組みと防御策｜AD攻撃の2大手法を解説
• イベントログで攻撃を検知する実践パターン
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
• gMSAの設定手順ガイド

参考文献

• 参考：Credential Guard の概要（Microsoft Learn）
• 参考：LSA Protection の構成（Microsoft Learn）
• 参考：NTLMの廃止に向けた取り組み（Microsoft Security Blog）