This is an anonymized field note from an internal penetration test. The client's environment is not identifiable, but the pattern is, because we have seen a version of it in a substantial majority of the Active Directory environments we assess.
The engagement began at 9am with a standard domain user account, the equivalent of a new employee on their first day. Domain administrator privilege was held before the end of the working day.
The Setup
The organization ran a mature-looking environment. Endpoint detection was deployed, patching was reasonably current, and the security team was competent and engaged. Active Directory had been in place for around fifteen years and had grown with the business through several reorganizations and two acquisitions.
That last detail is the one that matters. Nothing in this engagement exploited a missing patch. Everything exploited accumulated configuration that had been individually reasonable at the time it was made.
The Attack
Step one, around forty minutes in: a readable share. Enumeration from the standard account found a file share readable by all authenticated users, holding an IT department folder of scripts and runbooks. One deployment script contained a service account password in plain text, added years earlier to make an installation work.
Step two: Kerberoasting for a second account. In parallel, operators requested service tickets for every account with a service principal name, which any authenticated user may do. Three of the resulting hashes cracked offline within the hour against a standard wordlist. Two of those service accounts held local administrator rights across large groups of servers.
Step three: harvesting what those accounts could reach. Using the server administrator rights, operators collected credentials cached in memory on the systems they could now access. Among them were the credentials of a help desk administrator who had logged into one of those servers to troubleshoot a problem some weeks earlier.
Step four: unconstrained delegation. Directory mapping showed a legacy application server configured with unconstrained delegation, a setting dating from an application decommissioned years earlier. The help desk account had rights to that server. Operators compromised it, waited for a privileged account to authenticate, and captured credentials that carried domain administrator privilege.
Elapsed time from first login to domain administrator: under eight hours, most of it waiting.
What Made It Work
None of the four steps is exotic. Each is documented, well understood and routinely found. What made the chain work was that no single team owned the whole picture.
The share permissions were set by one group, the service accounts created by another, the delegation setting inherited from a project that had closed, and the help desk login was ordinary support work. Every decision was defensible. The combination was not, and nobody had ever looked at the combination.
Impact
Domain administrator means the directory is no longer a security boundary. Every domain-joined system, every file, every account and the backup infrastructure are all reachable. In a ransomware scenario, this is precisely the position from which an attacker deploys across an entire estate simultaneously, which is why the sequence above is not a testing curiosity. It is the standard operating procedure of the crews currently doing this for money.
Detection through all of this was minimal. Every action used legitimate protocols and valid credentials.
How to Break the Chain
The chain has four links and breaking any of them stops it. Breaking all four is the goal.
- Get credentials out of scripts and shares. Audit shares for readability by all authenticated users, then search them for passwords. This is unglamorous and consistently productive.
- Fix service accounts. Move to Group Managed Service Accounts, which rotate automatically and cannot be Kerberoasted usefully. Where that is not possible, enforce long random passwords and remove privilege the application does not need.
- Eliminate unconstrained delegation. Inventory it, and replace each instance with constrained or resource-based delegation. Mark privileged accounts as sensitive and not delegatable.
- Restrict where privileged accounts log in. Administrative credentials cached on ordinary servers are how privilege travels. Use privileged access workstations and tiered administration.
- Map your own paths. Run a directory mapping tool against your environment and look at the graph. The paths exist whether or not anyone has looked.
For the wider pattern, see Active Directory attack paths. To have someone map these paths in your environment before an attacker does, get in touch.
Frequently asked questions
How can an attacker reach domain admin so quickly?
Rarely through a single exploit. The usual route is a chain of individually unremarkable misconfigurations: a readable share holding credentials, a service account with excessive privilege, a delegation setting nobody reviewed, and a password reused across systems. Each looks minor in isolation, which is exactly why each survived. Tools that map these relationships find the chain in minutes.
What is Kerberoasting?
Kerberoasting abuses a normal feature of Kerberos. Any authenticated user can request a service ticket for an account with a service principal name, and part of that ticket is encrypted with the service account's password hash. The attacker requests the ticket, takes it offline and cracks it. It requires no special privilege, generates ordinary-looking traffic, and works whenever a service account has a weak password.
Why are service accounts such a common weakness?
They are created for an application, given broad privilege so the application works, assigned a password that must not change because a change breaks the application, and then forgotten. The result is a highly privileged account with an old, often weak password that nobody rotates and nobody monitors. Group Managed Service Accounts solve most of this and remain underused.
What is unconstrained delegation and why is it dangerous?
Unconstrained delegation lets a server impersonate any user who authenticates to it, anywhere on the network. A server configured this way stores the credentials of everyone who connects, so an attacker who compromises it inherits every one of those identities, including administrators. It exists for legacy reasons and should be replaced with constrained or resource-based delegation.
How do we find these paths before an attacker does?
Map them. Tools that graph Active Directory relationships show attack paths from ordinary users to privileged accounts, and running one against your own directory is the fastest way to understand your exposure. Follow that with regular privileged access review, service account audits and a check for delegation settings. The paths are discoverable; the question is who discovers them first.