Adversary Tradecraft: Exploitation of the SharePoint RCE

CVE-2025-53770 and CVE-2025-53771 are critical remote code execution vulnerabilities (CVSS base score 9.8) impacting Microsoft SharePoint, a widely deployed enterprise collaboration and content management platform.

In this blog, we will simulate the exploitation of this SharePoint RCE vulnerability and analyze the resulting telemetry inside Graylog. Throughout the post we will highlight actionable threat hunting and detection strategies you can use to monitor, identify, and defend against real-world exploitation in your own environments.

This issue affects on-premises deployments of SharePoint Server:

• SharePoint Server 2016
• SharePoint Server 2019
• SharePoint Subscription Edition
• See Microsoft for further guidance here
  …and likely earlier, unsupported versions as well.

Attack Overview of The SharePoint RCE

Attackers exploit a chain of vulnerabilities in Microsoft SharePoint that ultimately allows unauthenticated remote code execution. The root cause lies in SharePoint’s insufficient validation of page components—specifically how ToolPane.aspx handles crafted HTTP POST requests and improperly manages the deployment of layout files.

Using this flaw, an attacker can upload a malicious .aspx file (commonly named spinstall0.aspx) directly into a trusted SharePoint directory. This file acts as a webshell and can later be accessed via a simple GET request. Once active, it enables the attacker to extract sensitive application-level secrets, including SharePoint’s MachineKey (used to sign __VIEWSTATE payloads). The attacker then forges signed ViewState objects that are deserialized without validation, resulting in arbitrary code execution inside the SharePoint worker process (w3wp.exe).

The most widely observed exploitation campaign uses the spinstall0.aspx webshell, but research by Palo Alto Networks has identified at least two additional variants, including obfuscated filenames, payloads using sleep() to delay detection, and artifacts that drop configuration data into files like debug_dev.js.

Emulating the Adversary SharePoint RCE

Lab Setup

To emulate and analyze the attack, we’ve set up a lab environment with Graylog Enterprise 6.1.3 and Illuminate Microsoft IIS Content Pack enabled to parse, normalize and enrich the logs. The pack is available in Illuminate 7.0 with the Security and Enterprise License.  A Graylog rule is also included.

A Windows Server 2025 will serve as our “victim host” with a default installation of SharePoint and Microsoft IIS. The attack is unauthenticated and therefore SharePoints audit logs will not log this incident. The adversary has to use a crafted payload. SharePoint uses Microsoft IIS as a webserver. IIS creates logs that contain the payload.

Additionally, Windows Server may log process creation.

By sending Microsoft IIS logs and Microsoft system/security events to Graylog, this attack can be detected.

Requirements:

• Installation of a vulnerable Microsoft Sharepoint version (the M365 versions are not vulnerable)
• Installation of Microsoft IIS
• IIs log forwarding to Graylog

Currently, a publicly available PoC is not available, but the attack can be simulated.

Simulate the SharePoint RCE

The attacker has to send a payload to Sharepoint. The target is the Sharepoint page ToolPane.aspx via a post request.

/_layouts/15/ToolPane.aspx?DisplayMode=Edit

This file allows an unauthenticated upload.

In a webserver log such a request shows up like:

2025-07-22 14:12:46 10.0.0.12 POST /_layouts/15/ToolPane.aspx DisplayMode=Edit 443 - 104.238.159.149 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/122.0.0.0+Safari/537.36 - 200 0 0 431

The next step is to upload a malicious ASPX file like spinstall0.aspx that gets saved into a trusted directory like:

C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\15\TEMPLATE\LAYOUTS

Note:
This is an example directory, a real exploit may be located at a different location.

Via a GET command, the webshell gets triggered. In a log file, this may look like:

2025-07-22 14:13:21 10.0.0.12 GET /_layouts/15/spinstall0.aspx - 443 - 103.186.30.186 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko /_layouts/SignOut.aspx 200 0 0 209

Note:
Many detections aim to identify the exploit via the file name spinstall0.aspx. More sophisticated adversaries will change the file name.

The spinstall0 webshell will try to extract Machine Keys and/or Validation Keys.

This step is done in the memory and usually not logged.
Yara rules can detect the keywords ValidationKey and DecryptionKey in a memory dump.

Post Exploitation

The next optional step is to run an encoded PowerShell command.

The chain could be:
w3wp.exe → cmd.exe → powershell.exe with -EncodedCommand

Sysmon can detect these activities.

Unusually long ViewState POSTs may contain encoded commands, an IIS webserver log could look like this:

2025-07-22 17:01:05 134.199.202.205 POST /Pages/default.aspx __VIEWSTATE=some_ecoded_data 443 - 131.226.2.6 Mozilla/5.0 - - 200 0 0 102

Detections

Requirements to detect this exploit:

• Installing the Illuminate Microsoft IIS Content Pack in Illuminate 7.0 or
• Create an own parsing pack or
• Use a Graylog Community Pack for Microsoft IIS
• Installation of Sysmon and the Illuminate Sysmon Content pack

At least two ways can be used to detect an incident.
1. Writing a Sigma rule (need a Security License) or
2. Creating a Graylog rule (Graylog Open).

This chapter shows both approaches.

Sigma rule

Sigma rules can be utilized to detect the typical behavior of this attack. One Sigma rule can look for suspicious webserver logs and a different rule can look for suspicious process creation.

For this attack spinstall0.aspxa a malicious ASP.NET web shell is often used. It is used to extract sensitive cryptographic material, specifically the ValidationKey and DecryptionKey.

Note: Adversaries may use other web shells or rename the file to avoid detection.

Sigma Rule 1

This rule can be used together with webserver logs and is used in this blog. Sharepoint uses Microsoft IIS.

title: SharePoint Exploitation Activity via IIS Logs (CVE-2025-53770)
id: a04a4a2e-84f9-4a84-8c44-8e35f8c53770
status: experimental
description: Detects signs of exploitation related to SharePoint CVE-2025-53770 in IIS logs by matching specific file paths, file hashes, and IP indicators
author: Stefan Waldvogel / Graylog Security
date: 2025/07/21
references:
  - https://research.eye.security/sharepoint-under-siege/
  - https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/#hunting-queries
  - https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/
logsource:
  category: webserver
  product: windows
  service: iis
detection:
  ioc_uri_stem:
    http_request_path|contains:
      - "/_layouts/15/spinstall0.aspx"
      - "/_layouts/16/spinstall0.aspx"
      - "/_layouts/15/debug_dev.js"
      - "/_layouts/16/debug_dev.js"
  ioc_c_ip:
    source_ip|contains:
      - "131.226.2.6"
      - "134.199.202.205"
      - "104.238.159.149"
      - "188.130.206.168"
  ioc_cs_referer:
    http_referrer|contains:
      - "c34718cbb4c6.ngrok-free.app"
  ioc_hash:
    hash_sha256|contains: # Only applicable if logs include hash data (e.g., endpoint sensor on webroot)
      - "92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514"
  condition: ioc_uri_stem or ioc_c_ip or ioc_cs_referer or ioc_hash
falsepositives:
  - Developer SharePoint deployments
  - Red team operations using similar payload structure
level: high
tags:
  - attack.initial_access
  - attack.execution
  - cve.CVE-2025-53770
  - sharepoint
  - detection.iocs

Sigma Rule 2

This rule can be used together with a windows or Sysmon content pack.

The rule to detect the exploit via process creation:

title: SharePoint CVE-2025-53770 (ToolShell) Exploitation and Post-Exploitation
id: 98d5f97b-2f32-4000-be3e-d22956390044
description: Detects patterns consistent with exploitation of CVE-2025-53770 in Microsoft SharePoint via ToolPane.aspx, webshell drops, and encoded PowerShell launched from IIS worker processes.
status: experimental
date: 2025-07-22
author: Graylog, Stefan Waldvogel
logsource:
  product: windows
  category: process_creation
detection:
  # ToolPane.aspx viewed inside w3wp.exe context
  selection_dotnet_toolpane:
    Image|endswith: '\w3wp.exe'
    CommandLine|contains: 'ToolPane.aspx'

  # File drop indicators of spinstall0.aspx and debug_dev.js
  selection_file_drop:
    Image|endswith: '\powershell.exe'
    TargetFilename|contains|all:
      - 'web server extensions'
      - '\layouts\'
    TargetFilename|endswith:
      - 'spinstall0.aspx'
      - 'debug_dev.js'

  # w3wp → cmd.exe → powershell.exe with base64 payload
  selection_encoded_ps:
    ParentImage|endswith: '\w3wp.exe'
    Image|endswith: '\cmd.exe'
    CommandLine|contains: 'powershell'
    CommandLine|contains: '-enc'

  condition: selection_dotnet_toolpane or selection_file_drop or selection_encoded_ps

fields:
  - CommandLine
  - ParentImage
  - Image
  - TargetFilename
  - User
  - Hostname
  - Hashes

level: critical
tags:
  - attack.execution
  - attack.t1059.001
  - attack.persistence
  - attack.defense-evasion
  - cve.2025-53770
  - sharepoint
  - webshell
falsepositives:
  - Admins uploading valid SharePoint customizations
  - Legitimate PowerShell run under IIS for automation

This rule looks for three different activities. The first section is the most specific part. The last block detects encoded powershell commands together with w3wp.exe (the IIS worker process)

Using a Graylog rule

If writing a Sigma rule is not possible, create a rule.
The following rule looks for known IoCs and at the end creates two fields.

rule "sharepoint_ioc_detection"

when
    (
    //  Match suspicious file names
        (
            has_field ( "http_request_path" ) 
                && (
                    contains(lowercase(to_string($message.http_request_path)), "spinstall0.aspx") ||
                    contains(lowercase(to_string($message.http_request_path)), "spinstall.aspx") ||
                    contains(lowercase(to_string($message.http_request_path)), "spinstall1.aspx") ||
                    contains(lowercase(to_string($message.http_request_path)), "spinstall2.aspx") ||
                    contains(lowercase(to_string($message.http_request_path)), "iis_server_dll.dll") ||
                    contains(lowercase(to_string($message.http_request_path)), "sharphostinfo.x64.exe") ||
                    contains(lowercase(to_string($message.http_request_path)), "xd.exe") ||
                    contains(lowercase(to_string($message.http_request_path)), "debug_dev.js")
                    )
                )
            ||
    // Match suspicious file path
                (
                    has_field("http_request_path")
                    &&
                    contains(lowercase(to_string($message.http_request_path)), "\\template\\layouts\\debug_dev.js")
                )
            ||
    // Match SHA-256 hashes (most webservers do not create a hash or file_hash, adjust if needed)
                (
                has_field("hash_sha256") &&
                    (
                        to_string($message.hash_sha256) == "92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514" ||
                        to_string($message.hash_sha256) == "24480dbe306597da1ba393b6e30d542673066f98826cc07ac4b9033137f37dbf" ||
                        to_string($message.hash_sha256) == "b5a78616f709859a0d9f830d28ff2f9dbbb2387df1753739407917e96dadf6b0" ||
                        to_string($message.hash_sha256) == "c27b725ff66fdfb11dd6487a3815d1d1eba89d61b0e919e4d06ed3ac6a74fe94" ||
                        to_string($message.hash_sha256) == "1eb914c09c873f0a7bcf81475ab0f6bdfaccc6b63bf7e5f2dbf19295106af192" ||
                        to_string($message.hash_sha256) == "4c1750a14915bf2c0b093c2cb59063912dfa039a2adfe6d26d6914804e2ae928" ||
                        to_string($message.hash_sha256) == "83705c75731e1d590b08f9357bc3b0f04741e92a033618736387512b40dab060" ||
                        to_string($message.hash_sha256) == "f54ae00a9bae73da001c4d3d690d26ddf5e8e006b5562f936df472ec5e299441" ||
                        to_string($message.hash_sha256) == "b180ab0a5845ed619939154f67526d2b04d28713fcc1904fbd666275538f431d" ||
                        to_string($message.hash_sha256) == "6753b840cec65dfba0d7d326ec768bff2495784c60db6a139f51c5e83349ac4d" ||
                        to_string($message.hash_sha256) == "7ae971e40528d364fa52f3bb5e0660ac25ef63e082e3bbd54f153e27b31eae68" ||
                        to_string($message.hash_sha256) == "567cb8e8c8bd0d909870c656b292b57bcb24eb55a8582b884e0a228e298e7443" ||
                        to_string($message.hash_sha256) == "445a37279d3a229ed18513e85f0c8d861c6f560e0f914a5869df14a74b679b86" ||
                        to_string($message.hash_sha256) == "ffbc9dfc284b147e07a430fe9471e66c716a84a1f18976474a54bee82605fa9a" ||
                        to_string($message.hash_sha256) == "6b273c2179518dacb1218201fd37ee2492a5e1713be907e69bf7ea56ceca53a5" ||
                        to_string($message.hash_sha256) == "c2c1fec7856e8d49f5d49267e69993837575dbbec99cd702c5be134a85b2c139" ||
                        to_string($message.hash_sha256) == "6f6db63ece791c6dc1054f1e1231b5bbcf6c051a49bad0784569271753e24619" ||
                        to_string($message.hash_sha256) == "d6da885c90a5d1fb88d0a3f0b5d9817a82d5772d5510a0773c80ca581ce2486d" ||
                        to_string($message.hash_sha256) == "62881359e75c9e8899c4bc9f452ef9743e68ce467f8b3e4398bebacde9550dea"
                    )
                )
            ||
    // Match C2 IP addresses in source or destination fields
                (
                    has_field("source_ip") 
                        && (
                            to_string($message.source_ip) == "131.226.2.6" ||
                            to_string($message.source_ip) == "134.199.202.205" ||
                            to_string($message.source_ip) == "104.238.159.149" ||
                            to_string($message.source_ip) == "188.130.206.168" ||
                            to_string($message.source_ip) == "65.38.121.198"
                        )
                )
            ||
                (
                    has_field("destination_ip") 
                        && (
                            to_string($message.destination_ip) == "131.226.2.6" ||
                            to_string($message.destination_ip) == "134.199.202.205" ||
                            to_string($message.destination_ip) == "104.238.159.149" ||
                            to_string($message.destination_ip) == "188.130.206.168" ||
                            to_string($message.destination_ip) == "65.38.121.198"
                        )
                )
            ||
    // Match malicious domains or URLs
                (
                    has_field("http_uri") 
                        && (
                            contains(to_string($message.http_uri), "c34718cbb4c6.ngrok-free.app/file.ps1") ||
                            contains(to_string($message.http_uri), "msupdate.updatemicfosoft.com") ||
                            contains(to_string($message.http_uri), "update.updatemicfosoft.com")
                        )
                )
            ||
                (
                    has_field("http_host") 
                        && (
                            to_string($message.http_host) == "msupdate.updatemicfosoft.com" ||
                            to_string($message.http_host) == "update.updatemicfosoft.com"
                        )
                )
            )

then
    set_field ( "threat_detected" , true);

  // Store the Microsoft blog URL as an alert indicator so analysts can read more
    set_field (
        "alert_indicator",
        "https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/"
    );

end>

Indicators

During the active exploitation of CVE‑2025‑53770, attackers deploy a malicious ASP.NET webshell named spinstall0.aspx to vulnerable Microsoft SharePoint servers.

Adversaries often place it in trusted directories like \15\TEMPLATE\LAYOUTS\ or \16\TEMPLATE\LAYOUTS\.

Another known malicious file, debug_dev.js, has been observed being used to store or exfiltrate stolen configuration data.

One confirmed SHA‑256 hash for spinstall0.aspx is: “92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514”

As part of the attack chain, the threat actors have been observed delivering follow-up payloads such as PowerShell scripts through tunnels like:

“https://c34718cbb4c6.ngrok-free.app/file.ps1”

Malicious file paths used during exploitation include:

\15\TEMPLATE\LAYOUTS\debug_dev.js

\16\TEMPLATE\LAYOUTS\spinstall0.aspx

Multiple IP addresses have been associated with exploitation attempts or command-and-control traffic:

131.226.2.6 – post-exploitation C2

134.199.202.205 – observed delivering malicious requests

104.238.159.149 – associated with initial access attempts

188.130.206.168 – IP linked to scanning and exploitation activity

Organizations running on-premise SharePoint should monitor for access to /spinstall0.aspx, web uploads to the above paths, and outbound connections to any of the listed IPs or the ngrok domain. These indicators are critical for detection, containment, and threat hunting efforts.

Graylog Detections

Graylog has provided the Sigma Rules and Indicators here to share threat detection intelligence with those not running Graylog Security. Note that Graylog Security customers receive a content feed including Sigma Rules, Anomaly Detectors, Dashboards, and other content to meet various security use cases.

To learn how Graylog can help you improve your security posture, contact us today.