Analyzing New HijackLoader Evasion Tactics

Introduction

HijackLoader (also known as IDAT Loader and GHOSTPULSE) is a malware loader initially discovered in 2023. The loader is not only capable of delivering second-stage payloads, but also offers a variety of modules to expand the malware’s capabilities. The modules are mainly used for configuration information and to evade security software, as well as inject and execute code. Recently, Zscaler ThreatLabz uncovered new HijackLoader modules with additional evasion techniques. In this blog, we analyze these modules that implement features including call stack spoofing to mask the origin of function calls from endpoint detection, virtual machine detection to identify analysis environments, and another module that establishes persistence via scheduled tasks.

Key Takeaways

• HijackLoader is malware downloader dating back to 2023 that has received continuous updates via new modules.
• HijackLoader released a new module that implements call stack spoofing to hide the origin of function calls (e.g., API and system calls).
• HijackLoader added a new module to perform anti-VM checks to detect malware analysis environments and sandboxes.
• Another new module is designed to establish persistence via scheduled tasks.

Technical Analysis

In the following sections, we examine HijackLoader’s new modules and changes in evasion tactics. The module names added since our last analysis are the following: ANTIVM, MUTEX, CUSTOMINJECT, CUSTOMINJECTPATH, modTask, modTask64, PERSDATA, and SM.

First stage

HijackLoader’s first stage has undergone two changes. The first change involves the blocklist processes check, where a new process name, avastsvc.exe, was added to the list. If any of the processes in the table below are running, HijackLoader delays execution by 5 seconds. 

Table 1: Processes blocklisted by HijackLoader.

The second change pertains to the decryption of modules. While most HijackLoader samples still use IDAT headers in a PNG file to store encrypted modules, a few samples are embedding them in the PNG’s pixel structure.

Second stage (ti module)

As mentioned in our previous blog, HijackLoader uses the Heaven's Gate technique to execute x64 direct syscalls. We have now observed that call stack spoofing has been added to the list of evasion tactics used by HijackLoader. This technique uses a chain of EBP pointers to traverse the stack and conceal the presence of a malicious call in the stack by replacing actual stack frames with fabricated ones.

The ti module only uses call stack spoofing for the following native system APIs:

• ZwCreateSection
• ZwMapViewOfSection
• ZwUnmapViewOfSection
• ZwProtectVirtualMemory
• ZwReadVirtualMemoy
• ZwWriteVirtualMemory
• ZwWriteFile
• ZwResumeThread
• ZwGetContextThread
• ZwSetContextThread
• ZwRollbackTransaction 
• ZwClose 
• ZwTerminateProcess 

HijackLoader API calls

HijackLoader collects the API hash, system call number, function name, and function address of all API names that start with Zw in ntdll.dll. This information is stored as an array of elements, with each element being a structure of size 16, which we will refer to as a DIRECTSYSCALL_STRUCT, as shown below.

struct DIRECTSYSCALL_STRUCT {
 uint32_t APIHash; // CRC32 hash of the API function name
 uint32_t ssn; // System service number (SSN)
 char *APIName; // API function name
 void *APIFunctionAddress; // API function address
};

When HijackLoader calls a Windows API function, the malware first locates the corresponding structure (DIRECTSYSCALL_STRUCT) for the specified API. HijackLoader then invokes the Windows API function either by directly calling its address (if not running under WOW64) or by utilizing a combination of call stack spoofing, Heaven's Gate, and direct syscalls (if running under WOW64).

Call stack spoofing

Call stack spoofing is used to mask the origin of function calls such as API and system calls. The figure below shows a high-level view of how HijackLoader leverages call stack spoofing:

Figure 1: Diagram showing how HijackLoader uses call stack spoofing to mask the origin of function calls. 

HijackLoader uses the base pointer register (EBP) to navigate the stack by following the chain of EBP pointers. The malware retrieves the return address pointer (EBP+4) from the stack frames. If the return address is not located in the text section of NTDLL or kernelbase, HijackLoader collects both the return address pointer and the return address of the stack frame. The return address pointer is then patched with a random address from the text section of a legitimate system DLL. This activity is repeated until the stack limit is reached or when three adjacent stack frames have the return address in the text section of NTDLL or kernelbase. The process is illustrated in the diagram below:

Figure 2: Diagram depicting how HijackLoader traverses the stack to retrieve and patch the return addresses to spoof stack frames.

The name of this legitimate system DLL is specified in the HijackLoader SM module. After this, HijackLoader employs the Heaven’s Gate technique, which allows it to switch from executing 32-bit (x86) code to executing 64-bit (x64) code. Once in 64-bit mode, HijackLoader performs the direct syscall. HijackLoader uses the syscall number (ssn) and the necessary parameters for the native system service API to execute the direct syscall. Following the syscall, HijackLoader transitions back to x86 and patches the return address pointers with the actual return addresses.

Previously, HijackLoader utilized direct syscalls for process injection and to remap the .text section of the x64 ntdll.dll in memory with the .text section of the x64 ntdll.dll from disk. In addition to remapping ntdll.dll, HijackLoader now also remaps the .text section of the x64 wow64cpu.dll from disk to memory to remove user-mode hooks.

Other than the ti module, the modules modCreateProcess, modUAC, and modTask also use call stack spoofing. However, these modules do not use Heaven's Gate or make direct syscalls, but instead invoke Windows API functions directly.

The figure below shows the call stack for a call to CreateProcessW after the return addresses have been patched by the modCreateProcess module. In the call stack, the return addresses outside of the text section of NTDLL and kernelbase are patched with addresses from the text section of a legitimate system DLL (shdocvw.dll) until three adjacent stack frames have the return address in the text section of NTDLL or kernelbase.

Figure 3: Example of HijackLoader spoofing the call stack with the fake frames enclosed in a red square.

Recent HijackLoader modules

The table below lists information about the more recent HijackLoader modules.

Table 2: Description of more recent HijackLoader modules.

Virtual machine detection module

The virtual machine detection module ANTIVM contains a configuration used by HijackLoader to identify virtual machines and analysis environments. This configuration is stored in a structure which we will refer to as the ANTIVM_STRUCT, as shown below.

struct ANTIVM_STRUCT {
 uint32_t antiVMType;
 uint32_t timeThreshold;
 uint32_t minPhysicalMemory;
 uint32_t minProcessorCount;
 uint32_t antiVMType2;
 wchar_t username[20]; // Hardcoded to "george" (may change between samples)
 byte PhysicalMemory;
 byte ProcessorCount;
};

The first member, antiVMType determines the type of anti-VM check to be performed. These checks employ common anti-VM techniques. The antiVMType can include multiple values combined using bitwise OR operations. The values supported are listed in the table below.

Table 3: Description of values supported by the HijackLoader virtual machine detection module.

Persistence module

Before transferring control to the modTask persistence module, the ti module copies itself to a new address and the ti module copy is XOR’ed with the performance counter value obtained by calling the QueryPerformanceCounter API. The new address of the XOR’ed ti module and the XOR key are stored for restoration purposes.

When control is transferred to the modTask module, HijackLoader begins by overwriting the entire plaintext ti module with zeros. HijackLoader then performs call stack spoofing as previously described. Next, the modTask module copies the TinycallProxy module into the text section of the system DLL specified in the SM module and uses this copied TinycallProxy module to call APIs. 

Then, HijackLoader creates a scheduled task for persistence using the configuration in the PERSDATA configuration module. The configuration is stored in a structure which we will refer to as the PERSDATA_STRUCT, with the definition shown below.

struct PERSDATA_STRUCT {
  uint32_t triggerTaskOnLogon; // If set, the task will be triggered when the
                               // user logs in, otherwise the task will execute 
                               // at regular intervals.
  uint32_t TaskFlag;           // Flag used in ITask::SetFlags method
  uin32_t MinutesInterval;     // Task execution interval in minutes
  uin32_t wRandMinutesInterval;// Unused by the TASK_TRIGGER structure
  wchar_t taskName[50];        // Name of the task 
};

More information about HijackLoader’s modules are available in our previous blog.

Conclusion

HijackLoader is a highly modular malware loader that shows no signs of slowing down. HijackLoader's new modules demonstrate the malware’s evolving evasion tactics that increasingly focus on enhancing its anti-detection capabilities. Thus, we anticipate that HijackLoader will continue to introduce new modules that are further designed to complicate analysis and detection.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to HijackLoader at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for HijackLoader.

Figure 4: Zscaler Cloud Sandbox report for HijackLoader.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to HijackLoader at various levels with the following threat names:

• Win64.Downloader.HijackLoader
• Win32.Downloader.HijackLoader

Indicators Of Compromise (IOCs) 

MITRE ATT&CK Techniques