Home / Security / Active Directory / AD Attacks & Defenses

Active Directory Attacks & Defenses

LAB ONLY — Read This First

The techniques described in this guide are for systems you own or have explicit written permission to test. Running any of them against systems you do not own — even systems your employer owns, if your role does not include offensive security and you do not have a written engagement letter — is illegal in most jurisdictions and gets people fired and prosecuted.

This guide is written from a defender's perspective. We describe how each attack works at a conceptual level, the signals it leaves behind, and how to prevent it. We deliberately do not include step-by-step exploit commands.

This guide is a continuation of our Active Directory lab series. By now, we have a working domain with a DC, a handful of users, and at least one member server. We're going to look at five techniques that show up in real AD compromises, and — more importantly — what to log, monitor, and configure to stop them.

Defender's Mindset

Every section follows the same structure: theory (what the attack is), how it works (high-level, not a turnkey recipe), detection (event IDs and signals to alert on), and mitigation (configuration changes that remove the attack surface). Read it as "things to audit in our environment," not "things to run."

1. Kerberoasting

Theory

Service accounts in AD have a Service Principal Name (SPN) so that Kerberos can issue service tickets to them. The service ticket (TGS) is encrypted with the service account's password hash. Any domain user — not just admins — can request a TGS for any SPN, by design.

If the service account's password is weak, an attacker can request the TGS, take it offline, and brute-force the password from the encrypted ticket, never touching the DC again.

How it works

  1. Attacker authenticates as any normal domain user (a phished or compromised account, for example).
  2. Enumerates accounts that have a non-null servicePrincipalName attribute. These are easy to list with vanilla LDAP — no special privilege required.
  3. Requests a Kerberos service ticket (TGS-REQ) for one of those SPNs. The DC responds with a TGS-REP encrypted under the service account's NTLM-derived key (or AES key, depending on the configured encryption types).
  4. Extracts the encrypted blob and runs it through an offline cracker. Weak passwords fall in minutes; long random ones don't.

The public tooling commonly associated with this technique is Rubeus and Impacket's GetUserSPNs.py. We name them so defenders can write detection rules; we are not providing invocation strings.

Detection

  • Event ID 4769 on the Domain Controller (Security log): "A Kerberos service ticket was requested." Look at the Ticket Encryption Type field. Modern domains negotiate 0x12 (AES-256). Requests for 0x17 (RC4-HMAC) for a privileged service account are highly suspicious — that's the classic Kerberoasting fingerprint, because RC4 hashes crack faster than AES.
  • One user requesting TGS for many SPNs in a short window.
  • TGS requests for SPNs from a host that has no business calling that service.

Mitigation

  • Use Group Managed Service Accounts (gMSAs) wherever possible. gMSAs use 240-character randomly-generated passwords rotated automatically every 30 days. They are functionally un-crackable.
  • For any SPN-bound account that cannot be a gMSA, set a long random password (25+ characters) and rotate it on a schedule.
  • Disable RC4 for Kerberos where you can. Set the user account flag "This account supports Kerberos AES 128/256 bit encryption" and enforce the domain-wide Network security: Configure encryption types allowed for Kerberos GPO to AES-only.
  • Audit who has SPNs set. Common AD lab one-liner (defensive enumeration): Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName, PasswordLastSet.

2. AS-REP Roasting

Theory

Kerberos pre-authentication is a step where the client encrypts a timestamp with its password-derived key and sends it to the DC. The DC tries to decrypt it; if it works, the DC then issues a TGT. Pre-auth makes offline brute force harder because the attacker needs to provoke the client to send something.

If pre-authentication is disabled on an account (the DONT_REQUIRE_PREAUTH User Account Control flag, also called "Do not require Kerberos preauthentication" in the UI), anyone can ask the DC for an AS-REP for that user, and the AS-REP contains a chunk of data encrypted with the user's password hash. Offline crack follows.

How it works

Attacker sends an AS-REQ for a vulnerable account without pre-auth data. The DC returns an AS-REP. Crack the password offline.

Detection

  • Event ID 4768 (Kerberos authentication ticket TGT requested) with Pre-Authentication Type = 0 is the signature.
  • Periodically audit and alert on anyone with the DONT_REQ_PREAUTH flag set.

Mitigation

Find accounts with pre-auth disabled and re-enable it (or delete the account):

Defensive audit query

# Find accounts with pre-auth disabled
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol |
    Select-Object SamAccountName, Enabled, useraccountcontrol

# Re-enable pre-authentication on a single account
Set-ADAccountControl -Identity 'someuser' -DoesNotRequirePreAuth $false

(4194304 is 0x400000, the DONT_REQ_PREAUTH bit of the userAccountControl bitmask.) The accounts that legitimately need this flag set are extremely rare — usually none in a modern domain.

3. Pass-the-Hash (Concept)

Theory

Windows authenticates over NTLM using the user's NT hash directly — the cleartext password is not required. If an attacker can read the NT hash (from LSASS memory on a machine where the user has logged on, from a SAM dump, or from a backup of ntds.dit), they can authenticate as that user to any service that accepts NTLM, without ever cracking the password.

How it works (concept only)

An attacker with local admin on Host A reads cached credential material out of LSASS. If a privileged account ever logged in to Host A (interactively, with RunAs, via RDP), its hash is now in attacker hands. The attacker then authenticates to Host B as that account by replaying the hash through an NTLM-aware client. From Host B they can move further into the network.

This is the technique that turns "one compromised laptop" into "domain admin" if internal segmentation and credential hygiene are weak.

Detection

  • Event ID 4624 (Successful logon) with Logon Type 3 (Network), Authentication Package = NTLM, especially for privileged accounts logging in to non-admin workstations.
  • Event ID 4648 (Logon attempt with explicit credentials) from unexpected source hosts.
  • EDR or Sysmon process events showing lsass.exe being opened with VM_READ by an unusual process.

Mitigation

  • LAPS (Local Administrator Password Solution) — unique, randomized local-admin password per machine. This kills lateral movement using a shared local-admin hash.
  • Credential Guard on Windows 10/11/Server 2016+ — uses virtualization-based security to isolate LSASS, making the hash unreachable from kernel and userland.
  • Tiered admin model (see below): privileged accounts never log in to user workstations, so their hashes never end up there.
  • Disable NTLM where possible. Audit with Network security: Restrict NTLM GPOs in audit-only mode, then start blocking.
  • Protected Users group — members do not cache credentials, cannot delegate, and cannot use NTLM/Digest/CredSSP for authentication.

4. LLMNR / NBT-NS Poisoning

Theory

When a Windows host can't resolve a name via DNS (typo, expired record, misconfigured share path), it falls back to LLMNR (Link-Local Multicast Name Resolution, port UDP/5355) and then to NBT-NS (NetBIOS over TCP/IP, UDP/137). Both ask the local broadcast/multicast segment "does anyone know who printerserver is?"

An attacker on the same subnet can answer "yes, that's me." The victim then attempts to authenticate to the attacker's machine, leaking an NTLMv2 hash challenge/response. That can be cracked offline, or — worse — relayed to another service the victim has access to (SMB relay, LDAPS relay) for instant impersonation without ever cracking anything.

The publicly-known tool here is Responder. Again, named so detection rules can include it.

Detection

  • Network IDS rules for UDP/5355 (LLMNR) and UDP/137 (NBNS) response traffic from unexpected hosts.
  • SMB authentication attempts with random/typo'd hostnames.
  • Sysmon Event ID 22 (DNSEvent) catching unusual fallback resolutions.

Mitigation

  • Disable LLMNR domain-wide via GPO: Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution = Enabled.
  • Disable NetBIOS over TCP/IP on each NIC. Either via DHCP scope option, GPO/PowerShell, or the adapter's WINS tab.
  • Enable SMB Signing on all clients and servers (Group Policy: Microsoft network client/server: Digitally sign communications (always) = Enabled). SMB signing breaks the SMB relay attack path completely.
  • Enable Extended Protection for Authentication on LDAP, IIS, etc., to defeat LDAP/HTTP relay.

5. BloodHound for Attack Path Discovery

Theory

BloodHound is a graph-based analysis tool. It models AD as a graph of objects (users, computers, groups, OUs, GPOs) and edges (memberships, ACLs, sessions, GPO links, delegations). Given the graph, it can compute the shortest path from any low-privilege starting point to a Domain Admin. The collector that gathers the data is called SharpHound.

BloodHound is just as useful — arguably more useful — for defenders. We run it against our own domain, look at the paths, and remove edges that shouldn't exist.

How it's used (defender side)

  1. Run SharpHound from a regular domain-joined workstation under a regular domain user account. It enumerates the directory using normal LDAP queries that any user can make.
  2. Output is one or more JSON files (in newer versions, a zip).
  3. Stand up BloodHound (the Community Edition or BloodHound CE) with its Neo4j backend on an isolated analyst host.
  4. Upload the JSON. Run the built-in query "Shortest Paths to Domain Admins".
  5. For each unwanted edge in the graph (an obscure ACL granting GenericWrite, an unintended group nesting, a forgotten AdminCount=1), remediate.

What to focus on

  • Sessions: privileged accounts that have active sessions on user-tier workstations. These are pass-the-hash time bombs.
  • ACL edges: GenericAll, GenericWrite, WriteDACL, ForceChangePassword, AddMember on Tier-0 objects from non-Tier-0 principals.
  • Delegations: Unconstrained delegation on any host; Resource-Based Constrained Delegation pointing to privileged groups.
  • Kerberoastable accounts and AS-REP roastable accounts — the queries are built in.

Detection

  • SharpHound itself is LDAP-heavy. Look for a single source making a very large number of LDAP search requests in a short window, especially querying nTSecurityDescriptor, which is unusual for benign software.
  • Microsoft Defender for Identity (formerly Azure ATP) and several SIEM content packs ship signatures for SharpHound enumeration patterns.

Mitigation

BloodHound itself isn't the threat — the attack paths it reveals are. The defensive use of BloodHound is to walk the graph and prune.

The Strategic Defense: Tiered Admin Model

Microsoft's tiered administration model partitions privileged identities and the machines they may sign in to. The classic three tiers:

  • Tier 0 — Identity infrastructure. Domain controllers, AD CS, AD FS, Azure AD Connect, PAM/PIM solutions, backups of any of the above. Tier-0 accounts log in only to Tier-0 systems.
  • Tier 1 — Servers and server applications (file servers, app servers, SQL, web). Tier-1 admins manage Tier-1 systems but never Tier-0.
  • Tier 2 — User devices: workstations, laptops, helpdesk admin scope. Tier-2 accounts touch only Tier-2 hosts.

Rules of the model:

  1. A higher-tier account never authenticates to a lower-tier system. If a Domain Admin logs onto a laptop, the laptop now effectively has Domain Admin rights — its hash is reachable.
  2. Each tier uses dedicated admin accounts (e.g. j.smith.t0, j.smith.t1, j.smith), separate from the human's day-to-day account.
  3. Privileged access is performed from a Privileged Access Workstation (PAW) — a hardened, locked-down device dedicated to admin tasks, not used for email/browsing.

This is the single change that flattens the attack surface against every technique above. Kerberoasting still happens, but the cracked service account doesn't unlock anything Tier-0. Hash dumping happens, but the cached hashes don't belong to Tier-0 principals.

Defender's Checklist

What to harden in the lab (and in production)

Identity hygiene
  [ ] gMSAs for every service that can use one
  [ ] Long random passwords on SPN-bound accounts that cannot be gMSAs
  [ ] Audit and disable accounts with DONT_REQ_PREAUTH (UAC bit 0x400000)
  [ ] Protected Users group for Tier-0 admins
  [ ] LAPS deployed on every member workstation and member server
  [ ] No password reuse between Tier 0 / Tier 1 / Tier 2 accounts

Protocol hardening
  [ ] LLMNR disabled (GPO)
  [ ] NetBIOS over TCP/IP disabled
  [ ] SMB signing required (client and server)
  [ ] NTLM auditing on; NTLM blocked where feasible
  [ ] Kerberos AES-only via "Configure encryption types allowed for Kerberos"
  [ ] LDAP signing + LDAP channel binding required

Logging and detection
  [ ] Advanced Audit Policy enabled (Account Logon, Logon/Logoff,
      Object Access, Account Management, DS Access, Privilege Use)
  [ ] DC Security log forwarded to SIEM with 90+ day retention
  [ ] SACLs on sensitive OUs / objects to log directory changes
  [ ] Alert on 4769 with RC4 encryption (0x17) for privileged accounts
  [ ] Alert on 4768 with PreAuthType=0 (AS-REP roasting fingerprint)
  [ ] Alert on 4648 from non-admin hosts using admin credentials

Architecture
  [ ] Tiered admin model documented and enforced
  [ ] Privileged Access Workstations (PAWs) for Tier-0 admins
  [ ] Backups of ntds.dit treated as Tier-0 (anyone with the backup
      effectively has every NTLM hash in the domain)
  [ ] Run BloodHound periodically on your own domain, prune the graph

Summary

None of these attacks are exotic — they're the standard playbook every internal penetration testing engagement runs through, and the standard playbook real intrusions follow. The good news is that the defences are well understood: gMSAs, LAPS, SMB signing, LLMNR off, AES-only Kerberos, and a tiered admin model. Walk the checklist, run BloodHound on your own domain, and most of the attack surface evaporates before anyone tries to use it.

Reminder: Everything in this guide is for defending and understanding systems you own or have written permission to test.

Back to Guides