Why I Get Domain Admin in Every Penetration Test

People ask me why penetration testing is worth the cost when "we already have EDR and a firewall." Then I show them how I get Domain Admin access in their environment, usually within hours.

The truth that security vendors won't tell you: products don't fix misconfigurations. You can have the best EDR money can buy, but if your service accounts have weak passwords and Domain Admin privileges, I'm going to exploit that. No alert will fire because I'm using legitimate protocols the way they're supposed to work.

My Standard Attack Path

Here's what a typical day looks like when I start an internal penetration test:

Hour 1: I plug into the network and run Responder. Within minutes, I'm capturing NTLMv2 hashes from machines looking for network resources. Most of the time, SMB signing is disabled, so I can relay these directly.

Hour 2: While Responder runs, I enumerate the domain with a standard user account (often from a compromised workstation or credentials from the captured hashes). I find service accounts with SPNs and request their Kerberos tickets.

Hour 3: I crack the service account passwords. "SqlService2019!" cracks in under a minute. The service account has Domain Admin rights because "the application needed elevated privileges."

Hour 4: I'm Domain Admin. The engagement just started.

What Goes Wrong

This isn't about sophisticated hacking. It's about basic hygiene that gets ignored:

• No SMB signing = I relay credentials freely
• Weak service account passwords = Kerberoasting works
• Over-privileged accounts = One compromise leads to total compromise
• No network segmentation = My access from one workstation lets me reach everything
• No tiered admin model = Domain Admins log into workstations

The Logging Problem

When I ask companies to show me their AD security logs, I usually get blank stares. They're logging domain controller events to local storage that fills up every few days. Nobody reviews them.

Even when logging is configured:

• They're not monitoring for Kerberoasting (Event 4769 with RC4)
• They're not alerting on NTLM relay attempts
• They're not tracking DCSync operations
• They're not watching for suspicious service account usage

I can operate for days without triggering a single alert because nobody configured alerts for the attacks I'm actually performing.

What You Should Do

Before you hire a penetration tester, fix the obvious issues:

1. Enable SMB and LDAP signing everywhere
2. Use Group Managed Service Accounts (gMSAs)
3. Run BloodHound against your own domain
4. Implement a tiered admin model
5. Configure proper logging and actually monitor it
6. Disable NTLM where possible

Then hire a penetration tester. Not to validate that your network is secure, but to find the issues that remain after you've fixed the low-hanging fruit.

I'd rather find fewer issues because you've done the basics than give you a 200-page report full of the same problems every company has. Those reports don't make you more secure. They just make you aware of problems you should have known about already.