AV-04 · Lateral movement after initial access

Once inside, attackers use shared credentials, over-trusted network paths, and gaps in east-west monitoring to move across systems and escalate privileges before defenders notice.

$ action: Segment networks, reduce admin sprawl, monitor east-west traffic, and alert on abnormal authentication patterns between internal hosts.

1. Why Lateral Movement Matters

Initial access rarely ends the incident — it starts it. Most serious breaches become severe because the attacker moved from one compromised host to others, collected credentials along the way, and reached something critical before containment.

Lateral movement succeeds where environments allow broad internal trust: shared local admin passwords, flat network segments, unrestricted RDP or SMB access between workstations, and service accounts with domain-wide reach. Each of those conditions is a free path between systems.

Defenders who rely on perimeter controls will miss this phase entirely. Internal authentication and east-west traffic need the same scrutiny as traffic crossing the edge.

2. Common Weaknesses Attackers Exploit Internally

Shared local admin credentials are a common starting point. Once an attacker has a local admin hash or password on one machine, tools like CrackMapExec or impacket can spray it across the subnet automatically. Hosts that share passwords become the same host from an attacker's perspective.

Lack of east-west monitoring is the other side of the problem. If admin protocols moving between systems aren't baselined and alerted on, attackers can traverse the environment for days without triggering anything. The logging exists; it's just not being watched.

Segmentation and identity controls have to work together. Segmentation without authentication monitoring lets attackers use legitimate credentials to cross boundaries. Identity alerts without path restrictions trigger after movement has already happened.

3. How Defenders Reduce Lateral Movement Risk

Segment by function and trust level — not just by VLAN. Validate those controls with testing, not assumptions. A firewall rule that's supposed to block RDP between workstations and servers should be tested to confirm it actually does.

Reduce admin sprawl. Implement privileged access controls, role separation, and just-in-time elevation where practical. Every service account with domain admin rights that doesn't need them is a lateral movement shortcut waiting to be used.

Build alerts focused on behavior changes rather than single events. A single failed SSH login is noise. SSH from a workstation to a server it has never contacted, followed by a successful login and immediate privilege use — that's worth a page.

detection-signals

$Windows event logs or Linux auth logs show an admin login from a workstation to a server it has never accessed before, especially outside business hours.
$SMB, RDP, or WinRM connections appear between systems in segments that should be blocked by network policy.
$A service account authenticates to a host outside its normal scope — for example, a backup service account logging in interactively to a domain controller.
$A user account appears in admin group membership changes on multiple hosts within a short window after a suspected initial compromise.
$Zeek conn.log shows the same source host making admin-protocol connections to a large number of internal destinations within minutes.

telemetry-sources

$Internal authentication logs (Windows event logs, Linux auth logs, IdP where applicable).
$East-west network telemetry (Zeek, Suricata, NetFlow, firewall internal segment logs).
$Endpoint telemetry and EDR/XDR alerts for credential use and remote admin activity.
$AD/identity logs and privilege change auditing.
$Network segmentation policy logs and change records for validation.

recommended-tools-and-guides

open Zeek Analyze internal protocol metadata and suspicious east-west connections at scale. open Suricata Detect suspicious internal traffic and admin protocol abuse patterns. open Wazuh Correlate host telemetry and auth events across systems during lateral movement triage. open BloodHound Understand identity and privilege relationships that can enable movement. open CrackMapExec Lab-only learning tool to understand what automated movement attempts look like and how to detect them.

related-learning-modules

Build fundamentals and workflows that directly support defending against this threat pattern.

open /learning/network-security-monitoring-zeek-suricata Network Security Monitoring with Zeek and Suricata open /learning/linux-windows-logging-basics-for-defenders Linux and Windows Logging Basics for Defenders open /learning/threat-informed-defense-attack-technique-mapping Threat-Informed Defense Using ATT&CK-Style Technique Mapping

related-tool-pages

Use these detailed tool guides to practice safe validation, evidence collection, and triage workflows for this threat.

open /learning/tools/zeek Zeek open /learning/tools/suricata Suricata open /learning/tools/wazuh Wazuh open /learning/tools/bloodhound BloodHound open /learning/tools/crackmapexec CrackMapExec open /learning/tools/sigma Sigma

lab-safe-detection-workflows

These commands are for learning, validation, and defensive triage in your own lab or authorized environment. Adapt to your tooling and log locations.

East-west traffic baseline and anomaly review

zeek -r internal-sample.pcap local
zeek-cut id.orig_h id.resp_h service proto < conn.log | head -n 40
tshark -r internal-sample.pcap -z conv,tcp -q

$ why: Use packet/metadata analysis to identify which internal hosts are communicating and whether admin protocols appear in unexpected paths.

Authentication and admin activity triage

journalctl --since "-2h" | grep -Ei "sudo|ssh|auth|winrm|rdp" | tail -n 100
grep -Ei "Accepted|Failed|sudo" /var/log/auth.log | tail -n 80 || true
printf "time,src,dst,account,protocol,event,next_action\n" > lateral-movement-triage.csv

$ why: Build a timeline of internal admin/auth events and map them to source/destination systems before containment decisions.

triage-questions

?Which host or account represents the likely initial compromise, and what was the first internal connection it made afterward?
?Are admin protocols appearing on network paths that segmentation policy should be blocking?
?Is a service account or privileged account authenticating outside its normal hosts or schedule?
?What east-west traffic and authentication logs confirm or disprove lateral movement — are there timestamps that build a sequence?
?What's the fastest containment action that limits further spread: account disable, host isolation, or blocking a specific internal path?

defender-actions.checklist

$Segment internal networks and restrict management protocol paths.
$Reduce shared credentials and broad admin access across systems.
$Monitor east-west traffic and internal authentication anomalies.
$Review service accounts and privilege assignments regularly.
$Practice post-compromise containment playbooks (account disable, host isolate, path block).

study-workflow

Learn what normal behavior looks like for this area (auth, exposure, config, or internal traffic).
Identify the logs and telemetry that should show the behavior.
Practice one safe validation in a lab or authorized environment.
Write a short playbook for detection, triage, and response.
Review the related tool guides under /learning/tools.

<- previous threat AV-03 · Vulnerability exploitation and misconfiguration abuse -> next threat AV-05 · Insider threat and privilege misuse