If you are like me, at some point in most penetration tests you'll have a session on a Windows host, and you'll have an opportunity to dump Windows credentials from that host, usually using Mimikatz. Mimikatz parses credentials (either clear-text or hashes) out of the LSASS process, or at least that's where it started - since it's original version back in the day, it has expanded to cover several different attack vectors. An attacker can then use these credentials to "pivot" to attack other resources in the network - this is commonly called "lateral movement", though in many cases you're actually walking "up the tree" to ever-more-valuable targets in the infrastructure. The defender / blue-teamer (or the blue-team's manager) will often say "this sounds like malware, isnt't that what Antivirus is?". Sadly, this is half right - malware does use this style of attack. The Emotet strain of malware for instance does exactly this, once it gains credentials and persistence it often passes control to other malware (such as TrickBot or Ryuk). Also sadly, it's been pretty easy to bypass AV on this for some time now - there are a number of well-known bypasses that penetration testers use for the Mimikatz + AV combo, many of them outlined on the BHIS blog: https://www.blackhillsinfosec.com/bypass-anti-virus-run-mimikatz But what about standard Windows mitigations against Mimikatz? Let's start from the beginnning, when Mimikatz first came out, Microsoft patched against that first version of code using KBKB2871997 (for Windows 7 era hosts, way back in 2014). Since then, this protection has been integrated into Windows 8.x, Windows 10 and Server 2016+. Unfortunately, even after applying this patch credentials are still stored in memory. You still need to update a registry key to disable this behaviour: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest (again, this is not required unless you still have Windows 7 or XP) However, what you'll find is that these protections only protect against the initial vector. Mimikatz and Microsoft are in an ongoing game of "cat and mouse" over this issue, and newer versions of Mimikatz have newer attacks. So What else can you do? As with everything, if you have SMBv1 or unsigned connections enabled, there are easier ways to skin the AD credential cat than to use Mimikatz - namely just use responder if you happen to have a host on the inside network: You might want to scan for hosts that still support SMBv1 and mitigate those ( https://isc.sans.edu/forums/diary/Rooting+Out+Hosts+that+Support+Older+Samba+Versions/22672/ ). You can also disable SMBv1 globally using GPO: Also, forcing the signature of SMB connections will help against responder-type attacks:
Back to Mimikatz Specific Defenses:
All too often we still see original-era Server 2008, Windows 7, or even Server 2003 and XP (or in some cases Server 2000! ). Needless to say, the newer Windows Server OS's shine a brighter light on security - newer really is better. If it won't break your server applications, update to Windows Server 2016 and Windows 10 (or 2019 if you are brave) Update Active Directory's Functional level Really this restates the first point. Many of the Enterprise Protections that we'll discuss later in this post simply aren't available unless your AD Functional Level is set to some modern version. If you can get the member stations updated, get your AD to 2016 at all possible! Disable the debug right for local administrators on all servers and workstation This is a newer attack - Windows has a "debug mode" that allows you to bypass many of it's native protections. This is meant mainly to troubleshoot things like device drivers and other OS or low-level Application components. Disable the WDigest protocol across the board This protocol was introduced way back in the day (XP era) for transparent HTTP authentication, and is still enabled by default in any surviving Windows 7 / Server 2008 hosts. It's disabled by default in Windows 8 and newer. Adding some monitoring of registry keys allows you to detect if a future attacker changes these settings back. Enable LSA protection (RunAsPPL registry key) This provides some protection of the memory used by the LSASS process. To enable this, in the registry, navigate to This one does have some risk, as it tries to apply protections to other components that LSASS might call (like 3rd party authentication code). This is the first mitigation that carries risk - this can break things! Fortunately Microsoft has some audit settings that can be deployed in advance to assess if you have a problem in this area first. More details on this, and the setting in general can be found here: https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
Disable storage of plain text passwords in AD Sometimes backwards compatibility thing comes back to bite Micosoft every day of the week. The "Reversible Encryption" setting is one of these. Back in olden times (Windows 2000 days), it was decided that people should be able to decrypt passwords, at the time mostly to make RADIUS work (IAS back then, now NPS). Sadly this setting remains with us today, and it allows you to decrypt passwords as fast as they can echo to the screen. To disable this, in Group Policy navigate to: Computer Configuration / Security Settings / Account Policies / Password Policy, and set "Store Passwords using reversible encryption" to "Disabled":
More details on this can be found here: https://www.blackhillsinfosec.com/your-password-is-wait-for-it-not-always-encrypted
This sets up your RDP session to NOT store credentials in the memory of the target host. To start a session in Restricted Admin Mode, run your RDP session as: mstsc /restrictedadmin /v:targethost Note however that this means that your credentials aren't cached (that being the point), so from that RDP session you won't be able to use cached credentials to "pivot" to another host - for instance you won't be able to run Server Manager, WMIC, PSRemoting or any other AD admin tool and connect to transparently to another host. That's a good thing, because if you could you would have just defeated your own protection (oops) You can also control this behaviour with registry keys: In HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa, set the DWORD value DisableRestrictedAdmin to "0" to enable restricted mode (this setting does not exist by default) also HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa, the DWORD value to create and set is DisableRestrictedAdminOutboundCreds:
More can be found on these settings here:
This sets "restricted admin mode" as the default for all RDP sessions that are initiated by domain members that are in scope for that GPO. This approach is generally preferred over setting the registry keys as outlined above The GPO seeting is: Enforce NLA (Network Level Authentication) for RDP sessions NLA forces RDP authentication over TLS (using a protocol called CredSSP), before the RDP session establishes. This means that this setting doesn't mitigate against Mimikatz per-se, since Mimikatz attacks are generally against the local machine - it is more of a "prevent password sniffing off the wire" mitigation, so it defends against responder and the like. However, this setting is typically deployed in combination with Restricted Admin Mode and Protected Users Groups (see below for this one). To enforce this in Group Policy: For Clients: Disable password caching By default Windows will cache the last "x" number of authentications (including the password hashes), in case no Domain Controllers are available. You can disable this in Group Policy at: Note that this might mess things up for people with laptops, who will want to login while away from the office. You can set up your VPN client to force a VPN connection before login, but that'll of course cause you headaches if you need to authenticate to a wireless hotspot first. Often that is mitigated by telling people to allow tethering to their cellphone, and then in written policies and technical controls forbid the use of free/public hotspots such as hotel or coffee shop wifi. This is a simple and effective mitigation, but it needs some thought and communication in advance to make it work in many organizations.
Put administrative accounts in the “Protected Users” AD group, to force Kerberos authentication Before using the Protected Users group, carefully review at least these two "starter" MS docs on this topic - there are pre-requisits and some gotchas! From the MS Documentation: If the domain functional level is Windows Server 2012 R2 (or higher), members of the group can no longer: So for our discussion it disables most of the password caching we've discussed, forces Kerberos Authentication, and disables DES and RC4 ciphers.
As the name implies, Credential Guard, well, guards your credentials. The configuration for Credential Guard is somewhat convoluted, but the high points are:
Have we mentioned that this is an arms race? In September of 2018, a bypass of this protection was announced in Mimikatz. While prior to this Mimikatz could harvest hashes directly from memory, what this bypass does is harvest credentials as they are entered - before they get to that protected memory area.
Again, this one doesn't stop Mimikatz from stealing credentials from the machine, but what it does do is prevent the re-use of those credentials for lateral movement to other targets, which is usually the whole point of the attack. In Active Directory Admin Center (ADAC), under Authentication Policies, the option exists to for instance "pin" a service account to the host that the service runs on. This means that that account (which is likely privileged) can't easily be used for lateral movement, even if the credentials are successfully recovered (using Mimikatz or other methods).
Set long and complex passwords for admin and service accounts There are always more Mimikatz attacks - I haven't covered Kerberoasting and extraction of password hashes for services for instance, mainly because this story is more for the "Blue Team" defenders than the Red Team (attackers) - stay tuned, we'll get there on attacks. Other defensive measures There are log entries to look for to detect Mimikatz as well, but that's more detection than prevention - I'll try to cover that in a future post. I'll also run through some Mimikatz attack scenarios if someone doesn't beat me to it :-)
With this list behind us, it's apparent that this game between Mimikatz and Microsoft is an ongoing thing. I'm sure that I've missed things in the list above, but this is a decent "starter" list of mitigations that should give you some decent coverage. A determined attacker is likely to be able to still "get the job done", but implementing everything above will likely slow them down. Automated malware that uses Mimikatz methods has less chance, no surprise there. I'd also not be surprised if an entirely new attack doesn't pop up in the next few months, with a new defense from Microsoft to match it. Also with everything being said, I've yet to find an AD domain where everything above has been implemented. Most AD Domains that I've assessed or pentested still have Server 2003 or Windows 7 (or even Server 2000!) members in production, so some of the recommended settings above can't be implemented yet. Challenge to our Readers: With everything I've described, what Mimikatz attacks do you use that will still execute successfully after the mitigations above are in place? Please, use our comment form and share - I'd count this one as a win if we have more mitigations posted by you, our readers than I have in the write-up above!
==============
|
Rob VandenBrink 563 Posts ISC Handler Feb 5th 2019 |
Thread locked Subscribe |
Feb 5th 2019 2 years ago |
Great write up. One thing that always confused me about disabling SMBv1 via group policy was the "SMB1 server" and "SMB1 client" registry additions that need to be made. Do both of those registry additions need to be deployed to workstations?
|
Anonymous |
Quote |
Feb 5th 2019 2 years ago |
You'll want both - any local share (including a printer) makes you a server.
You can also "help the cause" on this front this with DHCP settings - disable Netbios over TCP for your DHCP clients at: Server options / advanced / then set option 001 (Microsoft Disable Netbios Option) to "0x2". This won't disable SMBv1, but will disable NBT at least for any hosts out there that aren't domain members. |
Rob VandenBrink 563 Posts ISC Handler |
Quote |
Feb 5th 2019 2 years ago |
Great post Rob. Looking forward to reading your detection write up if you get around to it!
|
Anonymous |
Quote |
Feb 5th 2019 2 years ago |
Thanks Rob for the great post!
I've presented on Mimikatz detections using Sysmon and Splunk at two FIRST events. Maybe there's some useful info in there for you to use or expand on? Slides: http://security-research.dyndns.org/pub/slides/FIRST-TC-2018/FIRST-TC-2018_Tom-Ueltschi_Sysmon_PUBLIC.pdf Blog: http://c-apt-ure.blogspot.com/2017/12/is-this-blog-still-alive.html Related: https://twitter.com/c_APT_ure/status/1092035814387798016 Hope it's useful for someone ![]() Cheers, Tom |
TomU 8 Posts |
Quote |
Feb 6th 2019 2 years ago |
Great article Rob!
I've been waiting to find information all in one place like this for quite some time! What about flagging admin accounts in AD by checking the "account is sensitive" box? I read about that here: https://www.theregister.co.uk/2018/12/03/notpetya_ncc_eternalglue_production_network/ If setting that helps stop of the spread of malware like NotPetya, might it also protect against other attacks? |
rand0m 8 Posts |
Quote |
Feb 7th 2019 2 years ago |
Sign Up for Free or Log In to start participating in the conversation!