A Comprehensive Analysis of the HijackLoader ——Analysis of the Typical Loader Family Series IV

Introduction to the Loader Series Analysis Report

With the development of network attack technology, the malicious code loader is becoming the key component of malicious code execution. Such loaders are a malicious tool used to load various malicious code into an infected system and are typically responsible for bypassing system security protections, injecting malicious code into memory and executing, Lay the foundation for the subsequent deployment of malicious code of the Trojan horse type. The core functions of the loader include persistence mechanisms, fileless memory execution, and multi-level avoidance techniques.

Antiy CERT has been tracking the reserves of typical malicious loader families over the last few years, aggregating information into special reports and continuing to track new popular loader families. This project will focus on the technical details of the loader, and dig into its core functions in the attack chain, including its obfuscation technology, encryption mechanism and injection strategy. In addition, we will constantly improve our security product capability, take effective technical solutions to further improve that recognition rate and accuracy rate of loader, and help user organizations to identify and prevent potential threats in advance.

1.Overview

Hijackloader is a modular design malicious code loader that was first discovered in July 2023 and was used to deliver families of malicious code such as Stealc, Lumma Stealer, Danabot, RedLine Stealer. The HijackLoader has strong concealment, and the loader detects anti-virus programs such as Kaspersky, Bitdefender and McAfee. According to the different detection results, different strategies are implemented to avoid the threat detection of the anti-virus program, which makes it a great threat to the security of the user system.

In order to avoid threat detection, HijackLoader also uses two anti-hooking method, where HijackLoader will manually load an ntdll for calling sensitive functions, and HijackLoader will also try to remove the hook from the ntdll to call commonly used functions. And the anti-hooking means will also be performed in the delivered target payload. In addition, in order to reverse that virtual machine, the HijackLoader can detect the virtual machine flag by calculating the execution speed of the code, and comprehensively judge the basic information of the compute, so as to avoid running in the virtual environment. In terms of function, HijackLoader only has the function of persisting and loading the target payload, but uses a lot of code in it to avoid the detection of anti-virus software. Each stage in the HijackLoader has multiple implementations, each of which hides different behavior characteristics, and the HijackLoader will run different schemes according to different anti-virus software.

See Antivirus Encyclopedia [1] for details of this loader.

Figure 1-1 Long press the identification QR code to view details of the HijackLoader‑

2.Analysis of the Survival Technology of the HijackLoader

2.1 Confusing technical analysis

Hijackloader has two hiding ways to hide its configuration files as pictures. The first way is to hide the configuration file as pixels of the picture and determine the starting position of the configuration file by a specific sequence.

Figure 2-1: How to find the configuration file start sequence

The second method is to load the image from the resource file, obtain the additional data from the end of the image, and then decrypt and decompress the additional data after splicing to obtain the configuration file.

Figure 2-2 The second decryption configuration file code of the HijackLoader

2.2 Analysis of injection technology

Although HijackLoader has logic where many parameters affect injection, it can be broadly divided into two situations: Running the load in its own process and running the load in other processes. When HijackLoader decides to run the payload in another process, the target process is injected with an rshell module to assist in the work of running the payload.

Figure 2-3 Flow chart of code injection

2.3 Analysis of Persistence Technology

Hijackloader has two types of persistence, one for persistence by creating shortcuts in the boot directory and the other for creating services. There are also two different triggers that can be set when persistence is achieved by creating a service: A user login-time trigger and a fixed interval trigger.

Figure 2-4 HijackLoader partial persistence logic

2.4        Anti-virtual machine analysis

The anti-virtual machine technology of HijackLoader is divided into three aspects: Detecting the execution speed of cpuid instructions, detecting the specific fields of cpuid instructions, and detecting the computer basic information such as the computer memory and the number of CPUs. Hijackloader will stop running when any of these conditions are not met.

Figure 2-5 HijackLoader detecting virtual machine information ‑

3.Attack process

The HijackLoader can be broadly divided into four stages. In that first phase, the HijackLoader decrypt the shellcode, loads the section in. text into itself, and execute. In the second stage, HijackLoader is responsible for decrypting the configuration file, extracting the ti64 module from it and executing it. In the third phase, HijackLoader will de-hook the ntdll and manually load a copy of the ntdll through the MapViewOfFile function to execute some sensitive functions. In the third stage, HijackLoader will also detect the virtual machine in a variety of ways, and stop the operation if it is found to be running in the virtual environment. Then HijackLoader will inject shellcode into the Windows system tool to execute the fourth phase of the code. In the fourth phase, HijackLoader will perform the persistence operation and complete the delivery of the target payload.

Figure 3-1 HijackLoader Loading Flow

4.Sample analysis

4.1 Sample labels

Table 4-1 HijackLoader Sample Tags

Virus name Trojan / Win32.HijackLoader
Md5 433ea562e46151b403a3b0f17e9a6c70
Processor architecture X64
File size 318 KB (326,302 bytes)
File format Binexecute / Microsoft.EXE [: X64]
Time stamp 2024-11-06 03: 12: 47
Digital signature Lamantine Software a.s. (digital signature is invalid)
Shell type None
Compiled Language Embarcadero Delphi (10.4 Sydney) [Professional]
Vt First Upload Time 2024-12-04 14: 37: 28
Vt test result 48 / 71

4.2 The first phase of the HijackLoader loader

In that first phase, the HijackLoader decrypt the second phase payload and overlays it in the first phase of the HijackLoader code snippet, then call the second phase code entry point for execution.

Figure 4-1 HijackLoader decrypts and executes the second stage of code

4.3 Phase II of the HijackLoader Loader Loader

In that second phase, the HijackLoader detect whether AVG and Avast exist in the system, and if so, the execution of the subsequent logic is delayed for 30 seconds.

Figure 4-2 HijackLoader detects an AV program and delays execution

Then HijackLoader will load the configuration file based on the first phase parameters.

Figure 4-3 HijackLoader Selection of configuration file loading method

If mode 1 is selected for decryption, HijackLoader will search for a PNG file of appropriate size from the file and decrypt it.

Figure 4-4 A HijackLoader search for a picture containing a configuration file

The HijackLoader then takes the pixel’s RGB information and saves it as a byte array. Hijackloader finds the starting position of the configuration file by calculating the CRC-32 value of the sequence fragment in the byte array, and obtains the configuration file size and the exclusive-OR key, and decrypts the configuration.

Figure 4-5 Decrypting the configuration file using HijackLoader Mode 1

When the mode 2 is used to decrypt the picture data, the HijackLoader searches the picture sequence, obtains the configuration file from the attached data at the end of the picture, then decrypts the file, and then decompresses the file using the LZNT1 algorithm.

Figure 4-6 Decrypting the configuration file using HijackLoader Mode 2

When the HijackLoader downloads the configuration file from the network, the HijackLoader will read the URL array from the configuration and download the data, and select to decrypt the configuration using mode 1 or mode 2 according to the content of the data.

Figure 4-7 HijackLoader download configuration file

Hijackloader carries the following payloads and modules in the configuration file:

Table 4-2 List of load carried by HijackLoader

Load designation Load function
Avdata There are various anti-virus software hashing and response methods.
Esal The fourth phase of the HijackLoader cleans up the HijackLoader data usage when the current process posts the final payload.
Esal64 The 64-bit version of ESAL.
Esldr In that third phase of the HijackLoader, it was responsible for inject the fourth phase shellcode into the Windows system tool for use.
Esldr64 A 64-bit version of the ESLDR.
Eswr In that fourth phase of the HijackLoader, the HijackLoader data is clean up when the target payload is delivered in other process.
Eswr64 The 64-bit version of ESWR.
Fixed Vmware – related 32 -bit white files can be used as the program to be injected when delivering the final payload.
Launcherldr64 Is responsible for decrypting configuration files that are temporarily stored on the hard disk, only in 64-bit versions and are not being used correctly in the current sample.
Modcreateprocess Responsible for creating the child process, when creating the child process, the HijackLoader code will be temporarily encrypted to avoid detection.
Modcreateprocess64 A 64-bit version of modCreateProcess.
Modtask Responsible for creating the scheduled task, temporarily encrypting the HijackLoader code and calling the TinycallProxy module to combat stack backtracking when creating the scheduled task.
Modtask64 The 64-bit version of modTask.
Moduac The UAC extracts the relevant modules, which are not used in this sample.
Moduac64 A 64-bit version of modUAC.
Modwritefile Write file related modules that are not used in this sample.
Modwritefile64 The 64-bit version of modWriteFile.
Rshell The module that assists in delivering the final payload in the process being injected may perform an anti-hook operation on the final payload.
Rshell 64 The 64 – bit version of the rshell.
Ti Responsible for the second stage logic of HijackLoader.
Ti64 64-bit version of ti.
Tinycallproxy Responsible for indirect function calls, with anti- stack backtracking function.
Tinycall Proxy64 A 64-bit version of TinycallProxy.
Tinystub A program that does not have any functionality to assist in injecting an rshell to circumvent detection.
Tinystub64 A 64-bit version of tinystub.
Tinyutilitymodule.dll Fill specific data with 0, which is not used in this sample.
Tinyutilitymodule64.dll A 64-bit version of tinyutilitymodule .dll.
Sm Specifies the DLL used by the TinycallProxy to disguise the call address against stack tracebacks.
Bdata A white program, used only for running.
Mutex The mutex created by the program.
Custominject The program that is injected when delivering the final payload.
Custominjectpath The path of storing CUSTOMINJECT.
Antivm Anti-virtual machine related configuration.

When HijackLoader decrypts the configuration file, it searches for a module named ti64 from the configuration file, overwrites the ti64 module data to the shell32 code segment, and calls the ti64 module to enter the third stage of HijackLoader.

Figure 4-8 HijackLoader Running ti64 Module

4.4 The third stage of the HijackLoader

In the third stage of HijackLoader, HijackLoader will search for the system function beginning with Zw from the ntdll, and record the system call number, function name and function address for subsequent calls.

Figure 4-9 HijackLoader Search and Save System Call Number

Hijackloader loads the ntdll through the CreateFileMappingW and MapViewOfFile functions, and calls some of the functions through the new ntdll to prevent sensitive functions from being hooked.

Figure 4-10: New ntdll loaded by HijackLoader

Hijackloader will also perform unhook operation on the original ntdll. first, HijackLoader will load an ntdll in the memory, but HijackLoader will redirect it using the original ntdll base address in the system. In order to make that new ntdll be consistent with the original ntdll of the system in the memory layout.

Figure 4-11: Hijackloader Redirects the ntdll loaded on the hand

Then HijackLoader will compare whether the ntdll function loaded manually is the same as the original ntdll function, and if it is different, it will be covered to realize unhook operation.

Figure 4-12 HijackLoader Unhook operation on the original ntdll

Hijackloader will read the data in the configuration file ANTIVM to detect the virtual machine and avoid running in the virtual machine.

Figure 4-13: Hijackloader Detection of Virtual Machine

Hijackloader searches for the MUTEX configuration file from the payload decrypted in the second phase and creates mutexes based on the configuration.

Figure 4-14 HijackLoader Creating Mutex

If there is a specific configuration, that HijackLoader use the modUAC module to initiate the authorization.

Figure 4-15 HijackLoader detects the process permission and attempts to grant it

If a particular configuration exists, HijackLoader will hide the injected process by creating a new desktop.

Figure 4-16 HijackLoader creating a new desktop hide is injected into the process

Then HijackLoader will select the execution mode of the subsequent code according to the configuration file. If that configuration file has a specific flag and no Kaspersky is detect, the HijackLoader execute the fourth stage logic directly in the current process.

Figure 4-17 HijackLoader executes the subsequent logic in the current process

If the above conditions are not met, then HijackLoader will inject shellcode into the Windows system tool more .com to execute the fourth phase.

Figure 4-18 Injection of HijackLoader into Windows System Tools, more .com

If a specific configuration file exists and Avast or AVG is present in the system, HijackLoader will inject shellcode into the more .com process by hijacking the main process through the ESLDR64 module, executing the fourth phase.

Figure 4-19ESLDR64 Injection shellcode into the target program

If that above condition is still not met, HijackLoader inject shellcode into more .com in the current module to execute the fourth phase of the logic. After the injection is complete, HijackLoader writes a character to the more .com pipeline, causing it to exit the blocking state caused by reading the standard input stream, in order to run shellcode.

Figure 4-20 HijackLoader Executing ShellCode

Hijackloader has the same unhook process as the ti module when executing shellcode. In addition, HijackLoader suspends other threads in its own program based on the configuration file settings. The fourth stage of the HijackLoader logic is then executed in shellcode.

Figure 4-21 HijackLoader suspends other threads in its own program

4.5 Stage 4 of the HijackLoader

In the fourth phase, HijackLoader detects the antivirus programs running on the system and, depending on their configuration, affects the behavior of subsequent persistence and injection. The anti-virus procedures for known detection are as follows:

Table 4-3 Antivirus Program for HijackLoader Detection

Then HijackLoader will determine whether to move its own path according to the configuration, and if it moves itself, it will try to copy using BackgroundCopyManager and CopyFileW.

Figure 4-22 HijackLoader moves itself to the target path

Then HijackLoader will choose the persistence method and try to achieve persistence by creating a service or by creating a shortcut in the boot directory. Finally, HijackLoader will perform the self-delete behavior according to the configuration.

Figure 4-23 HijackLoader persistence operation

Hijackloader calls the modTask module when creating service implementation persistence. The module can be triggered when the user logs in according to the configuration file settings.

Figure 4-24 Modtask Module Creation of Scheduled Task

It is also possible to trigger scheduled tasks at fixed intervals according to the configuration file.

Figure 4-25 Another implementation of the creation schedule task for the modTask module

When this module calls sensitive functions such as CoInitialize and CoCreateInstance, it will call TinycallProxy module to resist stack backtracking.

Figure 4-26: The modTask module calls the TinycallProxy module to combat stack backtracking

Tinycallproxy module is used to call the object function indirectly. Hijackloader overwrites the TinycalProxy module into the code segment of a dll, and passes the called object function and parameters into the TinycalProxy module, and the TinycalProxy module calls the object function.

Figure 4-27 Calling the target function by the TinycallProxy module

In calling the target function, the TinycallProxy disguises the return address of the function against stack backtracking.

Figure 4-28TinyCallProxy Module Overlay Function Return Address Anti-stack-traceback ‑

After the persistence, the HijackLoader decrypts and runs the payload to be delivered, where there are three ways to run the payload depending on the payload type and configuration.

(1) Target load delivery mode 1

When the payload is a dll, HijackLoader loads a target dll according to the configuration or uses the default msi.dll, whose address space is used to write to the payload to be posted. Then HijackLoader will destroy the IMAGE _ SECTION _ HEADER of the payload as needed according to the installed anti-virus software, so as to interfere with the anti-virus program to detect it.

Figure 4-29 HijackLoader destroys the IMAGE _ SECTION _ HEADER structure

The dll entry point is then called to run the target payload.

Figure 4-30 HijackLoader Running the target payload to be delivered

When the target program is exe and the value indicating the delivery method in the configuration file is less than 3, the payload runs in much the same way as the dll, but there is a slight difference at the point of entry of the calling program.

In this case, HijackLoader will first modify the ImageBase in the payload OptionalHeader and the ImageBaseAddress in the PEB, and assign it to the base address where the actual payload is located.

Figure 4-31 HijackLoader Modify Program Base Address Information

The entry point of the payload is then cleared by the ESAL module of the HijackLoader data and called.

Figure 4-32 The ESAL module cleans up the HijackLoader code and calls the target payload entry point

(2) the target load delivery mode 2

When the value indicating the delivery method in the configuration file is equal to 3, HijackLoader selects the target program for injection according to the following rule. When you have specific antivirus software, HijackLoader creates the same process as the current one to execute the target payload. Otherwise, if there is a CUSTOMINJECT file in the configuration file, then HijackLoader creates CUSTOMINJECT as the process that executes the target payload. Otherwise, if the target payload is. net program, then HijackLoader selects MSBuild. exe as the process that executes the target payload according to the. net version. Otherwise, if the target payload is a 32 -bit process, HijackLoader extracts the FIXED program from the configuration file as the process executing the target payload. Otherwise, HijackLoader uses explorer. exe as the process that executes the target payload.

Figure 4-33 HijackLoader selecting injection target

Among them, FIXED is a VMware related application with a valid digital signature.

Figure 4-34 FIXED ED procedure for injection with HijackLoader

And CUSTOMINJECT is an application program related to AutoIt, and it also has a valid digital signature.

Figure 4-35 CUSTOMINJECT routine for injection with HijackLoader

Then HijackLoader can load the rshell module and the target payload into the target process in a number of ways, and run the target payload through the rshell module.

If HijackLoader injects both the target payload and the rshell into the target program, the rshell simply unhook and then calls the payload entry point to run the target payload.

Figure 4-36rshell module call target payload entry point

Otherwise, HijackLoader simply injects the rshell and reads the configuration file through the rshell, from which it loads and runs the target payload.

Figure 4-37 The rshell module loads and runs the final payload

When the target payload and rshell are both injected into the target program by the HijackLoader, the HijackLoader has three injection means:

  • Add rshell to the target payload’s dat section and write it to the hard disk, map it into the target process’s memory through ZwCreateSection and ZwMapViewOfSection, and finally run the payload through rshell and delete the file through transaction rollback.

Figure 4-38 HijackLoader maps the rshell into memory as part of the target payload

  • The target payload is mapped into memory, and then the rshell is written to the target process memory using ZwWriteVirtual Memory.

Figure 4-39 HijackLoader writes the rshell and payload to memory separately

  • Writes payload and rshell to target process memory directly using ZwWriteVirtualMemory.

Figure 4-40 HijackLoader writes the rshell and payload directly to memory

Hijackloader still has two means to communicate with the rshell:

  • The parameter is written into a temporary file, and the file path is passed through a global variable.

Figure 4-41 HijackLoader uses temporary files to pass parameters to the rshell

  • Parameters are passed to the rshell by patch rshell code.

Figure 4-42 A HijackLoader parameter passing through the patch rshell

After code injection and argument passing, HijackLoader still has two ways to run the rshell:

  • Run the rshell thread directly with ZwResumeThread.
  • The rshell is run indirectly through the ESWR module, which also does the cleaning of the HijackLoader when the rshell is run through the ESWR module.

Figure 4-43 ESWR Module Running rshell

After executing the rshell, HijackLoader can, according to the configuration, populate the PE header of the process with random data to interfere with the detection of the anti-virus program.

Figure 4-44 HijackLoader Overwriting Process PE Header

(3) Delivery method of target load 3

When the value indicating the delivery method in the configuration file is equal to 4, the HijackLoader will first manually load the target payload in the current process, and then copy it to the target process to run.

Figure 4-45 Loading Load of HijackLoader Usage Mode 4

Finally, the payload of the delivery is determined as Lumma Stealer based on the URL string constructed by the runtime.

Figure 4-46 Lumma Stealer Memory dump data

5.IoCs

IoCs
433ea562e46151b403a3b0f17e9a6c70
437be5fdecda6a594832bca890a384f5
0925a949c9ba0b37270fad920e9b8af0
C23ff523318cbc80e57db4ac18e6839b
85916a2a3a4f031d9b9d160a36c4193f
7810468d24fd195d88306ecb25a91b50
F23c4fdaf25912b6c7242745b5e19fac
Aab45679f168655475ec95961c2ac816
D6f152b0fcd53aa4970c1fd0ecea9220
C432241b9d5094abada43976c63d6a45
34f3f146e0f0804986079af7cff09f3d
0610ada475cf5750e08d8d9f55ba5a9e
Ce465fe573686280a39e3b255598e479
F9bdad57e46c123bd66df2201e8a2335
8df1b4bf9c929c6bf55ed2b740d48b12
2d23793ca35c2481b716cd97507f1be5
Fdc2c1e36b068191037b79b8f3b07b63
62c3d91214f27b3ba8bf6d0e2aa39ff1
7c3129e457dba8304b0b4cf7f042f0c2
87359226c8358019fef4ac53f4355431
684da5a9048014e342fa73fd4a9c87a1
27f65f518279eabd674cda430f181372
9a4fd7b2f77f6e2f17df74a038f9ed49

6.Att&CK Mapping Map of Samples

Figure 6-1 Mapping of Technical Features to ATT & CK

Specific ATT & CK technical behavior description table:

Table 6-1 ATT & CK Technical Behavior Description Table

Att & CK stages / categories

Specific behavior

Notes

Persistence

Use automatic startup to perform booting or logging

Hijackloader implements persistence by creating shortcuts in the start directory

Utilization of planned tasks / jobs

Hijackloader implements persistence by creating services

Defensive evasion

Circumventing the debugger

Hijackloader unhooks ntdll

Hijackloader calls sensitive functions using the ntdll loaded by MapViewOfFile

Concealment

Hijackloader delays execution for a period of time when specific antivirus software exists

Hijackloader has a variety of writes that perform the ultimate payload manner to circumvent detection

Hijackloader fights stack backtracking through the TinycallProxy module

Remove beacons

After HijackLoader injection, the PE header can be destroyed to avoid detection

Hijackloader injection can destroy the node table to avoid detection

Hijackloader cleans its own memory after execution

Confusion of document information

Hijackloader stores configuration files disguised as pictures

Virtualization / Sandbox Escape

Hijackloader detects virtual machines

7.Antiy IEP helps users defend against loader threats

After testing, the terminal security products of Antiy IEP, relying on Antiy’s self-developed threat detection engine and core-level active defense capability, can effectively detect, kill and defend the virus samples found this time.

Antiy IEP can monitor the local disk in real time and automatically detect the virus of new files. In response to this threat, when a user stores the HijackLoader loader locally through receiving email attachments, WeChat transmission, network downloading, etc., IEP will immediately alert the virus and clear malicious files. Prevent the terminal from being attacked by the user boot file.

Figure 7-1 When a virus is found, the first time a virus is captured and an alarm is sent

In addition, IEP can also discover suspicious start item creation behavior through active defense function, and block the behavior of the program during the persistence phase to prevent the subsequent malicious attack action.

Figure 7-2 Immediately Intercept when Abnormal Startup Item Creation Behavior is Discovered

IEP also provides a unified management platform for users, through which administrators can view details of threats within the network in a centralized manner and handle them in batches, thus improving the efficiency of terminal security operation and maintenance.

Figure 7-3 The IEP Management Center assists the administrator to realize efficient terminal security management

Appendix I: Antiy LanDi VILLM (Virus Inspection Large Language Model)

Antiy LanDi VILLM can carry out automatic analysis on the samples. part of the analysis contents are as follows:

文本框: Judgment conclusion:
Based on the provided log, the analysis tool determines that the file is Trojan. Win32.spybind [FakeAV], which is a Trojan horse disguised as a system library. The accuracy of the result is high, and the accuracy of the evaluation is about 95%.
Detailed explanation:
1.	Feature matching:
o	String match:
§	A lot of path matches like "D:\\ path\ to\ file.dll" or "C:\ path\ to\ file.dll" appear in the log, indicating that the file may be injected into the system for malicious operation.
§	Multiple suspicious character strings appear, such as "\\ x89\\ x8A\\ x4C\\\ x61\\ x6C\\ x65\ x4A\ x6F\ x6F\ x6F\ x4A\ x6F\ x6F\ x6F\\ x6F\\ x6F\\\ x6F\\\ x6F\\\ x6F\\\\\ x6F."; A class definition or function call may be involved, implying that the file may contain dynamic link libraries or custom API calls.
o	Function calls and API calls:
§	Api calls such as "LoadLibraryA," "GetProcAddress," "VirtualAllocEx" and "WriteProcessMemory" appear many times in the log, and these functions are often used to inject malicious code or modify the system memory, which is a common mechanism of malware.
§	Multiple suspicious function calls have occurred, indicating that the file may contain calls to these APIs to implement malicious behavior.
o	Document characteristics:
§	The log shows a file size of 9,911,696 bytes, and large files are often used to hide malicious activity or load more malicious code.
§	More than one string appears that is not selected as a feature (with??) May indicate that these strings were not recognized or filtered during the analysis.
2.	Code Confusion and Hiding:
o	Obfuscation code:
§	Multiple pieces of code that were confused, For example, "\ xA0\ x34\ x86\ x32\ x68\ x74\ x74\ x70\ x3A\ x2F\ x2F\ x6F\ x63\ x73\ x64\ x69\ x69\ x65\ x72\ x74\ x2E\ x63\ x74\ x63\ x74\ x2E\ x6F\ x6D," This may indicate that the code is being obfuscated, trying to hide its true intent and circumventing detection.
o	Code encryption or compression:
§	There are encrypted or compressed code blocks, such as "\ x89\ x8A\\ x4C\\\ x61\ x6C\ x65\ x4A\ x6F\ x6F\ x6F\ x4A\ x6F\ x6F\ x6F\\ x6F\ x4A\ x6F\\\ x6F\ x6F\\ x6F\ x6F\ x6F\ x6F\ x6F."; It may indicate that the code is encrypted or compressed to increase the difficulty of analysis.
3.	Behavior patterns:
o	Abnormal system call:
§	There are several abnormal system calls, such as "RegSetValueExA," "WritePrivateProfileStringA," "CreateRemoteThread," etc. these functions are often used to modify registry, write configuration files and create remote threads, which are the common behavior patterns of malware.
o	Dynamic link library loading:
§	Multiple function calls, such as "LoadLibraryA," "GetProcAddress," indicate that the file may contain dynamic link libraries or custom API calls, and may load other malicious modules or dynamic code.
4.	Document structure and content characteristics:
o	Repeated or unusual byte sequence:
§	Multiple repeated or abnormal byte sequences, such as "000000Z\ x17\ x0D3111092359Z0b1\ x0B0\ x09," may indicate that the file is divided or compressed to increase the analysis difficulty.
o	Unrecognized characteristics:
§	There are multiple strings that are not selected as features, which may indicate that these strings are not identified or filtered during the analysis, increasing the file's suspiciousness.
Assessment accuracy:
•	High accuracy (95%):
o	Based on multi-dimensional feature analysis, the determination result covers multiple malicious behavior patterns that may exist in the file, such as code obfuscation, API call exception, file feature exception and so on.
o	While a few features go unselected, these unrecognized strings or behaviors may exist in normal software, but are filtered by the tool, increasing its suspiciousness.
Judgment basis:
1.	Suspicious Behavior Patterns:
o	Dynamic link library loading: Multiple API calls such as "LoadLibraryA" indicate that the file may be loaded with other malicious modules.
o	Function call exception: There are several abnormal function calls, such as "WriteProcessMemory," "VirtualAllocEx," which may be used for process injection, memory operation and other malicious behaviors.
o	Code confusion: A lot of confusion of code fragments, increased code concealment, reduced the accuracy of analysis.
2.	Document characteristics:
o	Large file size: The file size is 9,911,696 bytes, and large files are often used to hide malicious activity or load more malicious code.
o	Exception byte sequence: A sequence of bytes where multiple repetitions or exceptions occur, which may indicate that the file is split or compressed, increasing the difficulty of analysis.
3.	String match:
o	Suspicious string: Multiple suspicious string and function calls indicating that the file may contain malicious code or be used for malicious activity.
4.	System call is abnormal:
o	Abnormal system call: Multiple abnormal system calls, such as "RegSetValueExA," "CreateRemoteThread," may be used for malicious actions such as registry modification and creation of remote threads.
Conclusion:
Combined with the above analysis, the characteristics in the log show that the file may contain Trojan horses with malicious behavior disguised as a system class library. The tool confirms that the file is Trojan. Win32.spybind [FakeAV] with high accuracy through various feature matching and behavior analysis.
文本框: o	While a few features go unselected, these unrecognized strings or behaviors may exist in normal software, but are filtered by the tool, increasing its suspiciousness.
Judgment basis:
5.	Suspicious Behavior Patterns:
o	Dynamic link library loading: Multiple API calls such as "LoadLibraryA" indicate that the file may be loaded with other malicious modules.
o	Function call exception: There are several abnormal function calls, such as "WriteProcessMemory," "VirtualAllocEx," which may be used for process injection, memory operation and other malicious behaviors.
o	Code confusion: A lot of confusion of code fragments, increased code concealment, reduced the accuracy of analysis.
6.	Document characteristics:
o	Large file size: The file size is 9,911,696 bytes, and large files are often used to hide malicious activity or load more malicious code.
o	Exception byte sequence: A sequence of bytes where multiple repetitions or exceptions occur, which may indicate that the file is split or compressed, increasing the difficulty of analysis.
7.	String match:
o	Suspicious string: Multiple suspicious string and function calls indicating that the file may contain malicious code or be used for malicious activity.
8.	System call is abnormal:
o	Abnormal system call: Multiple abnormal system calls, such as "RegSetValueExA," "CreateRemoteThread," may be used for malicious actions such as registry modification and creation of remote threads.
Conclusion:
Combined with the above analysis, the characteristics in the log show that the file may contain Trojan horses with malicious behavior disguised as a system class library. The tool confirms that the file is Trojan. Win32.spybind [FakeAV] with high accuracy through various feature matching and behavior analysis.

According to the national standard draft, the threat classification is Trojan. Win32. Spybind, and the YARA rules for automatic feature extraction are as follows:

Rule Trojan. Win32.spybind: Trojan {

Meta:

Description = “This is a section of YARA rules generated by the VILLM V2 model. used to detect Trojan.Win32.SpyBind.”

Strings:

      $a = {65 48 8b 04 25 60 00 00}

      $b = {48 8b 48 18 48 83 c1 10}

      $c = {4d 8d 40 01 66 0f 47 ca 43 0f b7 14 43 0f b7 c1 44 03 c8}

      $d = {8b b4 38 88 00 00 48 03 f7 44 8b 56 20 8b 5e 18 4c 03 d7}

      $e = {8b 46 24 8b 4e 1c 48 03 c7 48 03 cf 42 0f b7 14 58 44 8b 34 91 4c 03 f7}

      $f = {73 21 49 63 d0 42 8b 0c 0a 41 03 ca 89 0c 1a}

Condition:

All of them

}

Antiy LanDi VILLM is the first threat detection generation algorithm registered by the State Cyberspace Administration in China. The model is trained based on the massive sample feature engineering data accumulated over the past 20 years by Antiy Cybertron. The training data includes file identification information, decision information, attribute information, structure information, behavior information, host environment information, data information, and the like, The system supports threat judgment and detailed knowledge understanding of vector features under different scenarios, forms multi-form detection methods applying different requirements and scenarios, and improves the ability to judge hidden threats in the background. Further empowering safe operations.

Figure Antiy LanDi VILLM sample analysis

Appendix II: Reference Materials

Antiy.trojan / Win32.HijackLoader virus description and protection – Computer virus encyclopedia [R / OL]. (2025-04-23)

https: / / www.virusview.net / malware / Trojan / Win32 / HijackLoader

Appendix II: About Antiy

Anty is committed to enhancing the network security defense capabilities of its customers and effectively responding to security threats. Through more than 20 years of independent research and development, Antiy has developed technological leadership in areas such as threat detection engines, advanced threat countermeasures, and large-scale threat automation analysis.

Antiy has developed IEP (Intelligent Endpoint Protection System) security product family for PC, server and other system environments, as well as UWP (Unified Workload Protect) security products for cloud hosts, container and other system environments, providing system security capabilities including endpoint antivirus, endpoint protection (EPP), endpoint detection and response (EDR), and Cloud Workload Protection Platform (CWPP) , etc. Antiy has established a closed-loop product system of threat countermeasures based on its threat intelligence and threat detection capabilities, achieving perception, retardation, blocking and presentation of the advanced threats through products such as the Persistent Threat Detection System (PTD), Persistent Threat Analysis System (PTA), Attack Capture System (ACS), and TDS. For web and business security scenarios, Antiy has launched the PTF Next-generation Web Application and API Protection System (WAAP) and SCS Code Security Detection System to help customers shift their security capabilities to the left in the DevOps process. At the same time, it has developed four major kinds of security service: network attack and defense logic deduction, in-depth threat hunting, security threat inspection, and regular security operations. Through the Threat Confrontation Operation Platform (XDR), multiple security products and services are integrated to effectively support the upgrade of comprehensive threat confrontation capabilities.

Antiy provides comprehensive security solutions for clients with high security requirements, including network and information authorities, military forces, ministries, confidential industries, and critical information infrastructure. Antiy has participated in the security work of major national political and social events since 2005 and has won honors such as the Outstanding Contribution Award and Advanced Security Group. Since 2015, Antiy’s products and services have provided security support for major spaceflight missions including manned spaceflight, lunar exploration, and space station docking, as well as significant missions such as the maiden flight of large aircraft, escort of main force ships, and Antarctic scientific research. We have received several thank-you letters from relevant departments.

Antiy is a core enabler of the global fundamental security supply chain. Nearly a hundred of the world’s leading security and IT enterprises have chosen Antiy as their partner of detection capability. At present, Antiy’s threat detection engine provides security detection capabilities for over 1.3 million network devices and over 3 billion smart terminal devices worldwide, which has become a “national-level” engine. As of now, Antiy has filed 1,877 patents in the field of cybersecurity and obtained 936 patents. It has been awarded the title of National Intellectual Property Advantage Enterprise and the 17th (2015) China Patent Excellence Award.

Antiy is an important enterprise node in China emergency response system and has provided early warning and comprehensive emergency response in major security threats and virus outbreaks such as “Code Red”, “Dvldr”, “Heartbleed”, “Bash Shellcode” and “WannaCry”. Antiy conducts continuous monitoring and in-depth analysis against dozens of advanced cyberspce threat actors (APT groups) such as “Equation”, “White Elephant”, “Lotus” and “Greenspot” and their attack actions, assisting customers to form effective protection when the enemy situation is accurately predicted.