June 9 2022 Thursday
Ransomware Prevention Part 10 - Credential Guard, the feature you didn’t know existed
Part 10 - Credential Guard, the feature you didn't know existed
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said all the way back in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
This series is now over a year in the making.....I hope a reader or two still exists.
Certain versions of Windows have a special feature called Credential Guard. Due to Microsoft not being, well, particularly into security this feature is not present in Home nor Pro versionS of Windows. I view this a travesty, but hey Microsoft makes tons of money so why should they care. It does exist in Enterprise and Education desktop Windows and also in Windows Server since 2016. If you have looked at doing Windows 10 Enterprise before, but haven't found a killer feature, then this is it (and LTSC). If you have never looked at buying Windows 10 Enterprise, this is the feature that should make you look into it.
Not only is is not widely available, it's woefully marketed. Did you even know about this? One of the two most important tools in the hacker prevention tool chest? (the other being SRP, aka part 6 in this series)
Credential Guard does what it says on the box, it protects credentials. Specifically in-memory credentials. These are stored in such a way as to be accessible to hackers once they compromise the device ("pass the hash" is the usual name for this type of hack). If you have no idea what I'm talking about go watch this video that uses the MimiKatz tool to extract in-memory credentials (password hashes to be exact) out of thin air....
https://youtu.be/bTYR_xYSDIk
Scared yet? If you're not then you're in the wrong job. Go read a gardening blog or take up knitting.
What the above video shows is how easy it is to effectively harvest credentials from Windows OSes. Credential Guard addresses this Windows "feature". It also worth noting that some CPUs now also have this type of protection built in, specifically AMD Ryzen Pro CPUs can have a similar protection enabled in BIOS. But on the Pro line.
OK, so I have Windows 10 Enterprise, or 2019/2022 server. How do I get this level of protection? For starters, VMs are a bit different, so I'll cover those later. Second, laptops with VPN clients are different so read this all before you enable it on laptops. Even a standard desktop OS it's a lot of convoluted steps. Thankfully Microsoft do provide a PowerShell script to simplify enabling it. They way it works it also a bit convoluted. The setup even more so. The PowerShell (see two paragraphs down) is a God send.
See, the "fix" Microsoft came up with is to install a Hyper-V machine on the device in question, lock it down and encrypt it and store the credentials in that Hyper-V instance. So now you have two PCs. Kind of. If you really want to know more about how it works see here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works
The PowerShell readiness/enablement script is here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/dg-readiness-tool
The above script needs to be ran in an admin PowerShell with the -capable switch, then you need to reboot and run it again with -capable. Be sure to check out the pre-reqs as well (UEFI, enable virtualization technologies in BIOS, etc.)
If the script says you can enable it, run it with -enable. A reboot and few auto reboots later, Credential Guard is installed. Note, if you use a VPN client on the device in question, chances are the VPN is not fully CG compatible, so be sure to check, If the VPN client is not CG compatible run with -enable -cg (so not just -enable, add the -cg).
Here I'm running the script with the -capable switch to see if my PC can indeed enable CG.....
I need to reboot, then I run the -capable again:
In the above screen shot I have highlighted an issue. In this case it is very likely a VPN shim driver as I'm running it on a laptop with a VPN client so I will run the "-enable -cg" flags to enable *only* CG (just "-enable", so without "-cg" does get me better security, but experience tells me it will stop my VPN client for working.)
Above, we can now see Hyper-V and IOMMU have been enabled. Time to reboot again....and then rerun the PowerShell with the -ready switch:
As you can see I now have Credential Guard enabled. The yellow warning are because I chose to *only* enable CG and not the other option as that would croak my VPN client. MimiKatz has now been taken to the vet and euthanized and the password hashes are no longer accessible to hackers. You can see this in action on this video:
https://youtu.be/urqXgBbVyWY
Once enabled my LSA credentials are not longer stored in-memory in plain text. This also adds another Windows process, LSALSO which is the new credential handler:
If this were a LAN PC, and hence no need for the -cg switch (I'm presuming a LAN connected PC doesn't need to VPN into the LAN.....) the -ready check should show this after I ran a straight -enable switch. Below is Windows 2022 Server after the -enable with all features green:
OK, servers. Physical servers are enabled the same as desktops. VMware Windows guests are different. These need to enabled in the VM options under Virtualization Based Security (VBS) and then the PowerShell ran as desktop. This feature is available in vCenter 6.7 and higher. At the time of writing I'm still not getting Windows Server 2016 to work even though it should, 2019 and 2022 are both fine. YMMV. As always take a snapshot for the VM before jacking with it. Checking the VBS box will enable IOMMU and UEFI (you should already be using UEFI anyway). Here's the check box in question for VMs (note, you only see this if you specifically set the guest OS version, i.e. Windows Server 2022 in the General Options section, if you leave VMWare Tools to figure it out this check box does not appear):
It is not lost on me the irony of a Windows VM running a Windows VM in order to secure it's credentials. Nested VMs like this used to be a big serious no-no but with the advent of CG/VBS most of the real-world arguments are around performance. I haven't seen an perceptible performance degradation on any VM, but again YMMV.
I'm a really big believer in doing Credential Guard whenever and wherever possible. If it's a 2019 or greater server and I've built it chances are it's CG protected. All of the STS desktops and laptops are CG enabled as well, although you do need Windows 10 Enterprise or Education to enable it. If you want to talk about getting on the Windows 10 Enterprise bus, drop Lisa a line and we can talk about it. It's a worth having if for no other reason than CG.
This is just the basics of Credential Guard so be sure to check out the additional mitigations you can also take to further secure your environment here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/additional-mitigations
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said all the way back in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
This series is now over a year in the making.....I hope a reader or two still exists.
Certain versions of Windows have a special feature called Credential Guard. Due to Microsoft not being, well, particularly into security this feature is not present in Home nor Pro versionS of Windows. I view this a travesty, but hey Microsoft makes tons of money so why should they care. It does exist in Enterprise and Education desktop Windows and also in Windows Server since 2016. If you have looked at doing Windows 10 Enterprise before, but haven't found a killer feature, then this is it (and LTSC). If you have never looked at buying Windows 10 Enterprise, this is the feature that should make you look into it.
Not only is is not widely available, it's woefully marketed. Did you even know about this? One of the two most important tools in the hacker prevention tool chest? (the other being SRP, aka part 6 in this series)
Credential Guard does what it says on the box, it protects credentials. Specifically in-memory credentials. These are stored in such a way as to be accessible to hackers once they compromise the device ("pass the hash" is the usual name for this type of hack). If you have no idea what I'm talking about go watch this video that uses the MimiKatz tool to extract in-memory credentials (password hashes to be exact) out of thin air....
https://youtu.be/bTYR_xYSDIk
Scared yet? If you're not then you're in the wrong job. Go read a gardening blog or take up knitting.
What the above video shows is how easy it is to effectively harvest credentials from Windows OSes. Credential Guard addresses this Windows "feature". It also worth noting that some CPUs now also have this type of protection built in, specifically AMD Ryzen Pro CPUs can have a similar protection enabled in BIOS. But on the Pro line.
If a hacker can harvest a domain admin account you are toast. They have already won. Just take down your tent and go home. Find a good gardening blog or take up knitting. Your job is to prevent that from happening......
OK, so I have Windows 10 Enterprise, or 2019/2022 server. How do I get this level of protection? For starters, VMs are a bit different, so I'll cover those later. Second, laptops with VPN clients are different so read this all before you enable it on laptops. Even a standard desktop OS it's a lot of convoluted steps. Thankfully Microsoft do provide a PowerShell script to simplify enabling it. They way it works it also a bit convoluted. The setup even more so. The PowerShell (see two paragraphs down) is a God send.
See, the "fix" Microsoft came up with is to install a Hyper-V machine on the device in question, lock it down and encrypt it and store the credentials in that Hyper-V instance. So now you have two PCs. Kind of. If you really want to know more about how it works see here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works
The PowerShell readiness/enablement script is here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/dg-readiness-tool
The above script needs to be ran in an admin PowerShell with the -capable switch, then you need to reboot and run it again with -capable. Be sure to check out the pre-reqs as well (UEFI, enable virtualization technologies in BIOS, etc.)
If the script says you can enable it, run it with -enable. A reboot and few auto reboots later, Credential Guard is installed. Note, if you use a VPN client on the device in question, chances are the VPN is not fully CG compatible, so be sure to check, If the VPN client is not CG compatible run with -enable -cg (so not just -enable, add the -cg).
Here I'm running the script with the -capable switch to see if my PC can indeed enable CG.....
I need to reboot, then I run the -capable again:
In the above screen shot I have highlighted an issue. In this case it is very likely a VPN shim driver as I'm running it on a laptop with a VPN client so I will run the "-enable -cg" flags to enable *only* CG (just "-enable", so without "-cg" does get me better security, but experience tells me it will stop my VPN client for working.)
Above, we can now see Hyper-V and IOMMU have been enabled. Time to reboot again....and then rerun the PowerShell with the -ready switch:
As you can see I now have Credential Guard enabled. The yellow warning are because I chose to *only* enable CG and not the other option as that would croak my VPN client. MimiKatz has now been taken to the vet and euthanized and the password hashes are no longer accessible to hackers. You can see this in action on this video:
https://youtu.be/urqXgBbVyWY
Once enabled my LSA credentials are not longer stored in-memory in plain text. This also adds another Windows process, LSALSO which is the new credential handler:
If this were a LAN PC, and hence no need for the -cg switch (I'm presuming a LAN connected PC doesn't need to VPN into the LAN.....) the -ready check should show this after I ran a straight -enable switch. Below is Windows 2022 Server after the -enable with all features green:
OK, servers. Physical servers are enabled the same as desktops. VMware Windows guests are different. These need to enabled in the VM options under Virtualization Based Security (VBS) and then the PowerShell ran as desktop. This feature is available in vCenter 6.7 and higher. At the time of writing I'm still not getting Windows Server 2016 to work even though it should, 2019 and 2022 are both fine. YMMV. As always take a snapshot for the VM before jacking with it. Checking the VBS box will enable IOMMU and UEFI (you should already be using UEFI anyway). Here's the check box in question for VMs (note, you only see this if you specifically set the guest OS version, i.e. Windows Server 2022 in the General Options section, if you leave VMWare Tools to figure it out this check box does not appear):
It is not lost on me the irony of a Windows VM running a Windows VM in order to secure it's credentials. Nested VMs like this used to be a big serious no-no but with the advent of CG/VBS most of the real-world arguments are around performance. I haven't seen an perceptible performance degradation on any VM, but again YMMV.
I'm a really big believer in doing Credential Guard whenever and wherever possible. If it's a 2019 or greater server and I've built it chances are it's CG protected. All of the STS desktops and laptops are CG enabled as well, although you do need Windows 10 Enterprise or Education to enable it. If you want to talk about getting on the Windows 10 Enterprise bus, drop Lisa a line and we can talk about it. It's a worth having if for no other reason than CG.
This is just the basics of Credential Guard so be sure to check out the additional mitigations you can also take to further secure your environment here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/additional-mitigations
