Nov 3, 2021
103 Views
0 0

Anatomy of native IIS malware

Written by

ESET researchers publish a white paper putting IIS web server threats under the microscope
ESET researchers have discovered a set of previously undocumented malware families, implemented as malicious extensions for Internet Information Services (IIS) web server software. Targeting both government mailboxes and e-commerce transactions, as well as aiding in malware distribution, this diverse class of threats operates by eavesdropping on and tampering with the server’s communications.
Along with a complete breakdown of the newly discovered families, our new paper, Anatomy of native IIS malware, provides a comprehensive guide to help fellow security researchers and defenders detect, dissect and mitigate this class of server-side threats. In this blogpost, we summarize the findings of the white paper.
Today, we are also launching a series of blogposts where we introduce the most notable of the newly discovered IIS malware families, as case studies of how this type of malware is used for cybercrime, cyberespionage and SEO fraud.
The findings of our IIS malware research were first presented at Black Hat USA 2021 and will also be shared with the community at the Virus Bulletin 2021 conference on October 8th.
Anatomy of native IIS malware
IIS is Microsoft Windows web server software with an extensible, modular architecture that, since v7.0, supports two types of extensions – native (C++ DLL) and managed (.NET assembly) modules. Focusing on malicious native IIS modules, we have found over 80 unique samples used in the wild and categorized them into 14 malware families – 10 of which were previously undocumented. ESET security solutions detect these families as Win{32,64}/BadIIS and Win{32,64}/Spy.IISniff.
IIS malware is a diverse class of threats used for cybercrime, cyberespionage, and SEO fraud – but in all cases, its main purpose is to intercept HTTP requests incoming to the compromised IIS server and affect how the server responds to (some of) these requests.
With the default installation, IIS itself is persistent, so there is no need for extension-based IIS malware to implement additional persistence mechanisms. Once configured as an IIS extension, the malicious IIS module is loaded by the IIS Worker Process (w3wp.exe), which handles requests sent to the server – this is where IIS malware can interfere with the request processing.
We identified five main modes in which IIS malware operates, as illustrated in Figure 1:
Figure 1. Overview of IIS malware mechanisms
All of these malware types are discussed at length in the paper.
Native IIS modules have unrestricted access to any resource available to the server worker process – thus, administrative rights are required to install native IIS malware. This considerably narrows down the options for the initial attack vector. We have seen evidence for two scenarios:
For example, between March and June 2021, we detected a wave of IIS backdoors spread via the Microsoft Exchange pre-authentication RCE vulnerability chain (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065), aka ProxyLogon. Targeted specifically were Exchange servers that have Outlook on the web (aka OWA) enabled – as IIS is used to implement OWA, these were a particularly interesting target for espionage.
After our colleagues reported the first such case in March 2021, we have detected four more campaigns of various IIS backdoors spreading to Microsoft Exchange servers through the same vulnerability. To complement our telemetry, we have performed internet-wide scans to detect the presence of these backdoors, which allowed us to identify and notify other victims of the malware.
Figure 2 shows the geographical locations of servers affected by these five campaigns, using data from our telemetry and internet-wide scans.
Figure 2. Victims of native IIS backdoors spread via the ProxyLogon vulnerability chain
The following entities were among the victims:
Note that while IIS backdoors may be well-suited for spying on high-profile mailboxes, victims of IIS malware are not limited to compromised servers – all legitimate visitors of the websites hosted by these servers are potential targets, as the malware can be used to steal sensitive data from the visitors (IIS infostealers) or serve malicious content (IIS injectors). Please refer to the full white paper for the details on the targets of the other analyzed IIS families.
From the technical perspective, all types of native IIS malware are implemented as dynamic-link libraries (DLLs), written using the IIS C++ API. Any such DLL must:
Figure 3. A typical RegisterModule function of native IIS malware
Server events refer to the steps that the IIS server takes during request processing (see Figure 4), but also to other actions taken by the server (for example, sending an HTTP response). These events generate event notifications, which are handled by event handlers implemented in the server’s modules (see Figure 5).
Figure 4. HTTP request-processing pipeline in IIS
In short, the event handlers (or the methods of IIS module core classes) are where the IIS malware functionality is implemented and where any reverse engineers should focus their analysis. For a deep dive into IIS malware essentials and how to analyze such binaries, refer to the Anatomy of native IIS malware section of our white paper.
Figure 5. Event handlers: methods of the module classes, CHttpModule and CGlobalModule
A notable feature of IIS malware is how it communicates with its operators. Malicious IIS modules, especially IIS backdoors, don’t usually create new connections to their C&C servers. They work as passive implants, allowing the attackers to control them by providing some “secret” in an HTTP request sent to the compromised IIS web server. That’s why IIS backdoors usually have a mechanism to recognize attacker requests that are used to control the server and have a predefined structure, such as:
Figure 6. Passive C&C communication channel (IIS backdoors)
On the other hand, some IIS malware categories do implement an alternative C&C channel – using protocols such as HTTP or DNS – to obtain the current configuration on the fly. For example, an IIS injector contacts its C&C server every time there is a new request from a legitimate visitor of the compromised website, and uses the server response to modify the content served to that visitor (such as malicious code or adware).
Figure 7. Alternative C&C communication mechanism (IIS injectors)
Table 1 summarizes how the C&C channels, as well as other notable techniques, are implemented by the 14 analyzed IIS malware families.
Table 1. Summary of obfuscations implemented, and functionalities supported by analyzed IIS malware families
Since native IIS modules can only be installed with administrative privileges, the attackers first need to obtain elevated access to the IIS server. The following recommendations could help make their work harder:
For details on how to detect and remove IIS malware, refer to the Mitigation section of the white paper. We are also publishing a set of YARA rules that you can leverage to detect all the 14 analyzed IIS malware families.
Internet Information Services web servers have been targeted by various malicious actors, for cybercrime and cyberespionage alike. The software’s modular architecture, designed to provide extensibility for web developers, can be a useful tool for attackers to become a part of the IIS server, and intercept or modify its traffic.
It is still quite rare for endpoint (and other) security software to run on IIS servers, which makes it easy for attackers to operate unnoticed for long periods of time. This should be disturbing for all serious web portals that want to protect their visitors’ data, including authentication and payment information. Organizations that use OWA should also pay attention, as it depends on IIS and could be an interesting target for espionage.
While IIS server threats are not limited to native IIS malware, we believe this paper will be a helpful starting point for defenders for understanding, identifying, and removing IIS threats, and a guide to our fellow researchers to reverse engineer this class of threats and understand their common tactics, techniques and procedures.
Additional technical details on the malware and Indicators of Compromise can be found in our comprehensive white paper, and on GitHub. For any inquiries, or to make sample submissions related to the subject, contact us at: threatintel@eset.com.
Acknowledgements to fellow ESET malware researchers Marc-Étienne Léveillé and Mathieu Tartare for their work on this investigation.

Comments are closed.