{
	"id": "be027132-a07f-410a-91ef-71accd6ba5dd",
	"created_at": "2026-04-06T00:17:06.843217Z",
	"updated_at": "2026-04-10T03:20:42.773475Z",
	"deleted_at": null,
	"sha1_hash": "22ccb51afcadb86416287210c793ad0bb57fbc48",
	"title": "HijackLoader | ThreatLabz",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 84981,
	"plain_text": "HijackLoader | ThreatLabz\r\nBy Nikolaos Pantazopoulos\r\nPublished: 2023-09-08 · Archived: 2026-04-05 13:01:24 UTC\r\nModules\r\nHijackLoader’s modules assist with the code injection and execution process of the final payload. The table below\r\nshows the modules identified by ThreatLabz, along with the corresponding CRC32 values and functionality.\r\nTable 2 - HijackLoader modules observed by ThreatLabz\r\nCRC32 MODULE NAME DESCRIPTION\r\n0x78b783ca AVDATA\r\nBlocklist of security products’ process names. The blocklist\r\nincludes the CRC32 value of each process name.\r\n0x757c9405 ESAL Clears out the shellcode data and executes the final payload.\r\n0x6364a15b ESAL64 64-bit version of the ESAL module.\r\n0xe7794e15 ESLDR Assists with code injection of the main instrumentation shellcode.\r\n0x4fa01ac5 ESLDR64 64-bit version of ESLDR module.\r\n0x93eb1cb1 ESWR Clears out the shellcode data and executes the rshell module.\r\n0x699d0c82 FIXED\r\nLegitimate executable file (e.g., QQPCMgr), which is used for\r\ninjecting code into its process.\r\n0xfea2e0eb\r\n \r\nLauncherLdr\r\nDecrypts the stored modules table file from disk. We have only\r\nseen the 64-bit version of this module being included.\r\n0xf4f141c2 LauncherLdr64 64-bit version of LauncherLdr module.\r\n0x74984889 rshell Relocates, parses and executes the final payload.\r\n0x7b37e907 rshell64 64-bit version of rshell module.\r\n0x3ee477f1 ti\r\nExecuted after the first stage. Performs code injection for other\r\nstages and modules.\r\n0x2ab77db8 ti64 64-bit version of ti module.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 1 of 7\n\nCRC32 MODULE NAME DESCRIPTION\r\n0x4eace798 tinystub\r\nEmpty executable file, which is used for patching during the final\r\npayload execution process.\r\n0xa1d724fc tinyutilitymodule.dll Overwrites the PE headers of a specified file with null bytes.\r\n0x263596ba tinyutilitymodule64.dll 64-bit version of tinyutilitymodule.dll module.\r\n0x1ae7700a Unknown\r\nUnknown module. Not included in any of the observed binaries.\r\nBased on the analyzed code, we assess that it includes a file path\r\nalong with an optional parameter. The current running file is\r\ncopied into this new location and executed along with the\r\nspecified parameter.\r\nN/A\r\nMain instrumentation\r\nshellcode\r\nShellcode injected into the specified target process from the ti\r\nmodule. This module is responsible for executing the final\r\npayload.\r\nMoreover, each module has a structure that holds information such as:\r\nModule name\r\nModule offset in the table\r\nModule size\r\nDue to the quality of the code and because the rest of the structure fields are not being used, ThreatLabz was not\r\nable to identify the purpose for the rest of the structure members. However, ThreatLabz assesses that the following\r\ninformation might be included as well:\r\nModule timestamp\r\nInternal names (e.g., rLdr64 for the rshell module)\r\nFrom the modules mentioned above, our analysis focused on the ti and the main instrumentation shellcode\r\nmodules since these two implement the majority of the core functionality for HijackLoader.\r\nTI module\r\nAnti-Analysis\r\nThe anti-analysis techniques are the same as presented in the previous section, but there are two notable\r\ndifferences:\r\n1. The developers have included the Heaven's gate technique.\r\n2. The process blocklist remains the same but the code behavior is different as can be seen in Table 3.\r\nTable 3 - Process blocklist in the HijackLoader ti module\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 2 of 7\n\nPROCESS\r\nNAME\r\nDESCRIPTION\r\navastsvc\r\nAdds persistence by creating a shortcut (LNK) file and saving the current executable\r\nunder a random filename in the Windows folder %AppData%. NOTE: A flag, which\r\nis set in the decrypted payload at offset 4 is required too.\r\nGenerates a random environment variable name with seed 0xE1ABD1C2 and a new\r\nrandom filename. This is used at a later stage for storing the modules table.\r\nWrites to disk a legitimate executable file (the FIXED module) and uses it for code\r\ninjection at a later stage.\r\navgsvc Same as avastsvc\r\na2service No behavioral code change.\r\nwrsa No behavioral code change.\r\nmsmpeng No behavioral code change.\r\nExecution Phase\r\nThe primary role of the ti module is to inject the main instrumentation module, which is responsible for loading\r\nthe final stage. \r\nThe ti module executes the next stage by using one of the following methods:\r\nRe-executes the initial file from a new location and parameter (if the module with the CRC32 value\r\n0x1ae7700a exists).\r\nCreates a new process (specified in the configuration), maps the hijacked file into it (e.g. mshtml), and\r\ninjects the main instrumentation shellcode. In addition (depending on the configuration flags), it executes\r\nthe FIXED module, which might be used later for code injection.\r\nHijackLoader might include an additional set of files, which can be used for DLL hijacking. In this case, it\r\nwrites them to disk along with the encrypted payload (from stage 1) and executes the hijacked executable.\r\nExecutes the ESLDR module, which injects the main instrumentation shellcode.\r\nMain Instrumentation Module\r\nThe main instrumentation module contains the core functionality for loading and executing the final stage of the\r\ninfection chain.\r\nAnti-Analysis\r\nThe anti-analysis techniques remain the same with the previous aforementioned stages. However, one key\r\ndifference is the deployment of the AVDATA module. The AVDATA module contains a set of process names and if\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 3 of 7\n\nany of them are detected then the code behavior might change. The process names observed by ThreatLabz and\r\ntheir CRC32 values are presented in the table below.\r\nTable 4 - Process name blocklist in the HijackLoader AVDATA module\r\nCRC32 PRODUCT NAME PROCESS NAME\r\n0xb02ef94 Avast Antivirus avastsvc.exe\r\n0xc0bfbba0 ESET Smart Security ekrn.exe\r\n0x40cb21d3 Kaspersky AntiVirus avp.exe\r\n0xc0fe273f Symantec Event Manager ccsvchst.exe\r\n0x9e0539f6 Norton 360 n360.exe\r\n0xe6ef3ab Avira avguard.exe\r\n0x8e9e8add AVG Internet Security avgsvc.exe\r\n0x923d5594 AVG Internet Security avgui.exe\r\n0xce1599c2 BitDefender AntiVirus vsserv.exe\r\n0x83ed98a3 BitDefender AntiVirus epsecurityservice.exe\r\n0xd50dea99 TrendMicro AntiVirus coreserviceshell.exe\r\n0x2fba3706 McAfee Antivirus mcshield.exe\r\n0x1235ed11 McAfee Antivirus mctray.exe\r\n0x3a39ba4 Norton Internet Security nis.exe\r\n0xe981e279 Norton Internet Security ns.exe\r\n0x19e8fad2 BitDefender Antivirus bdagent.exe\r\n0x5f1c2fc2 Trend Micro Security uiseagnt.exe\r\n0xc68b2fd8 ByteFence Anti-Malware bytefence.exe\r\n0xefba2118 McAfee Security Scan Plus mcuicnt.exe\r\n0xfeb42b97 Internet Security Essentials vkise.exe\r\n0x6274fa64 Comodo Internet Security cis.exe\r\n0x4420ef23 Malwarebytes Anti-Malware mbam.exe\r\n0x31c100e7 360 Safe Guard zhudongfangyu.exe\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 4 of 7\n\nCRC32 PRODUCT NAME PROCESS NAME\r\n0x219b199a 360 Total Security 360tray.exe\r\n0x64760001 N/A Unknown\r\n0x27873423 N/A Unknown\r\n0x8bdc7f5b N/A Unknown\r\nEach process block in the AVDATA module has the following structure:\r\nstruct avdata_process_block\r\n{\r\n  unsigned int CRC32; // CRC32 value of process.\r\n  unsigned char Execution_Type; // Code execution method for the final payload.\r\n  unsigned char LNK_Persistence_Flag; // Adds persistence with an LNK shortcut file.\r\n  unsigned char unknown; // Not used.\r\n  unsigned char unknown_2; // Not used.\r\n  int BITS_Persistence_Flag; // Adds persistence by creating a BITS job.\r\n  int unknown_3; // Not used.\r\n  int unknown_4; // Not used.\r\n  int Injection_Type; // Defines what code injection method to use.\r\n  int overwrite_pe_headers_with_junk_Flag; // Used during module deployment.\r\n};\r\nPersistence\r\nAs described in the structure above, persistence on the compromised host is established via the following\r\nmethods:\r\nCreation of a BITS job, which points to the executable file.\r\nCreation of a shortcut file (LNK) in the Windows Startup folder. The shortcut’s path is added in a new\r\nBITS job and points to the executable file.\r\nFinal payload decryption and execution\r\nThe embedded payload is decrypted using a bitwise XOR operation with the key being derived from the first 200\r\nbytes. This can be easily represented in Python as follows:\r\nenc_data = data[200:]\r\nkey = data[:200]\r\ndec = bytearray()\r\nfor idx in range(0, len(enc_data), 4):\r\n    dec_int = struct.unpack(\" key[idx%200:idx%200 + 4])[0]\r\n    dec.extend(dec_int.to_bytes((dec_int .bit_length() + 7) // 8, byteorder='little'))\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 5 of 7\n\nHijackLoader’s shellcode then proceeds with the injection or direct execution of the decrypted payload. The\r\ntechnique the shellcode uses depends on a number of different factors such as the payload’s file type and a flag,\r\nwhich is stored in the settings and indicates the injection method to use. In the table below, we describe each case\r\nalong with a description of the action taken.\r\nTable 5 - HijackLoader Code Injection Methods\r\nINJECTION TYPE DESCRIPTION\r\nDLL file type.\r\nIn the case of a DLL file type, the shellcode parses the PE file and\r\nleverages the ESLR module, which erases the shellcode data and executes\r\ndirectly the entry point of the DLL.\r\nCode injection when the\r\ninjection flag is set to 3 and PE\r\nrelocation is required (Method\r\n1).\r\nCreates a process of the FIXED module and writes to disk a file, which\r\nincludes various information such as:\r\nPointer to the address of the rshell module data.\r\nProcess and thread handles of the created process.\r\nPointer to the address of the final payload.\r\nThen it executes the ESWR module, which injects the rshell module into\r\nthe created process. As a result, the rshell module reads the written file and\r\ntherefore the data of the final payload. After relocating and parsing the file,\r\nHijackLoader executes the final payload.\r\nCode injection when the\r\ninjection flag is set to 3 and PE\r\nrelocation is required (Method\r\n2).\r\nCreates a process of the FIXED module, loads the tinystub module,\r\nand adds a new PE section to it.\r\nThe patched stub module is written to the disk. It is important to\r\nnote that HijackLoader writes the data without including the “MZ”\r\nstring. Instead, it delays the execution for a few seconds and then\r\nwrites to the file the MZ signature byte-by-byte.\r\nFinally, it proceeds with the execution of the final payload as\r\ndescribed in the previous method.\r\nCode injection when the\r\ninjection flag is set to 3 and no\r\nPE relocation is required\r\n(Method 1).\r\nThe implementation is similar to the previous two cases. However, there\r\nare a few notable differences:\r\nHijackLoader adds a new section in the final payload file. This new\r\nsection has the rshell module.\r\nIn the case of a .NET file, HijackLoader creates an msbuild process\r\ninstead of using the FIXED module.\r\nThe code searches for certain values in the rshell module and\r\nreplaces them with the same values that are used in the file, which\r\nis written to disk (i.e., egg-hunting).\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 6 of 7\n\nINJECTION TYPE DESCRIPTION\r\nIn order to evade detection by security products, it writes random\r\ndata to the injected process.\r\nCode injection when the\r\ninjection flag is set to 3 and no\r\nPE relocation is required\r\n(Method 2).\r\nSame code injection technique as with the previous case, but the data\r\ninjection takes place with timing delays.\r\nCode injection when the\r\ninjection flag is set to 3 with a\r\n.NET PE file.\r\nCreates an msbuild process, and injects the rshell module and the\r\npayload. \r\nSearches for certain values in the rshell module and replaces them\r\nto point to the address of the decrypted payload along with the\r\ninjection type and the payload size. NOTE: No file is written on\r\ndisk.\r\nWrites random data in the injected process.\r\nCode injection when the\r\ninjection flag is set to 4.\r\nCreates an msbuild process and injects the rshell module and the\r\npayload. \r\nSearches for certain values in the rshell module and replaces them\r\nto point to the address of the decrypted payload along with the\r\ninjection type and the payload size. NOTE: No file is written on\r\ndisk.\r\nWrites random data in the injected process.\r\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader"
	],
	"report_names": [
		"technical-analysis-hijackloader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434626,
	"ts_updated_at": 1775791242,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/22ccb51afcadb86416287210c793ad0bb57fbc48.pdf",
		"text": "https://archive.orkl.eu/22ccb51afcadb86416287210c793ad0bb57fbc48.txt",
		"img": "https://archive.orkl.eu/22ccb51afcadb86416287210c793ad0bb57fbc48.jpg"
	}
}