HotPage: Story of a signed, vulnerable, ad-injecting driver

Malware research involves studying threat actor TTPs, mapping infrastructure, analyzing novel techniques… And while most of these investigations build on existing research, sometimes they start from a hunch, something that looks too simple. At the end of 2023, we stumbled upon an installer named HotPage.exe that deploys a driver capable of injecting code into remote processes, and two libraries capable of intercepting and tampering with browsers’ network traffic. The malware can modify or replace the contents of a requested page, redirect the user to another page, or open a new page in a new tab based on certain conditions.

The installer was detected by most security products as an adware component but what really piqued our interest was the embedded driver signed by Microsoft. According to its signature, it was developed by a Chinese company named 湖北盾网网络科技有限公司 (machine translation: Hubei Dunwang Network Technology Co., Ltd), the lack of information about which was intriguing. The distribution method is still unclear but according to our research, this software was advertised as an “Internet café security solution” aimed at Chinese-speaking individuals. It purports to improve the web browsing experience by blocking ads and malicious websites, but the reality is quite different – it leverages its browser traffic interception and filtering capabilities to display game-related ads. It also sends some information about the computer to the company’s server, most likely to gather installation statistics.

On top of its obvious mischievous behavior, this kernel component unintentionally leaves the door open for other threats to run code at the highest privilege level available in the Windows operating system: the SYSTEM account. Due to improper access restrictions to this kernel component, any processes can communicate with it and leverage its code injection capability to target any non-protected processes.

We reported this driver to Microsoft on March 18^th, 2024 and followed their coordinated vulnerability disclosure process. Microsoft Security Response Center (MSRC) determined that this is no longer a vulnerability as the offending driver was removed from the Windows Server Catalog on May 1^st, 2024. ESET technologies detect this threat as Win{32|64}/HotPage.A and Win{32|64}/HotPage.B.

Who is 湖北盾网网络科技有限公司 ?

During its execution, the HotPage malware installs a driver, but before diving into the technical details of its inner workings, we wanted to learn more about the code-signing signature of this driver. What first caught our attention was the signing certificate’s owner, as illustrated in Figure 1.

Since the 64-bit version of Windows 7, kernel-mode drivers have been required to be signed to be loaded by the operating system. As previously detailed by Mandiant Intelligence, SentinelLabs, and G DATA teams, the signing process is built on trust but there have been cases where this was abused. It seems that the Chinese company went through Microsoft’s driver code-signing requirements and managed to obtain an Extended Verification (EV) certificate as shown in Figure 2.

In order to retrieve the company name associated with this signature, the extraction of the signers’ attributes was necessary. Figure 3 shows the SpcSpOpusInfo attribute identified by the object ID 1.3.6.1.4.1.311.2.1.12.

Using the LIEF binary parser, it is possible to extract the structure member programName that identifies the company behind this signature, as displayed in Figure 4.

We found a reference to this company in the Windows Server Catalog, as shown in Figure 5. The company used various product categories when submitting its drivers for certification. Based on its name, it appears the company developed two network filtering programs: a netfilter component and the HotPage driver referred as adsafe or by its internal name KNewTalbeBase (Note the [Tt]albe typo, which also occurs elsewhere in the HotPage code).

Investigating the company through search engines didn’t yield many results. According to the company register dingtalk, we discovered that the company was created on January 6^th, 2022 and provided the email address dwadsafe@mail[.]io. The business scope includes: technology-related activities such as development, services, consulting, etc., but also advertising activities. As translated in Figure 6, the principal shareholder is now Wuhan Yishun Baishun Culture Media Co., Ltd, a very small company that looks to be specialized in advertising and marketing.

From the Intellectual Property tab, we learned that in April and May 2022 the company applied for the trade name Shield Internet Café Security Defense and the website dwadsafe[.]com was created on February 22^nd, 2022. The domain now resolves to localhost (127.0.0.1) and is therefore inaccessible. However, a screenshot of the website was taken on November 10^th, 2023 by a web crawler, as seen in Figure 7.

The HTTP body of the URL https://www.dwadsafe[.]com/login/reg.html (SHA-1: 744FFC3D8ECE37898A0559B62CC9F814006A1218) was also captured by VirusTotal. The source code contains the description 网吧主动防御云平台 (machine translation: Internet café active defense cloud platform). This page includes a license agreement that details the purpose of the software, albeit with contradictions. Table 1 lists some interesting bits of that information.

Table 1. Translation of the relevant parts of the license agreement

According to the license agreement, the software is indeed marketed as a security solution for internet cafés to block ads. However, despite the company’s claims that DwAdsafe does not have any interception capability, our investigation revealed that the software does have a rather intrusive one and comes with pre-written, unmodifiable rules.

Apart from these bits of information, the company behind this malicious component remains a mystery.

HotPage analysis

In this section we describe how the different components are installed and interact with each other to achieve their purpose: injecting ads into the browser. So far, we haven’t found out how the malware was distributed but we believe, with low confidence, that it might have been bundled with another software package or advertised as a security product due to the level of privileges needed to install the driver. A few references advertising the product were found in some forums in 2022; an example is seen in Figure 8.

The installer drops the driver on disk and starts a service to execute it. It decrypts its configuration file, which contains a list of target Chromium-based browsers and libraries. If such executables are found running or being loaded, the driver tries to inject one of the listed libraries into the browser process. After hooking network-based Windows API functions, the injected library checks the URL being accessed and under certain conditions, it displays another page to the user through diverse means.

The installer

The installer we analyzed (SHA-1: 941F0D2D4589FB8ADF224C8969F74633267B2561) is a UPX-compressed file that was uploaded to VirusTotal on 2023-08-26. Figure 9 provides a high-level overview of the driver installation.

The installer contains the encrypted versions (single-byte XOR operation with the key 0xE3) of the driver component, the libraries that will be injected into web browser processes, and three JSON-formatted configuration files:

• chromedll contains the names of the targeted browser libraries to hook and the targeted functions’ pattern for hooking them,
• hotPage (unused) contains the list of targeted browsers, allowlists of command line parameters and websites, and the homepage URL that could be used, and
• newtalbe contains filtering rules, an API endpoint to send basic information about the compromised computer, and another one to manage configuration updates.

The malware starts by executing the CPUID instruction (see Hypervisor Discovery), to check whether it’s running within a virtualized environment. Then it checks if the driver’s device filename \\.\KNewTableBaseIo exists and if not, it decrypts the driver and stores it in C:\Windows\ShieldNetWork\Business\. Its name is a randomly generated 7-character string followed by the .sys extension. A service is created with the file path of the stored driver, and the random string is used as the service name. Since the start type is set to SERVICE_DEMAND_START, the service needs to be explicitly started in order to load the driver. Oddly, this adware doesn’t implement any persistence mechanisms, or at least not in this version.

The installer proceeds to communicate with and configure the driver via its device filename using I/O control codes in the following order:

1. 0x9C4013FC – send the 32-bit hooking library that will be injected into target web browser processes.
2. 0x9C400FFC – send the 64-bit hooking library that will be injected into target web browser processes.
3. 0x9C40173C – send the chromedll configuration.

The installer retrieves the registry key associated with the created service and checks to see if the values IP and port are present. These values are never set by this code so they are presumably created by another component. Without going into the details of the network protocol, the remote server should serve an update of the newtalbe configuration. The communication is encrypted with RC4, using a key derived from the string ID:f~WdH+K?KD)r*sD4mk using the Windows BCryptGenerateSymmetricKey function. Figure 10 shows the content of the configuration file.

Table 2 describes the important values used from this file, listed in the order that they appear in the configuration file (Figure 10).

Table 2. newtalbe configuration description

Using the hostapi URL value of this file, an HTTP GET request is made over TLS with a generic User-Agent string. The received data is decrypted using RC4 with the hostapikey value; it contains a dictionary of gaming-related hostnames with their corresponding resolved address.

Once these updates are done, the installer sends the updated newtalbe configuration to the driver by issuing an I/O request with the control code 0x9C400BFC.

Finally, the malware iterates over the list of endpoints provided by the JSON element apiurl and for each one of them it creates a JSON-formatted string containing information about the compromised computer, encrypts it with RC4 using the key Abc123!@#&XM derived via the Windows API BcryptGenerateSymmetricKey, and sends the collected information to the remote server via an HTTP POST request. The collected information includes the computer name, the network interface MAC address, the version of the operating system, and the dimensions of the screen.

Injector driver

The driver’s main purpose is to inject libraries into browser applications and alter their execution flow to change the URL being accessed or open a page in a new tab. Two threads are created to handle requests for opening a new tab and injecting libraries using the publicly available Blackbone project. Additionally, process creation and image loading notification routines are set to monitor newly created processes and executable images being loaded. The simplified logic of the driver is illustrated in Figure 11.

For an unknown reason, the driver starts by deleting its image from the disk. Afterwards it creates a device object named \\.\KNewTableBaseIo and sets its IRP_MJ_DEVICE_CONTROL routine to handle the various I/O requests listed in Table 3. The control codes (IOCTL) used for configuration or setting the injected libraries can only be called once; therefore the settings cannot be updated. These special control codes are protected by checking that the caller’s file path matches the regular expression *ShieldNetWork\\Business\\DwBusiness_*.

Table 3. List of available IOCTLs and their description

When handling the control codes 0x9C400BFC and 0x9C40173C, the driver iterates over the loaded modules of all the running processes. If one of the targeted modules listed in the chromedll configuration is found, a request to inject a library into that process is queued.

Finally, the driver ends its initialization by creating two threads and setting the notification routines mentioned above.

It is important to note that the hotPage configuration is never set. Any mentions of this file are solely made to describe how it would be used according to the driver’s control flow. Essentially the hotPage configuration is used to redirect the user to a specific page (or homepage) filled with ads when a targeted browser is launched.

The version of the software we analyzed relied only on the chromedll and newtalbe configurations to achieve its ad injection.

Library injection thread

This thread checks the queued injection requests, and for each of them, it attaches itself to the targeted process via KeStackAttachProcess, allocates chunks of memory, and copies its shellcode. Using the Blackbone library function ZwCreateThreadEx, the driver calls the shellcode, which implements its own PE loader and calls the entry point of the injected library.

New tab thread

The second thread uses the same logic; however, the injected shellcode is different. It calls the Windows API function CreateProcessW with the command line parameter being the process name of the targeted process concatenated with the URL that should be opened. The latter is made of the URL followed by the sum of the idindex and the userid variables from the hotPage configuration. For instance, the configuration shown in Figure 12 would create the string https://www.hao774[.]com/?90386-00001. Since Chromium-based browsers create a new process for each new tab, creating a process from the browser process will effectively create a new tab.

Figure 12 shows the content of the hotPage configuration file.

This configuration file contains the list of targeted web browsers and command line parameters that determine whether the process should be injected. The domain names are either related to gaming ads or internet café maintenance.

Process creation notification routine

Essentially, this routine makes sure the homepage of the new web browser instance is redirected to a specific URL present in the hotPage configuration. This section describes how the driver implements this feature even if it’s not used, since this version of the installer never sends this configuration to the driver.

Depending on the following conditions, the web browser process will be marked as eligible for opening the URL in the hotPage configuration:

• this is the first instance of the browser and not a new tab being opened,
• the process’s file path matches one of the regular expressions in the browser list in the hotPage configuration,
• the command line of the process does not match any regular expression in the wlist list of the hotPage configuration, and
• if the process’s command line includes its own file path, it must not match any regular expressions in the ppwlist list of the hotPage configuration.

As detailed in the next section, when the browser process starts loading the first executable images, a request to open a new tab is queued. Figure 13 and Figure 14, respectively, show the difference between the legitimate web directory 2345[.]com and the ad-riddled page displayed to the user.

Image loading notification routine

This routine essentially handles two types of scenarios. If the image being loaded is in the chromedll list, an APC routine is queued that will load one of the hooking libraries via its own PE loader.

Otherwise, if the process was marked eligible for opening a new page, the malware achieves this either by opening it in a new tab or in the current one. If the process filename matches one of the regular expressions in the browser1 list of the hotPage configuration, a request to open a new tab is queued and will be handled by the appropriate thread (note that the browser1 list element was not present in the configuration file we retrieved). In the other case, the page will be opened in the tab being created by queuing a work item (via IoQueueWorkItemEx) that will modify the command line of the process being created. The latter attaches itself to the process, finds the export address of GetCommandLineA and GetCommandlineW inside the kernelbase.dll library, and modifies the Unicode string stored in BaseAnsiCommandLine. The command line is replaced with the process’s executable file path concatenated with the URL in the hotPage configuration. Figure 15 shows a side-by-side comparison of the code responsible for finding the command line buffer and the disassembly of the GetCommandLineA function.

Injected library

The first thing that the injected library does is to retrieve the hotPage and newtalbe configurations by querying the driver. If the injected browser filename is 360Chrome, it deletes the registry key HKCU\Software\360chrome\Homepage and patches the Preferences file (located under the browser’s default directory 360chrome\chrome\User Data\Default\Preferences) to make the homepage point to the URL value of the hotPage configuration.

Using the Microsoft Detours hooking library, the sample hooks SetProcessMitigationPolicy to make it return 1 in order to prevent security policies from being applied to the process, thereby allowing code injection. Then getaddrinfo is hooked to force the browser to resolve certain hostnames to specific IP addresses to ensure the redirection is made to the right server in case the domain names do not exist anymore.

Hooking SSL_read and SSL_write

The malware hooks the SSL_read and SSL_write functions to allow the manipulation of the browser’s decrypted TLS traffic; it does so by searching for specific patterns inside the loaded modules, since these functions are not exported. For instance, the chromewrite dictionary inside the chromedll configuration contains two types of patterns, sslcode and oldchrome, as seen in Figure 16. They are, respectively, used for finding newer and older versions of the DoPayloadWrite function. We tested and confirmed that the patterns match the Microsoft Edge library msedge.dll version 122.0.2365.80.

The mode value is used to determine the version of the pattern, either 32-bit or 64-bit; the code value is the actual byte pattern, and the offset is the distance from the start of the pattern to the pointer to the SSL_write function (see Figure 17).

Once SSL_write and SSL_read are found, they are hooked using the Detours library. For the former, the malware inspects the data and then calls the original function, which encrypts and sends it. As for the latter, the injected library does the opposite in order to manipulate decrypted data. For both functions, the data is inspected by the code that respectively handles the AFD_SEND and AFD_RECV control codes in the function hooking NtDeviceIoControlFile.

Hooking NtDeviceIoControlFile and inspecting incoming and outgoing data

The malicious library hooks the NtDeviceIoControlFile function to handle specific IOCTL codes as seen in Figure 18.

For the control code 0x12023 (AFD_SEND_DATAGRAM used when sending UDP packets), the malware cancels any DNS requests by returning STATUS_INVALID_PARAMETER if the remote port number is 53. This ensures that the web browser only uses the hosts provided by the newtalbe configuration.

The routine that handles the control code 0x1201F (AFD_SEND) starts by extracting the URL and the Referrer header from the request. Based on the URL matching certain values in the newtalbe and hotPage configurations, the malware performs assorted actions, as described in Table 4. In some cases, the request is sent but the response is modified in the routine handling the AFD_RECV control code by different redirection methods explained afterwards.

Table 4. List of actions performed under certain conditions when sending HTTP requests

For control code 0x12017 (AFD_RECV), the malware first retrieves the data received by the client and checks if the response was marked eligible for redirection. There are four types of redirections as described in Table 5. The xxx string in the modified response is changed for the URL in the newtalbe configuration.

Table 5. Redirection methods

Figure 19 illustrates redirection method 0 being applied after navigating to a URL matching one of the blist URL patterns of the newtalbe configuration (www.5zy[.]cn). Another tab is opened and points to the url specified in the same configuration.

Security issues and privilege escalation

When initializing its device object, the driver does not specify any access control lists (ACLs) to restrict who can communicate with it; therefore, anyone can send I/O requests to it. As mentioned previously, some I/O control codes require the requesting process to be in a path matching the regex:

*ShieldNetWork\\Business\\DwBusiness_*

This is clearly not sufficient to check whether the communicating process is one of the HotPage components and can easily be bypassed by creating the required directories under a user-writable folder.

We came up with two scenarios that would allow a user with the HotPage driver running on their system to run code as the NT AUTHORITY\System account. We created a proof-of-concept (PoC) script in Python to achieve both scenarios.

Scenario #1: Privilege escalation via arbitrary DLL injection in arbitrary processes

In this first scenario, we assume that the driver was loaded but that the chromedll configuration and the libraries to inject it were not set. In that case, it is possible to create and set our own library to inject. We created a small library that would simply log the PID of the injected process, whether it is running with administrator privileges, and the injected process’s file path.

As seen in the screenshot of the log file in Figure 20, a lot of processes were injected with our library including processes with administrator privileges.

It should be noted, however, that protected processes cannot be injected using this technique.

Scenario #2: Privilege escalation via changing the command line of newly created processes

In the first scenario, we relied on the fact that both the injected libraries and the chromedll configuration were not set, but, as seen in the installer analysis, they are both set as soon as the driver is initially loaded. However, the hotPage configuration never gets set. Based on the control flow analysis, we devised a way to leverage the driver’s process creation and image loading notification routines’ logic to execute the same executable again but with a different command line.

Under certain conditions, as explained in the Process creation notification routine and Image loading notification routine sections, the driver can open a new tab pointing to the URL present in the hotPage configuration. This is achieved either by replacing the command line of the newly created browser process or by duplicating the browser process and changing its command line to the URL in the hotPage configuration. If we specify which process can be duplicated and the new command line, we can achieve privilege escalation by targeting a process with SYSTEM privileges, for instance.

Conclusion

The analysis of this rather generic-looking piece of malware has proven, once again, that adware developers are still willing to go the extra mile to achieve their goals. Not only that, these have developed a kernel component with a large set of techniques to manipulate processes, but they also went through the requirements imposed by Microsoft to obtain a code-signing certificate for their driver component.

The HotPage driver reminds us that abusing Extended Verification certificates is still a thing. As a lot of security models are at some point based on trust; threat actors are inclined to play along the line between legitimate and shady. Whether such software is advertised as a security solution or simply bundled with other software, the capabilities granted thanks to this trust expose users to security risks.

As annoying as adware can be, the vulnerabilities introduced by this malware leave the system open to even more dangerous threats. An attacker with a non-privileged account could leverage the vulnerable driver to obtain SYSTEM privileges or inject libraries into remote processes to cause further damage, all while using a legitimate and signed driver.

ESET technologies detect this threat – which Microsoft removed from the Windows Server Catalog on May 1^st, 2024 – as Win{32|64}/HotPage.A and Win{32|64}/HotPage.B.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

Files

Network

MITRE ATT&CK techniques

This table was built using version 15 of the MITRE ATT&CK framework.