Lateral movement is the set of techniques attackers use to move between systems inside your environment after gaining an initial foothold. MITRE ATT&CK classifies it as tactic TA0008, distinct from Initial Access (TA0001), which covers how attackers get into your network in the first place.
Initial access means an attacker crossed your perimeter. Lateral movement means they're navigating within your environment, hopping from a compromised workstation to a domain controller, or from a Kubernetes pod to an AWS IAM role. That traversal is what turns a contained compromise into a full breach.
The challenge for defenders is that lateral movement relies on the same protocols, credentials, and admin tools your environment already depends on. PowerShell, RDP, WMI, and IAM role assumptions all produce valid authentication events. You can't block them outright, and signature-based detection can't reliably separate malicious use from routine administration. Detection comes down to behavioral context and data quality.
This article breaks down how lateral movement works, what detection opportunities exist at each stage, and how to constrain the paths attackers exploit.
Key Takeaways:
Lateral movement (MITRE ATT&CK TA0008) turns a single compromised endpoint into a full network breach.
Attackers follow a repeatable three-stage pattern: reconnaissance, credential theft, and target access. Each stage relies on built-in tools like PowerShell, WMI, and RDP that are hard to distinguish from legitimate administration.
In cloud environments, the attack surface centers on identities and permissions. IAM role chaining and Kubernetes service account token theft are important lateral movement vectors, and they leave no Windows Event IDs to catch.
Threat detection depends on data completeness and behavioral analysis rather than perimeter security.
How Lateral Movement Attacks Unfold
Lateral movement follows a repeatable three-stage pattern: map the environment, steal credentials, then use those credentials to access target systems:
1. Reconnaissance and Network Mapping
Discovery gives attackers the internal map they need before they start stealing credentials or touching high-value systems. The tools often include remote system discovery activity, net view, ping, arp, netstat, and PowerShell AD modules, which can blend into normal administration.
Documented examples from real intrusions show the pattern clearly. HAFNIUM enumerated domain controllers using net group "Domain computers" and nltest /dclist. During a TrickBot intrusion, operators used PowerShell to export information on domain-joined Windows systems to a CSV file, then conducted additional reconnaissance for lateral movement targets.
The Lynx intrusion followed the same playbook: netscan.exe was executed multiple times when the threat actor accessed the network. These commands are common administrative tools, which makes them hard to separate from normal activity.
2. Credential Theft and Privilege Escalation
Credential theft gives attackers the authentication material required to move beyond the first compromised host. With a network map in hand, attackers harvest credentials, typically domain admin or service account credentials.
Mimikatz remains central to credential harvesting, with capabilities including LSASS memory dumping, DCSync, Pass-the-Hash, and Golden Ticket creation. During the Nitrogen/BlackCat intrusion, operators dumped LSASS memory, moved laterally via Impacket wmiexec, dumped LSASS again on the next server, and escalated to domain administrator.
Muddled Libra demonstrated how fast this can happen: MFA bypass through IT support exploitation to domain administrator in under 40 minutes.
3. Accessing Target Systems
Remote access turns stolen credentials into execution on additional systems. With valid credentials, attackers authenticate to and execute on target systems using remote protocols. RDP, PsExec, WMI, WinRM, and SSH are the primary mechanisms, all legitimate, all signed, and all expected on many enterprise networks.
The Lynx intrusion completed this stage when the threat actor connected to the domain controller via RDP using Domain Admin credentials. FIN6 operators used Cobalt Strike's PsExec module, which creates services with random 16-character names on target systems.
Common Lateral Movement Techniques
Most lateral movement techniques fit into two practical buckets: attacks that abuse authentication material and techniques that abuse legitimate remote administration tools. Breaking them apart makes it easier to understand how attackers move and where you can detect them.
1. Credential-Based Attacks
Credential-based attacks let attackers authenticate as legitimate users without knowing plaintext passwords.
Pass-the-Hash (T1550.002) lets attackers use captured NTLM hashes to authenticate without knowing the actual password. After LSASS dumping, attackers can use the recovered hash for pass-the-hash authentication to remote systems, including for lateral movement via tools such as PsExec or WMI.
Pass-the-Ticket (T1550.003) uses stolen Kerberos tickets, TGTs or TGS, to move laterally without passwords. Golden Ticket attacks enable access as any account in Active Directory.
Kerberoasting (T1558.003) is a growing lateral movement enabler. Any authenticated domain user can request service tickets encrypted with a service account's password hash, then crack those tickets offline. The attack typically leaves only standard Kerberos service-ticket request events (such as Event ID 4769) that must be monitored and analyzed to detect the activity. See the October 2024 mitigation guidance for hardening steps.
2. Remote Access and Living-off-the-Land Tools
Living-off-the-land tools make lateral movement hard to spot because the same binaries support legitimate administration. Attackers favor tools that are already present and trusted:
WMI, with over 104 documented detection analytics
Administrators and attackers can run the same wmic.exe command. These tools produce valid authentication events and use trusted process lineage. Detection has to rely on behavioral context, parent processes, timing, user baselines, and cross-system correlation.
Lateral Movement in Action: Real-World Examples
Documented incidents show the same mechanics across ransomware and cloud intrusions. The examples below separate host-based propagation from identity-driven cloud pivots so you can see how the movement path changes with the environment.
Ransomware Propagation
Ransomware campaigns show how quickly lateral movement can turn one compromised system into broad impact. NotPetya (June 2017) spread through four vectors:
EternalBlue/EternalRomance SMB exploits
Mimikatz credential harvesting via LSASS injection
PsExec
WMI
Global damages exceeded $10 billion.
Ryuk took the opposite approach: human-operated, multi-week campaigns following an Emotet → TrickBot → Ryuk kill chain. Operators used Cobalt Strike and Mimikatz for post-compromise activity before deploying ransomware, making detection of loader activity days or weeks before encryption the best intervention point.
Cloud-Native and Identity-Driven Attacks
Cloud lateral movement centers on identities and permissions rather than host-to-host traversal. Cloud environments generate telemetry through cloud-native logs rather than Windows Event IDs, and the attack surface is heavily influenced by identities and permissions.
The SCARLETEEL operation (2023) shows how this plays out: attackers exploited a vulnerable Kubernetes workload, queried the AWS IMDS endpoint to steal IAM role credentials, then found cleartext IAM keys in a Terraform state file stored in S3, enabling further access and privilege escalation. The pivot chain used API calls.
Kubernetes-related threat activity increased 282% between 2024 and 2025. North Korean operators known as Slow Pisces stole Kubernetes service account tokens, readable at a default path inside every pod, and pivoted from cluster access to cloud-level compromise. A compromised AI inference pod yielded credentials in 86 seconds: Azure Managed Identity tokens, Kubernetes service account tokens, and application-level secrets.
How to Detect Lateral Movement
Lateral movement detection depends on two things: behavior that stands out from normal administration and enough data to connect activity across systems.
Behavioral Indicators Worth Monitoring
Behavioral indicators surface lateral movement earlier than payload-based detections because the tools attackers use are legitimate. Detection depends on context: who ran the command, from where, at what time, and whether the pattern matches that user's baseline.
As Jeff Bollinger, Director of Incident Response and Detection Engineering at LinkedIn, puts it, "behavior in my mind indicates an intent."
Internal port scanning is a prerequisite for lateral movement. Watch for sequential
ping,arp, ortracertcommands in rapid succession, and domain enumeration vianltestornet group.Abnormal authentication patterns expose credential abuse. RDP logons from non-jump-host IPs can appear as Event ID 4624 with Logon Type 10, multiple distinct accounts authenticating from a single workstation via explicit credentials (Event ID 4648), and Kerberos TGS requests (Event ID 4769) without corresponding TGT activity (Event ID 4768) are potential high-fidelity signals.
East-west traffic catches movement even without endpoint telemetry. Workstation-to-workstation SMB on port 445, WMI connections on port 135, and sudden peer-to-peer traffic bursts from hosts that historically only communicated with servers are high-value signals.
Why Log Coverage and Data Quality Determine Detection Success
Detection quality depends on whether the right data sources are enabled and correlated. Eight data sources are off by default in standard Windows and cloud configurations, including command-line capture in Event ID 4688, PowerShell Script Block Logging, Sysmon LSASS access monitoring, and AWS VPC Flow Logs.
Fragmentation makes this worse. When an attacker bypasses MFA through Okta, then uses PsExec on a Windows endpoint, those events share no native correlation key. Okta uses email addresses. Windows uses DOMAIN\user. CloudTrail uses IAM principal ARNs. Without an identity resolution layer that normalizes these representations, analysts have to connect the activity manually across multiple consoles.
Zapier's security team went from logging only 20% of security events to monitoring 70% of their security data by consolidating critical sources, including Okta, AWS CloudTrail, and custom logs, into Panther. Unified ingestion turns fragmented signals into a connected lateral movement detection chain.
Panther supports 60+ native connectors for cloud, identity, endpoint, and SaaS sources, with custom ingestion via HTTP webhook, S3, and SQS for everything else.
How to Prevent Lateral Movement
Prevention works by limiting both the paths and the permissions attackers can use after initial access. Network controls and identity controls address different parts of the problem.
Network Segmentation and Zero Trust
Network controls reduce the number of systems an attacker can reach after the first compromise. Default-deny east-west traffic policies are the most direct way to limit lateral movement paths.
CISA microsegmentation guidance recommends creating segments and policies that limit server-to-server communication to only what is needed for business functions. In cloud-native environments, this means workload-level network policies, Kubernetes NetworkPolicies and tightly scoped AWS Security Groups instead of VPC or subnet boundaries.
NIST SP 800-207 frames Zero Trust Architecture around protecting resources through continuous verification and least-privilege access, with access granted on a per-session basis using dynamic policy rather than static role assignments. For microservices, NIST SP 800-207A extends this to service-mesh-based mutual authentication between services and references SPIFFE in its cloud-native zero trust model.
Identity Controls: Least Privilege, MFA, and Service Account Hygiene
Identity controls limit how far attackers can go even when they steal valid credentials. Over-permissioned non-human identities are a major lateral movement risk in cloud-native environments. Over 62% of non-human identities show no activity in 90 days, yet many retain permissions, some with administrative privileges.
Enumerate all service accounts and API keys, flag idle NHIs, and audit wildcard IAM policies.
As Matt Jezorek, former CISO at Panther, puts it, "If every incident needs to have an identity stolen then the most important thing I should probably protect is identity." Then replace static API keys with instance roles and managed identities (AWS IRSA, GCP Workload Identity, Azure Managed Identities), automate secret rotation, and implement a disable → observe → revoke → delete lifecycle for decommissioned service accounts.
Docker's security team used Panther to achieve 85% fewer false positives while tripling ingestion across their multi-cloud environment. Fewer false positives help make identity-based detection rules sustainable for lean teams.
Why Lateral Movement Stays Ahead of Most Defenses
Lateral movement stays ahead of many defenses because it rides on the same identities, protocols, and admin tools your environment already depends on. PowerShell, RDP, WMI, IAM roles, and Kubernetes service account tokens are part of normal operations. You usually can't block them outright, and signature-based detection cannot reliably separate malicious use from routine administration.
Perimeter security alone does not solve this problem. Global median dwell time rose to 14 days in 2025, with some of the stealthiest campaigns reaching nearly 400 days, well beyond many log retention policies.
Stopping lateral movement requires treating it as an identity and data quality problem. Complete, correlated visibility across cloud APIs, identity providers, and endpoints is what lets defenders connect the attack without stitching it together manually. Close the data gaps, normalize identities across sources, and build behavioral detection rules that operate on context rather than signatures, and you change the economics of lateral movement for attackers.
Start by auditing your log coverage against the eight default-off data sources identified above, then build cross-source correlation rules that track identity across Okta, Active Directory, and cloud IAM.
Share:
RESOURCES
