SharePoint exploitation and stolen keys: what IAM teams should notice

TL;DR: Microsoft SharePoint’s ToolShell vulnerabilities were actively exploited within days of disclosure, enabling attackers to steal machine keys, move laterally, and deploy ransomware, according to Cybertrust Japan’s summary of vendor and incident reporting. The pattern shows how exposed internet-facing collaboration systems can become privilege escalators when cryptographic trust is broken.

NHIMG editorial — based on content published by Cybertrust Japan covering SharePoint vulnerability exploitation: analysis of ToolShell abuse and follow-on ransomware activity

By the numbers:

• Eye Security said it scanned more than 8,000 SharePoint servers and found that dozens of systems were actively compromised between attack waves.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: What breaks when SharePoint machine keys are exposed in a server compromise?

A: When machine keys are exposed, patching the vulnerable code no longer guarantees recovery because the attacker may still be able to forge trusted authentication tokens.

Q: Why do internet-facing collaboration servers often become privilege escalators?

A: Internet-facing collaboration servers become privilege escalators because they sit close to documents, integrations, and trust material that other services accept as legitimate.

Q: How can security teams tell whether exploit activity has become an identity incident?

A: Look for account creation, privilege changes, anomalous administrative tools, directory reconnaissance, or sudden credential rotation needs on the affected host.

Practitioner guidance

• Restrict server-side secret access Limit which services can read SharePoint machine keys, application secrets, and related trust material, and move those values out of the server whenever possible.
• Hunt for post-exploitation tooling Create detections for web shells, Mimikatz, PsExec, Impacket, and abnormal Group Policy changes across SharePoint-adjacent hosts.
• Reduce administrative blast radius Remove standing domain-level administrative paths from servers that can be reached from the internet, and segment management channels so a compromised application host cannot directly become a launch point for enterprise-wide deployment.

What's in the full article

Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:

• IoC lists and vendor-detected indicators from Microsoft, Eye Security, and Palo Alto to support incident hunting.
• Specific command sequences, filenames, and web shell behaviour observed during the ToolShell exploitation chain.
• Per-source detection guidance, including how XDR systems can spot suspicious POST activity and follow-on exploitation.
• Named threat actor tracking and incident references that help teams map this campaign to wider hostile activity.

👉 Read Cybertrust Japan’s analysis of SharePoint ToolShell exploitation and ransomware spread →

SharePoint exploitation and stolen keys: what IAM teams should notice?

Explore further

View Full Forum →  |  NHI Foundation Course →