1

Lateral Movement vs. Pivoting — Key Distinction

These two terms are used interchangeably in the field — but for the CySA+ exam, there is a meaningful distinction between them.

Lateral Movement
What it is:Progressively moving through a network searching for high-value targets — hopping from host to host in search of data, assets, or further vulnerabilities to exploit.
Focus:The movement itself — reconnaissance, host discovery, exploiting new systems.
Analogy:A football lateral pass — moving sideways across the field to find a better position to advance.
IOC:Irregular peer-to-peer communications, port scans from internal hosts, unusual remote logons between workstations.
Pivoting
What it is:Using a compromised host as a launch platform to attack other hosts — particularly ones that cannot be reached directly from outside (e.g. behind a firewall on a different subnet).
Focus:The established attack point — using Host B to bypass restrictions and reach Host C.
Mechanism:Port forwarding, SSH -D proxies, netcat relay chains.
IOC:Unexpected port forwarding rules, outbound connections from an internal host to another internal subnet, SSH tunnels from unexpected hosts.
Exam tip: In the field, practitioners use these terms interchangeably. On the exam they are distinct: lateral movement = moving between hosts searching for targets; pivoting = using a compromised host as a relay/launch point to reach otherwise-inaccessible targets. When you see port forwarding, think pivoting. When you see host-to-host reconnaissance, think lateral movement.
2

Pivoting — Port Forwarding & Hop Chains

Pivoting exploits the trust relationships between network segments. An attacker who can only reach Host A uses Host A to attack Host B, then uses Host B to reach Host C — which Host A could never reach directly because a firewall blocks it. The compromised intermediate host becomes a transparent relay.

Pivoting topology — three-host example

How port-forwarding pivoting works

pivoting via SSH -D proxy (attacker's view)
# Attacker is on Host A (10.1.0.10), wants to reach Host C (172.16.0.5)
# Firewall blocks direct A → C. But Host B (10.1.0.20) can reach C.

# Step 1: SSH from A to B, set up local SOCKS proxy with -D flag
A$ ssh -D 1080 attacker@10.1.0.20
↑ -D 1080 = dynamic port forwarding (SOCKS proxy) on local port 1080
All traffic sent to A:1080 is forwarded through B to its destination

# Step 2: Attacker uses the SOCKS proxy to reach Host C through Host B
# To B, all those connections look like they came from B — not from A
# Firewall permits B→C but would block A→C directly

# RDP pivot via port forwarding on Host B (netcat relay)
B$ nc -l -p 3389 -e "nc 172.16.0.5 3389"
↑ anything arriving at B:3389 gets relayed to C:3389
A$ mstsc /v:10.1.0.20:3389
↑ attacker opens RDP to B which transparently forwards to C
Multi-hop chains: Attackers can chain multiple pivot points together — A→B→C→D — to reach deeply segmented network zones (accounting subnets, SCADA networks, PCI cardholder data environments). Each hop adds a layer of indirection that makes traffic attribution harder. Detection requires correlating across all segments simultaneously.

Pivoting IOCs to watch for

Unexpected port forwarding
A workstation or internal server has an active port forwarding rule — particularly to a port number associated with remote access (3389 RDP, 22 SSH, 5900 VNC). No business justification exists for this host to be relaying traffic.
Cross-subnet internal connections
An internal host is making connections to IP addresses in a subnet it normally has no reason to reach — especially if that subnet is security-controlled (DMZ, finance segment, ICS/SCADA network).
SSH -D tunnel from unexpected host
Dynamic port forwarding (SSH -D) creates a SOCKS proxy. An internal workstation that isn't an administrator's machine establishing SSH tunnels to another internal host is suspicious.
3

Pass the Hash — Credential Theft without the Password

Pass the Hash (PtH) is a network-based attack where an attacker steals a hashed user credential and uses the hash directly to authenticate — without ever cracking or knowing the actual plaintext password. Windows stores NTLM password hashes in the SAM (Security Account Manager) and uses them for authentication via Kerberos and SMB. An attacker with access to those hashes can authenticate as that user to any system that trusts those credentials.

How Pass the Hash works — step by step

1
Legitimate user logs on to a domain workstation. The domain controller verifies via Kerberos. The password hash is cached in the SAM on the local workstation.
2
On subsequent logons, Windows uses the cached SAM credentials — no domain controller contact needed. The hash sits in lsass.exe's memory.
3
Attacker gains access to the workstation via any exploit. Once on the machine, they dump the SAM — extracting all cached NTLM password hashes.
4
The attacker uses tools (Mimikatz, Metasploit hashdump module) to extract hashes from the SAM dump. No cracking needed — the hash is used directly.
5
Attacker presents the stolen hash to other systems in the domain. Windows accepts it — it looks like a valid Kerberos/NTLM authentication. Audit logs show a legitimate logon.
Why PtH is hard to detect: The attacker is using valid credentials — the hash that Windows expects. The authentication succeeds. Audit logs record a normal logon event. There is no failed login, no brute force, no anomalous authentication package. The activity is nearly indistinguishable from legitimate use in real-time.

Mimikatz — the tool behind most PtH attacks

Metasploit — smart_hashdump module (conceptual)
# After gaining access to a victim Windows machine via any exploit:
msf> use post/windows/gather/smart_hashdump
msf> run

[*] Running module against WIN-VICTIM
[*] Hashes on the machine:
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
jason:1001:aad3b435b51404eeaad3b435b51404ee:7c08bb1b16c5e8f7df58834b7f20db4e:::

# Format: username:RID:LM_hash:NT_hash
# Attacker can now use the NT hash (second hash) for Pass the Hash
# No need to crack — the hash itself is the credential

Five PtH mitigations

1
Domain admin accounts: domain controllers only. If a domain admin account is never used to log on to a regular workstation, its hash can never be captured from a workstation SAM dump — the highest-value target for PtH attacks.
2
Restrict local admin accounts. Every local admin account whose hash is captured expands the attacker's privilege scope. Minimise the number of accounts with local admin rights — use LAPS (Local Administrator Password Solution) to randomise local admin passwords per machine.
3
Antivirus/antimalware blocks PtH tools. Most AV products detect and block Mimikatz, Metasploit hashdump modules, and similar tools by signature. Attackers may use binary packing to evade this — ensure AV is updated and deployed on all endpoints.
4
Restrict inbound traffic to workstations. Configure Windows host-based firewalls to block inbound connections from unknown hosts — except those authorised for help desk, security scanners, and administrative servers. This limits the attacker's ability to use stolen hashes to move laterally.
5
IDS rules on authentication events. Monitor for Windows Event IDs 4624 (successful logon) and 4625 (failed logon) with logon type 3 (network) and NTLM authentication package. Expect many false positives — this rule is most useful post-breach for timeline reconstruction, not real-time alerting.
IDS detection note: A PtH IDS signature matching Event IDs 4624/4625 + logon type 3 + NTLM will generate enormous numbers of false positives in a live environment because legitimate network logons use the same mechanisms. Use this for post-incident analysis, not real-time SOC alerting.
4

Golden Ticket — Kerberos Domain Compromise

A Golden Ticket is a forged Kerberos Ticket-Granting Ticket (TGT) that grants the attacker administrative access to any resource in the Active Directory domain — essentially a skeleton key for the entire domain. To create a golden ticket, the attacker needs the krbtgt hash (the Kerberos ticket-granting ticket hash), which is the trust anchor of the entire Active Directory domain.

Quick Kerberos background

krbtgt hash
The master key of Active Directory's Kerberos implementation. Functions like the private key of a root CA. Used to sign all Ticket-Granting Tickets issued in the domain. If an attacker has this hash, they can forge any ticket.
TGT (Ticket-Granting Ticket)
Issued by the Key Distribution Center (KDC) when a user successfully authenticates. Used to request service tickets for specific resources. Encrypted with the krbtgt hash — the KDC trusts anything it can decrypt with that key.
KDC (Key Distribution Center)
The Active Directory domain controller component that issues TGTs and service tickets. Trusts any TGT that is validly signed with the krbtgt key — including forged golden tickets.

How a Golden Ticket attack works

1
Attacker gains admin access to any domain-joined system and accesses the NTDS.DIT file — the Active Directory database stored on domain controllers. This file contains all account hashes, including krbtgt.
2
Attacker dumps the NTDS.DIT to extract the krbtgt hash and all administrative account hashes.
3
Using the krbtgt hash, the attacker forges a golden ticket for any user — typically a Domain Admin. This ticket is indistinguishable from a legitimately issued TGT.
4
Attacker uses the golden ticket to authenticate to any resource in the domain — including domain controllers — with full administrative rights. Can persist for the lifetime of the krbtgt hash (up to years if not rotated).
The incident responder's trap: After discovering a breach, responders typically force-reset all user account passwords. But if they forget to reset the krbtgt account password, the attacker still has a valid golden ticket and maintains full domain access — invisibly. Resetting all user passwords does nothing if the krbtgt hash isn't rotated.

Golden Ticket detection and response

Legacy IOC
Older golden ticket tools left the domain name field blank in logon events. Still look for this — an account logon with an empty domain field in Windows Event Logs is suspicious. Newer tools have fixed this, so it's not reliable as the sole detection.
Response — reset krbtgt twice
If golden ticket use is suspected, reset the krbtgt account password twice in quick succession — with a short pause between resets. The double reset ensures all existing golden tickets are invalidated. Do this even if you didn't identify the attacker's entry point.
Rotate krbtgt proactively
Regularly rotating the krbtgt account password (quarterly at minimum) limits the window of exposure if the hash is ever compromised. Most organisations never rotate it — making a stolen hash valid indefinitely.
Exam mnemonics: PtH = steals the hash, works on local + cross-domain if hash is shared. Golden Ticket = steals the krbtgt hash, creates unlimited tickets, works across the entire domain. NTDS.DIT = the file containing krbtgt hash (on domain controllers). Reset krbtgt password twice to invalidate golden tickets.
5

Pass the Hash vs. Golden Ticket — Comparison

Pass the Hash
Target:NTLM password hash in the SAM / lsass.exe on a workstation
Source:SAM database dump from any joined workstation
Tool:Mimikatz, Metasploit smart_hashdump
Scope:The specific accounts whose hashes are captured. Cross-domain if those accounts have domain-wide privileges.
Protocol:NTLM, SMB, Kerberos (limited)
Detection:Extremely difficult in real-time. Event IDs 4624/4625 + logon type 3 + NTLM — high false positive rate.
Mitigation:Domain admin accounts on DCs only. Restrict local admin. AV blocks Mimikatz. Inbound traffic restrictions.
Golden Ticket
Target:krbtgt hash — the Kerberos trust anchor in Active Directory
Source:NTDS.DIT file on a domain controller
Tool:Mimikatz, Impacket, Empire
Scope:The entire Active Directory domain — any resource, any account, any service.
Protocol:Kerberos
Detection:Legacy IOC: blank domain name in logon events (older tools). Modern tools have fixed this. Anomalous TGT lifetimes.
Mitigation:Rotate krbtgt password regularly. Reset twice if breach suspected. Protect DC access.
6

Lateral Movement Tools — WMIC, PsExec & PowerShell

Attackers practice "living off the land" — using tools that are already legitimately present on Windows systems for their lateral movement. This makes detection harder because the same tools used by system administrators can look identical to attacker activity in the logs.

Remote Access Services
VPN / SSH / Telnet / RDP / VNC
Any remote access protocol can be weaponised for lateral movement. An attacker with credentials can use RDP, SSH, VNC, or VPN to move from host to host just as a legitimate admin would. Legitimate use makes these nearly invisible without behavioural baselining.
WMIC
Windows Management Instrumentation CLI
Provides a terminal interface for running scripts and administrative commands on remote systems. Attackers use it for: process execution at elevated privilege, reconnaissance (BIOS, disk partitions, installed software), and lateral movement commands. Post-exploitation favourite because it's built into Windows and often whitelisted.
PsExec
Sysinternals — remote execution
Developed by Mark Russinovich as a Telnet alternative. Uses the Windows SYSTEM account for privilege escalation. Allows attackers to: open backdoors on remote systems, execute processes at SYSTEM level, run commands across many hosts simultaneously. Built for admins, abused by attackers constantly.
Windows PowerShell
Task automation + scripting
Built into every modern Windows system. Supports WMIC commands, remote execution, and scripting. Attackers use PowerShell Empire — a pre-built exploit framework with 91+ modules for everything from credential dumping to pivoting, all using PowerShell syntax.

PowerShell Empire — attacker's toolkit context

What it is
A post-exploitation framework built entirely in PowerShell. Once an initial foothold is established, Empire provides pre-built modules for credential dumping, persistence, lateral movement, and data exfiltration — all using native Windows tooling.
Why it's dangerous
All activity runs through PowerShell — a trusted Windows component. Attackers can disable PowerShell logging, script block logging, and module logging to evade detection. Fileless execution means nothing persists to disk.
Detection approach
Enable PowerShell Script Block Logging (Group Policy) and PowerShell Transcription Logging. These capture PowerShell commands even when attackers attempt to disable other logging. Also monitor Sysmon Event ID 1 (process creation) for powershell.exe with encoded command strings.

Living-off-the-land IOCs

WMIC from unexpected source
WMIC running on a user workstation (not an admin machine) querying remote systems. Especially suspicious if querying sensitive servers or executing processes remotely.
PsExec on non-admin machines
PsExec.exe appearing on a workstation without an IT ticket authorising its use. Or PsExec running as SYSTEM from an account that shouldn't have SYSTEM privileges.
PowerShell encoded commands
PowerShell invoked with -EncodedCommand or -enc flags, especially when launched by a non-admin process. Base64-encoded commands are often used to obscure malicious content.
Unexpected remote logons
Windows Event ID 4624 logon type 3 (network logon) or type 10 (remote interactive) from unusual source IPs — especially workstation-to-workstation. Admins log in to servers; users don't usually log in to each other's workstations.
7

Weak Passwords as a Lateral Movement Vector

The simplest form of lateral movement requires no exotic tooling — just a password list. Attackers can move between hosts by logging in with common passwords or passwords discovered from previous breaches. The larger the organisation, the more statistically likely it is that at least some employees use weak passwords.

Real top passwords still in use: "12345", "password", "123456789", "QWERTYUIOP" (top row of keyboard), "Q1W2E3R4T5Y6" (keyboard walking — alternating between number and letter rows). "Keyboard walking" and top-row patterns look random but aren't — they appear in every leaked password dataset. These are passwords that will be tried in every brute-force dictionary attack.
Keyboard walking
"Q1W2E3R4T5Y6", "1qaz2wsx", "qwerty123" — alternating between rows or following key adjacency patterns. Looks complex but is enumerable with any modern password attack tool.
Brute-force / spray risk
Weak admin passwords are catastrophic — an admin account on one machine compromised through password guessing can propagate to every machine in the domain if that admin has used the same password everywhere.
Mitigation: audit passwords
Periodically run password audit tools against your domain (BloodHound, Crackmapexec with wordlists, or Hashcat against your own SAM dumps) to identify weak passwords before attackers do. Change control + complexity policies + mandatory multi-factor authentication.
Exam

Quick Reference Cheat Sheet

Lateral movement vs. pivoting
Lateral movement = hopping between hosts searching for targets (reconnaissance + exploitation). Pivoting = using a compromised host as a relay to reach otherwise-inaccessible systems (port forwarding). Often used interchangeably in field — exam distinguishes them.
Pivoting mechanics
Port forwarding via Netcat relay or SSH -D (dynamic/SOCKS proxy). Host A can't reach C (firewall blocks). A→B via exploit. B→C via port forward (firewall trusts B). Attacker uses A→B→C chain. Multi-hop chains can cross many subnets. IOC: unexpected port forwarding rules on internal hosts.
Pass the Hash
Steal NTLM hash from SAM/lsass.exe. Use hash directly — no cracking needed. Tool: Mimikatz. Works on local machines and domain-joined systems. Near-undetectable in real time (uses valid credentials). Mitigation: domain admin → DCs only; restrict local admin; AV blocks Mimikatz; Windows firewall restrictions.
Golden Ticket
Steal krbtgt hash from NTDS.DIT on domain controller. Forge Kerberos TGT for any user → access entire domain. Old IOC: blank domain name in logon events (newer tools fixed this). Response: reset krbtgt password TWICE to invalidate all existing golden tickets. Rotate krbtgt regularly.
PtH vs. Golden Ticket
PtH: NTLM hash → SAM → workstation-level → NTLM/SMB → hard to detect. Golden: krbtgt hash → NTDS.DIT → entire domain → Kerberos → blank domain name (legacy IOC). Both use Mimikatz. PtH limited to captured accounts. Golden = unlimited domain-wide skeleton key.
Living-off-the-land tools
Remote access services (RDP/SSH/VPN/VNC). WMIC = remote command execution + recon. PsExec = SYSTEM-level remote execution (Sysinternals). PowerShell Empire = 91+ pre-built exploit modules. All are legitimate admin tools repurposed. IOC: these tools running on non-admin machines or from unexpected processes.
PowerShell IOCs
-EncodedCommand / -enc flags = obfuscated command (suspicious). PowerShell spawned by unexpected parent process (Word, Excel, browser). Enable Script Block Logging + Transcription Logging via GPO. Monitor Sysmon Event ID 1 for powershell.exe. PowerShell Empire = post-exploitation framework.
Authentication event IDs
4624 = successful logon. 4625 = failed logon. Logon type 3 = network (remote). Type 10 = remote interactive (RDP). NTLM auth package = used in PtH. Logon type 3 + NTLM + no matching domain = possible PtH (high false positives). Blank domain name = golden ticket legacy IOC.
Weak password risks
Keyboard walking looks secure but isn't (Q1W2E3R4T5Y6, QWERTYUIOP). Admin accounts with weak passwords = domain-wide lateral movement. Audit passwords proactively before attackers do. MFA eliminates password-based lateral movement even when passwords are compromised.