Beyond the Patch: SharePoint Exploits and the Hidden Threat of IIS Module Persistence

The cybersecurity landscape witnessed a perfect storm in July 2025 when multiple critical SharePoint vulnerabilities collided with sophisticated IIS module-based persistence techniques, creating a nightmare scenario for enterprise defenders. CVE-2025-53770, CVE-2025-53771, CVE-2025-49704, and CVE-2025-49706 are being actively exploited by sophisticated threat actors, but the real danger extends far beyond the initial exploitation phase.

What makes this campaign particularly insidious is that adversaries aren't stopping at traditional webshells. They're leveraging malicious IIS modules to establish deep, persistent access that survives patches, reboots, and traditional security scans. This represents a fundamental evolution in post-exploitation tactics where DLLs dropped to disk and loaded into IIS create invisible backdoors that most solutions won't touch due to the risk of crashing critical web enterprise services.

Quick Facts

Primary Vulnerabilities:

• CVE-2025-53770: SharePoint ToolShell Auth Bypass and RCE (CVSS 9.8)
• CVE-2025-53771: SharePoint ToolShell Path Traversal
• CVE-2025-49704: SharePoint Remote Code Execution
• CVE-2025-49706: SharePoint Post-auth RCE

Affected Systems: On-premises SharePoint Server 2016, 2019, and Subscription Edition
Attack Vector: Unauthenticated POST requests to ToolPane endpoint
Initial Payload: spinstall0.aspx (and variants) webshell for machine key theft|Persistence Method: Custom IIS modules loaded as DLLs into w3wp.exe
Status: CISA added to Known Exploited Vulnerabilities catalog, patches available

The SharePoint Exploitation Chain

^{(Mermaid diagram of attack flow, Splunk 2025)}

The attack begins with a deceptively simple POST request to the SharePoint ToolPane endpoint, but what follows is a sophisticated multi-stage compromise that demonstrates the evolution of adversary tactics.

Initial Access and Reconnaissance

Threat actors conduct reconnaissance by sending POST requests to the ToolPane endpoint, testing for vulnerable SharePoint servers. The exploitation bypasses authentication mechanisms entirely, granting immediate access to the target environment.

^{(ToolShell POST request, security content, Splunk, 2025)}

Web Shell Deployment

Upon successful exploitation, attackers deploy a malicious script named spinstall0.aspx (with variants including spinstall.aspx, spinstall1.aspx, spinstall2.aspx) that contains commands to retrieve MachineKey data and return results through GET requests. This initial foothold enables credential theft and lateral movement preparation.

^{(GET request to webshell, security content, Splunk 2025)}

As the week progressed, we saw variations of spinstall or renamed variants showing up in requests:

^{(variations of requests in the wild for various webshell related, Splunk 2025)}

The webshell's primary purpose is stealing ASP.NET machine keys - cryptographic keys that can be used to decrypt view state, authentication cookies, and other sensitive data. Once stolen, these keys allow attackers to maintain persistence even after the initial vulnerability is patched.

From Webshells to IIS Modules: The Persistence Evolution

While security teams work to patch SharePoint vulnerabilities and hunt for webshells, a more sophisticated threat lurks beneath the surface. Attackers are increasingly leveraging Internet Information Services (IIS) extensions as covert backdoors into servers, which hide deep in target environments and provide a durable persistence mechanism.

As we detailed in our previous research on IIS Components, these extensions provide attackers with a nearly perfect hiding mechanism. IIS backdoors are significantly harder to detect since they may reside in the same directories as legitimate modules used by target applications and follow identical code structures as clean modules. This legitimate appearance, combined with the fact that malicious IIS extensions are less frequently encountered compared to script web shells, leads to a relatively lower detection rate that adversaries exploit to their advantage.

Many security solutions avoid scanning or blocking DLLs loaded by the IIS worker processes (w3wp.exe) due to the real risk of causing service crashes that could bring down critical web applications (e.g. SharePoint, Exchange). This creates a significant blind spot that sophisticated attackers understand and leverage. The deep integration capabilities of IIS modules make them particularly dangerous - event handlers are given full read and write access to requests, allowing malicious modules to hide communications within any aspect of web requests and effectively turning every page that does and does not exist into a potential web shell.

The Technical Mechanics

IIS modules operate at the heart of the web request pipeline, intercepting traffic before it reaches the web application and after responses are generated. By setting up event handlers on BeginRequest, EndRequest, and Error event triggers, actors can intercept all requests before the web service can process them and before responses are sent to clients.

^{(IIS Modules flow, Spunk 2025)}

This positioning allows malicious modules to:

• Intercept and modify HTTP requests and responses
• Hide malicious commands within legitimate web traffic
• Execute code without creating suspicious child processes
• Monitor authentication attempts and steal credentials
• Maintain persistence across system reboots and patches

SharePoint + IIS Modules: A Perfect Storm

The combination of SharePoint vulnerabilities with IIS module persistence creates a particularly dangerous scenario. Typically, attackers first exploit a critical vulnerability in the hosted application for initial access before dropping a script web shell as the first stage payload. At a later point, the attackers install an IIS backdoor to provide highly covert and persistent access.

Observed Attack Pattern

Based on Microsoft's research and our analysis, the attack progression typically follows a predictable but sophisticated pattern. Attackers begin by exploiting SharePoint vulnerabilities for unauthenticated access, immediately followed by deploying spinstall0.aspx webshells for immediate control and machine key theft. During the reconnaissance phase, they use these webshells to enumerate the environment and gather credentials before deploying custom IIS modules for long-term persistence. The final phase involves cleaning up obvious webshells while maintaining covert access through the embedded IIS modules.

^{(Attack pattern flow, Splunk 2025)}

The Detection Challenge

Hunting for malicious IIS modules requires a fundamentally different approach than traditional webshell detection. You cannot rely on usual web shell detection strategies, such as high frequency page requests or URI patterns. Malicious IIS modules instead require new detection techniques and use of advanced IIS logging. In the following sections we will cover strategies to retrieve logs related to assisting with identifying modules as outlined in our prior research.

Enable IIS Logging and Collect Modules

In their latest blog, Microsoft recommends enabling advanced IIS logging to hunt for web shells. The Microsoft-IIS-Configuration/Operational log provides details on new modules being added by site/app pool.

• Lists additional logs available for IIS: `wevtutil el | findstr -i IIS`
• Configuration for the selected log: `wevtutil gl Microsoft-IIS-Configuration/Operational` 
• Enable the selected log: `wevtutil sl /e:true Microsoft-IIS-Configuration/Operational`

^{(enable IIS Configuration logs, Splunk 2025)}

Once enabled, we will need to add the following to an inputs.conf to be collected:

[WinEventLog://Microsoft-IIS-Configuration/Operational]
index=win
sourcetype=IIS:Configuration:Operational
disabled = false

The collected data in Splunk may look like the following

^{(IIS operational logs, Splunk 2025)}

The advanced IIS logging is a great source, however, another method we can use with Splunk Universal Forwarders is PowerShell scripted inputs. In this instance, we want to gather all installed modules on our IIS server fleet. As outlined here, we can pass a script or command via inputs.conf and the output will be ingested into Splunk. Deploy the new inputs.conf matching your environment to ingest modules. Modify the scheduled time to meet your needs.

[powershell://IISModules]
script = Get-WebGlobalModule
schedule = */1 * * * *
#schedule = 0 0 * * *
sourcetype = Pwsh:InstalledIISModules
index=iis

The latest Splunk Add-On for Microsoft IIS includes this scripted input. 

In Splunk we see:

Note the last 3 modules in a non-standard path.

Splunk also includes details on setting up logging for IIS here. Most importantly, is collecting the main IIS logs via this inputs:

[monitor://C:\inetpub\logs\LogFiles]
disabled = false
sourcetype = ms:iis:auto
index = 

Now, we will focus on hunting

Hunting in Your Environment

When a new module is added to IIS, it will load into w3wp.exe (IIS process). We may utilize an EDR product or Sysmon to look at all modules being loaded by w3wp.exe.

All modules loaded

`sysmon` EventCode=7 parent_process_name=w3wp.exe | stats values(ImageLoaded)

There is a pattern to normal modules being loaded. It is possible to filter out the most common paths to limit the amount of volume. Note that collecting module loads is intensive and sometimes does not provide high value.

`sysmon` EventCode=7 parent_process_name=w3wp.exe NOT (process_path IN ("*\\inetsrv\\*", "*\\windows\\system32\\*")) | stats values(ImageLoaded)

While testing out different ways to load a module, we received an error when the module wasn’t correctly formatted or made to load properly into IIS. This generated event code 2282, which occurs when a module fails to load into the IIS worker process.

The Persistence Problem

Here's the critical issue that keeps security teams awake at night: IIS modules can persist even after SharePoint patches are applied. Unlike webshells that may be removed during patching or system updates, malicious IIS modules become part of the web server's core functionality.

Why Patches Aren't Enough

The persistence challenge stems from how IIS modules integrate with the web server infrastructure. Once registered in applicationHost.config or web.config files, modules continue loading automatically even after patches are applied and systems are rebooted. Security products may remain hesitant to remove IIS DLLs due to legitimate stability concerns, while the modules' legitimate appearance allows them to blend seamlessly with genuine IIS extensions. Most critically, these modules operate within the w3wp.exe memory space, effectively avoiding process-based detection mechanisms that most security tools rely upon.

The Cleanup Challenge

Organizations face a difficult decision when malicious IIS modules are discovered:

• Removal Risk: Incorrect module removal can crash IIS and bring down critical web services
• Detection Difficulty: Determining which modules are malicious requires deep analysis
• Persistence Verification: Ensuring complete removal across all application pools and sites

^{(IIS Modules loaded in SharePoint 2019, Splunk 2025)}

Security Content

The following analytics were produced to assist defenders in utilizing multiple log sources to identify suspicious and malicious behavior on IIS web servers. In addition, we have added security content to assist with identifying SharePoint compromises related to CVE-2025-53770.

Analytic Story: Microsoft SharePoint Vulnerabilities

W3WP Spawning Shell

The following analytic identifies instances where a shell (PowerShell.exe or Cmd.exe) is spawned from W3WP.exe, the IIS worker process.

^{(W3wp spawning cmd.exe, Splunk 2025)}

Windows SharePoint ToolPane Endpoint Exploitation Attempt

The following analytic detects potential exploitation attempts against Microsoft SharePoint Server vulnerability CVE-2025-53770, also known as "ToolShell". This detection monitors for POST requests to the ToolPane.aspx endpoint with specific DisplayMode parameter, which is a key indicator of the exploit. 

Windows SharePoint Spinstall0 GET Request

The following analytic detects potential post-exploitation activity related to the Microsoft SharePoint CVE-2025-53770 vulnerability. After successful exploitation via the ToolPane.aspx endpoint, attackers typically deploy a webshell named "spinstall0.aspx" in the SharePoint layouts directory. 

^{(GET Request to spinstall, Splunk 2025)}

Analytic Story: IIS Components 

Data sources:

• PowerShell Script Block Logging - 4104
• Windows Sysmon, process monitoring
• Microsoft-IIS-Configuration/Operational
• Windows Application
• PowerShell Scripted Input - Get-WebGlobalModule

Windows Disable Windows Event Logging Disable HTTP Logging

Identifies the use of AppCmd.exe to disable HTTP logging.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes where NOT (Processes.parent_process_name IN ("msiexec.exe", "iissetup.exe")) Processes.process_name=appcmd.exe
Processes.process IN ("*set config*", "*httplogging*","*dontlog:true*") by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.original_file_name
Processes.process Processes.process_id Processes.parent_process_id
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

Windows IIS Components Add New Module

Identifies AppCmd.exe adding a new module.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes where NOT (Processes.parent_process_name IN ("msiexec.exe", "iissetup.exe")) Processes.process_name=appcmd.exe
Processes.process IN ("*install *", "*module *") AND Processes.process="*image*" by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.original_file_name
Processes.process Processes.process_id Processes.parent_process_id
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{(New module added via appcmd, Splunk 2025)}

Windows IIS Components Get-WebGlobalModule Module Query

Using PowerShell scripted inputs, gathers all installed IIS modules and outputs to Splunk.

`iis_get_webglobalmodule` | stats count min(_time) as firstTime max(_time) as lastTime by host name image | rename host as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

^{(Splunk scripted inputs, Splunk 2025)}

Windows IIS Components Module Failed to Load

When a module fails to load, it generates Event ID 2282.

`wineventlog_application` EventCode=2282 | stats count min(_time) as firstTime max(_time) as lastTime by EventCode dest Name ModuleDll | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

^{(Module failed to load, Splunk 2025)}

Windows IIS Components New Module Added

Utilizing EventCode 29 from the IIS Operational logs, identifies new modules installed.

`iis_operational_logs` EventCode=29
| stats count min(_time) as firstTime max(_time) as lastTime by OpCode EventCode ComputerName Message | rename ComputerName AS dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

^{(IIS components new module added, Splunk 2025)}

Windows PowerShell Disable HTTP Logging

Utilizing PowerShell Script Block Logging, identifies when HTTP logging is disabled.

`powershell` EventCode=4104 ScriptBlockText IN("*get-WebConfigurationProperty*","*Set-ItemProperty*") AND ScriptBlockText IN ("*httpLogging*","*Logfile.enabled*") AND ScriptBlockText IN ("*dontLog*", "*false*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer user_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{(PowerShell disable HTTP logging, Splunk 2025)}

Windows PowerShell IIS Components WebGlobalModule Usage

Utilizing PowerShell Script Block Logging, identifies the use of a new module being added, enabled or modified.

`powershell` EventCode=4104 ScriptBlockText IN("*New-WebGlobalModule*","*Enable-WebGlobalModule*","*Set-WebGlobalModule*")
| stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer user_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{(IIS new-webglobalmodule usage, Splunk 2025)}

Mitigation and Response Strategy

Immediate Actions

Organizations must prioritize applying the latest SharePoint security updates immediately across all supported versions. Equally critical is configuring Antimalware Scan Interface (AMSI) integration in SharePoint with Full Mode enabled for optimal protection. Following patch deployment, security teams should rotate SharePoint server ASP.NET machine keys and restart IIS on all SharePoint servers using the Set-SPMachineKey cmdlet. Finally, conducting a comprehensive IIS module inventory across all web servers provides the baseline necessary for ongoing monitoring. Additional mitigation guidance provided by Microsoft here.

Long-term Defense Strategy

Effective defense requires implementing continuous monitoring for IIS configuration changes, particularly Event IDs 29 and 50, while watching for module loading anomalies in w3wp.exe processes. Security teams should deploy behavioral analytics to identify unusual authentication patterns, anomalous web request behaviors, suspicious PowerShell execution from web contexts, and credential access attempts from IIS processes. Network segmentation becomes crucial - isolating SharePoint servers from critical internal networks, implementing strict egress filtering to prevent command and control communication, and monitoring for unusual network patterns from web servers.

The Bottom Line

The convergence of SharePoint vulnerabilities with IIS module persistence represents a fundamental shift in how we must approach web server security. Patching alone is insufficient when adversaries can establish persistence mechanisms that survive updates, reboots, and traditional security scans.

Organizations must immediately patch affected SharePoint, IIS webservers, systems while simultaneously conducting comprehensive IIS module audits across all web servers. Implementing advanced logging for IIS configuration changes becomes essential, along with deploying behavioral detection for web process anomalies and establishing continuous monitoring for module installation and loading activities.

The sophistication of these attacks demands an equally sophisticated defense strategy. The traditional "patch and pray" approach leaves organizations vulnerable to persistent threats that can operate undetected for months or years.

As we've seen with sophisticated campaigns and recent adversary activities, adversaries are investing heavily in IIS-based persistence techniques. The security community must respond with equally advanced detection and response capabilities.

The time for reactive security is over. In the age of living-off-the-land techniques and infrastructure persistence, our defense strategies must be as persistent and sophisticated as the threats we face.

Learn More

You can find the latest content about security analytic stories on research.splunk.com and in the Splunk ES Content Update app.

The Splunk Threat Research Team's analytic story for Microsoft SharePoint Vulnerabilities and IIS Components provides comprehensive detection coverage for this vulnerability and its exploitation patterns.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we'll follow up. Alternatively, join us on the Splunk Slack channel #security-research.

Contributors

We would like to thank Michael Haag for authoring this post, as well as the Splunk Threat Research Team (Raven Tait, Nasreddine Bencherchali, Lou Stella, Bhavin Patel, AJ King, Rod Soto, Eric McGinnis, Nasreddine Bencherchali, Teoderick Contreras, and Patrick Bareiss) for their contributions to the detection content and analysis.