Detecting lateral movement in 2026: what changed since the RDP-over-SSH era

Look, the lateral-movement detections most of us learned still fire. RDP logons, SMB to admin shares, a service install where one shouldn’t be. They still catch real intrusions. The problem is they’re covering a smaller and smaller slice of what an attacker actually does to get from the first box to the fifth one. If your lateral-movement coverage is mostly MITRE ATT&CK T1021 endpoint rules, you’re watching the door most crews stopped using.

I want to walk through what changed since the era when “lateral movement detection” mostly meant watching for psexec and RDP. Three shifts. None of them retire the old rules, but all of them move the interesting signal somewhere your old rules don’t look.

What the old playbook watched

For years the model was endpoint plus network. You watched:

• RDP: Windows Security 4624 with logon type 10 (RemoteInteractive), plus the network side.
• SMB / admin shares: 5140 and 5145 for share access, PsExec service creation showing up as 7045, the ADMIN$ and IPC$ reach-out.
• Remote execution: WMI and DCOM spawning, Sysmon EID 1 with a parent that has no business launching cmd, EID 3 for the network connection, EID 8 when something injects a thread remotely.
• Credential reuse on the box: pass-the-hash showing up as 4624 type 3 with the right logon package, LSASS access via Sysmon EID 10.

All of that still matters. Keep it. But notice what it assumes: that the attacker touches an endpoint you’re watching, runs a process you can see, or trips a network rule. In 2026 that assumption holds less and less often.

Shift one: it’s an identity problem now

This is the big one. Something like three quarters of the intrusions reported in 2025 were malware-free. The attacker didn’t drop a tool. They logged in.

Token theft, adversary-in-the-middle phishing, MFA fatigue, and straight token replay (T1550, use of alternate authentication material) mean the lateral step is an authentication, not an execution. And here’s the part that breaks the old playbook: when an attacker replays a valid session token or a stolen Kerberos ticket, the destination host sees a normal, authenticated session. Your process rules don’t fire because there’s no weird process. Your network rules don’t fire because it’s a normal protocol on a normal port. The box is behaving exactly as designed. It’s just doing it for the wrong person.

You catch this in identity telemetry, not endpoint telemetry. On-prem, that’s your Kerberos data: 4768 and 4769 with encryption downgrades, service tickets requested for services the account never touches, ticket lifetimes that don’t match your policy. In the cloud, it’s sign-in logs, token issuance events, impossible-travel and unfamiliar-sign-in-properties risk, and session tokens showing up from an IP or device that never held them before. Microsoft’s token theft investigation playbook is a decent map of what those events look like when it goes wrong.

If you take one thing from this post: the lateral-movement signal moved up the stack, from the endpoint to the identity provider. A detection program that hasn’t followed it up there is defending the 2019 attack path.

Shift two: the tool is legitimate now

The second shift is remote monitoring and management software. Attackers stopped bringing their own remote-access tool because yours is already installed, signed, and allowlisted. SimpleHelp, AnyDesk, ScreenConnect, TeamViewer, Atera. The DragonForce activity against SimpleHelp last year is the case everyone points at, but it’s a whole category.

Process-name detection is useless here. The binary is signed by a real vendor and half your IT department uses it for real. So you can’t alert on “AnyDesk ran.” You have to alert on context:

• An RMM agent getting installed on a host that isn’t in your managed fleet (7045 or Sysmon 11/13 for the install, matched against your actual RMM inventory).
• RMM running on a server when your RMM only belongs on workstations.
• The RMM process spawning cmd.exe or powershell.exe, which the legitimate workflow rarely does.
• RMM network connections going to something other than the vendor’s own infrastructure.

The catch, and it’s a real one, is false positives. Your own admins do some of this. The rule only works if you’ve baselined which RMM tools you actually run and on which tier of host. That baseline is the whole job. Without it the rule fires on Tuesday-morning helpdesk work and gets tuned out by Thursday.

Shift three: living off the land ate everything else

Roughly eight in ten severe breaches in 2025 involved living-off-the-land, and PowerShell showed up in most of them. This isn’t news, but it changes what a lateral-movement rule can be. If the attacker moves with WinRM (4624 type 3 landing next to a wsmprovhost.exe), WMI, scheduled tasks, or PowerShell remoting, there’s no malicious file to match. There’s only behavior that’s individually normal and collectively wrong.

Which is the same conclusion the other two shifts reach from different directions: no single telemetry source catches this anymore. A 4624 type 10 on its own is noise. That same logon, correlated with a token issued minutes earlier from an unfamiliar device, followed by an RMM install and a WinRM session outbound to three more hosts, is an intrusion you can see. The detection isn’t in any one event. It’s in the join.

What I’d tune first

If I were standing up lateral-movement coverage from scratch in 2026, in order:

1. Identity first. Get Kerberos service-ticket telemetry and cloud sign-in logs into the same place as your endpoint data. Alert on token and ticket reuse from new devices before you write another endpoint rule. This is where the malware-free intrusions live.
2. RMM inventory then RMM alerting. Spend the week building the baseline of what remote-access software you actually run, where, and by whom. Then alert on everything outside it.
3. Correlation over single-event rules. A logon plus an identity anomaly plus a follow-on remote session is worth ten standalone 4624 rules. If your platform can’t join across endpoint, network, and identity, that’s what to fix before you write more Sigma.
4. Keep the old rules. RDP, SMB, service-install, LSASS-access detections still catch the crews that never upgraded. Don’t retire them. Just stop pretending they’re the whole picture.

Honest caveat, because this is the part the vendor decks skip: correlated, twenty-four-hour coverage across identity, endpoint, and network is the hard part, and it’s mostly a staffing problem, not a tooling one. The telemetry is available. Watching it at 3am on a Sunday, and actually acting on the join before the fifth host is encrypted, is what most teams can’t sustain. That’s a separate post.

This catches most of it. Not all. But if your lateral-movement program still starts and ends at the endpoint, the identity side is where I’d spend the next month.