Active Directory Case Study: From Low-Priv User to Attack Path Discovery
Not domain or local admin. Just a regular domain user and access to a domain-joined workstation. No alarms. No crashes. No ransomware screens. From the outside, everything looked normal. But from the inside, this is where the real work begins.When people think about penetration testing or red teaming, they often imagine exploits and payloads. In reality, a large part of the job looks more like quiet observation than active exploitation.
– The First Hour After Foothold
When I first got access to the workstation, I did nothing for a few minutes. No tools, no scripts, no scans. Just a shell and a terminal.
In my early days, I used to immediately upload tools and start collecting everything. BloodHound, credential dumpers, network scanners. It felt productive — like I was moving fast.
In reality, I was just being loud.
Now, I work differently. The first hour is not for attacking. The first hour is for understanding.
I started with the simplest question:
whoami /all
This single command tells you more than most people realize — group memberships, privileges, logon information. You’re not just looking for admin rights. You’re looking for anything unusual: Backup Operators, Account Operators, custom IT groups. Anything that might be useful later.
Next question:
echo %USERDOMAIN%
nltest /dsgetdc:%USERDOMAIN%
Now I know the domain name and the Domain Controller. That’s important. Active Directory is the environment, and the Domain Controller is the center of it.
Then I wanted to know if this machine was interesting or just a random user workstation.
query user
hostname
If an admin is logged into this machine, the entire strategy changes. Suddenly, you’re not thinking about enumeration anymore — you’re thinking about credentials, tokens, and lateral movement.
But in this case, no admin sessions. Just normal users.
So I continued with quiet domain enumeration using built-in commands:
net user /domain
net group "Domain Admins" /domain
net group /domain
This is where the mental map starts forming. You start seeing naming conventions, service accounts, admin groups, departments. The domain slowly stops being an abstract thing and starts looking like an actual environment run by actual people.
And that’s the key: Active Directory is not just technology. It’s an organizational map.
If you understand the organization, you can often predict where the weaknesses are.
By the end of the first hour, I didn’t have Domain Admin.
I didn’t have passwords.
I didn’t have hashes.
But I had something more important: context.
And in Active Directory attacks, context is everything.
– Kerberos: Worth the Noise?
After the initial enumeration, the next big question was Kerberos.
Kerberoasting is one of those techniques that appears in almost every Active Directory guide. Because of that, many testers run it automatically, like it’s just another checklist item.
I don’t do that anymore.
Kerberos attacks generate traffic. Tickets are requested. Things get logged. And if you roast every service account in the domain, someone might notice.
So instead of asking, “How do I Kerberoast?” I ask a different question:
“Is Kerberoasting even worth it here?”
First, I look for Service Principal Names (SPNs). These usually belong to service accounts — accounts running SQL servers, web services, backup systems, and other infrastructure.
What I’m looking for is not just any SPN, but a good target:
- A human-managed service account
- An old password
- Membership in some IT or admin-related group
- Something that suggests this account might lead somewhere
Then I check for AS-REP roasting candidates — users who don’t require Kerberos preauthentication. These are rare in well-configured environments, but when you find one, it’s like finding a door that was accidentally left unlocked.
Now comes the part that no tool can really do for you: decision making.
If I roast a service account and crack the password, what do I actually get?
Does that account log into servers?
Is it a local admin somewhere?
Is it part of a group that has special rights?
This is why enumeration and analysis are more important than just running attacks. You’re not trying to collect passwords. You’re trying to find a path.
In this case, I found a service account with an SPN, an old password, and membership in a custom IT group. That was enough to justify Kerberoasting — not because Kerberoasting is cool, but because this specific account looked promising.
That’s the difference between random activity and a targeted attack.
And that’s also where modern workflows start to include automation and AI — not to hack automatically, but to help analyze relationships, permissions, and possible privilege escalation paths faster than a human can manually.
But even with AI, the most important part is still the same:
You need to know what you are looking at.
Tools can collect data.
AI can analyze data.
But you still need to think.
Small conclusion
Active Directory attacks are rarely about one big exploit.
They are about small steps, small weaknesses, and good decisions.
