Complicating Credential Theft
You've hopefully noticed a pretty consistent theme in this post series: If you are not acutely aware of how credentials are exposed on the systems in your network, sooner or later you're going to lose your network.
You've hopefully also noticed that there are some ways that are far safer than others when it comes to using a privileged account on a remote system.
Now that we know how things can go sideways, let's spend a bit of time talking about how to make things better, which is ultimately why we do what we do.
Patch the Katz
Like really patch it. If you're running anything up to and including Windows 8/2012, your credentials are just sitting there waiting to be burgled.
Pretty much every domain I've seen has KB2871997 installed and not a single one has actually implemented the corresponding registry key to prevent everyone's cleartext credentials from appearing in memory.
Perhaps they all make heavy use of the WDigest SSO functionality, but I'm guessing that they just haven't read the patch notes. Because who has time to read every patch note for every patch? Not me, that's for damn sure. I just install them. Next, next, OK, next.
It may well be that this is the only patch that requires extra intervention. I have no way of finding that out. My money is on it being the most critical patch to require manual intervention, though. This is one that is definitely worth the effort. All you need to do is set the following registry key (preferably using Group Policy Preferences with the Replace option):
That's it! Goodbye, cleartext credentials!
Preventing Token Theft
Token theft is a bit trickier, because it's really exploiting the way Windows works. We have two ways of preventing token theft.
Block Delegation of Sensitive Accounts
If you use delegation in your domain, ensure that your privileged accounts are not allowed to participate.
Not sure if you use delegation? Here's a one-liner that should help your out:
In the above one-liner, the TrustedForDelegation refers to unconstrained Kerberos delegation, which allows your tokens to be spread all over the damn place---anywhere the delegating server likes. The TrustedToAuthForDelegation is a lot more specific and requires an Enteprise or Domain Admin to define which services your delegated tokens can be passed to.
Stopping both types of delegation is easy. Under the properties of the user account in Active Directory Users and Computers, you'll find a checkbox that says Account is sensitive and cannot be delegated. Do this for all of your sensitve accounts.
Unfortunately, the magical checkbox won't do a damn thing to protect your Primary Tokens, which can just as easily be stolen. For that, the best cure is to just make sure that your privileged access tokens don't show up in the seedier areas of your network, which is easier said than done.
Silos Full of Administrators
One of the most effective things you can do to limit or eliminate opportunities for credential theft is to create administration silos in your environment. These silos group devices of a similar level of trust together, and restrict administrator accounts to a single silo, ensuring that your Domain Admins are never logging on to a sketchy workstation to sort out some strange ransomware problem.
To do this, start by creating some trust-based tiers to your environment.
I'm going to simplify Microsoft's fantastic Securing Privileged Access guidance here and say you should roll with these:
- Tier 0 - Domain Controllers, things that control Domain Controllers.
- Tier 1 - Servers
- Tier 2 -
Next, create groups to be used for the administration of each of these tiers (Domain Admins, Server Admins, Workstation Admins) and then use Group Policy to grant each group appropriate rights to the devices in its tier.
Group Policy is a b-e-a-utiful tool when you're looking to prevent unsafe logons by users to devices in a different tier of trust. Make judicious use of the following settings and chuckle as your token-spreading administrators are confined to their tier:
|Policy||Tier 0||Tier 1||Tier 2|
|Deny access to this computer from the network||WA, SA||DA, WA||DA, SA|
|Deny log on as a batch job||WA, SA||DA, WA||DA, SA|
|Deny log on as a service||WA, SA||DA, WA||DA, SA|
|Deny log on locally||WA, SA||DA, WA||DA, SA|
|Deny log on through Terminal Services||WA, SA||DA, WA||DA, SA|
DA - Domain Admins, SA - Server Admins, WA - Workstation Admins
The above configuration implements strong technical controls that will prevent privileged tokens from appearing anywhere but on privileged devices. Even if you completely own a workstation, at best you'll gain access to the rest of the workstation tier.
The above groups are a starting point. You'll also likely want to add other privileged groups that may be present in your domain.
The goal here isn't a one-size-fits-all solution. Think about how you administer your domain and put restrictions in place to ensure you're not causing yourself any headaches.
Local Administrator Lockdown
In my experience, local administrator accounts are almost always enabled, almost always have the same password, and are totally ignored from a security standpoint. What's the big deal if someone gets local?
By now I hope you can answer that. Token theft, credential theft, and pass the hash are the unholy trinity of cred-based attacks and local administrator accounts with common credentials are one of the big enablers.
Further, in a domain environment, there is likely no reason for you to have a local administrator account enabled. Administration can be performed with domain-level accounts nested in the local
Administrators group and in the eventyou lose your domain and need to administer something, the built-in administrator account is always enabled in safe mode. Disabling the built-in Administrator account is especially important since the pass-the-hash mitigations provided by KB2871997 do not apply to it.
So, delete all non-RID500 administrator accounts. Then disable
Administrator, preferably with Group Policy. Enable audit logging for local account creation and modifications to
Administrators group membership.
KB2871997 also 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
These can be used in conjunction with the "Deny access to this computer from the network" to block all non-RID500 remote access using local accounts. Winning! Unfortunately, as detailed in Harmj0y's post on the topic, this doesn't apply to the built-in
Even if you've completely disabled all local accounts, it's still worth deploying LAPS, which effectively renders pass-the-hash using LAPS-managed accounts a non-event.
Logons Full of Network
Finally, when using privileged accounts, ensure you're using network logons whenever possible. Interactive logons should only be used as a last resort when no other options are available. This ensures that there are limited opportunities for an attacker to gain access to your credentials or a solid credential proxy, like a token, and spread through the rest of the tier.
Credential theft is a hard thing to stop, but you can make it a lot less rewarding for attackers with very little effort. Think about how credentials are used in your domain and make attackers work for their DA.
- Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain)
- Protecting Privileged Domain Accounts: Safeguarding Access Tokens
- Protecting Privileged Domain Accounts: Safeguarding Password Hashes
- Protecting Windows Networks - Dealing with credential theft
- S4U2 Pwnage
- Trust? Years to earn, seconds to break
- Windows LSA Secrets
- Pass-the-Hash is Dead: Long Live LocalAccountTokenFilterPolicy