The domain falls by reuse, not by a single exploit
Watch a real internal engagement play out and the story is rarely a dramatic remote exploit against a domain controller. It is quieter than that. An attacker lands on one ordinary workstation as one ordinary user, usually through a phished password or a vulnerable internet-facing application. From there the work is almost entirely credential harvesting and reuse: read the secrets left behind on this machine, use them to authenticate to the next machine, read the secrets there, and repeat. The chain ends when the attacker reaches an asset that a highly privileged account, typically a Domain Admin, has logged into and left credentials behind.
This matters because most defensive spend goes to the wrong end of the problem. Patching the perimeter and buying an EDR licence are both worth doing, but neither addresses the mechanic that actually loses the domain: Windows caches reusable credentials on every machine an account touches, and Active Directory trusts those credentials by design. Break the reuse chain and a single compromised laptop stays a single compromised laptop. Leave it intact and that laptop is a path to everything.
Every logon leaves a credential behind
The core fact an attacker relies on is that interactive logons leave secrets in memory. When a user, a service, or an admin doing maintenance signs in to a Windows host, the Local Security Authority Subsystem Service (LSASS) holds the material needed to authenticate onward without re-prompting: NTLM password hashes, Kerberos tickets, and in some configurations cached plaintext. Anyone with local administrator rights on that host can read LSASS memory, and the public tooling for doing so has been mature for well over a decade.
There is more than one cache to worry about. Domain-joined machines store cached domain credentials (often called MSCache or DCC2) so a user can still log on when the domain controller is unreachable, and those can be pulled and cracked offline. The Data Protection API (DPAPI) protects saved browser passwords and other secrets, but its keys are recoverable once you own the machine or the user. Scheduled tasks, service accounts, and saved RDP credentials all leave material lying around. The practical takeaway is blunt: assume any account that has logged into a box is exposed to whoever later controls that box.
Pass-the-hash and pass-the-ticket: reuse, not cracking
The reason this is so effective is that Windows authentication often does not need a plaintext password at all. In NTLM authentication the password hash is functionally the password: present the hash and you are authenticated. That is pass-the-hash. An attacker who dumps an NTLM hash from one machine can use it to authenticate to any other machine that account has rights on, without ever knowing or cracking the password itself.
Kerberos has the same weakness in a different shape. A Kerberos ticket is a bearer token: whoever holds it is treated as the account it was issued to. Extract a Ticket Granting Ticket from memory and you can present it elsewhere, which is pass-the-ticket, for as long as it stays valid. This is why claiming strong passwords as a defence against lateral movement misses the point. The attacker is not attacking the password. They are reusing the artefacts the operating system creates after the password has already been accepted.
Kerberos abuse in plain terms
Kerberos deserves its own explanation because a handful of its features turn ordinary domain access into privilege escalation. Start with Kerberoasting. Any authenticated domain user can request a service ticket for an account that has 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 at leisure. Service accounts are the ideal target because they frequently carry weak, human-chosen passwords that never expire, and they are often granted far more privilege than they need.
AS-REP roasting is the cousin: accounts configured to not require Kerberos pre-authentication will hand out a response encrypted with the user's password hash to anyone who asks, again crackable offline. Then there is delegation. A server set up for unconstrained delegation caches the full ticket of every account that authenticates to it, so if an attacker compromises such a server and a Domain Admin connects to it, that admin's ticket is harvested directly.
The endgame is the krbtgt account. Its hash signs every ticket in the domain, so an attacker who obtains it can forge a golden ticket for any account and stay resident indefinitely. This is why genuine recovery from a domain compromise means rotating the krbtgt password twice, not just resetting a few admin logins. If you only reset the obvious accounts, the forged tickets keep working.
Tiering: why a Domain Admin on a laptop is a lost domain
Given that logging on leaves a credential behind, the single most important architectural control is tiering. Microsoft's enterprise access model splits assets into tiers: Tier 0 is the identity control plane (domain controllers, Active Directory itself, certificate authorities, Entra Connect, and anything that can grant Tier 0 rights); Tier 1 is servers and business applications; Tier 2 is user workstations. The rule that makes it work is one-directional: a Tier 0 credential must never authenticate to a Tier 1 or Tier 2 machine.
The reason is now obvious. If a Domain Admin remotes into a helpdesk technician's workstation to fix something, that admin's credential is now cached on a Tier 2 machine that dozens of lower-privileged people can reach. One compromise of that workstation and the attacker has a Domain Admin. Tiering is not a product you buy, it is a discipline: separate admin accounts per tier, dedicated privileged access workstations for Tier 0 work, and a hard rule that high-value credentials only ever touch high-value systems. Most environments we assess fail here first, and it is the failure that turns a contained incident into a full rebuild.
The handful of controls that break the chain
You do not need to defeat every technique above individually. A small set of controls attacks the shared mechanic, which is credential reuse, and each one removes several attacks at once.
None of these is exotic and none requires a new platform. Most map directly onto controls an organisation is already expected to have. Multi-factor authentication and regular patching, both Essential Eight strategies, matter as well, though it pays to be precise: MFA protects the initial and remote logon, but it does not stop intra-domain NTLM or Kerberos reuse once an attacker is already inside. That is exactly why the credential-hygiene controls carry the weight here.
- Restrict administrative privileges, an Essential Eight strategy: separate, dedicated admin accounts, no everyday Domain Admin membership, and no privileged account logging on to workstations. This is the highest-leverage change most shops can make.
- Windows LAPS: a unique, automatically rotated local administrator password on every machine, which kills the most common lateral hop of reusing one local admin password across the whole fleet.
- Credential Guard: virtualisation-based security isolates LSASS secrets so that even local administrator rights cannot dump hashes and tickets the old way, closing the harvesting step on modern Windows.
- Group Managed Service Accounts: long, machine-managed passwords that rotate automatically, which makes Kerberoasting economically pointless because there is nothing worth cracking.
- Protected Users group and removing unconstrained delegation: stops sensitive accounts from being cached or delegated in the ways attackers depend on.
- Monitoring the right events: anomalous service-ticket requests, privileged logons to unusual hosts, and honeypot accounts with Service Principal Names that should never be requested.
Where to start
If you do one thing, find out where your privileged credentials are logging on. Pull the logon events for your Domain Admins and count how many distinct workstations and servers those accounts have touched in the last month. In most environments the answer is alarming, and it is also the fastest thing to fix: create dedicated admin accounts, stop using them on general-purpose machines, and roll out LAPS so a single local password no longer unlocks the fleet.
The uncomfortable truth is that the techniques here are old, well-documented, and present in nearly every real intrusion, precisely because the defence is organisational discipline rather than a purchase. A focused internal penetration test shows you the actual chain in your environment, which machine leads to which credential leads to the domain, rather than the theoretical one. That is the work Black Shard does, and it tends to change the conversation from whether you are patched to who can reach your Tier 0.