Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Announcing the availability of ModSecurity extension for IIS

This blog post has also been posted on the Microsoft Security Research and Defense site:


  • Greg Wroblewski, Microsoft Security Engineering Center
  • Ryan Barnett, Trustwave SpiderLabs

Vulnerabilities in on-line services, like cross-site scripting, cross-site request forgery, or even information disclosure, are important areas of focus for the Microsoft Security Response Center (MSRC). Over the last few years Microsoft has developed a number of tools capable of mitigating selected web specific vulnerabilities (for example, UrlScan). To help on this front we have participated in a community effort to bring the popular open source module ModSecurity to the IIS platform. Yesterday at Black Hat Las Vegas, we have announced the availability of an RC version and we expect that stable release will be available soon.


Although the source code of ModSecurity's IIS components is fully published and the binary building process is publicly described (see mod_security/iis/winbuild/howto.txt in SourceForge repository), it is highly not recommended to self-build the module for non-research or non-development purpose.

A standard MSI installer of ModSecurity for IIS 7 and later versions is available from SourceForge files repository of ModSecurity project and in the future designated maintainers will be keeping it updated with latest patches and minor versions of the module.


The IIS installer does not interfere with currently running web applications. This means that the installation process must be followed by an application pool restart or recycling in order to load the new module into the application pool process. For the RC version of the module the restart/recycle step is also highly recommended each time a ModSecurity configuration file has been changed:


After successful load of the module into the application pool process a series of informational events is recorded in the application event log:


Runtime messages and notifications generated during the operational phase, both coming from the user-defined rules and system specific events or errors, are sent to the same application event log repository.

To apply a ModSecurity configuration file to a web application or a path, one has to use IIS configuration schema extension, like in the example below:

<?xml version="1.0" encoding="UTF-8"?><configuration>    <system.webServer>        <ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\test.conf" />    </system.webServer></configuration>

The c:\inetpub\wwwroot\test.conf config file is a regular ModSecurity configuration containing the same directives as used on the Apache web server.

Examples of Protection

The most common application of ModSecurity is a protection layer called "virtual patching" (see Resources section, [5]). Using two recent vulnerabilities as an example we would like to show how this layer can be specified in an environment with IIS server running with ModSecurity.


In December 2011 a vulnerability was addressed in ASP.NET that allowed attackers to cause excessive processor load on most ASP.NET web applications. The hash collision issue required attacker to send a large (typically 1MB or 4MB) POST request to the server, with tens of thousands of arguments with specially crafted names. There are at least four ways to mitigate this kind of attack:

  • Restrict the request body size.
  • Restrict the number of arguments.
  • Identify repetitive payloads.
  • Check arguments names against PoC data.

The approach of checking for the presence of repetitive payload is the most sophisticated one and it can be implemented in ModSecurity using the following chain of rules:

SecRule &ARGS "@ge 1000" "chain,id:1234,phase:2,t:none,deny,msg:'Possible Hash DoS Attack Identified.',tag:'‑information‑about‑the‑december‑2011‑asp‑net‑vulnerability.aspx?Redirected=true'"  SecRule REQUEST_BODY "^\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&" "chain,capture"    SecRule TX:1 "@streq %{tx.2}" "chain,setvar:tx.hash_dos_match=+1"    SecRule TX:2 "@streq %{tx.3}" "chain,setvar:tx.hash_dos_match=+1"    SecRule TX:3 "@streq %{tx.4}" "chain,setvar:tx.hash_dos_match=+1"      SecRule TX:HASH_DOS_MATCH "@eq 3"

When this rule is loaded into an IIS server configuration and the attack is launched on the protected path, the Windows application event log will record an access denied message from ModSecurity:


At the same time the attacker will see HTTP response 403, stopping the attack before it reaches ASP.NET vulnerable component.


In July 2012, Microsoft patched a classic case of reflected cross-site scripting vulnerability in Microsoft SharePoint 2010. For the attacks to exploit the vulnerability it was enough to trick user into clicking on a malicious URL, like the one below:


The script injected by the attacker could gain access to the entire data set available to the victim through the hacked SharePoint server.

One possible way to block this attack is a whitelist approach: let the URL with sections argument that does contain only valid characters pass through, while block all other URLs. Below is a ModSecurity rule implementing this approach for alphanumeric characters:

SecRule REQUEST_FILENAME "@contains /_layouts/scriptresx.ashx" "chain,phase:1,block,msg:'SharePoint Sections Param Violation - Illegal Chars"  SecRule ARGS:sections "!@rx ^\w+$"

The rule included through ModSecurity config file into the SharePoint web.config file, generates the following event when any invalid character (indicating possible attack attempt) is discovered in the corresponding SharePoint URL:



We encourage you to download and try out the tool. If you have any feedback on your experiences with the tool, you can reach us at or on the ModSecurity Users Mail-list.


The following people have contributed to the multi-platform effort of ModSecurity:

  • Microsoft – ModSecurity Port for IIS
    • Greg Wroblewski – Senior Security Developer
    • Suha Can – Security Researcher / Developer
  • Trustwave - ModSecurity
    • Ziv Mador – Director of Security Research
    • Ryan Barnett – Security Researcher Lead
    • Breno Pinto – ModSecurity Researcher & Developer
  • Open community - Security Port for Nginx
    • Alan Silva - Security Software Engineer at Locaweb

We would like to thank: Wade Hilmo and Nazim Lala, members of the Microsoft's IIS team , for their support and help in solving many technical problems.


[1] ModSecurity home page:

[2] OWASP Core Rule Set for ModSecurity:




Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More