Zscaler enttarnt HijackLoader – Zscaler unmasks HijackLoader

Der Loader startet mit der Ausführung einer modifizierten Funktion der Windows C Runtime (CRT). Während seiner Initialisierungsphase stellt der Loader fest, ob die endgültige Nutzlast in der Binärdatei eingebettet ist oder ob er sie von einem externen Server herunterladen muss. Dazu enthält er eine verschlüsselte Konfiguration. Darüber hinaus werden eine Reihe von Umgehungstechniken eingesetzt, um einer Entdeckung zu entgehen. Dazu gehören beispielsweise das dynamische Laden von Windows-API-Funktionen unter Ausnutzung einer benutzerdefinierten API-Hashing-Technik oder die Durchführung eines HTTP-Verbindungstests mit einer legitimen Website (z. B. mozilla.org). Wenn keine Verbindung hergestellt werden kann, bricht HijackLoader die Ausführung ab und befindet sich in einer Endlosschleife, bis eine Verbindung hergestellt werden kann. Zusätzlich werden in der ersten Stufe eine Reihe von laufenden Prozessen auf Sicherheitslösungen überprüft. Je nachdem, welche Prozesse gefunden werden, führt der Loader unterschiedliche Verzögerungsfunktionen aus.

HijackLoader lokalisiert die Payload der zweiten Stufe (d. h. das ti-Modul) schrittweise. Dazu analysiert er den entschlüsselten Konfigurationsblock, den er in der Initialisierungsphase erhalten hat. Dann sucht HijackLoader die verschlüsselte Payload-URL und entschlüsselt sie mit einer bitwise XOR-Operation. Anschließend lädt er die Payload herunter und prüft sie auf das Vorhandensein der (im Konfigurationsblock enthaltenen) Signatur in den Daten. Wenn die Validierung erfolgreich ist, wird die Payload auf die Festplatte geschrieben. Nun sucht der Loader anhand des zweiten Markers nach verschlüsselten Blobs. Jeder Marker steht für den Beginn eines verschlüsselten Blobs zusammen mit der Größe des Blobs (die vor jedem Auftreten gespeichert wird). Außerdem befindet sich der XOR-Schlüssel hinter dem Offset des ersten verschlüsselten Blobs. Sobald alle verschlüsselten Blobs extrahiert worden sind, werden sie miteinander verkettet und mit dem XOR-Schlüssel entschlüsselt. Schließlich wird die entschlüsselte Payload mit dem LZNT1-Algorithmus dekomprimiert.

Danach werden verschiedenste Module heruntergeladen. Am Ende wird die eingebettete Payload mit einer bitwise XOR-Operation entschlüsselt, wobei der Schlüssel aus den ersten 200 Bytes abgeleitet wird. Der Shellcode von HijackLoader fährt dann mit der Injektion oder direkten Ausführung der entschlüsselten Nutzdaten fort. Welche Technik der Shellcode verwendet, hängt von verschiedenen Faktoren ab, z. B. vom Dateityp der Payload und einem „Flag“, der in den Einstellungen gespeichert ist und die zu verwendende Injektionsmethode angibt.

Zusammenfassend lässt sich sagen, dass HijackLoader ein modularer Loader mit Umgehungstechniken ist, der eine Vielzahl von Ladeoptionen für bösartige Payloads bietet. Auch wenn die Qualität des Codes schlecht ist, warnen die Sicherheitsforscher von Zscaler angesichts der zunehmenden Beliebtheit vor dem neuen Loader. Sie erwarten Code-Verbesserungen und eine weitere Nutzung durch mehr Bedrohungsakteure, insbesondere um die von Emotet und Qakbot hinterlassene Lücke zu füllen. Die Zscaler Cloud Sandbox erkennt HijackLoader anhand unterschiedlichster Indikatoren und blockiert die Aktivitäten.

The loader starts by executing a modified Windows C Runtime (CRT) function. During its initialization phase, the loader determines whether the final payload is embedded in the binary or whether it needs to download it from an external server. For this purpose, it includes an encrypted configuration. In addition, a number of evasion techniques are used to avoid detection. These include, for example, dynamically loading Windows API functions by exploiting a custom API hashing technique or performing an HTTP connection test with a legitimate website (e.g. mozilla.org). If no connection can be established, HijackLoader aborts execution and is in an infinite loop until a connection can be established. In addition, the first stage checks a number of running processes for security solutions. Depending on which processes are found, the loader performs different delay functions.

HijackLoader locates the second-stage payload (i.e., the ti module) step by step. To do this, it analyzes the decrypted configuration block it received during the initialization phase. Then, HijackLoader looks for the encrypted payload URL and decrypts it using a bitwise XOR operation. It then downloads the payload and validates it for the presence of the signature (contained in the configuration block) in the data. If the validation is successful, the payload is written to disk. Now the loader searches for encrypted blobs based on the second marker. Each marker represents the beginning of an encrypted blob along with the size of the blob (which is stored before each occurrence). Also, 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 using the XOR key. Finally, the decrypted payload is decompressed using the LZNT1 algorithm.

After that, a wide variety of modules are downloaded. At the end, the embedded payload is decrypted with a bitwise XOR operation, deriving the key from the first 200 bytes. The HijackLoader shellcode then proceeds to inject or directly execute the decrypted payload. Which technique the shellcode uses depends on several factors, such as the file type of the payload and a „flag“ stored in the settings that specifies the injection method to use.

In summary, HijackLoader is a modular loader with bypass techniques that provides a variety of loading options for malicious payloads. Even though the quality of the code is poor, Zscaler security researchers warn against the new loader given its increasing popularity. They expect code improvements and continued use by more threat actors, especially to fill the hole left by Emotet and Qakbot. The Zscaler Cloud Sandbox detects HijackLoaders based on a wide variety of indicators and blocks activity.