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

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:

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.

Based on our telemetry data, after successfully establishing a foothold and placing the memory implant in the system memory, the next actions are to erase the previously existing traces by deleting the scheduled “MicrosoftsUpdate” job and both the initial DLL and batch files:

Older variants

We have also discovered earlier, differently named variants of HrServ. These DLL files date back to early 2021. They also use the custom encoding algorithm and behave the same way after a file read error. However, there are subtle differences.

• The web shell URL of these older variants differs from the current one:
  

  https://+:443/owa/MSExchangeService.svc

• These samples exhibit a distinct behavior by creating a process and retrieving its output through a pipe, as opposed to allocating a memory section and creating a thread from it.

Victims

The only known victim according to our telemetry is a government entity in Afghanistan.

Attribution

The TTPs analyzed in this investigation are not associated with any known threat actors we are tracking, but there are a few things that we observed:

• the GET parameters used in the hrserv.dll file, which is used to mimic Google services, include “hl”. This specifies the host language of the user interface. Although this parameter has no functionality within the attack vector, the assigned value “en-TW” specifies that the Google search interface should be displayed in English, but the search results should be displayed in Traditional Chinese:
  

  &cp=1&client=desktop-gws-wiz-on-focus-serp&xssi=t&hl=en-TW&authuser=0&pq=

• the samples include help strings for specific conditions, in English. We saw multiple typos that suggest the actor behind the samples is not a native English speaker.

Conclusion

The analyzed sample represents a capable web shell. Based on the compile timestamps, its origins date back to at least 2021. This sophisticated malware variant exhibits the ability to initiate in-memory executions. In the observed scenario, communication is established through registry manipulations and temporary files.

Notably, the web shell and memory implant use different strings for specific conditions. In addition, the memory implant features a meticulously crafted help message. Considering these factors, the malware’s characteristics are more consistent with financially motivated malicious activity. However, its operational methodology exhibits similarities with APT behavior. Despite the malware’s prolonged activity over several years, multiple instances involving these samples have not been documented. Our efforts are ongoing as we continue to monitor related activity, with the goal of unraveling the mystery in future investigations.

Indicators of compromise

File hashes

b9b7f16ed28140c5fcfab026078f4e2e
418657bf50ee32acc633b95bac4943c6
d0fe27865ab271963e27973e81b77bae
890fe3f9c7009c23329f9a284ec2a61b