credentials-protections.md (20005B)
1 --- 2 title: "Windows Credentials Protections" 3 section: "Windows" 4 sectionSlug: "windows-hardening" 5 sourcePath: "src/windows-hardening/stealing-credentials/credentials-protections.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/stealing-credentials/credentials-protections.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Windows Credentials Protections 14 15 ## WDigest 16 17 The [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>) protocol, introduced with Windows XP, is designed for authentication via the HTTP Protocol and is **enabled by default on Windows XP through Windows 8.0 and Windows Server 2003 to Windows Server 2012**. This default setting results in **plain-text password storage in LSASS** (Local Security Authority Subsystem Service). An attacker can use Mimikatz to **extract these credentials** by executing:<sup>[[8]](#references)</sup> 18 19 ```bash 20 sekurlsa::wdigest 21 ``` 22 23 To **toggle this feature off or on**, the _**UseLogonCredential**_ and _**Negotiate**_ registry keys within _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ must be set to "1". If these keys are **absent or set to "0"**, WDigest is **disabled**: 24 25 ```bash 26 reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential 27 ``` 28 29 ## LSA Protection (PP & PPL protected processes) 30 31 **Protected Process (PP)** and **Protected Process Light (PPL)** are **Windows kernel-level protections** designed to prevent unauthorized access to sensitive processes like **LSASS**. Introduced in **Windows Vista**, the **PP model** was originally created for **DRM** enforcement and only allowed binaries signed with a **special media certificate** to be protected. A process marked as **PP** can only be accessed by other processes that are **also PP** and have an **equal or higher protection level**, and even then, **only with limited access rights** unless specifically allowed. 32 33 **PPL**, introduced in **Windows 8.1**, is a more flexible version of PP. It allows **broader use cases** (e.g., LSASS, Defender) by introducing **"protection levels"** based on the **digital signature’s EKU (Enhanced Key Usage)** field. The protection level is stored in the `EPROCESS.Protection` field, which is a `PS_PROTECTION` structure with: 34 - **Type** (`Protected` or `ProtectedLight`) 35 - **Signer** (e.g., `WinTcb`, `Lsa`, `Antimalware`, etc.) 36 37 This structure is packed into a single byte and determines **who can access whom**: 38 - **Higher signer values can access lower ones** 39 - **PPLs can’t access PPs** 40 - **Unprotected processes can't access any PPL/PP** 41 42 ### What you need to know from an offensive perspective 43 44 - When **LSASS runs as a PPL**, attempts to open it using `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` from a normal admin context **fail with `0x5 (Access Denied)`**, even if `SeDebugPrivilege` is enabled. 45 - You can **check LSASS protection level** using tools like Process Hacker or programmatically by reading the `EPROCESS.Protection` value. 46 - LSASS will typically have `PsProtectedSignerLsa-Light` (`0x41`), which can be accessed **only by processes signed with a higher-level signer**, such as `WinTcb` (`0x61` or `0x62`). 47 - PPL is a **Userland-only restriction**; **kernel-level code can fully bypass it**. 48 - LSASS being PPL does **not prevent credential dumping if you can execute kernel shellcode** or **leverage a high-privileged process with proper access**. 49 - **Setting or removing PPL** requires reboot or **Secure Boot/UEFI settings**, which can persist the PPL setting even after registry changes are reversed. 50 51 ### Create a PPL process at launch (documented API) 52 53 Windows exposes a documented way to request a Protected Process Light level for a child process during creation using the extended startup attribute list. This does not bypass signing requirements — the target image must be signed for the requested signer class. 54 55 Minimal flow in C/C++: 56 57 ```c 58 // Request a PPL protection level for the child process at creation time 59 // Requires Windows 8.1+ and a properly signed image for the selected level 60 #include <windows.h> 61 62 int wmain(int argc, wchar_t **argv) { 63 STARTUPINFOEXW si = {0}; 64 PROCESS_INFORMATION pi = {0}; 65 si.StartupInfo.cb = sizeof(si); 66 67 SIZE_T attrSize = 0; 68 InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize); 69 si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize); 70 if (!si.lpAttributeList) return 1; 71 72 if (!InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize)) return 1; 73 74 DWORD level = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // or WINDOWS_LIGHT/LSA_LIGHT/WINTCB_LIGHT 75 if (!UpdateProcThreadAttribute( 76 si.lpAttributeList, 0, 77 PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, 78 &level, sizeof(level), NULL, NULL)) { 79 return 1; 80 } 81 82 DWORD flags = EXTENDED_STARTUPINFO_PRESENT; 83 if (!CreateProcessW(L"C\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, 84 flags, NULL, NULL, &si.StartupInfo, &pi)) { 85 // If the image isn't signed appropriately for the requested level, 86 // CreateProcess will fail with ERROR_INVALID_IMAGE_HASH (577). 87 return 1; 88 } 89 90 // cleanup 91 DeleteProcThreadAttributeList(si.lpAttributeList); 92 HeapFree(GetProcessHeap(), 0, si.lpAttributeList); 93 CloseHandle(pi.hThread); 94 CloseHandle(pi.hProcess); 95 return 0; 96 } 97 ``` 98 99 Notes and constraints: 100 - Use `STARTUPINFOEX` with `InitializeProcThreadAttributeList` and `UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, ...)`, then pass `EXTENDED_STARTUPINFO_PRESENT` to `CreateProcess*`.<sup>[[2]](#references)[[3]](#references)[[4]](#references)</sup> 101 - The protection `DWORD` can be set to constants such as `PROTECTION_LEVEL_WINTCB_LIGHT`, `PROTECTION_LEVEL_WINDOWS`, `PROTECTION_LEVEL_WINDOWS_LIGHT`, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT`, or `PROTECTION_LEVEL_LSA_LIGHT`. 102 - The child only starts as PPL if its image is signed for that signer class; otherwise process creation fails, commonly with `ERROR_INVALID_IMAGE_HASH (577)` / `STATUS_INVALID_IMAGE_HASH (0xC0000428)`. 103 - This is not a bypass — it’s a supported API meant for appropriately signed images. Useful to harden tools or validate PPL-protected configurations. 104 105 Example CLI using a minimal loader:<sup>[[1]](#references)</sup> 106 - Antimalware signer: `CreateProcessAsPPL.exe 3 C:\Tools\agent.exe --svc` 107 - LSA-light signer: `CreateProcessAsPPL.exe 4 C:\Windows\System32\notepad.exe` 108 109 **Bypass PPL protections options:** 110 111 If you want to dump LSASS despite PPL, you have 3 main options: 112 1. **Use a signed kernel driver (e.g., Mimikatz + mimidrv.sys)** to **remove LSASS’s protection flag**: 113 114  115 116 2. **Bring Your Own Vulnerable Driver (BYOVD)** to run custom kernel code and disable the protection. Tools like **PPLKiller**, **gdrv-loader**, or **kdmapper** make this feasible. 117 3. **Steal an existing LSASS handle** from another process that has it open (e.g., an AV process), then **duplicate it** into your process. This is the basis of the `pypykatz live lsa --method handledup` technique. 118 4. **Abuse some privileged process** that will allow you to load arbitrary code into its address space or inside another privileged process, effectively bypassing the PPL restrictions. You can check an example of this in [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) or [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump). 119 120 **Check current status of LSA protection (PPL/PP) for LSASS**: 121 122 ```bash 123 reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL 124 ``` 125 126 When running **`mimikatz privilege::debug sekurlsa::logonpasswords`**, it will probably fail with error code `0x00000005` because of this protection. 127 128 - For more information about this check [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)<sup>[[5]](#references)</sup> 129 130 131 ## Credential Guard 132 133 **Credential Guard**, a feature exclusive to **Windows 10 (Enterprise and Education editions)**, enhances the security of machine credentials using **Virtual Secure Mode (VSM)** and **Virtualization Based Security (VBS)**. It leverages CPU virtualization extensions to isolate key processes within a protected memory space, away from the main operating system's reach. This isolation ensures that even the kernel cannot access the memory in VSM, effectively safeguarding credentials from attacks like **pass-the-hash**. The **Local Security Authority (LSA)** operates within this secure environment as a trustlet, while the **LSASS** process in the main OS acts merely as a communicator with the VSM's LSA. 134 135 By default, **Credential Guard** is not active and requires manual activation within an organization. It's critical for enhancing security against tools like **Mimikatz**, which are hindered in their ability to extract credentials. However, vulnerabilities can still be exploited through the addition of custom **Security Support Providers (SSP)** to capture credentials in clear text during login attempts. 136 137 To verify **Credential Guard**'s activation status, the registry key _**LsaCfgFlags**_ under _**HKLM\System\CurrentControlSet\Control\LSA**_ can be inspected. A value of "**1**" indicates activation with **UEFI lock**, "**2**" without lock, and "**0**" denotes it is not enabled. This registry check, while a strong indicator, is not the sole step for enabling Credential Guard. Detailed guidance and a PowerShell script for enabling this feature are available online. 138 139 ```bash 140 reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags 141 ``` 142 143 For a comprehensive understanding and instructions on enabling **Credential Guard** in Windows 10 and its automatic activation in compatible systems of **Windows 11 Enterprise and Education (version 22H2)**, visit [Microsoft's documentation](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).<sup>[[9]](#references)</sup> 144 145 Further details on implementing custom SSPs for credential capture are provided in [this guide](/hacktricks/windows-hardening/active-directory-methodology/custom-ssp). 146 147 ## RDP RestrictedAdmin Mode 148 149 **Windows 8.1 and Windows Server 2012 R2** introduced several new security features, including the _**Restricted Admin mode for RDP**_. This mode was designed to enhance security by mitigating the risks associated with [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/) attacks. 150 151 Traditionally, when connecting to a remote computer via RDP, your credentials are stored on the target machine. This poses a significant security risk, especially when using accounts with elevated privileges. However, with the introduction of _**Restricted Admin mode**_, this risk is substantially reduced. 152 153 When initiating an RDP connection using the command **mstsc.exe /RestrictedAdmin**, authentication to the remote computer is performed without storing your credentials on it. This approach ensures that, in the event of a malware infection or if a malicious user gains access to the remote server, your credentials are not compromised, as they are not stored on the server. 154 155 It's important to note that in **Restricted Admin mode**, attempts to access network resources from the RDP session will not use your personal credentials; instead, the **machine's identity** is used. 156 157 This feature marks a significant step forward in securing remote desktop connections and protecting sensitive information from being exposed in case of a security breach. 158 159  160 161 For more detailed information on visit [this resource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).<sup>[[6]](#references)</sup> 162 163 ## Cached Credentials 164 165 Windows secures **domain credentials** through the **Local Security Authority (LSA)**, supporting logon processes with security protocols like **Kerberos** and **NTLM**. A key feature of Windows is its capability to cache the **last ten domain logins** to ensure users can still access their computers even if the **domain controller is offline**—a boon for laptop users often away from their company's network. 166 167 The number of cached logins is adjustable via a specific **registry key or group policy**. To view or change this setting, the following command is utilized: 168 169 ```bash 170 reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT 171 ``` 172 173 Access to these cached credentials is tightly controlled, with only the **SYSTEM** account having the necessary permissions to view them. Administrators needing to access this information must do so with SYSTEM user privileges. The credentials are stored at: `HKEY_LOCAL_MACHINE\SECURITY\Cache` 174 175 **Mimikatz** can be employed to extract these cached credentials using the command `lsadump::cache`. 176 177 For further details, the original [source](http://juggernaut.wikidot.com/cached-credentials) provides comprehensive information.<sup>[[7]](#references)</sup> 178 179 ## Protected Users 180 181 Membership in the **Protected Users group** introduces several security enhancements for users, ensuring higher levels of protection against credential theft and misuse: 182 183 - **Credential Delegation (CredSSP)**: Even if the Group Policy setting for **Allow delegating default credentials** is enabled, plain text credentials of Protected Users will not be cached. 184 - **Windows Digest**: Starting from **Windows 8.1 and Windows Server 2012 R2**, the system will not cache plain text credentials of Protected Users, regardless of the Windows Digest status. 185 - **NTLM**: The system will not cache Protected Users' plain text credentials or NT one-way functions (NTOWF). 186 - **Kerberos**: For Protected Users, Kerberos authentication will not generate **DES** or **RC4 keys**, nor will it cache plain text credentials or long-term keys beyond the initial Ticket-Granting Ticket (TGT) acquisition. 187 - **Offline Sign-In**: Protected Users will not have a cached verifier created at sign-in or unlock, meaning offline sign-in is not supported for these accounts. 188 189 These protections are activated the moment a user, who is a member of the **Protected Users group**, signs into the device. This ensures that critical security measures are in place to safeguard against various methods of credential compromise. 190 191 For more detailed information, consult the official [documentation](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).<sup>[[10]](#references)</sup> 192 193 **Table from** [**the docs**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**<sup>[[11]](#references)</sup> 194 195 | Windows Server 2003 RTM | Windows Server 2003 SP1+ | <p>Windows Server 2012,<br>Windows Server 2008 R2,<br>Windows Server 2008</p> | Windows Server 2016 | 196 | ----------------------- | ------------------------ | ----------------------------------------------------------------------------- | ---------------------------- | 197 | Account Operators | Account Operators | Account Operators | Account Operators | 198 | Administrator | Administrator | Administrator | Administrator | 199 | Administrators | Administrators | Administrators | Administrators | 200 | Backup Operators | Backup Operators | Backup Operators | Backup Operators | 201 | Cert Publishers | | | | 202 | Domain Admins | Domain Admins | Domain Admins | Domain Admins | 203 | Domain Controllers | Domain Controllers | Domain Controllers | Domain Controllers | 204 | Enterprise Admins | Enterprise Admins | Enterprise Admins | Enterprise Admins | 205 | | | | Enterprise Key Admins | 206 | | | | Key Admins | 207 | Krbtgt | Krbtgt | Krbtgt | Krbtgt | 208 | Print Operators | Print Operators | Print Operators | Print Operators | 209 | | | Read-only Domain Controllers | Read-only Domain Controllers | 210 | Replicator | Replicator | Replicator | Replicator | 211 | Schema Admins | Schema Admins | Schema Admins | Schema Admins | 212 | Server Operators | Server Operators | Server Operators | Server Operators | 213 214 ## References 215 216 - [1] [CreateProcessAsPPL – minimal PPL process launcher](https://github.com/2x7EQ13/CreateProcessAsPPL) 217 - [2] [STARTUPINFOEX structure (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw) 218 - [3] [InitializeProcThreadAttributeList (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist) 219 - [4] [UpdateProcThreadAttribute (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute) 220 - [5] [LSASS RunAsPPL – background and internals](https://itm4n.github.io/lsass-runasppl/) 221 - [6] [Restricted Admin Mode for RDP](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/) 222 - [7] [Cached Credentials - Juggernaut AppSec Wiki](http://juggernaut.wikidot.com/cached-credentials) 223 - [8] [WDigest Authentication (Microsoft TechNet)](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>) 224 - [9] [Manage Windows Defender Credential Guard (Microsoft Learn)](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage) 225 - [10] [Protected Users Security Group (Microsoft Learn)](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) 226 - [11] [Appendix C: Protected Accounts and Groups in Active Directory (Microsoft Learn)](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)