Share this
9 Lateral Movement Techniques Attackers Use (and How to Stop Them)
by Charlie Treadwell on Feb 28, 2026 11:32:27 PM
Every breach I've investigated or studied in detail has a moment where the attacker pivots. They've gotten their initial foothold (a phished credential, an exposed RDP port, a compromised vendor connection) and now they need to move. The specific lateral movement techniques they choose next determine whether the breach spirals or gets contained.
I've spent years talking to security engineers and CISOs about this exact inflection point. And the pattern is always the same: the initial access was survivable. It's the lateral movement that turned a single compromised endpoint into a domain-wide ransomware event.
The CrowdStrike 2026 Global Threat Report puts the average eCrime breakout time (the window between initial access and lateral movement) at 29 minutes, 65% faster than the prior year, with the fastest observed case at just 27 seconds. That's not a detection and response window. That's a blink.
This post breaks down 9 lateral movement techniques I see most often in breach reports and incident retrospectives, each mapped to its MITRE ATT&CK ID with a real-world example and, most importantly, what actually stops it at the network level.

Lateral movement by the numbers
- 29 minutes: Average eCrime breakout time from initial access to lateral movement, 65% faster than the prior year (CrowdStrike 2026 Global Threat Report)
- 82%: Percentage of detections that are malware-free, with attackers using valid credentials and trusted tools (CrowdStrike 2026 Global Threat Report)
- 90%: Percentage of ransomware breaches involving RDP abuse (Sophos 2024 Active Adversary Report)
- 71%: Living-off-the-land attacks that include PowerShell (Picus Security 2025 Red Report)
- 30%: Data breaches involving a third-party vector, double the prior year (Verizon 2025 DBIR)
Why lateral movement is the breach multiplier
Here's the thing about lateral movement: it's the phase that turns a $50K incident into a $5M one. Initial access gets the attacker through the door. Lateral movement lets them walk through every room in the building.
Most enterprise networks still rely on perimeter controls (firewalls, VPNs, endpoint detection) that do almost nothing once the attacker is already inside. The internal network is flat, or at best segmented into a handful of broad VLANs that don't restrict east-west traffic between devices in the same zone. That flat topology is exactly what every technique on this list exploits.
The defense isn't one tool. It's architectural control at the network layer, restricting which devices can talk to which other devices, over which protocols, based on verified identity. Each of these 9 techniques has identifiable network behavior that can be contained with the right segmentation policy.
The 9 lateral movement techniques
1. Pass-the-hash (MITRE ATT&CK T1550.002)
How it works: The attacker captures an NTLM password hash from memory (using tools like Mimikatz) and replays it to authenticate to other systems without ever needing the plaintext password. Windows NTLM authentication accepts the hash itself as proof of identity, so a stolen hash is as good as the password.
Real-world example: The NotPetya attack in 2017 used pass-the-hash alongside EternalBlue to propagate laterally across networks at Maersk, Merck, and other global enterprises, causing an estimated $10 billion in total damages. More recently, the CVE-2025-24054 campaign in March 2025 targeted government institutions in Poland and Romania, using malicious .library-ms files to harvest NTLMv2 hashes for lateral movement. Groups like APT28, APT41, and Wizard Spider continue to use this technique routinely.
Network-level defense: Pass-the-hash requires SMB (port 445) or WMI (port 135) connectivity between the compromised host and the target. If your segmentation policy restricts which endpoints can initiate SMB connections to which servers (based on device identity, not just network location), the replayed hash hits a wall. The authentication might succeed, but the network won't carry the traffic.
Practitioner insight: In my experience, the organizations most vulnerable to pass-the-hash are the ones where every workstation can reach every server over SMB. That's not a credential problem. That's a network architecture problem. Credential hygiene matters (disable NTLM where you can, use LAPS, enforce credential guard), but the network is where you actually contain the blast radius.
2. Remote Desktop Protocol abuse (MITRE ATT&CK T1021.001)
How it works: Attackers use stolen or brute-forced credentials to connect to systems via RDP (port 3389). Once connected, they have an interactive session with full GUI access, just like a legitimate admin. RDP is often enabled by default across Windows environments and rarely restricted at the network level.
Real-world example: According to the Sophos 2024 Active Adversary Report, RDP abuse appeared in 90% of ransomware incidents they investigated, the highest rate since they began tracking. Makop ransomware operations in 2025 targeted organizations across India, Brazil, and Germany using open RDP ports as both initial access and lateral movement vectors.
Network-level defense: Restrict RDP connectivity to specific, identity-verified admin workstations. Most users and most devices should never be allowed to initiate an RDP connection to a server. This is a straightforward policy: only devices identified as authorized admin endpoints, connecting from authorized users, can reach port 3389 on servers. Everything else gets denied at the switch.
Practitioner insight: RDP is the most over-provisioned protocol in enterprise IT. When I ask security teams "which devices can RDP to your domain controllers right now?", the answer is usually "we don't actually know." That's the problem. You can't defend a protocol you haven't scoped. Start by mapping every device that currently initiates RDP connections. I guarantee the list is longer than it should be.
3. PsExec and remote service exploitation (MITRE ATT&CK T1021.002)
How it works: PsExec is a legitimate Microsoft Sysinternals tool that allows remote command execution over SMB. Attackers use it (or its open-source equivalents like Impacket's smbexec) to execute payloads on remote systems using stolen admin credentials. It connects to the ADMIN$ share, copies a service binary, and executes it. From the network's perspective, it looks like normal Windows administration.
Real-world example: Ryuk and Conti ransomware operators made PsExec a core part of their playbook, using it to distribute ransomware encryptors across hundreds of endpoints simultaneously. In Conti's case, the DLL payload was dropped to ADMIN$ shares and remotely executed via PsExec in a matter of minutes. Black Basta, Akira, and LockBit have all adopted similar techniques, alongside more than 20 APT groups including HAFNIUM and Turla.
Network-level defense: PsExec relies on SMB (port 445) and the Windows Service Control Manager. Network-level microsegmentation can restrict which devices are allowed to push executables over SMB to server admin shares. In practice, the policy is simple: workstations don't push to ADMIN$ on other workstations. Only designated management servers, with verified identity, get that access path.
Practitioner insight: Here's what makes PsExec dangerous: it's also a tool your IT team probably uses every day. You can't just block it without breaking administration workflows. The answer isn't blocking the tool. It's restricting the network paths it can traverse. If a compromised accounting workstation tries to push a binary to a domain controller via SMB, the segmentation policy catches it because that workstation was never authorized for that communication flow.
4. Kerberoasting and Kerberos ticket abuse (MITRE ATT&CK T1558)
How it works: Any authenticated domain user can request a Kerberos Ticket Granting Service (TGS) ticket for any service account with a Service Principal Name (SPN). The ticket is encrypted with the service account's password hash. Attackers extract these tickets and crack them offline to obtain service account passwords, often gaining access to highly privileged accounts that haven't had their passwords rotated in years.
Real-world example: The Ascension Health ransomware attack in May 2024 exploited RC4-encrypted Kerberos tickets to crack privileged service accounts, contributing to a breach that took 140 hospitals to paper operations for six weeks and exposed data on 5.6 million patients. The FBI and ASD have also documented Kerberoasting use by Akira ransomware and APT40 in 2024 operations.
Network-level defense: Kerberoasting itself is a credential attack (targeting Active Directory), but the lateral movement that follows depends on network connectivity. Once the attacker cracks a service account password, they still need to reach the target systems over the network. Identity-based segmentation limits what systems those compromised service accounts can access by restricting traffic flows to only the paths that service legitimately needs.
Practitioner insight: Kerberoasting is a two-step problem. Step one is the credential compromise (fix that with AES-only encryption, regular password rotation for service accounts, and monitoring for anomalous TGS requests). Step two is the lateral movement that stolen credential enables. Most teams focus exclusively on step one. But even if the attacker cracks a service account password, if that account's traffic is constrained by identity-aware network policy to only its legitimate service paths, the damage is contained. Defense in depth means both layers.
5. WMI and PowerShell remoting (MITRE ATT&CK T1047 / T1021.006)
How it works: Windows Management Instrumentation (WMI) and PowerShell Remoting (WinRM) are built-in Windows management frameworks that allow remote code execution. Attackers use them because they're pre-installed, trusted by security tools, and leave minimal forensic artifacts. A single WMI command can execute a payload on a remote system, and PowerShell remoting provides full interactive sessions.
Real-world example: Fog ransomware, first observed targeting educational institutions in 2024, relied heavily on PowerShell and WMI for lateral movement in a classic living-off-the-land approach. According to the Picus Security 2025 Red Report, PowerShell appeared in 71% of living-off-the-land attacks, making it the single most common post-compromise tool across all ransomware families.
Network-level defense: WMI uses DCOM/RPC (port 135 plus dynamic ports). PowerShell Remoting uses WinRM (ports 5985/5986). Both require network connectivity between source and target. Segmentation policies that restrict which devices can initiate WinRM or RPC connections to which endpoints directly limit these techniques. The key is identity-aware policy: your IT admin's jump box can use WinRM to managed servers. A random workstation can't.
Practitioner insight: This is the lateral movement technique that frustrates security teams the most, because it uses the same tools admins rely on. The reality is that you can't distinguish malicious WMI from legitimate WMI at the payload level without deep inspection. But you can absolutely distinguish it at the network level. If a device that's never initiated a WMI connection to your file servers suddenly starts doing it, that's a policy violation your network should catch. The question isn't "is this WMI call malicious?" It's "should this device be making WMI calls to that destination at all?"

6. SSH hijacking (MITRE ATT&CK T1563.001)
How it works: Attackers on a compromised Linux or Unix host hijack existing SSH sessions or steal SSH keys (private keys, SSH agent sockets) to pivot to other systems. Because many environments use key-based SSH authentication with shared keys or agent forwarding, compromising one host can provide a chain of trust to dozens of others.
Real-world example: SSH-Snake, a self-modifying worm released in January 2024, automated network traversal by discovering SSH private keys on compromised systems and using them to propagate. CVE-2024-6387 (RegreSSHion), a critical OpenSSH vulnerability disclosed in mid-2024, enabled unauthenticated remote code execution as root on glibc-based Linux systems, giving attackers a direct path into SSH-accessible infrastructure.
Network-level defense: SSH runs on port 22 (typically). Microsegmentation policies should restrict which devices can initiate SSH connections and to which destinations. In most environments, only a small set of admin workstations and jump boxes should have SSH access to production servers. Restricting these paths at the network layer means a compromised web server can't SSH-hop to your database tier, even if the attacker has valid keys.
Practitioner insight: SSH key management is a mess in most organizations I've worked with. Keys get copied, agent forwarding gets left on, and nobody has an inventory of which keys grant access to which systems. That's an identity and access management problem, and you should fix it. But in the meantime, network-level segmentation gives you a containment layer. Even with a valid key, the attacker can't use it if the network policy blocks SSH traffic from the compromised host to the target.
7. Exploitation of internal application vulnerabilities (MITRE ATT&CK T1210)
How it works: Attackers exploit unpatched vulnerabilities in internal-facing applications and services to move laterally. Unlike external-facing exploits, these target services that are only accessible from inside the network: internal web apps, database servers, print spoolers, file shares, and management interfaces. The assumption that "it's internal, so it's safe" means these systems are often months or years behind on patches.
Real-world example: EternalBlue (the SMBv1 exploit behind WannaCry and NotPetya) is the textbook case, but the pattern persists. ProxyLogon and ProxyShell targeted internal Exchange servers in 2021. In 2024, multiple zero-days in Ivanti VPN appliances were exploited for credential theft, session hijacking, and lateral movement into internal networks. Log4Shell demonstrated that a single vulnerability in a ubiquitous library could provide remote code execution across thousands of internal services.
Network-level defense: Internal vulnerability exploitation requires network reachability between the attacker's current position and the vulnerable service. Microsegmentation limits the blast radius by restricting which devices can communicate with internal services. Your marketing team's workstations don't need access to your Exchange management interface, your print spooler management ports, or your database admin consoles. Every unnecessary network path is an attack path.
Practitioner insight: The honest answer is that you can't patch everything instantly. OT environments run systems that can't be patched at all (more on that next). The question isn't "are you fully patched?" because nobody is. The question is "if an attacker exploits an unpatched internal service, how far can they get?" If the answer is "everywhere, because the network is flat," then patching speed is irrelevant. Microsegmentation buys you time by limiting what an exploited service can reach.
8. Compromised credentials in OT/IoT environments (MITRE ATT&CK T1078 in OT context)
How it works: OT and IoT devices frequently use default credentials, shared passwords, hardcoded service accounts, or legacy protocols (Telnet, unencrypted Modbus, BACnet) that transmit credentials in plaintext. Attackers who gain initial access to an IT network pivot into OT segments using these weak credentials. Because OT devices rarely support multi-factor authentication, certificate-based auth, or even password complexity requirements, a single stolen credential can unlock an entire production network.
Real-world example: Volt Typhoon, the Chinese state-sponsored group documented by CISA, NSA, and FBI in their joint advisory, has been pre-positioning in U.S. critical infrastructure since at least 2023. Their approach: compromise IT environments using valid credentials and living-off-the-land techniques, then move laterally toward OT assets in communications, energy, transportation, and water systems. They've maintained persistent access to some environments for five or more years. In OT/IoT specifically, the Nozomi Networks 2025 OT/IoT Security Report found that brute-forcing default SSH and Telnet credentials remains the top technique for gaining access to IoT devices.
The convergence of IT and OT networks makes this worse. Organizations that merged their IT and OT networks for operational efficiency have created direct lateral movement paths from compromised IT endpoints to PLCs, HMIs, and safety instrumented systems. The OT devices themselves can't defend against this. They weren't designed to.
Network-level defense: This is where identity-based microsegmentation earns its keep. OT and IoT devices can't run endpoint agents, can't authenticate via 802.1X, and can't support modern credential management. But you can identify these devices by their network behavior, communication patterns, device type, firmware version, and Purdue level, then enforce policy based on that identity. A PLC that legitimately communicates with its HMI and engineering workstation over specific industrial protocols shouldn't be reachable from IT workstations over SSH or Telnet. That's an enforceable network policy, and it doesn't require any changes to the OT device itself.
The IEC 62443 standard specifically requires this kind of zoning: segmenting OT assets into security zones with controlled conduits between them. Identity-based approaches implement zones and conduits at the switch level without requiring OT network redesigns or production downtime. For a detailed comparison of how identity-based approaches compare to traditional NAC in OT environments, see our guide to the best NAC alternatives for industrial networks.
Practitioner insight: I've talked to OT security teams who know their default credentials are a problem but can't change them because the vendor doesn't support it, or because changing the password on a process controller requires a maintenance window that won't happen for six months. The reality is that credential hygiene in OT is a multi-year project with real operational constraints. You can't wait for it to be finished before you defend the network. Network-level segmentation is the control you can deploy now, around the devices you can't change, using the infrastructure you already have. It's not a replacement for credential management. It's the containment layer that protects you while you work on it.
9. Supply chain and trust relationship exploitation (MITRE ATT&CK T1199)
How it works: Attackers compromise a trusted third party (a software vendor, managed service provider, IT supplier, or business partner) and use that trusted connection to move laterally into the target organization. Because these connections are pre-authorized (VPN tunnels, API integrations, remote access tools, software update channels), the attacker inherits the trust that the third party was granted.
Real-world example: SolarWinds (2020) is the defining case: compromised build process, 18,000 organizations received malicious updates, and the attackers (Russian SVR) moved laterally through trusted Orion update channels into federal agencies and Fortune 500 companies. But the pattern has repeated. Kaseya (2021) hit 1,500 organizations through MSP infrastructure. 3CX (2023) was a supply chain attack that itself originated from a compromised third-party software package. MOVEit (2023) impacted more than 600 organizations. According to the Verizon 2025 DBIR, 30% of all data breaches now involve a third-party vector, double the prior year.
Network-level defense: Third-party connections should be treated as untrusted entry points, not as extensions of your internal network. Microsegmentation can enforce strict access policies on third-party connection points: the managed service provider gets access to the specific systems they manage, over the specific protocols they need, during the specific time windows they operate. They don't get broad lateral access to your network. If a trusted vendor connection is compromised, the blast radius is limited to the resources that vendor was authorized to reach.
Practitioner insight: The uncomfortable truth about supply chain attacks is that you're defending against an attacker who already has legitimate access. Traditional perimeter security is useless here because the connection was explicitly allowed. What works is granular, identity-aware policy enforcement on every third-party access path. I've seen organizations with hundreds of vendor VPN connections, and when I ask "what can each vendor actually reach once they're connected?", the answer is usually "everything on that VLAN." That's not a third-party access policy. That's an open door. Microsegmentation turns that open door into a controlled corridor.
Connecting the defense: from technique-level to architecture-level
If you've read through all 9 techniques, you'll notice a pattern: every single one requires network connectivity between the attacker's current position and the target. Pass-the-hash needs SMB. RDP needs port 3389. PsExec needs ADMIN$ shares. WMI needs RPC. SSH needs port 22. Every technique on this list has a network footprint.
That's not a coincidence. It's the fundamental insight behind microsegmentation as a lateral movement defense: you don't have to detect every technique perfectly. You have to control which network paths exist in the first place.
The practical approach looks like this:
- Discover and classify every device: You can't write policy for assets you don't know about. Complete asset visibility (IT, OT, IoT, virtual, cloud) is the prerequisite.
- Map communication flows: Understand which devices legitimately talk to which other devices, over which protocols. Most of the lateral movement paths on this list exist because organizations have never mapped their actual east-west traffic.
- Enforce identity-based policy: Restrict communication to only the verified, authorized flows. Policy follows the device identity, not the network port or VLAN. When a device moves, policy moves with it.
- Continuously verify: Identity and context aren't static. Device posture changes. New vulnerabilities emerge. Policy enforcement should adapt based on real-time identity verification and risk context.

This isn't a single product pitch. It's a network architecture decision that determines whether an attacker who gets in can move freely or gets contained at the first hop. The organizations I've seen do this well share one thing in common: they stopped treating their internal network as a trusted zone and started enforcing policy on every east-west connection.
Frequently Asked Questions About Lateral Movement Techniques
What are the most common lateral movement techniques used by attackers?
The most common techniques I see in breach reports are RDP abuse (appearing in 90% of ransomware cases, according to Sophos), pass-the-hash using stolen NTLM credentials, PsExec for remote code execution over SMB, and PowerShell/WMI living-off-the-land techniques. What they all share is a reliance on network connectivity between compromised hosts and targets, meaning network-level segmentation can contain all of them.
How can microsegmentation prevent lateral movement in a network?
Microsegmentation restricts which devices can communicate with which other devices, over which protocols, based on verified identity. Every lateral movement technique on this list requires a network path from the attacker's current position to the next target. If that path doesn't exist because policy blocks it, the technique fails regardless of what credentials or tools the attacker has. It doesn't replace detection. It limits the attacker's options before detection even kicks in.
How long does it take for attackers to achieve lateral movement after initial access?
It's getting faster every year. The CrowdStrike 2026 Global Threat Report measured the average eCrime breakout time at 29 minutes, with the fastest case at 27 seconds. That means network-level controls need to be in place before the attack happens, not deployed in response to it. You can't segment your way out of a breach in real time. The architecture has to already be there.
What is the difference between lateral movement and privilege escalation?
Privilege escalation means getting higher-level access on the system you've already compromised (going from a standard user to admin on the same machine). Lateral movement means moving to a different system entirely. In practice, attackers chain them together: escalate privileges on host A to steal credentials, then use those credentials to move laterally to host B. They're different MITRE ATT&CK tactics (TA0004 vs. TA0008), but they're almost always used in combination.
Go deeper on lateral movement prevention
- Understanding and Preventing Lateral Movement: A Strategic Guide for Enterprise Security Leaders
- The Top 11 Cyberattacks Using Lateral Movement: A 2023-2024 Analysis
- How to Stop Lateral Movement in Black Basta, Akira, and LockBit Ransomware Attacks
- The Hidden Highway: How Ransomware Groups Are Exploiting Lateral Movement in Critical Infrastructure
- Preventing Ransomware Through Microsegmentation: 2025 Guide to Zero Trust Network Defense
- Microsegmentation: The Essential Guide to Network Security
- IEC 62443 in 2025: Network Segmentation Requirements and Changes
About the Author
Charlie Treadwell is the Chief Marketing Officer at Elisity, where he focuses on identity-based microsegmentation for IT, OT, and IoT environments. With years of experience in network security and direct engagement with CISOs and security engineers across healthcare, manufacturing, and critical infrastructure, Charlie writes about the practical realities of stopping lateral movement, implementing Zero Trust, and defending converged networks. Connect with him on LinkedIn.
Share this
- Enterprise Cybersecurity (59)
- Zero Trust (25)
- Microsegmentation (23)
- Enterprise Architecture Security (13)
- Lateral Movement (10)
- Elisity (8)
- Network Security (8)
- Ransomware (6)
- Identity (5)
- Cyber Resilience (4)
- Cybersecurity Healthcare (4)
- Elisity Release (4)
- Remote Access (4)
- ICS Security (3)
- Identity and Access Management (2)
- Industrial Cybersecurity (2)
- OT Security (2)
- S4x26 (2)
- AI Security (1)
- Agentic AI (1)
- Forrester (1)
- MITRE (1)
- February 2026 (12)
- January 2026 (4)
- December 2025 (4)
- November 2025 (3)
- October 2025 (5)
- September 2025 (4)
- August 2025 (5)
- July 2025 (5)
- June 2025 (5)
- May 2025 (4)
- April 2025 (5)
- March 2025 (6)
- February 2025 (3)
- January 2025 (5)
- December 2024 (4)
- November 2024 (5)
- October 2024 (7)
- September 2024 (5)
- August 2024 (3)
- July 2024 (4)
- June 2024 (2)
- April 2024 (3)
- March 2024 (2)
- February 2024 (1)
- January 2024 (3)
- December 2023 (1)
- November 2023 (1)
- October 2023 (2)
- September 2023 (3)
- June 2023 (1)
- May 2023 (3)
- April 2023 (1)
- March 2023 (6)
- February 2023 (4)
- January 2023 (3)
- December 2022 (8)
- November 2022 (3)
- October 2022 (1)
- July 2022 (1)
- May 2022 (1)
- February 2022 (1)
- November 2021 (1)
- August 2021 (1)
- May 2021 (2)
- April 2021 (2)
- March 2021 (3)
- February 2021 (1)
- November 2020 (2)
- October 2020 (1)
- September 2020 (1)
- August 2020 (3)

No Comments Yet
Let us know what you think