SharePoint Under Siege: Why Lateral Movements Work, and How to Stop It

The recent SharePoint 0-day (CVE-2025-53770), now linked to the ToolShell campaign, has reawakened enterprise fears around lateral movement. What started as a remote code execution (RCE) vulnerability on exposed SharePoint servers quickly escalated to full internal compromise, with attackers using forged tokens, dropped webshells, and privilege escalation to move sideways into Teams, Exchange, and other Microsoft services.

As Eye Security's excellent triage highlights, the exploit enables attackers to plant a web shell and extract ASP.NET machine keys. With those keys, they forge authentication tokens, impersonate users, and move laterally with near-total stealth.

This isn't just about SharePoint. It's about a bigger question: why is lateral movement still this easy in 2025? And what will actually stop it?

What Is Lateral Movement and Why Is It So Effective?

Lateral movement refers to the set of techniques attackers use to pivot from an initial foothold to other systems within the network. It's the "quiet part" after the breach - the phase when the attacker maps out your environment, impersonates legitimate users, steals credentials, and quietly escalates their access.

ToolShell, like many modern attacks, leverages stolen keys or tokens to create authenticated sessions that bypass standard defenses. Once inside, network segmentation offers little protection. Why? Because most enterprises still rely on perimeters between machines - not between processes.

Why Traditional Defenses Fall Short

Recommendations like network segmentation and least privilege access are standard. They're also mostly ineffective against modern attacks. Segmenting VMs or VLANs is not the same as segmenting the actual runtime identity and behavior of each process. Once a legitimate process is hijacked — as in the SharePoint attack — the lateral movement begins inside the same host.

No traditional firewall, WAF, or microsegmentation solution can see that level of granularity. Worse, many tools assume trust based on IP addresses or service names - which are trivial for attackers to spoof once inside.

What If Lateral Movement Was Impossible?

At Riptides, we approach this differently. We believe every process - even those running on the same machine - must be explicitly authenticated, authorized, and continuously verified. That’s why we built a kernel level telemetry and enforcement layer that:

• Assigns SPIFFE-based identities to every process
• Enforces mutual TLS (mTLS) between all communications, even local ones
• Monitors posture continuously, not just at connection time
• Controls flows with per-process, per-intent policies at the kernel level

This means if an attacker compromises a workload but tries to pivot to other applications, or an internal data pipeline, they’ll be blocked. Not because of a VLAN rule. But because the process trying to communicate doesn’t have the right SPIFFE identity or posture. It simply won’t pass the mTLS handshake, and the kernel will drop the packet.

Why Zero Trust Must Include Internal Tools

A dangerous myth persists in security: that internal services can be "trusted by default." But the ToolShell campaign is yet another reminder that internally hosted tools - even critical ones like SharePoint - can become entry points. Zero Trust isn’t just about users or external APIs. It’s about every binary, every tool, every CLI, every service.

Riptides brings Zero Trust down to the process level - with SPIFFE based identity, posture enforcement, mTLS, and flow control from the kernel up. We don’t just log attacks. We stop them - before they move. It's time to move beyond surface level defenses - real Zero Trust starts with every process, every flow, and every decision enforced close to execution. That’s why we’re rethinking workload identity at the kernel level.

Take control of lateral movement risks - let’s talk!

‍