Get the latest Zscaler blog updates in your inboxSubscribe
HijackLoader is a new malware loader, which has grown in popularity over the past few months. Even though HijackLoader does not contain advanced features, it is capable of using a variety of modules for code injection and execution since it uses a modular architecture, a feature that most loaders do not have. Based on our telemetry, we have observed HijackLoader being used to load different malware families such as Danabot, SystemBC and RedLine Stealer.
In this blog, we examine the inner workings of HighjackLoader, from its initialization to modular design to anti-analysis techniques.
- HijackLoader is a new malware loader that ThreatLabz first observed in July 2023.
- The loader is being leveraged to drop numerous malware families, including Danabot, SystemBC, and RedLine Stealer, amplifying its potential threat.
- HijackLoader utilizes syscalls to evade monitoring from security solutions, detects specific processes based on an embedded blocklist, and delays code execution at different stages.
- The malware uses embedded modules that facilitate flexible code injection and execution - a feature uncommon among traditional loaders.
The following sections describe each stage and component of HijackLoader. It should be noted that the analysis focuses on one of the many samples observed by ThreatLabz. As a result, certain parts of the analysis might differ from sample to sample (e.g. structure field offsets).
First Stage Loader
Upon execution, HijackLoader starts by executing a modified (hooked) function of the Windows C Runtime (CRT), which points to the entry point of the first stage.
During its initialization phase, the loader determines if the final payload has been embedded in the binary or if it needs to download it from an external server. To achieve this, HijackLoader includes an encrypted configuration, which stores information such as:
- A DWORD hash value to detect the next stage (e.g., the ti module described later in the text) from the modules table.
- Windows API hashes for dynamic loading.
- An array of DWORDs, which are used to determine if the loader has to download the final payload. The offsets for these fields might differ from sample to sample.
- Parameters for several Windows API functions. For example, the constant PAGE_EXECUTE_READWRITE (0x40) for VirtualProtect.
- A DWORD seed value, which is used for deriving a string based on the compromised host’s username.
- A DWORD value, which is used for validating the payload, when loaded from disk, by searching it in the payload’s data.
- A DWORD value, which is used for detecting all blobs of the encrypted payload.
- An offset for the payload URL (if any) along with an XOR key to decrypt it.
- A blocklist of process name hashes (described later in Table 1).
The above configuration block is detected by using hardcoded offsets and then decrypted either with a bitwise XOR or ADD operation. The offsets for the configuration block detection (including the offset of the encryption key) might differ from sample to sample.
The first stage includes a limited set of evasion techniques:
- Dynamic loading of Windows API functions by leveraging a custom API hashing technique.
- Performing an HTTP connectivity test to a legitimate website (e.g. mozilla.org). If a connection cannot be made, then HijackLoader does not proceed with the execution and enters an infinite loop until a connection is made.
- Delaying of code execution at different stages.
- The first stager checks for the presence of a set of running processes. Depending on which ones are present, it executes different functionality. In Table 1, we summarize the corresponding functionality for each process.
|PROCESS NAME||PRODUCT NAME||DESCRIPTION|
|avastsvc||Avast Antivirus||Delay execution for 40 seconds.|
|avgsvc||AVG Internet Security||Delay execution for 40 seconds.|
|a2service||Emsisoft Anti-Malware||Skip the connectivity test.|
|wrsa||Webroot SecureAnywhere||Skip the connectivity test.|
|msmpeng||Microsoft Windows Defender||No behavioral code change.|
Second Stage Loading
HijackLoader locates the payload of the second stage (i.e., the ti module) by following the steps below:
- Parses the decrypted configuration block, which was obtained from the initialization phase. Then, HijackLoader locates the encrypted payload URL and decrypts it using a bitwise XOR operation.
- Downloads the payload and validates it by checking for the presence of the signature (included in the configuration block) in its data. If the validation passes, it writes it to disk.
- Searches for encrypted blobs using the second marker. Each marker represents the start of an encrypted blob along with the size of the blob (which is stored before each occurrence). Moreover, the XOR key is located after the offset of the first encrypted blob.
- Once all encrypted blobs have been extracted, they are concatenated together and decrypted with the XOR key.
- Finally, the decrypted payload is decompressed using the LZNT1 algorithm.
Pseudocode for this process is shown in Figure 1.
Figure 1: HijackLoader second stage code to download and execute payloads
The same procedure is followed when the payload is loaded from disk. The only difference is that HijackLoader uses an additional pattern (from the configuration block) for finding the start offset of the embedded payload (Figure 2).
Figure 2: HijackLoader second stage payload execution from a local file
The decrypted payload includes two components:
- A modules table - This includes the HijackLoader modules along with their settings and the final payload (e.g. SystemBC).
- Main shellcode and settings, or a list of optional files to use for DLL hijacking.
Next, the first stager needs to load and execute the next stage. This is accomplished by obtaining the file path of the DLL to patch (e.g. mshtml.dll) and a table for the modules of HijackLoader that is included in the decrypted payload.
Then, HijackLoader loads the specified DLL and locates the next stager (ti module) after searching for its hash (included in the configuration block) in the modules table. Lastly, it copies the module’s data into the code section of the legitimate DLL and executes it.
NOTE: The file paths and names of files that are written to disk by HijackLoader are generated based on the username of the compromised host.
HijackLoader’s modules assist with the code injection and execution process of the final payload. The table below shows the modules identified by ThreatLabz, along with the corresponding CRC32 values and functionality.
|0x78b783ca||AVDATA||Blocklist of security products’ process names. The blocklist includes the CRC32 value of each process name.|
|0x757c9405||ESAL||Clears out the shellcode data and executes the final payload.|
|0x6364a15b||ESAL64||64-bit version of the ESAL module.|
|0xe7794e15||ESLDR||Assists with code injection of the main instrumentation shellcode.|
|0x4fa01ac5||ESLDR64||64-bit version of ESLDR module.|
|0x93eb1cb1||ESWR||Clears out the shellcode data and executes the rshell module.|
|0x699d0c82||FIXED||Legitimate executable file (e.g., QQPCMgr), which is used for injecting code into its process.|
|LauncherLdr||Decrypts the stored modules table file from disk. We have only seen the 64-bit version of this module being included.|
|0xf4f141c2||LauncherLdr64||64-bit version of LauncherLdr module.|
|0x74984889||rshell||Relocates, parses and executes the final payload.|
|0x7b37e907||rshell64||64-bit version of rshell module.|
|0x3ee477f1||ti||Executed after the first stage. Performs code injection for other stages and modules.|
|0x2ab77db8||ti64||64-bit version of ti module.|
|0x4eace798||tinystub||Empty executable file, which is used for patching during the final payload execution process.|
|0xa1d724fc||tinyutilitymodule.dll||Overwrites the PE headers of a specified file with null bytes.|
|0x263596ba||tinyutilitymodule64.dll||64-bit version of tinyutilitymodule.dll module.|
|0x1ae7700a||Unknown||Unknown module. Not included in any of the observed binaries. Based on the analyzed code, we assess that it includes a file path along with an optional parameter. The current running file is copied into this new location and executed along with the specified parameter.|
|N/A||Main instrumentation shellcode||Shellcode injected into the specified target process from the ti module. This module is responsible for executing the final payload.|
Moreover, each module has a structure that holds information such as:
- Module name
- Module offset in the table
- Module size
Due to the quality of the code and because the rest of the structure fields are not being used, ThreatLabz was not able to identify the purpose for the rest of the structure members. However, ThreatLabz assesses that the following information might be included as well:
- Module timestamp
- Internal names (e.g., rLdr64 for the rshell module)
From the modules mentioned above, our analysis focused on the ti and the main instrumentation shellcode modules since these two implement the majority of the core functionality for HijackLoader.
The anti-analysis techniques are the same as presented in the previous section, but there are two notable differences:
- The developers have included the Heaven's gate technique.
- The process blocklist remains the same but the code behavior is different as can be seen in Table 3.
|avgsvc||Same as avastsvc|
|a2service||No behavioral code change.|
|wrsa||No behavioral code change.|
|msmpeng||No behavioral code change.|
The primary role of the ti module is to inject the main instrumentation module, which is responsible for loading the final stage.
The ti module executes the next stage by using one of the following methods:
- Re-executes the initial file from a new location and parameter (if the module with the CRC32 value 0x1ae7700a exists).
- Creates a new process (specified in the configuration), maps the hijacked file into it (e.g. mshtml), and injects the main instrumentation shellcode. In addition (depending on the configuration flags), it executes the FIXED module, which might be used later for code injection.
- HijackLoader might include an additional set of files, which can be used for DLL hijacking. In this case, it writes them to disk along with the encrypted payload (from stage 1) and executes the hijacked executable.
- Executes the ESLDR module, which injects the main instrumentation shellcode.
Main Instrumentation Module
The main instrumentation module contains the core functionality for loading and executing the final stage of the infection chain.
The anti-analysis techniques remain the same with the previous aforementioned stages. However, one key difference is the deployment of the AVDATA module. The AVDATA module contains a set of process names and if any of them are detected then the code behavior might change. The process names observed by ThreatLabz and their CRC32 values are presented in the table below.
|CRC32||PRODUCT NAME||PROCESS NAME|
|0xc0bfbba0||ESET Smart Security||ekrn.exe|
|0xc0fe273f||Symantec Event Manager||ccsvchst.exe|
|0x8e9e8add||AVG Internet Security||avgsvc.exe|
|0x923d5594||AVG Internet Security||avgui.exe|
|0x3a39ba4||Norton Internet Security||nis.exe|
|0xe981e279||Norton Internet Security||ns.exe|
|0x5f1c2fc2||Trend Micro Security||uiseagnt.exe|
|0xefba2118||McAfee Security Scan Plus||mcuicnt.exe|
|0xfeb42b97||Internet Security Essentials||vkise.exe|
|0x6274fa64||Comodo Internet Security||cis.exe|
|0x31c100e7||360 Safe Guard||zhudongfangyu.exe|
|0x219b199a||360 Total Security||360tray.exe|
Each process block in the AVDATA module has the following structure:
unsigned int CRC32; // CRC32 value of process.
unsigned char Execution_Type; // Code execution method for the final payload.
unsigned char LNK_Persistence_Flag; // Adds persistence with an LNK shortcut file.
unsigned char unknown; // Not used.
unsigned char unknown_2; // Not used.
int BITS_Persistence_Flag; // Adds persistence by creating a BITS job.
int unknown_3; // Not used.
int unknown_4; // Not used.
int Injection_Type; // Defines what code injection method to use.
int overwrite_pe_headers_with_junk_Flag; // Used during module deployment.
As described in the structure above, persistence on the compromised host is established via the following methods:
- Creation of a BITS job, which points to the executable file.
- Creation of a shortcut file (LNK) in the Windows Startup folder. The shortcut’s path is added in a new BITS job and points to the executable file.
Final payload decryption and execution
The embedded payload is decrypted using a bitwise XOR operation with the key being derived from the first 200 bytes. This can be easily represented in Python as follows:
enc_data = data[200:]
key = data[:200]
dec = bytearray()
for idx in range(0, len(enc_data), 4):
dec_int = struct.unpack("<L", enc_data[idx:idx+4]) ^ struct.unpack("<L",
key[idx%200:idx%200 + 4])
dec.extend(dec_int.to_bytes((dec_int .bit_length() + 7) // 8, byteorder='little'))
HijackLoader’s shellcode then proceeds with the injection or direct execution of the decrypted payload. The technique the shellcode uses depends on a number of different factors such as the payload’s file type and a flag, which is stored in the settings and indicates the injection method to use. In the table below, we describe each case along with a description of the action taken.
|DLL file type.||In the case of a DLL file type, the shellcode parses the PE file and leverages the ESLR module, which erases the shellcode data and executes directly the entry point of the DLL.|
|Code injection when the injection flag is set to 3 and PE relocation is required (Method 1).||
Creates a process of the FIXED module and writes to disk a file, which includes various information such as:
|Code injection when the injection flag is set to 3 and PE relocation is required (Method 2).||
|Code injection when the injection flag is set to 3 and no PE relocation is required (Method 1).||
The implementation is similar to the previous two cases. However, there are a few notable differences:
|Code injection when the injection flag is set to 3 and no PE relocation is required (Method 2).||Same code injection technique as with the previous case, but the data injection takes place with timing delays.|
|Code injection when the injection flag is set to 3 with a .NET PE file.||
|Code injection when the injection flag is set to 4.||
In summary, HijackLoader is a modular loader with evasion techniques, which provides a variety of loading options for malicious payloads. Moreover, it does not have any advanced features and the quality of the code is poor. However, considering the increasing popularity of HijackLoader, we expect code improvements and further usage from more threat actors, especially to fill the void left by Emotet and Qakbot.
In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community.
Zscaler’s multilayered cloud security platform detects indicators related to HijackLoader at various levels.
Indicators of Compromise (IOCs)
|Payload URL, which HijackLoader uses to load Danabot.|
|Payload URL, which HijackLoader uses to load RedLine stealer.|