I’ved logged more than 1,000 hours of internal pentesting in 2025 alone. I promise you, attack paths are everywhere. And attackers are counting on you not caring enough to find and fix them.
And you know, someone is going to find them, sooner or later.
It might be a pentester, it might be you, or it might unfortunately be a threat actor with initial access to your environment.
I think we both agree it’s probably better that you (or someone like me ;) ) find them.
The problem though is that running tools like BloodHound can be a bit confusing. It’s also a bit of a learning curve.
And waiting for your annual pentest isn’t always the best option either.
So here’s how to find attack paths in Active Directory without BloodHound, without waiting until your next pentest.
When you boil this down to it’s smallest components, in order to identify attack paths you have to know two things: 1) where to look, and 2) what to look for.
1) Where to look
The first and most important places to look for attack paths are your critical and privileged resources. Think, Domain Controllers, Domain Admins, Enterprise Admins, etc. What we typically refer to as tier 0 or wherever you have critical processes or sensitive data.
You want to look here first because misconfigurations related to these resources are the most impactful.
When I say look at your Domain Controllers, I’m saying look at the Computer object itself in Active Directory. The permissions, the Organizational Units, group membership, etc. More on this in the next section.
This is what I refer to as inbound control. You want to enumerate all the possible actions that can be taken upon that critical/privileged resource.
Then, you want to investigate what I call “unsafe groups.”
The initial list for those are: Authentication Users, Domain Users, Domain Computers, Everyone.
These are unsafe because they generally involve a large number of low-privileged users.
The thing you want to look for here is outbound control. In other words, what are the possible actions that these resources can take on other objects/resources.
Example:
The unsafe group, Everyone, has “FullControl” (more on this in a minute) over the root of the domain. If you’re like “holy crap how?!” My thoughts exactly.
But I’ve seen this on two separate internal pentests. Crazy right…
2) What to look for
A large number of Active Directory attack paths rely on misconfigured or dangerous permissions in some way. Not all of them, but a lot of them. So let’s focus on that.
What permissions you might be asking?
Here’s a good starting point. I call these “unsafe permissions.”
By the way, this is not an exhaustive list.
Writeallproperties
Genericall
FullControl
WriteDACL
ReplicateDirectoryChanges & ReplicateDirectoryChangsAll (DCSync)
ResetPassword
Of course, context matters a lot here. It’s not dangerous for Enterprise Admins to own and have FullControl over certificate templates.
However, if the “Everyone” group has FullControl over the root of the domain, that’s really bad.
Now that we know where to look and what to look for we need to know how to actually find these issues that create attack paths.
First and foremost you can obviously use Active Directory Users and Computers (ADUC). From there, make sure to enable “Advanced Features.”
Then you can inspect the permissions of objects in Active Directory. You can view group membership and Organizational Unit structure.
The next way to identify these issues that lead to attack paths is with one of my favorite tools, ADeleginator.
It’s a tool I wrote, which is a wrapper around ADeleg, that finds many common misconfigured delegated permissions in Active Directory.
Finding these issues I mentioned above is as simple as downloading a file and running a PowerShell script.
Here’s the steps:
Copy
Invoke-ADeleginator.ps1to your system orgit clone <https://github.com/techspence/ADeleginator>Download ADeleg.exe and place it in the same folder as
Invoke-ADeleginatorOpen PowerShell, navigate to the location of
Invoke-ADeleginator.ps1and dot source it using:. .\Invoke-ADeleginator.ps1Run with:
Invoke-ADeleginator
Now just review the resulting CSV files.
It’s literally that simple.
What now?
Now you block some time off on your calendar, maybe an hour or two, and try this in your environment. Best case, you don’t find anything. Win!
Worst case, you do find things. Also a win!
I’ve done A LOT of internal pentesting. I know how this can seem daunting and intimidating and time consuming.
But I promise you, it’s worth it.
All the best
Spencer Alessi
PS - This is quite literally my day job, so if you want help finding attack paths in your environment, you can book a discovery call with me here. I’d love to help.
