A penetration tester is performing post-exploitation on a Windows system and wants to dump credentials from LSASS. The target system has Credential Guard enabled. What is the expected result?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — when you're up against Credential Guard, it uses Virtualization-Based Security to stash NTLM hashes and Kerberos tickets in an isolated VSM that even kernel-level code can't touch, so traditional Mimikatz LSASS dumping comes up empty.
Full Explanation
Credential Guard prevents Mimikatz from extracting NTLM hashes and Kerberos tickets because they are stored in the isolated VSM (Virtual Secure Mode) is correct because Credential Guard uses Virtualization-Based Security to move NTLM credential material and Kerberos tickets into an isolated virtual trust level (VSM) that even kernel-level code cannot access, making traditional Mimikatz LSASS dumping ineffective. The option saying Mimikatz successfully extracts NTLM hashes and Kerberos tickets from LSASS memory is wrong because Credential Guard is specifically designed to prevent this attack; when properly configured, Mimikatz cannot extract these credentials. The option saying Mimikatz can still extract credentials by reading the SAM database directly is wrong because the SAM database stores local account hashes separately from LSASS secrets protected by Credential Guard; local SAM hashes may still be accessible via other techniques, but domain credential material in VSM is protected. The option saying Credential Guard only protects domain accounts while local account hashes are still exposed is wrong because Credential Guard specifically protects domain credentials (NTLM hashes, Kerberos tickets) held in LSASS; it does not protect SAM database hashes.