What Is Lateral Movement? a 2026 Defender's Guide

A lot of teams are staring at the same kind of queue right now: a low-confidence authentication alert, a remote service launch that looks like admin activity, maybe one PowerShell event from a host that usually stays quiet. Nothing in isolation looks like a crisis. Then the timeline fills in, and what looked like a single compromised account turns out to be an attacker walking through your environment with valid access.
That's why what is lateral movement isn't a beginner's glossary question. It's an operational question. It asks whether your team can tell the difference between normal administration and an adversary using the same channels to reach domain controllers, backup systems, cloud workloads, and SaaS data.
In practice, lateral movement is the set of post-compromise actions attackers use to move from one system, identity, or trust boundary to another after they already have a foothold. CrowdStrike describes it as a multi-step process that includes reconnaissance, credential and privilege gathering, and access to other computers, and in MITRE ATT&CK it sits as the 10th tactic in the framework's kill-chain structure used by defenders and researchers worldwide, as described in CrowdStrike's lateral movement overview.
Table of Contents
- The Alert That Started It All
- The Anatomy of Lateral Movement
- Common Attacker Techniques and ATT&CK Mapping
- Hunting for Shadows Key Detection Indicators
- Practical Detection Recipes and Queries
- The Lateral Movement Incident Response Playbook
- Unifying Detection and Response with ThreatCrush
The Alert That Started It All
The alert looked ordinary. A service account authenticated to a developer workstation it had never touched before. The login worked. A remote management process started soon after. Nobody escalated it immediately because every individual artifact had a plausible explanation.
By the time responders pulled the full timeline, the attacker had already used that first access to reach other systems, test privileges, and blend into internal traffic patterns. That's how lateral movement usually shows up in practice. Not as a dramatic perimeter event, but as a sequence of small, boring actions inside your environment.
Why teams miss it
Security teams still tend to anchor on initial access. They ask how the attacker got in, which matters, but it's often not where the major damage happened. The bigger problem is what the attacker did next with legitimate credentials, remote services, and built-in admin tooling.
Most severe breaches aren't defined by the first compromised endpoint. They're defined by the systems the attacker reached after that endpoint.
What makes this hard is that attackers often stop looking like outsiders once they're inside. They authenticate. They use approved protocols. They connect to systems your admins also manage. The difference isn't the existence of a remote session. The difference is the path, the identity, and the sequence.
What lateral movement means in practice
A clean practitioner definition is simple. Lateral movement is the process of expanding access from one compromised host, account, session, or service to additional systems and higher-value assets. The purpose is rarely movement for its own sake. Attackers move to find data, reach administrative control planes, establish persistence, or prepare impact.
That matters because this phase isn't niche. Research summarized by Picus Security says lateral movement techniques account for 80% of adversaries' attack time, cites VMware analysis finding lateral movement in 45% of intrusions, and notes separate industry analysis claiming 70% of breaches use lateral movement, all of which reinforce why it sits near the center of ransomware and data theft operations in Picus Security's review of lateral movement attacks.
For defenders, the practical lesson is blunt. If your team only watches the edge, you'll miss the intruder who already got a badge.
The Anatomy of Lateral Movement
Attackers don't usually compromise one host and stop there. Once they're in, they act like someone inside the building looking for keys, badges, floor plans, and the shortest route to sensitive rooms.
A simple mental model helps. The first foothold is just the open window. The main campaign starts when the attacker figures out which internal doors are accessible.
What the attacker does after the first foothold

Most lateral movement campaigns follow a recognizable sequence, even when the tooling changes:
Internal reconnaissance
The attacker maps reachable systems, active users, trust relationships, remote services, and admin patterns. They're identifying what can be reached and what's worth reaching.Credential and token collection
Passwords, hashes, Kerberos material, cached sessions, API tokens, SSH keys, browser tokens, and SaaS sessions all become movement fuel.Privilege escalation
The attacker looks for admin rights, delegated roles, over-permissioned service accounts, or inherited trust that turns a local foothold into broader control.Pivoting
They move to another asset through remote services, alternate authentication material, deployment tooling, or shared content and collaboration surfaces.Persistence and objective access
New admin accounts, scheduled access paths, modified policies, backdoors, and staged tooling keep the campaign alive while the attacker searches for data or impact points.
A short explainer helps visualize the chain in motion:
Why this phase dominates the real fight
Defenders often treat lateral movement as one ATT&CK box. That's too abstract to be useful in an incident. In operations, it's the connective tissue between initial compromise and business impact.
The reason it consumes so much attention is simple. Each hop gives the attacker three advantages:
| Advantage | What it gives the attacker | What it forces defenders to do |
|---|---|---|
| More reach | Access to additional systems and users | Reconstruct trust paths, not just host events |
| Better cover | Activity that looks like normal administration | Validate who should use which tools and where |
| Higher stakes | Access to backups, identity stores, and sensitive data | Contain quickly before scoping is perfect |
Practical rule: Track movement as a chain of identity decisions. Which account authenticated, from which asset, to which destination, using which remote method, and was that path expected?
That framing matters even more now because many intrusions no longer move only from endpoint to endpoint. They move through identities, remote management planes, and shared services. The host is still important, but the identity path often tells you more than the malware path.
Common Attacker Techniques and ATT&CK Mapping
The fastest way to misunderstand lateral movement is to think it requires custom malware. In many environments, attackers get farther with PowerShell, PsExec, WMI, SSH, RDP, and stolen service accounts than they ever would with something exotic.
Zero Networks makes this point clearly in its analysis of common lateral movement methods. Effective defense depends on recognizing that attackers often abuse legitimate tools and trusted admin channels, which is why segmentation, credential hygiene, and strong detections matter more than generic advice to watch for odd traffic in Zero Networks' guide to common lateral movement techniques.
Trusted channels are the real problem
A remote session isn't suspicious by itself. Your administrators use remote sessions every day. The problem starts when trusted channels appear from the wrong source, under the wrong identity, or in the wrong sequence.
Common examples include:
- PowerShell Remoting used by a workstation that has never administered servers.
- PsExec or service-based execution launched from a user device rather than a management host.
- WMI remote process creation from an account that normally signs into only one business application.
- SSH from a non-admin endpoint into production Linux systems.
- Stolen service account credentials authenticating interactively or reaching endpoints outside their normal scope.
That's why ATT&CK mapping is useful. It gives the SOC a shared language to tag these behaviors without turning every investigation into a taxonomy debate.
A practical ATT&CK view
Here's a defender-oriented mapping for the techniques you'll see most often:
| Technique | ATT&CK mapping | What to watch for |
|---|---|---|
| RDP and other remote services | T1021 Remote Services | New source-to-destination admin paths, interactive logons from unusual systems |
| PowerShell Remoting | T1021 Remote Services | Remote sessions initiated by non-admin hosts, encoded command chains, script execution after admin logon |
| WMI remote execution | T1047 Windows Management Instrumentation | Remote process creation, WMI provider activity, parent-child process chains that don't fit admin baselines |
| PsExec and remote service creation | T1021 Remote Services | Service installation, ADMIN$ usage, short-lived remote services created from workstations |
| Pass-the-hash, tokens, tickets, stolen material | T1550 Use Alternate Authentication Material | Authentication without expected interactive behavior, reused credentials across unrelated hosts |
| Software deployment abuse | Software Deployment Tools | Broad task execution outside approved deployment windows or from unexpected operators |
| Shared content and collaboration abuse | Taint Shared Content | Malicious file propagation, shared-script execution, infected content as a pivot path |
| SSH-based pivoting | T1021 Remote Services | East-west SSH from endpoints that don't normally administer Linux or network devices |
If your analysts need a cleaner process for turning observations into repeatable ATT&CK-aligned detections, this practical MITRE ATT&CK mapping workflow for SOC teams is useful because it keeps the focus on operational use, not slideware.
Don't ask only “what tool did they use?” Ask “what trust boundary did they cross with it?” That's usually the stronger detection lens.
Hunting for Shadows Key Detection Indicators
You won't catch lateral movement by collecting more logs and hoping correlation saves you. You catch it by prioritizing the signals that reveal an unexpected path. In modern environments, that usually means starting with identity evidence and then confirming it with endpoint and network context.
A major blind spot in many explainers is that modern intrusions often pivot through identities and cloud control planes, not just flat east-west traffic. MITRE ATT&CK includes techniques such as Remote Services, Alternate Authentication Material, and Taint Shared Content, which fit cloud and hybrid reality better than older endpoint-only models, as summarized in this overview of lateral movement and modern ATT&CK-aligned techniques).
Start with identity and authentication

If I have to choose where to invest first, I start with authentication telemetry. That's because identity-centric lateral movement leaves a trail even when payload visibility is weak.
Prioritize these indicators:
New source host for an existing account
A service account or admin identity authenticates from a workstation, VDI, or cloud host it doesn't normally use.New destination set for a known account
An account that usually touches one app tier suddenly authenticates to file servers, jump hosts, or developer systems.Remote admin method mismatch
The account is valid, but the protocol isn't. Example: a user account begins using SSH or remote management APIs it never used before.Session chaining across boundaries
One sign-in is followed by access to another host, then another, within a short operational window. It doesn't require a numerical threshold to be meaningful. It requires sequence awareness.Cloud and SaaS control-plane use that follows endpoint compromise
A host alert is followed by new administrative actions in cloud consoles, identity providers, or collaboration platforms.
Then validate with endpoint and network evidence
Authentication tells you that a path may be wrong. Endpoint and network evidence tell you how it was used.
A practical triage model looks like this:
| Evidence domain | Highest-value indicator | Why it matters |
|---|---|---|
| Endpoint process telemetry | PowerShell, WMI, PsExec, SSH, service creation | Shows how the move happened |
| Network telemetry | Rare east-west connections, unusual remote ports, new system-to-system pairs | Shows where the path opened |
| File and service artifacts | Dropped tools, temp scripts, new services, modified startup points | Shows staging and persistence |
| Identity and cloud logs | Token use, session reuse, admin actions from fresh source systems | Shows identity-based pivoting |
A single suspicious login can be noise. A suspicious login followed by remote execution and a new destination system is a movement story.
For cloud and SaaS environments, expand your hunt beyond host-to-host travel. Look for:
- Compromised identity followed by role use in a cloud control plane
- Session or token reuse from a source that doesn't fit the account
- Shared content or collaboration artifacts used to spread access
- Administrative API calls after endpoint compromise
Many teams still lag in this regard. They can explain SMB and RDP movement, but they can't answer how an attacker moved from a stolen session into cloud administration or SaaS data access. That gap matters now more than ever.
Practical Detection Recipes and Queries
Telemetry doesn't become detection until you turn it into logic that can fire, pivot, and scope. The best lateral movement analytics are narrow enough to catch path abuse but flexible enough to survive legitimate administration.
Below are practical starting points. They're intentionally opinionated. Tune them against your admin hosts, jump boxes, software deployment servers, and automation accounts.
Sigma for common movement patterns
Detect PsExec-style remote service execution from non-management hosts
title: Suspicious Remote Service Execution From Non-Admin Source
id: 1d2b8df4-remote-service-non-admin
status: experimental
logsource:
product: windows
category: process_creation
detection:
selection_img:
Image|endswith:
- '\psexec.exe'
- '\paexec.exe'
selection_parent:
ParentImage|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
filter_admin_hosts:
Computer|contains:
- 'jump'
- 'mgmt'
- 'deploy'
condition: selection_img and selection_parent and not filter_admin_hosts
fields:
- Computer
- User
- ParentImage
- CommandLine
falsepositives:
- Authorized administration from approved management systems
level: high
Detect WMI remote execution with suspicious process ancestry
title: WMI Spawned Shell or PowerShell
id: 8a6c4e12-wmi-shell-powershell
status: experimental
logsource:
product: windows
category: process_creation
detection:
selection_parent:
ParentImage|endswith:
- '\wmiprvse.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
condition: selection_parent and selection_child
fields:
- Computer
- User
- ParentImage
- Image
- CommandLine
level: high
The point of both rules isn't that PowerShell or WMI are bad. It's that source context matters. If the event comes from a jump server during a known maintenance window, it may be fine. If it comes from a finance workstation at an odd time under a service account, it deserves immediate review.
osquery for fast scoping and triage
osquery is useful when you already suspect movement and need to scope it fast across endpoints.
Find recently created services that may indicate remote execution
SELECT
name,
display_name,
path,
start_type,
user_account
FROM services
WHERE path LIKE '%Temp%'
OR path LIKE '%AppData%'
OR path LIKE '%Windows\\Tasks%'
OR path LIKE '%ProgramData%';
Find SSH authorized keys and recent shell profile modifications on Linux
SELECT
path,
directory,
filename,
uid,
gid,
size,
mtime
FROM file
WHERE path IN (
'/root/.ssh/authorized_keys',
'/home/%/.ssh/authorized_keys',
'/root/.bashrc',
'/home/%/.bashrc',
'/root/.profile',
'/home/%/.profile'
);
Hunt for unexpected remote admin tools on Windows
SELECT
path,
filename,
size,
mtime
FROM file
WHERE filename IN ('psexec.exe','paexec.exe','wmic.exe','plink.exe')
OR path LIKE '%Sysinternals%'
OR path LIKE '%Admin$%';
YARA for tool staging and payload discovery
YARA won't detect “lateral movement” as a behavior, but it helps catch staged tooling that often accompanies it.
Simple YARA to flag common remote admin tool strings in dropped binaries or scripts
rule Suspicious_Remote_Admin_Tool_Strings
{
meta:
description = "Flags common remote admin and execution tool markers"
author = "Practitioner recipe"
strings:
$s1 = "PsExec" nocase
$s2 = "PAExec" nocase
$s3 = "WMI" nocase
$s4 = "WinRM" nocase
$s5 = "Invoke-Command" nocase
$s6 = "New-PSSession" nocase
condition:
2 of them
}
Good lateral movement detections don't just alert. They answer three questions immediately: what identity was used, what path was taken, and what systems are now in scope.
Use these as seeds, not finished content. The primary work is environmental tuning, especially around management servers, software deployment tooling, and service accounts.
The Lateral Movement Incident Response Playbook
Once you suspect lateral movement, speed matters more than elegance. Don't wait for a perfect narrative. Stop the attacker's ability to pivot, then clean up the story.
The strongest containment lever is reducing reachable paths inside the environment. Microsegmentation creates distinct security zones so a compromise in one segment doesn't automatically expose others, and just-in-time MFA for privileged actions shrinks the window for credential abuse, as described in Zero Networks' guidance on lateral movement prevention and containment.
Contain movement before you perfect attribution

Your first actions should be about path denial:
- Isolate affected hosts when you have endpoint control and confidence the system is participating in movement.
- Disable or restrict compromised accounts, especially service accounts showing interactive or cross-tier behavior.
- Tighten remote administration paths fast. If a host doesn't need RDP, WinRM, WMI, SSH, or SMB admin access during the incident, close it.
- Force step-up controls for privilege use so stolen credentials are less useful.
- Apply emergency segmentation around crown-jewel systems, identity infrastructure, and backup platforms.
If you need a practical outside reference for segmentation thinking during response, the network segmentation guidance from Networking2000 security advice is worth reviewing because it focuses on limiting trust paths instead of only rearranging VLANs.
Scope the path not just the patient zero host
Many teams still investigate lateral movement like a malware outbreak. They study one machine in depth and miss the route the attacker already took through identities and remote services.
Use a path-based workflow instead:
List every suspect identity
Include user accounts, service accounts, local admins, cloud roles, API identities, and active sessions.Map source-to-destination authentication
Build a timeline of who authenticated where, from which system, and by what remote method.Validate remote execution evidence
Correlate process creation, service installs, scripts, WMI activity, PowerShell logs, and SSH artifacts.Check for persistence at each hop
Don't assume persistence exists only on the initial host. Look for new services, scheduled access, startup changes, and added accounts on every touched system.Reset trust, not just passwords
Rotate credentials, revoke sessions, invalidate tokens, and review delegated rights that let the attacker move again.
For teams refining investigation flow, this incident investigation guide is a good operational companion because it emphasizes scoping logic instead of raw alert handling.
During lateral movement response, the question isn't “which host is infected?” It's “which trust relationships are no longer trustworthy?”
Recovery comes after that. Re-enable access carefully, based on rebuilt trust paths and least privilege, not on pressure to restore convenience.
Unifying Detection and Response with ThreatCrush
Lateral movement is hard to stop when every clue lives in a different tool. Authentication data sits in one place, endpoint execution in another, network evidence somewhere else, and the response workflow depends on a human gluing the story together under pressure.
That's the operational gap ThreatCrush is built to close.

ThreatCrush brings CTEM, SIEM, EDR, and SOC workflows into one platform with a single agent and an extensible module model. That matters for lateral movement because the signal is rarely isolated. It usually appears as a sequence across network, process, file, and authentication telemetry. A unified platform can correlate those events into one intrusion path instead of leaving analysts with disconnected alerts.
The platform also fits the way modern defenders work. It uses open standards your team already knows, including MITRE ATT&CK, D3FEND, Sigma, YARA, osquery, OCSF/ECS, NIST CSF, and CIS Controls. That makes detections more portable and investigations easier to standardize. When you need deeper implementation detail, the ThreatCrush documentation lays out how the modules, workflows, and integrations fit together.
For response, the value is speed. When the platform can surface a probable movement chain, trigger real-time alerts, and support containment actions from the same operating surface, your team spends less time stitching and more time stopping the next hop.
If your team is trying to reduce lateral movement risk before the next incident, take a look at ThreatCrush. It gives you one place to detect identity abuse, remote execution, unusual network paths, and endpoint activity, then turn those signals into response actions without bouncing across separate products.
Try ThreatCrush
Real-time threat intelligence, CTEM, and exposure management — built for security teams that move fast.
Get started →