From One Laptop to Domain Admin: Active Directory Attack Paths and the Controls That Stop Them

Ask an internal penetration tester how they reach domain admin and the honest answer is usually unglamorous: they follow the credentials. This matters in interviews because it shows you understand both offence and the specific defensive controls that change the outcome.

The usual path

1. Foothold. A phished workstation or a device plugged into a network port.
2. Enumeration. Ordinary directory queries reveal users, groups, computers, sessions, permissions and delegation. Graph tools turn that into attack paths.
3. Credential collection. Legacy name resolution lets attackers capture or relay authentication on the network where SMB and LDAP signing are not required; service accounts with weak passwords are cracked offline from service tickets; scripts and shares hold plaintext passwords; and once local admin is gained, memory on machines where privileged users logged on yields their credentials.
4. Lateral movement. Those credentials open other machines. A shared local administrator password makes this trivial.
5. Domain control. Eventually an account with control over the domain is reached, through group membership, a misconfigured permission or delegation.

The controls, matched to steps

• Network credential exposure: disable LLMNR and NBT-NS, require SMB signing, LDAP signing and channel binding, and Extended Protection on web services.
• Service accounts: group-managed service accounts or long random passwords, AES only.
• Plaintext secrets: scan shares and scripts, move secrets to a manager.
• Local admin reuse: LAPS for unique, rotated passwords.
• Credentials in memory: tiered administration with privileged access workstations, Credential Guard, the Protected Users group.
• Misconfigured permissions: attack-path analysis run continuously, not once.
• Detection: bulk directory queries from workstations, many service ticket requests with weak encryption, authentication from unusual hosts, changes to privileged groups and replication requests from non-domain-controllers.

Why this path keeps working

Active Directory was designed for convenience inside a trusted network. Single sign-on means credentials are cached in memory so users are not asked again, directory data is readable by every user so applications can find what they need, and older protocols remain enabled because something somewhere still depends on them. None of these is a bug, which is why patching alone never closes the path. Each step an attacker takes uses a feature working as designed, in an environment where privileged accounts touch too many machines and old settings were never revisited.

That is also why the fixes are architectural and organisational rather than a single product. Tiering changes how administrators work every day, retiring NTLM needs an inventory of what still uses it, and attack-path analysis only helps if someone owns the findings and the paths are checked again after every reorganisation. In an interview, saying this out loud shows you understand why mature organisations still get compromised this way.

A compact model answer

"From a foothold an attacker enumerates the directory, collects credentials from the network, weak service accounts, files and memory, moves laterally with them and reaches a privileged account. I break that with signing and no legacy name resolution, gMSAs, LAPS, tiered administration with privileged workstations, Credential Guard, continuous attack-path analysis, and detections for roasting, relays and privileged changes."

Where to go deeper

Read from foothold to domain control, Active Directory attacks, NTLM and relay attacks and Windows services and LSASS, all placed on the learning journey.