Distribution of IIS Malware Targeting Web Servers (Larva-25003)
Overview
In February 2025, AhnLab SEcurity intelligence Center (ASEC) identified a threat actor, believed to be Chinese-speaking, distributing a web server native module targeting a South Korean web server. The threat actor gained control over the web server by attempting initial access to poorly managed web servers and using a .NET loader malware (WebShell) and a backdoor to perform web shell functions. The threat actor then registered and executed a malicious IIS (Internet Information Service) native module that they had created on a Microsoft Windows IIS web server.
When the malicious IIS native module is loaded into the w3wp.exe process, it intercepts all HTTP requests being sent to the web server. It then manipulates the response values to redirect to a specific page or perform a web shell function. Through the malicious native module, threat actors can intercept all traffic coming into the web server and modify it as needed.
The threat actor behind this attack is presumed to be a Chinese speaker due to the presence of the Gh0st RAT malware, which is known to be primarily used by Chinese threat groups, and a file-hiding utility program with the file name “HijackDriverManager” written in Chinese. The buttons in the utility’s GUI were all labeled in Chinese, and its main function is to control the Winkbj.sys rootkit driver, which is used to conceal the malicious IIS module from security products.
This blog post details the .NET loader malware, file hider utility, Gh0st RAT, and IIS native module malware used by the threat actor, and the necessary measures to prevent and respond to such attacks.
Malware Analysis
1. IIS Native Module Malware
The threat actor accessed a poorly managed web server and installed malware by using the AppCmd.exe IIS command-line management command as shown below.
- %SystemRoot%\System32\inetsrv\appcmd.exe install module /name:IsapiCachesModule /image:”C:\Windows\System32\inetsrv\caches.dll” /preCondition:bitness64
Executing the above command triggers the install module behavior, which allows the IIS global native module to be installed. The threat actor specified the module name as “IsapiCachesModule” to identify the malicious module, and used the bitness64 condition to ensure that only 64-bit w3wp.exe worker processes can load the DLL. As a result of executing the command, the w3wp.exe process loads caches.dll, the IIS native module malware, into the memory, allowing it to intercept and manipulate all requests coming into the web server. The identified malicious IIS module in this attack case inserts a malicious handler for each of the following three events: OnGlobalPreBeginRequest, OnBeginRequest, and OnSendResponse.
- CGlobalModule::OnGlobalPreBeginRequest -> Called first at the global level right before the GL_PRE_BEGIN_REQUEST event
- CHttpModule::OnBeginRequest -> The first call in the request-level pipeline upon the occurrence of the RQ_BEGIN_REQUEST event
- CHttpModule::OnSendResponse -> Called by IIS just before transmitting the final response buffer
As shown above, when the malicious native global module inserts the malicious handler at the global entry point (OnGlobalPreBeginRequest), request entry point (OnBeginRequest), and response transmission point (OnSendResponse), covert and powerful control and modification of the web packets requested by users can be performed across the entire IIS pipeline. Each handler additionally calls five malicious classes.
Figure 1. Malicious class invocation code
In each class, the HTTP request syntax is parsed to POST/GET and page path, and various functions are executed according to the matching conditions. Table 1 below shows the descriptions of the functions for each class.
|
Class Name |
Function |
|
WebdllServer |
1. Executed if the request URL path contains “web.dll”. 2. When the host header exists, the query string after “?” is extracted. The file is then searched for by appending .asp to it and executing it in the sub-path of C:\inetpub\wwwroot\, or a directory is created if necessary. The file is then loaded into the ASP engine and executed. |
|
RedirectServer |
1. Parses the landing page URL from the client’s HTTP request packet. 2. Returns a page response of <script>window.location.href=…</script> and sends the response value, prompting the client to access the page. |
|
AffLinkServer |
1. The “aff” parameter or cookie is found, and the link information for the affiliate banner server is checked. 2. Creates the affiliate banner HTML and sends the response value. |
|
HiJackServer |
1. Checks the existence of “/health”, “/debug”, “/conf”, “/clean”, “/delete_tmp”, etc. in the URI of the HTTP request packet. 2. Responds with the server status value according to the memory state and configuration value request. |
|
UploadServer |
1. Checks if the string “/mywebdll” exists in the URI of the HTTP request packet. 2. Provides an HTML upload form to the requesting client. |
Table 1. Five classes of threat actor commands
2. HijackDriverManager
Before the threat actor installed the IIS native module on the web server system, they created the “HijackDriverManager” utility using the rootkit malware, which provides a file hiding function. This utility appears to have been used to block access to kernel objects such as specific files, images, and registry keys through the rootkit driver, concealing the subsequently installed malicious native module from being detected by security products.
Figure 2. Screen of HijackDriverManager being executed (Chinese GUI)
3. Gh0st RAT
Traces of Gh0st RAT were additionally identified in the affected system. Gh0st RAT is a type of backdoor malware known to be used by APT threat actors based in China. It is a powerful backdoor malware that provides functions for managing files, shells, screens, videos, audios, keyboards, and systems.
C&C Server: 47.236.9[.]229:10086
Figure 3. Routine for exfiltrating audio data of Gh0st RAT’s malware
4. .NET Loader Malware (WebShell)
The .NET loader malware was also identified in the affected system. Upon checking the path of the discovered malware, it was found that a malicious DLL was created in the Temporary folder due to ASP.NET’s dynamic compilation mechanism. This means that when a client calls a URL on the web server, the w3wp.exe process loads and compiles the ASPX file. It is during this process that the malicious DLL is created and loaded in the following path.
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\44365c70\3eb5ad5a\App_Web_zcd2fld5.dll
The created loader malware decodes the BASE64 data of the body (Request.InputStream) requested to the server, then decrypts the data using the AES algorithm and performs assembly loading in the memory.
Figure 4. Assembly load code routine of the .NET Loader malware
It operates in a fileless form because assembly is loaded into memory. At the time of analysis, assembly data could not be obtained, but it is presumed that the final executed malware would have performed web shell functions.
Conclusion
In this case, the threat actor, taking advantage of the poor security management of an IIS web server, distributed a .NET loader, the Gh0st RAT backdoor, and a malicious IIS native module. These tools allowed the threat actor to intercept all HTTP traffic coming into the web server and modify the responses. Based on the functions of the collected malware, it is possible to speculate on the threat actor’s objectives. By installing their malicious modules on the web server, the threat actor was able to insert their affiliate links into the response values to the HTTP traffic requested from the web server. This allowed them to generate revenue by displaying their advertisements and banners on their partner websites. Additionally, the threat actor used the malware to install phishing pages and redirect users to them, thereby leaking sensitive information.
Therefore, server administrators must apply the latest security patches for the server OS and activate the real-time, behavior-based detection function of security products to prevent unknown files and threats.
