Making Lateral Movement Difficult in an Active Directory Environment
Last updated
Last updated
Intro:
I recently saw this post via Twitter:
And one thing that caught my eye was the "Pass the Hash" mitigation screenshot. I saw the GPO settings and understood their functionality but couldn't really piece it's full impact together until I tried it myself. I wanted to do a quick post illustrating a) how easy it is to set the GPO up and b) how large of a security impact it really has.
The Problem:
Does this scenario sound familiar to you: all your organizations' endpoints have a local administrative account with the same password? If it does, you're probably not alone as this is fairly typical practice. From an attackers standpoint though, this is a goldmine, as one compromised credential can mean access to many machines. Access to many machines also means that there's a greater chance that the attacker can grab sensitive credentials - Domain Admins etc - from these machines.
Let's illustrate this. I'm an attacker and I gained access to a workstation where the user was a local administrator. I proceed to dump hashes or pull clear text credentials and I'm now trying these credentials in the environment to see what they have access to.
In the below example, I'm using the awesome CrackMapExec to try a local administrative user / password combo that I acquired on my lab machines:
Awesome, I am now using one set of credentials to access all the machines on the network.
Since this is a local authentication attempt, the SOC will not likely see this unless you are collecting endpoint logs in addition to server and domain controller logs.
How then do we use the GPO above to make things harder for the attacker?
The GPO:
The GPO entries are found in Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Local Policies --> User Rights Assignment:
And an export of the GPO so you can see which groups get added to what policies.
Now that we have our GPO set, we apply it the computers we want. In my lab environment there are only two hosts so we put them in an OU and apply the GPO there:
At this point I had a question that you may or may not have. How does the GPO understand the concept of 'Local Account' ?
In other words, if you had two or more local accounts on your endpoints, how does the GPO understand the scope to mean all local accounts?
After some digging I found this article which cleared things up for me:
https://blogs.technet.microsoft.com/secguide/2014/09/02/blocking-remote-use-of-local-accounts/
After the release of KB 2871997, Microsoft introduced two new SIDs:
S-1-5-113: NT AUTHORITY\Local account
S-1-5-114: NT AUTHORITY\Local account and member of Administrators group
And these are what - for lack of a better term, link - the "local account" in the GPO to "all local accounts".
Although out of scope for this post, KB 2871997 also gives us the ability to disable clear text credential storage. A great post about this can be found here:
https://p16.praetorian.com/blog/mitigating-mimikatz-wdigest-cleartext-credential-theft
Lateral Movement Blocked
Now that we have our GPO in place, let's try to run CrackMapExec again and see what happens:
Pretty sweet. This time we are denied this access.
Recall that we also denied Domain Admins rights to log in locally or via Remote Desktop
So even if the attacker somehow has a domain administrator account, they would not be able to just use it on every system in the network. This also prevents domain administrators from using their credentials on endpoints where there is greater risk of credential theft.
And of course, the same restrictions apply to remote desktop:
Pass the Hash techniques are also a no go:
The Bigger Picture
As I mentioned above, the original Microsoft blog post highlights the GPO that we went over as a "Pass the Hash Mitigation Technique" Indeed it is so, but it also helps mitigate lateral movement via local administrative credentials.
This GPO however fits into a broader context of privileged access management & privileged access workstations. The idea is that domain administrators use segregated privileged access workstations to perform administrative Active Directory tasks with their Domain Administrator accounts. This GPO would prevent a Domain Admin from exposing their credentials on a less trusted workstation. The goal is to make it increasingly difficult for an attacker to get a hold of such sensitive credentials.
With this GPO in place in addition to proper domain admin segregation, an attacker would have a very difficult time to not only move laterally throughout the environment, but to also get a hold of DA credentials.
Wrap Up
Nothing in this post is new content, but when I first saw the GPO settings recommended, I didn't really grasp how they are actually implemented and what exact impact they had. If you had the same confusion, I hope that this post clears it up and paves the way for you to put this in place in your organization.
References
CrackMapExec --> https://github.com/byt3bl33d3r/CrackMapExec // https://twitter.com/byt3bl33d3r
The Original blog post I mentioned at the start of the post by Jessica Payne --> https://twitter.com/jepayneMSFT
Preventing local accounts from authenticating over the network is mentioned on ADSecurity as well --> https://adsecurity.org/?p=3299
Some more information about passing hashes --> http://www.harmj0y.net/blog/penetesting/pass-the-hash-is-dead-long-live-pass-the-hash/
General wisdom for AD defense --> https://twitter.com/PyroTek3
More information about privileged access workstations --> https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations
More ADSecurity wisdom --> https://adsecurity.org/?p=1684
I would love to hear from you if anything in this post is incorrect or if you tried this in your environment and had some additional insight. If you have any questions also feel free to get in touch
