What Is Lateral Movement?

Last verified on Nov 8, 2026.

Lateral movement is the part of an intrusion where an attacker, already inside one system, reaches other systems. MITRE ATT&CK describes it as techniques adversaries use to enter and control remote systems on a network, often by exploring to find the target and then pivoting through multiple systems and accounts to reach it.

The first machine an attacker gets into is rarely the one they want. A compromised web server is a foothold. The database, the build system, or the cloud admin console is the goal, and lateral movement is the route.

How Attackers Move

ATT&CK groups lateral movement into nine techniques under TA0008. The main ones:

ATT&CK notes that adversaries might install their own remote access tools, or use legitimate credentials with native tools, which may be stealthier. The second form is the hard one to spot: nothing is malware, and every login is "valid." That is why it links so closely to credential stuffing and account takeover, which supply the credentials.

What It Looks Like in Logs

A person logs in to the few hosts they use. An attacker with their credentials fans out. These illustrative auth.log lines show one account reaching several internal hosts in under two minutes, from a host that does not normally connect to them:

Nov  8 02:14:09 db-1 sshd[3121]: Accepted publickey for deploy from 10.0.4.17 port 51822 ssh2
Nov  8 02:14:41 db-2 sshd[2208]: Accepted publickey for deploy from 10.0.4.17 port 51830 ssh2
Nov  8 02:15:12 build-3 sshd[991]: Accepted publickey for deploy from 10.0.4.17 port 51844 ssh2
Nov  8 02:15:13 build-3 sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/bash

ATT&CK's detection strategy for SSH is the same pairing: a remote SSH login (sshd, /var/log/auth.log) followed by post-login execution or privilege escalation behavior. The login alone is normal. The login plus an immediate shell as root is the signal.

Three questions to ask of authentication and network logs:

1. Fan-out. How many distinct hosts did this account log in to within an hour, compared with its own history?
2. New edges. Has this source host ever connected to this destination on this port? In many networks, workstation-to-workstation traffic is rare.
3. What came next. Did a login lead to a new process, a new account, or a role change?

SELECT user, count(DISTINCT dest_host) AS hosts, min(ts) AS first_seen
FROM auth_events
WHERE outcome = 'success' AND ts > now() - INTERVAL '1 hour'
GROUP BY user
HAVING count(DISTINCT dest_host) >= 5

Use a per-account baseline rather than one fixed number, because a deploy or automation account may legitimately touch many hosts. See authentication anomalies for the login-side checks, and novel events for new source-destination pairs.

Limiting It

ATT&CK's mitigations for remote services are concrete:

• Use MFA on remote service logons where possible.
• Limit network access to hosts and shares, with gateways rather than open paths.
• Do not reuse local administrator passwords across systems.
• Limit which accounts may use remote services, and the permissions of accounts at higher risk.
• Disable remote connection types you do not need, and audit systems and permissions.

ATT&CK also notes that overlapping permissions across local, domain, and cloud accounts let an adversary pivot until they reach domain or enterprise administrator. Fewer shared accounts means fewer pivots. After a move, the attacker usually needs more rights: see privilege escalation.

Seeing It with Sazabi

Sazabi, an AI-native observability and security platform, accepts Linux auditd records and journald auth messages, which include login and sudo activity, alongside other sources. Send them from the auditd setup, then ask questions of the logs in plain language, such as which accounts logged in to the most hosts overnight. For the broader checks, see privilege changes and security issues.