The Client Said "You'll Never Get In." We Were Domain Admin by Lunch.

"You can try," the IT director said, leaning back, "but we're locked down tight. You'll never get in." I wrote the quote in my notes, because clients who say that are usually the most fun. We had signed a two-week internal penetration test. We were Domain Admin before the first afternoon.

This is that engagement, anonymised, told the way it actually unfolded — because the sequence is a near-perfect tour of the PenTest+ PT0-003 objectives, and seeing it as a story makes those objectives stick far better than a bullet list ever will.

The kickoff and the boast

Every engagement starts with paperwork, and this is not the boring part — it is the part that keeps you out of prison. Scope, rules of engagement, emergency contacts, what is off-limits. The director's confidence came from a real investment in perimeter security: a good firewall, patched externals, MFA on the VPN. What he had not thought about was what happens once someone is inside.

Our scope was internal — we were dropped onto the network as if we were a contractor who had plugged in a laptop, or a phished employee. That assumption, "assume breach", is how modern testing works, and it is why perimeter confidence is misplaced.

Recon: mapping the ground

You cannot attack what you cannot see. The first hour is always the same: find the hosts, find the services, find the domain controllers. Quietly.

Enumeration — the first hour# Sweep the subnet for live hosts and services
nmap -sV -T3 --top-ports 100 10.10.0.0/24

# Find the domain controllers via SRV records
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local

# List SMB shares readable without creds
smbclient -L 10.10.0.12 -N

The scan came back with a flat network — no internal segmentation — and a file server happily listing shares to an anonymous session. A flat network means that one foothold anywhere is a foothold everywhere. That was the first crack.

The foothold nobody guards

On that open share sat a folder of IT scripts, and inside one of them, in plain text, was a service account and its password. Someone had hard-coded credentials into a login script years ago and forgotten. It happens on the majority of engagements.

From user to Domain Admin

That service account was not special — just a normal domain user. But a normal user can query Active Directory, and Active Directory tells you where the powerful accounts have logged in. We found a Domain Admin session cached on a server the service account could reach, and from there the path to full control was mechanical.

By lunch we had a Domain Admin hash, dumped the directory, and could authenticate as anyone in the company. The afternoon was spent doing the genuinely hard part: writing it up so the client could fix it.

How this maps to PT0-003

Read back over the story and you have walked the PenTest+ blueprint in order.

What we did	PT0-003 domain
Scope, rules of engagement, contacts	Engagement Management
Subnet sweep, DC discovery, share listing	Reconnaissance & Enumeration
Finding creds in a readable script	Vulnerability Discovery
Using them to reach a DA session	Attacks & Exploits
Dumping the directory, proving impact	Post-Exploitation

That is why the certification is structured the way it is. A real engagement is not a bag of tricks — it is a sequence, and PenTest+ tests whether you understand the sequence. The director, to his credit, took the report well. Perimeters are necessary. They are just nowhere near sufficient.

What the client should have done

The debrief is the most valuable hour of any engagement, because it turns "you got owned" into "here is how you stop it". For this client the fixes were unglamorous and cheap. Network segmentation would have meant our single foothold did not reach the domain controllers — a flat network is what turned one weak credential into total compromise. Removing the hard-coded credential from that login script, and rotating it, would have closed the door entirely. Restricting where Domain Admin accounts can log in would have denied us the cached session we pivoted through.

None of that requires a bigger security budget. It requires knowing where to look, which is precisely the value a penetration test delivers: not the thrill of breaking in, but a prioritised list of the specific, affordable changes that would have stopped it.

Why the report is the real deliverable

Newcomers imagine the exploitation is the job. It is not. The client cannot act on a screenshot of a root shell; they can act on a clear, prioritised report that explains what we found, how serious each finding is, how we exploited it, and exactly how to remediate it. A finding that is technically brilliant but poorly written gets ignored, and an ignored finding fixes nothing. This is why PenTest+ weights reporting and communication so heavily, and why so many technically capable candidates are surprised by the exam — they trained to break things and never practised explaining them. On a real engagement, the twenty-minute compromise earns the fee; the three-day report earns the next contract.

Assume breach, always

If there is one idea to take from this engagement, it is the assumption we started from: assume the attacker is already inside. The director had spent his budget on the perimeter because that is where the frightening headlines are, but modern attackers phish an employee, compromise a contractor's laptop, or find an exposed service and simply walk in. Once inside, a flat network with over-privileged accounts and forgotten credentials hands them everything. Defending only the perimeter is like fitting the strongest possible front door to a house with no internal walls. The organisations that survive real attacks are the ones that segment their networks, enforce least privilege, monitor for unusual internal activity, and assume that any single control will eventually fail. That mindset — defence in depth, breach assumed — is what a penetration test is really selling, and it is why the profession exists.