🚨 The Persistence Blind Spot: IIS Modules Are Hiding in Plain Sight

My full research on IIS modules may be found here: https://www.splunk.com/en_us/blog/security/fantastic-iis-modules-and-how-to-find-them.html

Video Demos and Atomic Tests

📺 : https://youtu.be/LMCyzdwbLvQ?feature=shared

📔 : https://github.com/Atomics-on-A-Friday/Episode-Notes/blob/main/Notes/AF%20-%20Ep4%20-%20IIS-Sassins.md

The recent SharePoint vulnerabilities (CVE-2025-53770, CVE-2025-49704) actively exploited by Chinese nation-state actors aren't just another patch-and-forget scenario. They represent a fundamental shift in how adversaries achieve persistence on web servers. While organizations rush to patch, threat actors are already entrenched through IIS modules – and most security teams don't even know how to hunt for them.

The Problem: Patching Isn't Enough

Microsoft's latest security advisory reveals that Linen Typhoon, Violet Typhoon, and Storm-2603 are exploiting SharePoint servers not just for initial access, but to establish deep, persistent footholds. After successful exploitation, these actors deploy web shells like spinstall0.aspx to steal machine keys and maintain access.

Here's the critical insight: SharePoint runs on IIS. Once compromised, these servers become launching pads for IIS module-based persistence that survives patches, reboots, and even some system reimaging.

This isn't new – it's the evolution of a known threat. Microsoft first warned about this in July 2022 and again in December 2022, documenting how threat actors were already using IIS modules as "quiet persistent backdoors" and the "evolution of web shells." The SharePoint attacks represent the maturation of these techniques at nation-state scale.

Why IIS Modules Are Security's Blind Spot

Traditional hunting focuses on process execution, scheduled tasks, registry keys, and file drops. But IIS modules operate in a different realm entirely:

• They load directly into the w3wp.exe process (IIS worker process)

• Most AVs won't rip them because disrupting IIS DLLs could crash web services

• They look legitimate by design – distinguishing malicious from benign requires deep expertise

• They persist across patches unless specifically hunted and removed

• Rotating keys is not going to stop the image load

Microsoft's research reveals the sophistication: These modules can intercept ALL web requests through event handlers (BeginRequest, EndRequest, Error), essentially turning every page into a potential web shell. They can tamper with requests and responses, hide malicious communications in headers or parameters, and even serve malicious payloads to website visitors.

Even more concerning – they can execute .NET assemblies reflectively within the IIS process, loading tools like Mimikatz or SharpHound directly into memory without creating child processes that traditional monitoring would catch.

The Technical Reality: It's Complicated

Having previously researched IIS module hunting extensively, I can tell you – this isn't point-and-click detection. Here's what hunting actually involves:

Manual Module Enumeration Commands:

AppCmd Method:

PowerShell Method:

Adding Persistence (What Adversaries Do):

Microsoft documented multiple installation techniques adversaries use:

The Detection Challenge:

Multiple Data Sources Required:

• IIS Operational logs (Microsoft-IIS-Configuration/Operational)

• Sysmon process and module loading events

• PowerShell script block logging

• Custom PowerShell scripted inputs for module inventory

• Application event logs for module load failures

Advanced IIS Logging (Critical): Microsoft DART specifically recommends enabling advanced IIS logging that most organizations miss:

This captures Event ID 29 when IIS modules are added/removed and Event ID 50 for web.config modifications. Since IIS modules are rarely added to production servers, these events should trigger immediate investigation.

Complex Filtering Needed:

Reflective Assembly Loading Detection:

Configuration File Analysis:

• Examine %windir%\system32\inetsrv\config\applicationhost.config

• Look for suspicious entries in <globalModules> and <modules> sections

• Cross-reference module paths with known-good baselines

Real-World Impact: Beyond SharePoint

The SharePoint attacks are just the beginning. Microsoft documented real campaigns targeting Exchange servers where attackers:

• Deployed custom IIS backdoors like FinanceSvcModel.dll with built-in Exchange management capabilities

• Used PowerShDLL toolkit to avoid spawning cmd.exe or powershell.exe (evading detection)

• Implemented credential stealers that monitor sign-in patterns and dump credentials

• Created web shell variants of China Chopper and Antsword as IIS modules

The attack flow is sophisticated:

1. Initial compromise via vulnerability (ProxyShell, SharePoint CVEs, etc.)

2. Deploy script web shell for reconnaissance

3. Install custom IIS module for persistent, covert access

4. Use reflective .NET loading for tools like Mimikatz, SharpHound

5. Exfiltrate data through legitimate IIS channels

IIS powers much more than SharePoint:

• Exchange servers (another favorite target)

• Corporate intranets and portals

• API gateways and web applications

• E-commerce platforms

Each represents a potential persistence vector that survives traditional incident response procedures.

The Call to Action: Hunt Now, Hunt Deep

For Security Teams:

1. Enable advanced IIS logging immediately – Microsoft-IIS-Configuration/Operational events (Event ID 29, 50)

2. Implement continuous IIS module monitoring – Baseline and alert on changes

3. Deploy PowerShell scripted inputs for regular module inventory collection

4. Hunt for reflective assembly loading – Look for .NET modules loaded without file paths

5. Monitor w3wp.exe child processes – But know that sophisticated attacks won't create them

6. Train analysts on IIS architecture – This isn't traditional malware analysis

Critical Technical Recommendations:

• Regularly inspect %windir%\system32\inetsrv\config\applicationhost.config and site web.config files

• Scan application bin directories and GAC paths for suspicious DLLs

• Enable Microsoft-Windows-DotNETRuntimeRundown ETW for assembly visibility

• Monitor appcmd.exe and gacutil.exe execution from w3wp.exe processes

• Implement file integrity monitoring on IIS configuration files

For Organizations:

• Audit your IIS infrastructure – Map all servers running IIS/SharePoint/Exchange

• Implement defense in depth – AMSI integration, Defender for Endpoint, proper segmentation

• Rotate machine keys regularly – Don't wait for compromise indicators

• Consider IIS hardening – Remove unnecessary modules, restrict GAC access

• Plan for containment – Traditional IR may miss persistent IIS modules

The Bottom Line

Traditional security tools excel at detecting obvious malware but struggle with abuse of legitimate functionality. IIS modules represent exactly this challenge – they're features, not bugs, being weaponized by sophisticated adversaries.

Stop hunting yesterday's threats. Start hunting today's reality.

The SharePoint attacks prove that nation-state actors are already operating with sophisticated IIS module persistence. Thanks to Chris Glyer for highlighting the foundational Microsoft research that warned us this was coming. The question isn't whether your organization will face similar attacks – it's whether you'll detect them when they happen.

What's your organization doing to hunt for IIS module persistence? Have you implemented advanced IIS logging and monitoring? Share your experiences and challenges in the comments.