Can an intruder still possibly succeed with pass-the-hash or pass-the-ticket on Windows 10 / Server 2016 networks where Credential Guard is enabled?

Question

In sum: Does Credential Guard make passing-the-hash and passing-the-ticket attacks effectively unavailable on networks of Windows 10 / Windows Server 2016 machines? If not, how do you still acquire hashes or tickets to pass?

---

From what I've learned about pen testing and malicious attacker methods over the couple of years that I've been studying them in earnest, one of the happiest discoveries that an offensive actor can make happens when penetrating a target's Windows network and finding that it is not properly configured & administered to resist pass-the-hash and/or pass-the-ticket attacks. In such situations, it often becomes disturbingly easy for the intruder to (using a tool like mimikatz) dump NTLM password hashes and Kerberos credentials that are contained in the memory or are on the disk of the foothold machine that was originally compromised and use them to successfully move laterally and breach other boxes on the network. In the best case, it's possible to sooner or later get your hands on the keys to the kingdom: an NTLM hash or Kerberos ticket for a Domain Administrator or Enterprise Administrator. And if that happens... the target is in a world of trouble.

Unfortunately for the offense, in Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Microsoft has implemented a number of measures to try to make passing-the-hash and passing-the-ticket attacks harder to pull off. The most ambitious of these is called Credential Guard, and arrived in Windows 10 Enterprise on the client and Windows Server 2016. The details of how Credential Guard appears to work technically are a little complicated. But at a high level things are more straightforward: Windows takes advantage of virtualization capabilities present in newer Intel and AMD processors to encase the credentials store that exists in memory on a Windows machine in a special kind of virtual machine. A virtual machine that (in theory) even a program that manages to get administrator/SYSTEM privileges on the OS cannot penetrate. Thus, as the pitch goes even if you manage to get your malware onto a PC, and even manage to elevate your privileges on that PC all the way to SYSTEM, if that PC has Credential Guard enabled on it and you try to use a tool like mimikatz to dump the credential store you will get nothing usable for passing-the-hash or passing-the-ticket.

In theory.

So let's say you're a pen tester facing a Windows domain that consists exclusively of Windows 10 Enterprise workstations, Windows Server 2016 servers, and a Windows Server 2016 domain controller. All running with Credential Guard enabled. If you'd like to use pass-the-hash or pass-the-ticket for lateral movement, are you just screwed? Aside from being able to dump the hashes & tickets in the credential store, what other methods might an attacker use to gain hashes or tickets that can be passed? Can you bypass or disable Credential Guard? Or are you faced with just giving up on passing hashes/tickets entirely and trying other ways to do lateral movement?

Edit: FYI, it turns out that in the July Windows 10 "Anniversary Update" Microsoft very quietly introduced Remote Credential Guard, which is apparently designed to prevent your credentials from ever being sent to the remote box when you initiate a Remote Desktop connection to it. (Same general idea as Restricted Admin mode for RDP, I guess, except improved.) A "helpful" diagram from MS:

Answer 1

Against normal adversaries ( non-APT; e.g. cyber criminals) it will be quite effective. But I'll focus on the question of how to bypass Credential Guard so you can get an idea of the sophistication needed.

In the link you provided Microsoft has a visual describing the various security rings of a system.

Like most people Microsoft put Hypervisor (ring -1) directly above the hardware.

Of course, it would undermine their point and raise questions if there was to be a layer between their security mechanism and the hardware.

But if i google ring -2 i don't get any fancy graphics describing anything more privileged...

No. But you will get a mention of SMM here and there. This is usually not something that you can experiment with, so there's not much resources on it.

However this video and this slide deck describe exploits for "rings" that are lower than the Hypervisor and could circumvent the mechanism you mention:.

... we have encountered systems in the wild where the SMRAM is locked by a non-integrity measured BIOS, thereby preventing an SMI intercept from being generated when the CPU is in guest mode. In other words, an SMM handler (as a result of an SMI) can execute in SMM mode without the hypervisor having any control over it. This leaves a hypervisor on such hardware potentially vulnerable to malicious SMM handler code.

The NSA has developed multiple rootkits for this mode of operation. From the wikipedia on SMM:

By design, the operating system cannot override or disable the SMI. Due to this fact, it is a target for malicious rootkits to reside in,[12][13][14] including NSA's "implants"[15] which have individual code names for specific hardware, like SOUFFLETROUGH for Juniper Networks firewalls,[16] SCHOOLMONTANA for J-series routers of the same company,[17] DEITYBOUNCE for DELL,[18] or IRONCHEF for HP Proliant servers.[19]

Answer 2

Credential Guard is very effective against pass-the-hash attack as it removed support for all protocols/APIs that use NTLM hash.

It seems to prevent pass-the-ticket by hiding TGT in the VM. This is only sound if the LSA in the VM (LSAIso) can effectively vet requests for tickets, I am not quite sure how it gets enough info to do so.

Vulnerabilities that compromised the host may also apply to the VM. The VM approach only shrinks the attack surface not eliminating it. The most trivial attacks like keyloggers are still not prevented.

The removal of NTLM hash support (especially CredSSP) will force many applications/services that does not use Kerberos to prompt for credentials, possibly via plain dialogs/web forms that lack the protection of the secure desktop and would allow non-privileged malware to intercept the credentials. These apps may be using HTTP Basic without HTTPS which exposes the password in plain-text to the network. (HTTPS was not required for HTTP Negotiate/SPNEGO to work securely (sans the server's ability to pass the hash).) To avoid prompting for credentials on every request, applications will probably cache them in its own memory which is less protected than LSASS. Uses may also choose shorter password due to the loss of SSO.

In a sense deploying Credential Guard in an environement that relies on NTLM-based SSO does not necessarily improve security.

Answer 3

Background

Credential Guard uses a customized Hyper-V instance to store user credentials. There is still a local instance of the Local Security Authority, but it communicates to the virtualized instance via a special secure channel. The exact nature of this channel is not publicly documented, but only the LSASS may use it.

Attack vectors

For decades, there have been attempts to "break out" of virtual machines and compromise the hypervisor. These attacks are usually called virtual machine escape attacks.

Varying levels of success have been demonstrated against different hypervisors, ranging from information disclosure to arbitrary code execution. Most major hypervisors have had some vulnerabilities discovered.

Microsoft vulnerabilities

There have been arbitrary code escapes against Hyper-V. These attacks affected all versions from Server 2008 to Server 2016, including the desktop variants.

It is not clear that attackers could have extracted credentials from a Credential Guard guest after escaping a Windows 10 guest, but "arbitrary code" means they could have tried almost anything to do so.

Both Hyper-V vulnerabilities were announced and patched under MS17-008.

Analysis

While there are no disclosed cases of Credential Guard attacks in the wild, such attacks have always been theoretically possible. Moreover, the previous arbitrary code attack against Hyper-V demonstrates such attacks are entirely plausible.

Credential Guard effectively stops the most common form of lateral movement within a Windows network. It is the strongest technical barrier Microsoft has implemented in the years since the first PtH attacks. It is a very strong defense, but it would be foolish to assume it is completely effective and immune to compromise.

Conclusion

As with any sound security measure, you should both implement it and assume it can fail. This is consistent with the principle of defense in depth, which seeks to throw as many meaningful obstacles at an attacker as possible.

Due to a number of factors---potential attacks on Credential Guard, lack of support on older machines, lack of availability on older Windows releases---it is still necessary to retain other PtH mitigations for the foreseeable future.

Answer 4

Yes, it seems Credential Guard has effectively guarded the credentials. Vulnerabilities in any of the component (the trustlets, secure kernel, VSM or even hypervisor) can make a path to reach isolated LSA, that would be a different thing. But, to answer the question you asked, I would say the present implementation is effective in preventing Pass-the-hash style of attacks. The only option I see is to find a mis-configured or out-dated system to sniff out credentials.