smallsec
about | contact

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):

1
2
3

Key:     HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest
Setting: UseLogonCredential
Value:   0

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:

1
2

# Script from http://blog.backslasher.net/finding-accounts-trusted-for-delegation.html
Get-ADComputer -Filter * -Properties Name,Description,msDS-AllowedToDelegateTo,TrustedForDelegation,TrustedToAuthForDelegation |Where-Object {$_.TrustedForDelegation -eq 'True' -or $_.TrustedToAuthForDelegation -eq 'True' -or $_.'msDS-AllowedToDelegateTo' -ne $null} | Select-Object Name,DNSHostName,Description,@{Name='msDS-AllowedToDelegateTo';Expression={$_.'msDS-AllowedToDelegateTo' -join ";"}},TrustedForDelegation,TrustedToAuthForDelegation

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:

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:

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 Administrator account.

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.

ELI5

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.

Resources

<<
>>