Field Notes: Domain Admin in a Day

Reaching full control of an Active Directory environment rarely needs a novel exploit. On a recent internal engagement for a national logistics firm, our operators moved from a single low-privileged foothold to Domain Admin inside a working day. Nothing we used was exotic. Every step relied on a common misconfiguration that the organisation could have closed in advance.

These field notes are anonymised. No client is named, no real data is reproduced, and the details below are generalised so the lessons transfer without exposing anyone. What we want to show is how attackers reach domain admin in practice, and how ordinary decisions quietly build the path they walk.

The Setup

The brief was a standard assumed-breach internal test. Rather than spend days on perimeter access, the client wanted to know what an attacker could achieve once inside, whether through a phishing click, a rogue device or a compromised contractor laptop. We were given a single set of low-privileged domain credentials, the kind any new starter might receive, and network access from a segment used by general office staff.

That starting position is realistic. Most serious intrusions do not begin with an administrator account. They begin with one ordinary user and a patient attacker, which is exactly the scenario an internal penetration test is designed to stress.

Before touching the network, we did what an external attacker would do first. Open-source intelligence on the organisation surfaced staff names, job titles and email formats from professional networking sites, conference talks and cached documents. That told us the naming convention for accounts, which teams ran which systems, and who was likely to hold elevated access. None of it was sensitive on its own. Together it was a map.

Initial Foothold

With valid low-privileged credentials, we enumerated the domain from the inside. Standard read access is enough to query Active Directory for users, groups, computers and, crucially, service accounts. This is not a flaw, it is how the directory is meant to work, and it is precisely why an authenticated foothold is so valuable to an attacker.

The enumeration returned the usual picture of a large estate that had grown over many years. There were service accounts created for applications long since retired, groups nested inside other groups until the effective membership was hard to reason about, and a handful of accounts whose names hinted at broad privilege. We built a quiet inventory and looked for the shortest path upward.

Escalation

The break came through Kerberoasting. In Active Directory, any authenticated user can request a Kerberos service ticket for an account that has a service principal name set, which marks it as running a service. Part of that ticket is encrypted with the service account's password hash. We requested tickets for several such accounts and took them away to crack offline.

Offline is the important word. There were no failed logons on the network, no account lockouts and nothing for a help desk to notice. On our own hardware we ran the tickets against a wordlist enriched with the organisation's name, local place names and common seasonal patterns. Within a short time one service account fell. Its password was memorable, had never been changed, and had never been set to expire.

That single account was the whole game. It had been granted membership of a highly privileged group years earlier so an application could run without permission errors, and the privilege had never been reviewed. From there we moved laterally, authenticating to other systems and confirming that the account's rights extended across the estate. A short chain later we held Domain Admin.

The final privilege escalation was almost anticlimactic. Once a foothold account can reach highly privileged credentials, the remaining steps are routine tradecraft: harvest cached credentials, pivot to a domain controller, and confirm control. The difficulty was never the exploitation. It was finding the first weak link, and the environment offered several.

Impact

We stopped at proof and did not touch production data. In an assumed-breach test the objective is to demonstrate reach, then document it carefully so the organisation can act.

Holding Domain Admin means holding the keys to the whole environment. An attacker in that position can read or alter any data, disable security controls, create hidden accounts for persistence, and deploy ransomware across every joined system at once. For a logistics operator, that maps directly to halted dispatch, frozen tracking and a recovery effort measured in weeks rather than hours. We kept the impact assessment qualitative and grounded in what the access made possible, rather than inventing figures, because the reach itself was the finding.

What struck the client most was the speed. They had assumed that reaching this level of control would take a determined attacker weeks. In practice the chain was hours long, and every link was a decision made for convenience at some point in the past.

What Went Wrong

None of the failures here were sophisticated. They were the accumulated cost of small compromises:

• Service accounts with weak, memorable passwords that never expired.
• A service account granted broad privilege for convenience, then never reviewed.
• No tiering between everyday accounts and administrative ones, so a single crack reached the top.
• No monitoring for unusual Kerberos ticket requests, so the escalation was invisible.
• Public information that made account naming and target selection trivial.

Each on its own looks minor. Chained together they form a straight road from one ordinary account to complete control.

How to Prevent This

The good news is that the same chain is straightforward to break, and you only need to break one link.

• Give every service account a long, random password, and prefer group managed service accounts so credentials rotate automatically and are never guessable.
• Enforce least privilege for service identities. A service should hold only the rights it genuinely needs, and privilege grants should be reviewed on a schedule rather than left to accrete.
• Adopt a tiered administration model. Domain administrators should never log on to ordinary workstations, and high-value credentials should never be exposed to lower-trust systems.
• Monitor for the behaviour, not just the breach. Unusual volumes of service ticket requests and unexpected lateral movement are detectable signals if someone is watching for them.
• Reduce your public footprint where you reasonably can, and assume attackers already know your naming conventions.

Most importantly, test the whole path rather than individual controls. A configuration review might flag a weak password in isolation, but only an attacker's-eye engagement shows how that one weakness connects to full control. This is exactly the value that internal penetration testing and a broader red team engagement provide, and why pairing them with regular vulnerability assessments keeps the picture current between deeper tests.

If you are not certain how far an attacker could get from a single ordinary account on your network, that uncertainty is worth resolving before someone else resolves it for you. Our expert operators run these engagements across Australia from our Brisbane base, and we are always happy to talk it through. Get in touch or call 1300 654 898 to start the conversation.