Windows Credentials Protections

Reading time: 17 minutes

Credentials Protections

WDigest

WDigest プロトコルは、Windows XP と共に導入され、HTTP プロトコルを介した認証のために設計されており、Windows XP から Windows 8.0 および Windows Server 2003 から Windows Server 2012 までデフォルトで有効です。このデフォルト設定により、LSASS にプレーンテキストのパスワードが保存されます（ローカル セキュリティ認証局サブシステムサービス）。攻撃者は Mimikatz を使用して、次のコマンドを実行することでこれらの資格情報を抽出できます:

sekurlsa::wdigest

この機能をオフまたはオンに切り替えるには、UseLogonCredential および Negotiate レジストリキーを HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest 内で "1" に設定する必要があります。これらのキーが存在しないか "0" に設定されている場合、WDigestは無効になります。

reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

LSA Protection (PP & PPL protected processes)

Protected Process (PP) と Protected Process Light (PPL) は Windowsカーネルレベルの保護 で、LSASS のような敏感なプロセスへの不正アクセスを防ぐために設計されています。Windows Vista で導入された PPモデル は、元々 DRM の施行のために作成され、特別なメディア証明書 で署名されたバイナリのみが保護されることを許可していました。PP としてマークされたプロセスは、同じくPP で 同等またはそれ以上の保護レベル を持つ他のプロセスからのみアクセス可能であり、その場合でも 特に許可されない限り、制限されたアクセス権 でのみアクセスできます。

PPL は Windows 8.1 で導入され、PPのより柔軟なバージョンです。デジタル署名のEKU (Enhanced Key Usage) フィールドに基づいて "保護レベル" を導入することで、より広範な使用ケース (例: LSASS, Defender) を可能にします。保護レベルは EPROCESS.Protection フィールドに格納されており、これは以下を持つ PS_PROTECTION 構造体です：

• Type (Protected または ProtectedLight)
• Signer (例: WinTcb, Lsa, Antimalware など)

この構造体は1バイトにパックされ、誰が誰にアクセスできるか を決定します：

• 高い署名者の値は低いものにアクセスできる
• PPLはPPにアクセスできない
• 保護されていないプロセスはPPL/PPにアクセスできない

攻撃的な視点から知っておくべきこと

• LSASSがPPLとして実行されている場合、通常の管理者コンテキストから OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION) を使用して開こうとすると、0x5 (Access Denied) で失敗します。たとえ SeDebugPrivilege が有効でもです。
• Process Hacker のようなツールを使用するか、プログラム的に EPROCESS.Protection 値を読み取ることで LSASSの保護レベルを確認できます。
• LSASSは通常 PsProtectedSignerLsa-Light (0x41) を持ち、より高いレベルの署名者（例: WinTcb (0x61 または 0x62））で署名されたプロセスのみがアクセスできます。
• PPLは ユーザーランド専用の制限 であり、カーネルレベルのコードは完全にバイパスできます。
• LSASSがPPLであることは、カーネルシェルコードを実行できる場合や 適切なアクセス権を持つ高特権プロセスを利用できる場合、資格情報のダンプを防ぐものではありません。
• PPLの設定または削除 には再起動または Secure Boot/UEFI設定 が必要で、これによりレジストリの変更が元に戻された後でもPPL設定が持続することがあります。

PPL保護をバイパスするオプション：

PPLにもかかわらずLSASSをダンプしたい場合、主に3つのオプションがあります：

1. 署名されたカーネルドライバ (例: Mimikatz + mimidrv.sys) を使用して LSASSの保護フラグを削除します：

2. Bring Your Own Vulnerable Driver (BYOVD) を使用してカスタムカーネルコードを実行し、保護を無効にします。PPLKiller、gdrv-loader、または kdmapper のようなツールを使用することでこれが可能になります。
3. 他のプロセスから既存のLSASSハンドルを盗む（例: AVプロセス）し、それを 自分のプロセスに複製します。これは pypykatz live lsa --method handledup テクニックの基礎です。
4. 任意のコードをそのアドレス空間にロードできる特権プロセスを悪用するか、別の特権プロセス内で実行し、実質的にPPL制限をバイパスします。この例については bypassing-lsa-protection-in-userland または https://github.com/itm4n/PPLdump を確認できます。

LSASSのためのLSA保護 (PPL/PP) の現在の状態を確認:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL

mimikatz privilege::debug sekurlsa::logonpasswords を実行すると、エラーコード 0x00000005 で失敗する可能性があります。

• この件についての詳細は https://itm4n.github.io/lsass-runasppl/ を確認してください。

Credential Guard

Credential Guard は Windows 10 (Enterprise and Education editions) 専用の機能で、Virtual Secure Mode (VSM) と Virtualization Based Security (VBS) を使用してマシンの資格情報のセキュリティを強化します。これは、CPUの仮想化拡張を利用して、主要なプロセスを保護されたメモリ空間内に隔離し、メインオペレーティングシステムのアクセスから遠ざけます。この隔離により、カーネルでさえもVSM内のメモリにアクセスできず、pass-the-hash のような攻撃から資格情報を効果的に保護します。Local Security Authority (LSA) はこの安全な環境内でトラストレットとして動作し、メインOSのLSASS プロセスはVSMのLSAとの通信を行うだけです。

デフォルトでは、Credential Guard はアクティブではなく、組織内で手動での有効化が必要です。これは、資格情報を抽出する能力が制限されるため、Mimikatz のようなツールに対するセキュリティを強化するために重要です。ただし、カスタム Security Support Providers (SSP) を追加することで、ログイン試行中に平文で資格情報をキャプチャする脆弱性が依然として悪用される可能性があります。

Credential Guard の有効化状態を確認するには、HKLM\System\CurrentControlSet\Control\LSA の下にあるレジストリキー LsaCfgFlags を調べることができます。値が "1" の場合は UEFI lock で有効化されており、"2" はロックなし、"0" は無効を示します。このレジストリチェックは強力な指標ですが、Credential Guard を有効にするための唯一のステップではありません。この機能を有効にするための詳細なガイダンスと PowerShell スクリプトはオンラインで入手可能です。

reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags

包括するための包括的な理解と指示は、Windows 10でのCredential Guardの有効化と、**Windows 11 Enterprise and Education (version 22H2)**の互換性のあるシステムでの自動アクティベーションについて、Microsoftのドキュメントを訪問してください。

資格情報キャプチャのためのカスタムSSPの実装に関する詳細は、このガイドに記載されています。

RDP RestrictedAdmin モード

Windows 8.1 と Windows Server 2012 R2 は、_RDPのRestricted Adminモード_を含むいくつかの新しいセキュリティ機能を導入しました。このモードは、パス・ザ・ハッシュ攻撃に関連するリスクを軽減することで、セキュリティを強化することを目的としています。

従来、RDPを介してリモートコンピュータに接続する際、資格情報はターゲットマシンに保存されます。これは、特に特権のあるアカウントを使用する場合に、重大なセキュリティリスクをもたらします。しかし、_Restricted Adminモード_の導入により、このリスクは大幅に軽減されます。

mstsc.exe /RestrictedAdminコマンドを使用してRDP接続を開始すると、リモートコンピュータへの認証は、資格情報を保存することなく行われます。このアプローチにより、マルウェア感染や悪意のあるユーザーがリモートサーバーにアクセスした場合でも、資格情報がサーバーに保存されていないため、危険にさらされることはありません。

Restricted Adminモードでは、RDPセッションからネットワークリソースにアクセスしようとする試みは、個人の資格情報を使用せず、代わりにマシンのアイデンティティが使用されることに注意が必要です。

この機能は、リモートデスクトップ接続のセキュリティを強化し、セキュリティ侵害が発生した場合に機密情報が露出するのを防ぐための重要なステップです。

詳細情報については、このリソースを訪問してください。

キャッシュされた資格情報

Windowsは、Local Security Authority (LSA)を通じてドメイン資格情報を保護し、KerberosやNTLMのようなセキュリティプロトコルを使用してログオンプロセスをサポートします。Windowsの重要な機能は、最後の10回のドメインログインをキャッシュする能力であり、これによりドメインコントローラーがオフラインであってもユーザーがコンピュータにアクセスできるようになります。これは、会社のネットワークから離れていることが多いノートパソコンユーザーにとって大きな利点です。

キャッシュされたログインの数は、特定のレジストリキーまたはグループポリシーを介して調整可能です。この設定を表示または変更するには、次のコマンドが使用されます：

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

これらのキャッシュされた資格情報へのアクセスは厳しく制御されており、SYSTEM アカウントのみがそれらを表示するための必要な権限を持っています。情報にアクセスする必要がある管理者は、SYSTEM ユーザーの特権を使用して行う必要があります。資格情報は次の場所に保存されています: HKEY_LOCAL_MACHINE\SECURITY\Cache

Mimikatz は、コマンド lsadump::cache を使用してこれらのキャッシュされた資格情報を抽出するために使用できます。

詳細については、元の source が包括的な情報を提供しています。

保護されたユーザー

Protected Users group へのメンバーシップは、ユーザーに対していくつかのセキュリティ強化を導入し、資格情報の盗難や悪用に対するより高い保護レベルを確保します：

• Credential Delegation (CredSSP): Allow delegating default credentials のグループポリシー設定が有効であっても、Protected Users のプレーンテキスト資格情報はキャッシュされません。
• Windows Digest: Windows 8.1 および Windows Server 2012 R2 以降、システムは Protected Users のプレーンテキスト資格情報をキャッシュしません。Windows Digest の状態に関係なく。
• NTLM: システムは Protected Users のプレーンテキスト資格情報や NT 一方向関数 (NTOWF) をキャッシュしません。
• Kerberos: Protected Users に対して、Kerberos 認証は DES または RC4 keys を生成せず、プレーンテキスト資格情報や初期のチケット授与チケット (TGT) 取得を超える長期キーをキャッシュしません。
• Offline Sign-In: Protected Users はサインインまたはロック解除時にキャッシュされた検証子が作成されないため、これらのアカウントではオフラインサインインはサポートされません。

これらの保護は、Protected Users group のメンバーであるユーザーがデバイスにサインインした瞬間に有効になります。これにより、資格情報の侵害に対するさまざまな方法から保護するための重要なセキュリティ対策が講じられます。

詳細な情報については、公式の documentation を参照してください。

Table from the docs.