After 1,000’s of hours inside internal networks I’ve developed a “spidey sense” for finding Active Directory attack paths. Here’s 4 attack paths to look for in your environment and how to find them.
1. Help Desk with control over Tier-0 accounts: this is actually one of the more common issues I see. It’s not always exactly help desk. Sometimes it’s “database admins” or “service desk” or “application admins” or similar.
What to look for: Check your IT administrative groups, ones where the members should not be domain admins or equivalent, and look for where they have elevated permissions on tier-0 resources.
This topic is exactly what we’re going to be talking about on the upcoming IS Decisions webinar. They’ve sponsored me to be a guest and I’m super excited to share what I know about AD security and making your environment harder to attack.
It’s this Wednesday at 11am Eastern. Click here to save your spot.
2. Finance group members of local admins: on more than one internal pentest I’ve seen low-privilege non-admin groups, such as finance, be members of a group that’s then added to local administrators on all workstations.
What to look for: check your non-admin groups to ensure they are not members of administrative or privileged groups, like local admin groups.
3. Domain Users/Computers with certificate abuse potential: this is a catch all for both ESC1 and ESC4, both of which can result in privilege escalation to Domain Admin by either directly requesting a vulnerable certificate template or by modifying the settings of a template.
What to look for: check your certificate templates for those that low privilege users can enroll in, that allow supplying an alternate SAN, are enabled for client authentication and don’t require manager approval. That’s ESC1. Then check the permissions on each template to ensure low privilege users don’t have FullControl or modify rights.
4. SQL credentials on shares & SQL running as Domain Admin: this is a multipart issue where SQL credentials are found in web.config files on shares. Then it turns out, more often than not, that the SQL service is running as a Domain Admin. This is unfortunately very common to see.
What to look for: audit file shares looking for credential files, like web.config. These often have plaintext credentials in them and are a prime target for attackers. Then check your SQL accounts to make sure they are not domain admins, if at all possible.
This is really just scratching the surface. This list doesn’t even include some of the wildest attack paths I’ve seen, like that one time when the Everyone group had FullControl at the root of the domain!
Run through this list in your own environment and even if you don’t find these exact issues, I bet you at least find mistakes you can fix.
Go make your environment harder to attack.
All the best
Spencer
By the way, you should absolutely register for the upcoming IS Decisions webinar I am a guest on. Here’s the link. It’s gonna be fun! See you there!