Credentials Guard, available for Windows 10 Enterprise since build 1507, is a new Microsoft feature that will protect your credentials and any NTLM or Kerberos tokens inside Virtual Secure Mode. The user cannot access this secure mode or kernel space because it resides in “another” OS; it’s completely isolated. Therefore, the only difference for attackers is that they won’t be able to dump credentials from the LSASS process.
However, there are many limits to this feature, making it almost impossible to activate in most environments. Not all of the credentials are stored in the LSASS, and there are numerous ways attackers can elevate their privileges in the domain.
To fully operate Credentials Guard in your domain, you will need the following:
- Each computer must run on 64bit architecture, Windows 10 1507 and above
- VT-x or AMD-V, and VT-D or AMD-Vi support
- UEFI firmware with Secured Boot
- Motherboard with TPM 1.2 or 2.0
- Finally, it cannot be activated on a virtual machine or be installed with other local Virtual Machines applications such as VirtualBox and Vmware (VMware only added support in vSphere version 6.7 released in May 2018).
The reason for these requirements is because this feature is actually running on another OS under the context of the original OS in order to store the credentials.
But even if you’ve managed to activate this feature, you’re not fully protected, and here’s why:
- Token Manipulation Credentials Theft is an alternative to LSASS credentials theft. An attacker can use a built-in Windows API function to copy access tokens from existing processes (commonly known as token stealing). When this occurs, the process also adopts the security context associated with the user. Endpoints are fully exposed.
- Hijacking Running RDP / Terminal Sessions is still a threat; fully exposed.
- Local accounts (Stored in SAM database) won’t be protected, Local Admin Traversal attack will still work.
- Kerberoasting is still a threat.
- TGS Tickets will still be exposed.
- Service Credentials stored locally in the LSA Secrets registry hive will still be exposed.
- 3rd Party software storing credentials won’t be affected.
- MITM Credentials theft attacks won’t be affected.
- If Secured Boot using UEFI firmware isn’t activated, attackers will be able to turn off Credentials Guard.
- Keylogger tools won’t be affected.
- Digest authentication, Credentials Delegation, and MS-CHA2 will still be exposed.
- Single Sign-on solution won’t work anymore (Digest, CredSSP)
- Backward compatibility features such as NTLMv1 support, Kerberos DES Encryption, and Unconstrained-Delegation will break once Credentials Guard is on.
- Social Engineering scenarios are still possible.
- Physical Theft scenarios of credentials or Physical Attacker on-site (he can reboot the endpoint and disable “Secure Boot”)
In sum, Credentials Guard is good but not enough to protect against adversary lateral movement and credentials theft. Combining the complexity of activating it and the security holes that exist, attackers will still be able to achieve their goals.
Credentials Guard only manages to protect against malicious access of the LSASS process, but it fails to protect against lateral movement of any kind. The following attacks are enabled/possible by default in any AD environment: TGS Tickets Theft, Kerberoasting, Service Credentials, Old Security Protocols, Credentials Delegation, RDP Terminal Hijack, Token Manipulation, Local Admin Traversal, MITM Credentials Theft Attack, Keyloggers, and credentials managed by 3rd party applications. We cover a few of these techniques below:
LSA Protection, available from Windows 8.1. This feature denies the ability to access the LSASS process from the user space, making it a “Protected Process”. In other words, it’s protecting against credentials theft from the LSASS process.
Attackers can easily disable this feature when elevating their local privileges to run as a driver. It can be done with Mimikatz using the following commands:
Privilege::Debug
!+
!processprotect /process:lsass.exe /remove
sekurlsa::logonpasswords
Multi-Factor Authentication (Smart Cards and more). They won’t actually be able to protect you from credentials theft; they will only protect from physical credentials theft. Once a user authenticates using the smart card, his token will reside in the memory and will be exposed. Hence, they’re not providing any extra security abilities beside protecting physical stealing of “just the password”. A Domain environment with a fully implemented Smart Cards solution will still be exposed to all of the known Active Directory attacks.
Read our blog. https://jblog.javelin-networks.com/blog/why-are-smart-cards-attackers-favorite-persistence-tool/
Privileged Account Management solutions Read our PAM blog. https://jblog.javelin-networks.com/blog/can-jump-servers-and-privileged-account-management-really-stop-credentials-theft/
MITM Attacks. When attackers can’t steal any additional locally stored credentials, they might try MITM techniques, abusing protocols such as LLMNR, WPAD, and NBT-NS to trick endpoints and users to give them their credentials. In this scenario, the attacker will redirect authentication traffic to his endpoint and receive the hashes of computer accounts and user accounts inside his LAN.
Keyloggers. An attack in which malware is installed to record all of the keystrokes of the actual user using the infected endpoint. The attacker will be able to identify the password typed by the user and then reuse it to authenticate with other resources inside the network.
Internal Social Engineering. When attackers can’t steal any additional locally stored credentials, they might try to lure privileged users into their endpoint and then steal their credentials.
So just remember this: no matter how promising the protection of Credentials Guard sounds, attackers will still find a way to circumvent it.
Contact us for a demo of AD|Protect: [email protected]
Featured Image Attribution:
“Useless gate” by LHOON is licensed under CC BY-SA 2.0 / Added words to sign
Comments