HijackLoader Updates

Introduction

HijackLoader (a.k.a. IDAT Loader) is a malware loader initially spotted in 2023 that is capable of using a variety of modules for code injection and execution. It uses a modular architecture, a feature that most loaders do not have – which we discussed in a previous HijackLoader blog. ThreatLabz researchers recently analyzed a new HijackLoader sample that has updated evasion techniques. These enhancements aim to increase the malware’s stealthiness, thereby remaining undetected for longer periods of time. HijackLoader now includes modules to add an exclusion for Windows Defender Antivirus, bypass User Account Control (UAC), evade inline API hooking that is often used by security software for detection, and employ process hollowing.

In addition, HijackLoader’s delivery method involves the use of a PNG image, which is decrypted and parsed to load the next stage of the attack. ThreatLabz observed HijackLoader being used to drop multiple malware families, including Amadey, Lumma Stealer, Racoon Stealer v2, and Remcos RAT.

In this blog post, we discuss HijackLoader updates and provide a Python script to extract the malware configuration and modules from HijackLoader samples. Additionally, we delve into the malware families deployed by HijackLoader from March 2024 to April 2024.

Key Takeaways

• HijackLoader is a modular malware loader that is used to deliver second stage payloads including Amadey, Lumma Stealer, Racoon Stealer v2, and Remcos RAT.
• HijackLoader decrypts and parses a PNG image to load the next stage.
• HijackLoader now contains the following new modules: modCreateProcess, modCreateProcess64, WDDATA, modUAC, modUAC64, modWriteFile, and modWriteFile64.
• HijackLoader has additional features like dynamic API resolution, blocklist process checking, and user mode hook evasion using Heaven's Gate.
• ThreatLabz researchers created a Python script to decrypt and decompress the second stage and extract all HijackLoader modules.

Technical Analysis

The following sections focus on the new changes to HijackLoader.

First stage

The purpose of the loader’s first stage is to decrypt and decompress the HijackLoader modules, including the second stage (ti64 module for 64-bit processes and ti module for 32-bit processes), and execute the second stage.

The first stage resolves the APIs dynamically by walking the process environment block (PEB) and parsing the Portable Executable (PE) header. The loader uses the SDBM hashing algorithm below to resolve APIs.

  def SDBMHash(apiName):
     finalHash = 0
     for i in apiName:
          finalHash = (finalHash*0x1003F) & 0xFFFFFFFF
          finalHash = (finalHash + ord(i)) & 0xFFFFFFFF
     return finalHash

Using the SDBM hash algorithm above, the loader resolves the WinHTTP APIs to check for an internet connection. This is achieved with the following URL:

https://apache.org/logos/res/incubator/default.png

The loader repeats this process until there is an internet connection. After that, HijackLoader decrypts embedded shellcode by performing a simple addition operation with a key. It then sets the execute permission using VirtualProtect for the decrypted shellcode and calls the start address of the shellcode.

Blocklist processes

The shellcode uses the SDBM hash algorithm again to resolve additional APIs. After that, the shellcode uses the RtlGetNativeSystemInfo API to check for blocklisted processes running on the system. In previous versions of HijackLoader, the loader checked for five processes related to antivirus applications. Now, the code only checks for two processes.

The names of current running processes are converted to lowercase letters and the SDBM hashing algorithm is compared with the hashes of the two processes. If these values match, execution is delayed using the NtDelayExecution API. Information for the two blocklisted processes can be found in the table below.

Table 1: Processes blocklisted by HijackLoader.

Note that the AVG process was also previously blocklisted by earlier versions of HijackLoader.

Second stage loading process

There are two methods that HijackLoader uses to load the second stage, both of which are embedded in the malware’s configuration. HijackLoader retrieves a DWORD from the configuration at offset 0x110 and XOR’s the value with a DWORD from the configuration at offset 0x28. Let's refer to the result of this XOR as the value “a”.

The malware loads a copy of itself into memory using GlobalAlloc and ReadFile. Then it reads a DWORD from the configuration at offset 0xC and adds this value to the address where the malware file was loaded into memory, and then reads a DWORD from this address. Let's call this value “b”. 

• If “a” and “b” do not match, a PNG file is downloaded and used to load the second stage. 
• If “a” and “b” match, an embedded PNG is used to load the second stage.

The image below shows an example of an embedded PNG when rendered using an image viewer.

Figure 1: An embedded PNG image containing the encrypted modules used by HijackLoader in a PNG viewer.

PNG payload

The screenshot below displays the decompiled HijackLoader code that checks whether the PNG is embedded within the file or if it needs to be downloaded separately.

Figure 2: The decompiled output of HijackLoader to find if the PNG is embedded or if it should be downloaded.

If the PNG is embedded, the malware starts searching for the PNG image with the following bytes: 49 44 41 54 C6 A5 79 EA. This contains the IDAT header 49 44 41 54 and magic header C6 A5 79 EA.  

The logic replicated below in Python shows how the malware finds the IDAT header followed by the magic header.

checkFlag = 0
with open(malware_file, "rb") as input_file:
 input_file.seek(0)
 file = input_file.read()
 offset = 0
 
 try:
  resultOffsetNextByte = file.index(b'\x49\x44\x41\x54\xC6\xA5\x79\xEA', offset + 1)
  print("Found Corect PNG Image")
  checkFlag = 1     
 except ValueError:
   print('Could not Find PNG with Correct Header')

The screenshot below shows the IDAT header followed by the magic header C6 A5 79 EA.

Figure 3: The format of the IDAT header.

If the PNG needs to be downloaded, the URL is decrypted from the configuration using a simple XOR cipher. Following that, the WinHTTP library is utilized to download the PNG from the decrypted URL.

There are multiple encrypted blobs in the PNG file. Each encrypted blob is stored in the format Blob size:IDAT header. Each of the encrypted blobs can be found by searching for the IDAT header. The size of each encrypted blob is parsed and data of this size following the header is appended to a new memory address. When the total size is reached, the encrypted data is decrypted using a simple XOR cipher with the key: 32 A3 49 B3 (which is a DWORD that follows the MAGIC Header). Then, the decrypted blob is decompressed using the LZNT1 algorithm.

This decompressed data contains the modules and configurations used to load the second stage. The offset at 0xF4 of the decompressed data contains a DLL name (in this specific case pla.dll) that is loaded into memory. The modules are then parsed to locate the ti module (by name) using the SDBM hashing algorithm. Then, the ti module is copied to the DLL’s BaseOfCode field and is executed.

The screenshot below shows the decompiled output for the injection of the second stage.

Figure 4: The decompiled output for the injection of the second stage.

Second stage

The main purpose of the second stage is to inject the main instrumentation module. To increase stealthiness, the second stage of the loader employs more anti-analysis techniques using multiple modules. The modules have features that include a UAC bypass, Windows Defender Antivirus exclusion, using Heaven's Gate to execute x64 direct syscalls, and process hollowing.

Modules

The malware developers have continued to create new modules. The table below shows the HijackLoader modules added since our last blog.

Table 2: The new modules added to HijackLoader.

ti module

The ti module is the first module called by the first stage. It dynamically resolves APIs by walking the PEB and parsing PE headers using CRC-32 as a hashing algorithm. It then checks if a mutex, whose name is resolved using CRC-32 hashing, is present on the system. If the mutex is present, the process terminates; otherwise, it continues execution.

Next, the ti module retrieves the environment variable at offset 0x45 from the decompressed data (%APPDATA% in our case), expands it, and checks if the current process is running under this directory. If not, it copies itself to this location, executes the copied file, and terminates itself.

Next, the loader uses the Heaven's Gate technique to bypass user mode hooks – this is further explored in the next section.

Bypass user mode hooks for injection

To bypass user mode hooks, the loader uses a combination of Heaven's Gate and a direct syscall technique. The screenshot below shows HijackLoader employing the Heaven’s Gate technique to execute an x64 direct syscall.

Figure 5: HijackLoader using Heaven’s Gate to execute a x64 direct syscall.

Subsequently, the execution is returned to the 32-bit code. Following this, the next stage is injected. The process designated for injection is stored in the decompressed data at offset 0x90 (%windir%\SysWOW64\cmd.exe in our specific case). The cmd.exe is created as a child process, and the main instrumentation module is injected using process hollowing. The main instrumentation module uses the same process mentioned in our previous blog to decrypt the final payload and execute it.

Malware Delivery

In March 2024, ThreatLabz researchers analyzed around 50 samples of HijackLoader with an embedded PNG to identify which families are currently distributed by HijackLoader.

HijackLoader was used to distribute the following malware:

• Amadey: Trojan that collects data about the victim’s system and is capable of loading other malware. 
  • Amadey emerged as the most prevalent family delivered by HijackLoader, comprising 52.9% of observed instances—a notable margin above other malware families. 
• Lumma Stealer (aka LummaC2 Stealer): Information stealer that steals data from items like cryptocurrency wallets, steam accounts, KeePass, FileZilla, and browser extensions.
• Racoon Stealer v2: Information stealer that steals data such as saved passwords, cookies, auto-fill data, and cryptocurrency wallets.
• Remcos: Remote Access Trojan (RAT) used to gain backdoor access to a victim’s system.
• Meta Stealer: Information stealer that targets browsers, cryptocurrency wallets, wallet extensions and steam accounts, and shares many similarities with Redline Stealer.
• Rhadamanthys: Information stealer that targets wallets, emails, note-keeping apps, and messengers.

The figure below illustrates the distribution of malware families delivered by HijackLoader. 

Figure 6: A pie chart showing the different malware families distributed by HijackLoader.

Conclusion

HijackLoader has emerged as a significant threat, delivering multiple malware families such as Amadey, Lumma Stealer, Racoon Stealer v2, and Remcos RAT. Among these, Amadey has been the most commonly delivered family by HijackLoader. The loading of the second stage involves the use of an embedded PNG image or PNG image downloaded from the web, which is decrypted and parsed to load the ti module. Additionally, new modules have been integrated into HijackLoader, enhancing its capabilities and making it even more robust.

To assist the research community in analyzing HijackLoader, we have created a Python script that is available in our GitHub repository. The script enables the decryption and decompression of the second stage, providing access to HijackLoader’s modules.

ThreatLabz is actively monitoring this campaign and ensuring that Zscaler customers are protected from cybersecurity threats.

Zscaler Coverage

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

Figure 7: Zscaler Cloud Sandbox report

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
• W32/ABRisk.GXSZ-4158
• W64/ABRisk.UCRB-0609
• Win32.PWS.Lumma
• Win32.Trojan.Lummastealer.XT

Indicators Of Compromise (IOCs)

Host indicators

Network indicators

MITRE ATT&CK Techniques

Appendix

Visit our GitHub repository to access the Python script to aid in your malware analysis.