Why you should frustrate your pen testers

The third or fourth step in any breach (depending on who you talk to) is that an attacker must ‘gain authority’. Think of it like a bank; if the criminal breaks into the vestibule they have little or nothing to steal, they have to get from the vestibule to the main area of the bank, then they need move to the vault where the cash is stored. Each step requires gaining authority over the area where the valuables are stored. The same thing is true on networks, provided that at least some level of least privilege was performed ahead of time, and the network’s data or “valuables” aren’t just sitting there for the taking.

In our scenario, Admin Assistant Dave gets phished and the bad guys ‘hook’ his Windows 10 machine. Dave is not a local administrator and only has access to the things he needs to do his job. Our bad actor didn’t go through all this for that little haul, plus to gain persistence and drop malware (the real goal) he needs admin rights, first local and ultimately domain. This is where it gets interesting.

There are basically 5 ways that attackers harvest credentials on a Windows network in order to gain authority:

1. Hashes
2. Tokens
3. Cached Credentials
4. LSA Secrets
5. Tickets

If a business has the will, the fortitude, the budget and resources, they could thwart 90% of these methods and make the other 10% difficult. How?

Hashes –

• Upgrade the domain to Windows 2012R2 functional level
• Use Windows 10 enterprise
• Use Domain Protected Groups for all elevated accounts
• Use credential guard on the workstations
• Don’t use privileged accounts for interactive remote sessions
• Proper termination of RDP sessions

Tokens –

• Same as hashes above except also designate accounts as ‘Accounts cannot be delegated’ in Active Directory

Cached Credentials –

• Limit the number of cached logons by adjusting the registry
• Enforce password length and complexity rules
• Again, Domain Protect Users Group – requires Windows 2012R2 functional level

LSA Secrets –

• Do not use services or scheduled tasks requiring privilege on low trust systems
• Heavily audit any accounts that need to be used as services or scheduled tasks
• Make sure least privilege is used for these accounts (for example denying interactive logon for them and allowing them logon to only systems required in AD)
• Group managed accounts (requires Win2008R2 or newer) functional level

Tickets –

• Credential Guard (Win 10 enterprise or newer)
• Remote Credential Guard (Win 10 enterprise or newer)
• Long and complex passwords for service accounts
• Group Managed Service Accounts (requires Win2008R2 or newer)
• Heavy auditing of service accounts
• Change the KRBTGT password regularly

So why doesn’t every organization just do these things? One reason is budget. As you can see many of the features to perform this sort of hardening require up-to-date systems. That requires budget and time.

Next, knowledge is required. Group managed accounts have been around for a while but few know about them and use them. We see all the time in our consulting engagements where service accounts are just Domain Admins and not restricted and these features are not put into use. Many times, this is because of lack of resources in IT as this is the easy way to make sure everything functions, but it is not the right or secure way.

Finally limiting local administrator accounts by using LAPS (local administrator password system) a free tool from Microsoft, and restricting tools such as PowerShell remoting, to known-good jump boxes fills out the methods of controlling lateral movement. By doing these things we put the adversary in a box -they may get into the vestibule but they can’t get into the bank.