Active Directory Attack Paths & Hardening
In most enterprise breaches, the attacker does not need a zero-day. They need a single valid credential and a directory that trusts too much. Active Directory turns one low-privilege foothold into a chain of small, legitimate-looking steps that ends at Domain Admin — and understanding that chain is the first step to breaking it.
Active Directory has been the identity backbone of the enterprise for over two decades, and its design assumptions show their age. It is built to make resources discoverable and access frictionless — exactly the properties an attacker exploits. This article walks the classic path from an ordinary domain user to full domain compromise, explains the mechanisms behind each hop from a defender's perspective, and shows how tiering and targeted hardening remove the edges an attacker depends on. Everything here is framed for detection and defence — the goal is to recognise these techniques in your own environment, not to run them.
The foothold: one valid credential
Almost every internal compromise starts with a single authenticated context — a phished password, a credential sprayed against a login portal, or a token lifted from a workstation. Crucially, this account rarely needs any privilege at all. A standard domain user can query the directory, enumerate group memberships, list service accounts, and read the access-control relationships between objects. That read access is the attacker's map. The defensive lesson is that "just a normal user" is not a safe baseline — the directory hands out reconnaissance for free.
Kerberoasting: turning read access into an offline crack
Kerberos issues service tickets (TGS) encrypted with the password hash of the account that owns the target service's SPN. Any authenticated user can request a ticket for any service principal name, then take that ticket offline and attempt to crack it — no interaction with the service required, and no failed-logon noise. Accounts with weak, human-set passwords fall quickly. The reason this works is that service accounts are frequently exempt from the password policies applied to people, and are set to never expire.
Breaking the edge
Use group Managed Service Accounts (gMSAs), which rotate 120-character random passwords automatically and are effectively uncrackable. Where a gMSA is not possible, enforce 25+ character passphrases on service accounts and monitor for anomalous volumes of TGS requests using RC4 encryption — a strong signal of roasting.
AS-REP roasting: the pre-authentication gap
Kerberos normally requires pre-authentication — proof you know the password before the KDC responds. Accounts flagged with "do not require Kerberos pre-authentication" skip that step, and the KDC will return an AS-REP encrypted with the account's key to anyone who asks. That response is crackable offline just like a Kerberoast ticket. This setting is a legacy compatibility relic; the defence is simply to audit for it and remove it. There is almost never a legitimate modern reason to leave pre-authentication disabled.
Credential theft and lateral movement
Once an attacker lands on a host as local administrator — often via a cracked service account that was over-permissioned — they can harvest credentials cached in memory, in the LSASS process, or in the local SAM. Windows single sign-on means secrets for other users and services frequently sit in memory on shared hosts. With a harvested hash or ticket, the attacker performs pass-the-hash or pass-the-ticket to authenticate elsewhere without ever knowing the plaintext, moving host to host wherever those credentials are honoured.
The single most damaging pattern we find is a Domain Admin whose credentials are cached on a workstation. One compromised laptop then equals the whole domain — no exploit required, just reused trust.
DCSync: impersonating a domain controller
An account holding the directory replication rights (Replicating Directory Changes and Replicating Directory Changes All) can ask a domain controller to replicate account secrets — including the KRBTGT hash and every user's NTLM hash — using the same protocol DCs use among themselves. This is DCSync, and it needs no code to run on the DC itself, which is why it evades many endpoint controls. Possession of the KRBTGT hash enables forged "golden tickets" granting arbitrary access that survives password resets. Audit exactly which principals hold replication rights; the list should be short and contain no surprises.
Tiering: the structural fix
Individual hardening steps close individual edges, but the durable defence is administrative tiering. Microsoft's tiered model separates identities by the sensitivity of what they control: Tier 0 (domain controllers, AD, and the accounts that manage them), Tier 1 (servers and applications), and Tier 2 (workstations). The rule is that credentials never flow downward — a Tier 0 admin never logs on to a Tier 2 workstation, so their credentials are never cached where a lower-tier compromise can reach them. This breaks the "one laptop equals the domain" pattern at its root.
Complement tiering with the CISA-endorsed essentials: enforce phishing-resistant MFA, disable RC4 where possible, deploy the protected-users group and LAPS for local administrator passwords, and use attack-path mapping tools to visualise your own graph the way an attacker would. If you can see the edges, you can cut them.
Key takeaways
- A single non-privileged credential gives an attacker the reconnaissance to plan the entire path.
- Kerberoasting and AS-REP roasting exploit weak service-account passwords and legacy settings — gMSAs and audits close both.
- Cached credentials plus single sign-on make lateral movement trivial; treat every cached secret as a liability.
- DCSync and golden tickets follow from over-broad replication rights — audit exactly who holds them.
- Administrative tiering is the structural defence: keep privileged credentials out of reach of lower-trust hosts.