Longer Read But In Depth on AD Attack Paths
This is a pretty cool scenario. I really like more unique paths, but I want to highlight that this is not what I would call a “common” path. Most networks are not mature enough to warrant such attack paths. In general, AD environments are plagued with decades of configuration debt. There are USUALLY tens if not hundreds of relatively simple ways to get DA that involve a mix of misconfigurations and built in Microsoft bad.
This is a longer read cause I like to explain, but through it all notice how getting DA is really six-seven commands and very simple.
Let’s dive into what I would call a common scenario for how you would breach AD following the path of least resistance. This will be a longer read, but a worthwhile one if you’re newer to AD.
As you read, try to identify the moment you spot the path to Domain Admin and at what stage it becomes clear.
The Scenario
For this scenario let’s assume you have a machine on their network. It’s a Linux device that is plugged into their corporate network. It’s layer two adjacent to a bunch of other normal corporate machines. You have assumed breach creds to their domain to use IF NEEDED but you are to see if you can gain initial access WITHOUT using them.
The Goal
Compromise multiple Active Directory domains. See if you can breach their CDE(Card Data environment) or the segmented portion of the network. They’ve also authorized full dumping of their NTDS.dit for credential analysis.
Initial Access
Most networks are still susceptible to layer-two coercion attacks, either via rogue DHCPv6 servers or standard broadcast-based tricks. You run responder and see you can get net-ntlmv2. You run mitm6 with some good configs and more come in.
You then run a bunch of enumeration.
1. You find the domain via your /etc/resolv.conf file along with some dns servers. You run DNS SRV record enumeration to find the systems where Kerberos, ldap and global catalog are running. Which shows you where the domain controllers for that domain are. (AD creates DNS SRV records for services like Kerberos.) Doing this you see the domain is
corp.companynet.com. You then run another SRV enumeration against the parent domain of
company.com and no dice. But now you have the locations of domain controllers.
2. You see reference to another domain in the srv enumeration,
cde.companynet.com but are unable to reach its domain controllers. You see their hostnames and IPs though.
2. You scan the corp domain controllers and see one is running port 80. You then wget http:<domaincontroller>/certsrv/certfnsp.asp and see it responds with a “401 unauthorized”. It’s likely running a ADCS web enrollment endpoint so ESC8 is likely possible. You note it.
4. You port scan the environment for port 445 and identify hosts with SMB signing disabled. Most likely if you can admin access to any of these you can dump Sam and LSA secrets but lsass is unlikely without effort.
5. You attempt null smb sessions, and share enum just as a habit. Not much.
6. You find a list of MSSQL endpoints that you can relay the authentication to if nowhere else exists or as possible future opportunities for a more complex attack chain.
7. In your scanning of hosts with port 445 open, you find machines that are a part of
tech.comp.int. You run srv enumeration and find their DCs.
8. In your scanning you take note of windows devices with SCCM in the hostname.
At this point, you’ve gathered enough intel to form a solid plan with a 95% chance of getting you Domain Admin on corp. Can you see it yet?
Taking the Path of Least Resistance
There are a lot of ways we could take this engagement. However, taking the path of least resistance saves time and lets you work backward to uncover deeper issues.
Continued in the comments/replies
This is what a real-world path to Domain Admin looks like on an internal network (from a past internal pentest of mine)
*assume compromise*
1. Find a web config file with plaintext domain creds
2. That domain account is a local admin on a sql server
3. Pivot to the sql server using RDP (locked by mfa)
4. Pivot to the sql server using psremoting
5. Discover a scheduled task running (as a domain admin) a batch file from c:\scripts
6. Modify the batch file to add our initial account into the domain admins group
7. Psremoting to the dc for the screenshot
Notes for defenders:
1. Audit shares regularly for credential files
2. Ensure tasks run with least privilege (not DA accounts)
3. Ensure alerts are generated upon modification of tier 0 groups
4. Restrict access to servers from untrusted systems (like Suzie in accountings PC)