I have read that Windows 10 does not hold the password in memory from the creator of mimikatz:

Starting with 8.x and 10, by default, there is no password in memory.


  • When DC is/are unreachable, the kerberos provider keeps passwords for future negocation ;
  • When HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest, UseLogonCredential (DWORD) is set to 1, the wdigest provider keeps passwords ;
  • When values in Allow* in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults or HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation, the tspkgs / CredSSP provider keeps passwords.

Of course, not when using Credential Guard.

How is that possible? How can Windows keep the password outside of memory?


A quick search turned up the link below. They created a new technology called CredentialGuard, which isolates secrets in virtualized secure environments rather than storing everything in LSA like they used to. Mimikatz can no longer just dump lsass.exe process memory and parse the contents. They're still in some memory, strictly speaking, but not memory that we can access easily.

More: https://technet.microsoft.com/itpro/windows/keep-secure/credential-guard

  • Doesn't this defeat the purpose of storing paswords if we "cannot easily access them," or do we access "CredentialGuard" which then accesses the passwords? So, essentially, we need to learn a new API? – XaolingBao May 23 '16 at 20:29

Beginning with Windows 8.1, the plaintext of a user's password is usually no longer kept in memory. (If you're not familiar with Wdigest, yes, Windows used to really do this. By default, it still does in Windows 7.) Thus, if you successfully manage to dump the creds on a Windows 8.1 machine you'll get the NTLM v.2 hashes or the Kerberos ticket information of the logged-in users, but you won't actually get the plaintext of their password/s. That, I believe, is what the text you quoted is referring to. Of course, since you can (at least, in many scenarios) just pass-the-hash or pass-the-ticket anyway without having to actually have access to the plaintext of the password, the practical effect of this advance was less than seismic. And, as the section of text you noted shows, even with Windows 8.1 there are authentication settings an admin can enable that will result in the plaintext of passwords still being held in the LSA. However, since some progress is better than no progress this was a welcome advance.

Credential Guard, on the other hand, is a newer and different thing. 0rigien briefly described it and linked to a good TechNet article on it above. So it will suffice to say here that where it is in effect--it exists only on Windows 10, and only in the enterprise-deployed versions of the OS-- and configured properly it stops a pen tester or attacker from being able to dump creds from memory at all. The feature makes use of what Microsoft terms virtualization-based security in Windows 10 to essentially put the LSA credential memory store inside a very small, very lean virtual machine (to oversimplify things). A virtual machine that, thanks to technologies that have become standard in recent Intel and AMD processors, not even code that is running with administrator/system privileges is able to access. Pretty nifty.

That's the theory, anyway. So far, in the early history of Windows 10, I'm not aware of any bypass or exploited vulnerability being found to allow credential dumping where Credential Guard is in place and allowed to work with recommended settings. (However, it is my understanding if an admin does re-enable Wdigest or enable CredSSP delegated authentication Credential Guard still will be effectively deactivated. So think carefully before doing either of those things.) But we'll see what countermoves security researchers and bad guys come up with in the years ahead. And what counter-countermoves Microsoft comes up with.

  • You said that: " not even code that is running with administrator/system privileges is able to access." But in this post of Microsoft( docs.microsoft.com/en-US/windows/threat-protection/… ) they say that: "So that only privileged system software can access them." Then, wich "priviliged system software" are they refering to? – Peter11 Jul 17 '17 at 21:37
  • The idea is that there's system/user mode access, and then there's system/kernel access, and then there's system/hypervisor access. You can run your own code in user and kernel mode. You cannot run code at the hypervisor level. – Steve Mar 3 '18 at 0:28

Your Answer

