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:
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.