Credentials Protections
Last updated
Last updated
WDigest protocol was introduced in Windows XP and was designed to be used with HTTP Protocol for authentication. Microsoft has this protocol enabled by default in multiple versions of Windows (Windows XP — Windows 8.0 and Windows Server 2003 — Windows Server 2012) which means that plain-text passwords are stored in the LSASS (Local Security Authority Subsystem Service). Mimikatz can interact with the LSASS allowing an attacker to retrieve these credentials through the following command:
This behaviour can be deactivated/activated setting to 1 the value of UseLogonCredential and Negotiate in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest. If these registry keys don't exist or the value is "0", then WDigest will be deactivated.
Microsoft in Windows 8.1 and later has provided additional protection for the LSA to prevent untrusted processes from being able to read its memory or to inject code. This will prevent regular mimikatz.exe sekurlsa:logonpasswords
for working properly.
To activate this protection you need to set the value RunAsPPL in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA to 1.
It is possible to bypass this protection using Mimikatz driver mimidrv.sys:
Credential Guard is a new feature in Windows 10 (Enterprise and Education edition) that helps to protect your credentials on a machine from threats such as pass the hash. This works through a technology called Virtual Secure Mode (VSM) which utilizes virtualization extensions of the CPU (but is not an actual virtual machine) to provide protection to areas of memory (you may hear this referred to as Virtualization Based Security or VBS). VSM creates a separate "bubble" for key processes that are isolated from the regular operating system processes, even the kernel and only specific trusted processes may communicate to the processes (known as trustlets) in VSM. This means a process in the main OS cannot read the memory from VSM, even kernel processes. The Local Security Authority (LSA) is one of the trustlets in VSM in addition to the standard LSASS process that still runs in the main OS to ensure support with existing processes but is really just acting as a proxy or stub to communicate with the version in VSM ensuring actual credentials run on the version in VSM and are therefore protected from attack. Credential Guard must be turned on and deployed in your organization as it is not enabled by default. From https://www.itprotoday.com/windows-10/what-credential-guard More information and a PS1 script to enable Credential Guard can be found here.
In this case Mimikatz cannot do much to bypass this and extract the hashes from LSASS. But you could always add your custom SSP and capture the credentials when a user tries to login in clear-text. More information about **[SSP and how to do this here**](../active-directory-methodology/custom-ssp.md).
Credentials Guard could be enable in different ways. To check if it was enabled using the registry you could check the value of the key LsaCfgFlags in HKLM\System\CurrentControlSet\Control\LSA. If the value is "1" the it is active with UEFI lock, if "2" is active without lock and if "0" it's not enabled. This is not enough to enable Credentials Guard (but it's a strong indicator). More information and a PS1 script to enable Credential Guard can be found here.
With Windows 8.1 and Windows Server 2012 R2, new security features were introduced. One of those security features is the Restricted Admin mode for RDP. This new security feature is introduced to mitigate the risk of pass the hash attacks.
When you connect to a remote computer using RDP, your credentials are stored on the remote computer that you RDP into. Usually you are using a powerful account to connect to remote servers, and having your credentials stored on all these computers is a security threat indeed.
Using Restricted Admin mode for RDP, when you connect to a remote computer using the command, mstsc.exe /RestrictedAdmin, you will be authenticated to the remote computer, but your credentials will not be stored on that remote computer, as they would have been in the past. This means that if a malware or even a malicious user is active on that remote server, your credentials will not be available on that remote desktop server for the malware to attack.
Note that as your credentials are not being saved on the RDP session if try to access network resources your credentials won't be used. The machine identity will be used instead.
From here.
Domain credentials are used by operating system components and are authenticated by the Local Security Authority (LSA). Typically, domain credentials are established for a user when a registered security package authenticates the user's logon data. This registered security package may be the Kerberos protocol or NTLM.
Windows stores the last ten domain login credentials in the event that the domain controller goes offline. If the domain controller goes offline, a user will still be able to log into their computer. This feature is mainly for laptop users that do not regularly log into their company’s domain. The number of credentials that the computer stores can be controlled by the following registry key, or via group policy:
The credentials are hidden from normal users, even administrator accounts. The SYSTEM user is the only user that has privileges to view these credentials. In order for an administrator to view these credentials in the registry they must access the registry as a SYSTEM user. The Cached credentials are stored in the registry at the following registry location:
Extracting from Mimikatz: lsadump::cache
From here.
When the signed in user is a member of the Protected Users group the following protections are applied:
Credential delegation (CredSSP) will not cache the user's plain text credentials even when the Allow delegating default credentials Group Policy setting is enabled.
Beginning with Windows 8.1 and Windows Server 2012 R2, Windows Digest will not cache the user's plain text credentials even when Windows Digest is enabled.
NTLM will not cache the user's plain text credentials or NT one-way function (NTOWF).
Kerberos will no longer create DES or RC4 keys. Also it will not cache the user's plain text credentials or long-term keys after the initial TGT is acquired.
A cached verifier is not created at sign-in or unlock, so offline sign-in is no longer supported.
After the user account is added to the Protected Users group, protection will begin when the user signs in to the device. From here.
Windows Server 2003 RTM | Windows Server 2003 SP1+ | Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 | Windows Server 2016 |
Account Operators | Account Operators | Account Operators | Account Operators |
Administrator | Administrator | Administrator | Administrator |
Administrators | Administrators | Administrators | Administrators |
Backup Operators | Backup Operators | Backup Operators | Backup Operators |
Cert Publishers | |||
Domain Admins | Domain Admins | Domain Admins | Domain Admins |
Domain Controllers | Domain Controllers | Domain Controllers | Domain Controllers |
Enterprise Admins | Enterprise Admins | Enterprise Admins | Enterprise Admins |
Enterprise Key Admins | |||
Key Admins | |||
Krbtgt | Krbtgt | Krbtgt | Krbtgt |
Print Operators | Print Operators | Print Operators | Print Operators |
Read-only Domain Controllers | Read-only Domain Controllers | ||
Replicator | Replicator | Replicator | Replicator |
Schema Admins | Schema Admins | Schema Admins | Schema Admins |
Server Operators | Server Operators | Server Operators | Server Operators |
Table from here.