Look for suspicious POST requests to /_layouts/15/ToolPane.aspx, unusual Referer values such as /_layouts/SignOut.aspx, and unexpected code execution or network activity from the server. Those signals matter because exploitation can blend into normal application traffic. Correlate SharePoint logs with endpoint alerts to distinguish routine administrative activity from an active exploit chain.
What ToolShell exploitation looks like in SharePoint telemetry
ToolShell exploitation usually leaves a narrow but recognizable trail: a crafted POST to /_layouts/15/ToolPane.aspx, followed by requests that do not fit normal user behaviour, and often a session context that looks inconsistent with the surrounding traffic. The practical question is not whether one request looks odd in isolation, but whether the sequence shows an exploit attempt that reaches execution or post-exploitation activity.
Because SharePoint is a legitimate, busy application, defenders need to read these signals as a chain. A single suspicious request may be noise, but the combination of unusual endpoint access, strange referrers, and subsequent process or network activity is what turns a log line into a credible incident. For broader exploitation patterns, see the 52 NHI Breaches Analysis for how attacker abuse often moves from initial access to lateral action and persistence.
- Focus first on request path and method, then on the surrounding request chain.
- Treat abnormal referrers and timing as correlation clues, not proof by themselves.
- Escalate quickly if the server starts making outbound connections or spawning unexpected child processes.
For vulnerability context, it is worth checking whether the affected SharePoint build appears in the NIST National Vulnerability Database and whether it is listed in the CISA Known Exploited Vulnerabilities Catalog, because confirmed exploitation changes how aggressively you should treat weak signals.
How to separate exploit traffic from normal SharePoint administration
The hardest part of detection is that SharePoint administration can also generate privileged-looking traffic. That is why the most useful indicators are not isolated strings, but anomalies in sequence, source, and outcome. A request to /_layouts/15/ToolPane.aspx with a referer like /_layouts/SignOut.aspx is especially worth examining when it is followed by child activity that would not normally occur after a page interaction.
Correlate IIS and SharePoint logs with endpoint telemetry so you can connect a web request to a process, script, or network event on the host. If the web layer shows a suspicious POST but the endpoint remains quiet, you may be looking at failed probing. If the server launches PowerShell, cmd, or makes unexpected outbound calls shortly after the request, the event has moved beyond simple reconnaissance.
- Compare the source IP, user agent, authentication state, and URL sequence against known admin workflows.
- Check whether the same actor repeats requests across multiple servers or time windows.
- Validate whether the response codes and follow-on actions match a normal administrative session.
Where defenders need an exploitation baseline, the FIRST EPSS scoring model can help prioritise vulnerable versions that are more likely to be actively targeted, while the Gladinet Hard-Coded Keys RCE Exploitation case study shows how web-facing exploitation often turns into rapid code execution once attackers find a viable path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Suspicious web, host, and network activity must be monitored together on SharePoint servers. |
| DE.AE — Anomalies and Events | ToolShell indicators are abnormal event patterns that need anomaly detection and triage. | |
| Recommendation — Correlate application, endpoint, and network telemetry to detect active exploitation quickly. Flag unusual POST/referrer sequences and investigate them as anomalous events. | ||
| CIS Controls v8 | 8 — Audit Log Management | SharePoint and endpoint logs are the primary evidence for distinguishing exploit traffic from routine admin activity. |
| 13 — Network Monitoring and Defense | Outbound connections from a SharePoint host can confirm post-exploitation activity. | |
| Recommendation — Centralise and review SharePoint, IIS, and endpoint logs for suspicious execution chains. Inspect server egress and alert on unexpected external connections after suspicious requests. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | ToolShell exploitation is a public-facing application abuse pattern against SharePoint. |
| T1059 — Command and Scripting Interpreter | Unexpected code execution on the server is a key confirmation signal after exploitation. | |
| Recommendation — Map SharePoint exploit telemetry to public-facing application abuse and hunt for follow-on execution. Look for script or command interpreter activity that follows the suspicious SharePoint request. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Exploitation of web servers often leads to credential or secret theft on the host. |
| Recommendation — Rotate exposed secrets and credentials if SharePoint compromise is suspected. | ||
Practitioner Guidance
What to verify: Confirm whether the suspicious POST is paired with a believable user context. If the request comes from an admin network, test account, or maintenance window, you still need host-level evidence before dismissing it as legitimate.
What to prioritise: Hunt for post-request execution on the SharePoint host first, because that is the clearest sign the event has progressed from probing to compromise. Outbound DNS, HTTP, or PowerShell activity after the request is higher value than chasing isolated log noise.
Common mistake: Treating a strange referrer as sufficient proof. In practice, the referrer matters because it helps separate attacker automation from routine browsing, but the decision should rest on correlation across application, endpoint, and network telemetry.
Practitioner takeaway: The most reliable signal is not the suspicious URL alone, but the chain from anomalous SharePoint request to unexpected host activity; if that chain exists, assume the server may already be in an active exploit state.
Related resources from NHI Mgmt Group
- What signs indicate a WSUS exploitation attempt is under way?
- What are the signs that a SharePoint server may have been exploited through CVE-2025-53770?
- What are the signs that PHP-CGI exploitation is already underway on a server?
- What are the signs that a webshell is being used after exploitation of a server vulnerability?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
