Content menu Close

APT reports

HrServ – Previously unknown web shell used in APT attack

APT reports

minute read

Table of Contents

Authors

Introduction

In the course of our routine investigation, we discovered a DLL file, identified as hrserv.dll, which is a previously unknown web shell exhibiting sophisticated features such as custom encoding methods for client communication and in-memory execution. Our analysis of the sample led to the discovery of related variants compiled in 2021, indicating a potential correlation between these separate occurrences of malicious activity.

Initial infection

According to our telemetry data, the PAExec.exe process initiates the creation of a scheduled task on the system named MicrosoftsUpdate (sic), which in turn is designed to execute a .BAT file.

The .BAT file accepts the path of a DLL file as an argument. In this instance, the script is provided with the file $public\hrserv.dll, which is then copied to the System32 directory. After this operation, the script configures a service via the system registry and the sc utility. It then activates the newly created service.

HrServ web shell

MD5 418657bf50ee32acc633b95bac4943c6
SHA1 cb257e00a1082fc79debf9d1cb469bd250d8e026
SHA256 8043e6c6b5e9e316950ddb7060883de119e54f226ab7a320b743be99b9c10ec5
Link time 2023-Aug-30 08:28:15
File type PE32+ executable (DLL) (console) x86-64, for MS Windows
Compiler Microsoft Visual C/C++(2015 v.14.0)

The sequence of operations starts with the registration of a service handler. HrServ then initiates an HTTP server utilizing the HTTP server API for its functionality. It calls the HttpAddUrlToGroup function to register the following URL so that matching requests are routed to the request queue.

Client-server communication uses custom encoding techniques that include Base64 encoding and FNV1A64 hashing algorithms.

Based on the type and information within an HTTP request, specific functions are activated. These functions are distinguished by the GET parameter named cp. In addition, the DLL file utilizes the value of the NID cookie for various purposes. The use of the GET parameter pattern and the cookie value is consistent with practices employed by Google. We suspect that this intentional similarity in naming conventions is intended to disguise these requests in network traffic, making it more challenging to detect such malicious activity.

An example of such a request would be:

Request type cp value Description
GET 0 Call VirtualAlloc and copy a custom decoded NID cookie value, then create a new thread.
POST 1 Create a file using the custom decoded NID cookie value and write the custom decoded POST data to that file.
GET 2 Read a file using the custom decoded NID cookie value and return it as a response by appending it to the end of the “data:image/png;base64” string;
If an error occurs while reading the file, HrServ responds with the string:
data:image/png;base64,c3Dlc+DheRzlKBV2Yh92KS//;
GET 4 Return Outlook Web App HTML data.
POST 6 Call VirtualAlloc and copy the custom decoded POST data, then create a new thread.
GET 7 Return Outlook Web App HTML data [Duplicate].

Code execution

If the cp value in the request is 6, this indicates a code execution process.

  • Initially, it extracts the value of the NID cookie and applies its custom decoding technique
  • It writes this decoded value to the specified registry path, denoted as “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IdentityStore\RemoteFile”
  • The custom-decoded POST data is then copied to the memory, after which a new thread is created and the process enters a sleep state.

In a particular observed scenario, the cp value is unknown. A multifunctional implant is activated in the system memory. The implant creates a file in the directory “%temp%”, retrieves information from the registry, performs some actions based on this information, and records the output of these actions in the created file. As a result, the registry and the temporary file are used as a communication channel between the implant and HrServ.