{
	"id": "9cdeb2de-aa0d-45a9-9242-ec08bf053327",
	"created_at": "2026-04-06T00:13:32.128703Z",
	"updated_at": "2026-04-10T03:21:30.228172Z",
	"deleted_at": null,
	"sha1_hash": "9b42cad386604341069d03d7c6845dbe710d268e",
	"title": "New HijackLoader Evasion Tactics | ThreatLabz",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 760553,
	"plain_text": "New HijackLoader Evasion Tactics | ThreatLabz\r\nBy Muhammed Irfan V A\r\nPublished: 2025-03-31 · Archived: 2026-04-05 23:44:39 UTC\r\nTechnical Analysis\r\nIn the following sections, we examine HijackLoader’s new modules and changes in evasion tactics. The module\r\nnames added since our last analysis are the\r\nfollowing:  ANTIVM ,  MUTEX ,  CUSTOMINJECT ,  CUSTOMINJECTPATH ,  modTask ,  modTask64 ,  PERSDATA ,\r\nand  SM .\r\nFirst stage\r\nHijackLoader’s first stage has undergone two changes. The first change involves the blocklist processes check,\r\nwhere a new process name,  avastsvc.exe , was added to the list. If any of the processes in the table below are\r\nrunning, HijackLoader delays execution by 5 seconds. \r\nSDBM Hash\r\nValue\r\nProcess Name Description\r\n5C7024B2 avgsvc.exe\r\nThe  avgsvc.exe process is a component of AVG Internet\r\nSecurity.\r\n6CEA4537 avastsvc.exe The  avastsvc.exe process is a component of Avast Antivirus.\r\nTable 1: Processes blocklisted by HijackLoader.\r\nThe second change pertains to the decryption of modules. While most HijackLoader samples still use IDAT\r\nheaders in a PNG file to store encrypted modules, a few samples are embedding them in the PNG’s pixel structure.\r\nSecond stage (ti module)\r\nAs mentioned in our previous blog, HijackLoader uses the Heaven's Gate technique to execute x64 direct syscalls.\r\nWe have now observed that call stack spoofing has been added to the list of evasion tactics used by HijackLoader.\r\nThis technique uses a chain of EBP pointers to traverse the stack and conceal the presence of a malicious call in\r\nthe stack by replacing actual stack frames with fabricated ones.\r\nThe  ti module only uses call stack spoofing for the following native system APIs:\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 1 of 10\n\nZwCreateSection\r\nZwMapViewOfSection\r\nZwUnmapViewOfSection\r\nZwProtectVirtualMemory\r\nZwReadVirtualMemoy\r\nZwWriteVirtualMemory\r\nZwWriteFile\r\nZwResumeThread\r\nZwGetContextThread\r\nZwSetContextThread\r\nZwRollbackTransaction  \r\nZwClose  \r\nZwTerminateProcess  \r\nHijackLoader API calls\r\nHijackLoader collects the API hash, system call number, function name, and function address of all API names\r\nthat start with Zw in  ntdll.dll . This information is stored as an array of elements, with each element being a\r\nstructure of size 16, which we will refer to as a  DIRECTSYSCALL_STRUCT , as shown below.\r\nstruct DIRECTSYSCALL_STRUCT {\r\n uint32_t APIHash; // CRC32 hash of the API function name\r\n uint32_t ssn; // System service number (SSN)\r\n char *APIName; // API function name\r\n void *APIFunctionAddress; // API function address\r\n};\r\nWhen HijackLoader calls a Windows API function, the malware first locates the corresponding structure\r\n( DIRECTSYSCALL_STRUCT ) for the specified API. HijackLoader then invokes the Windows API function either by\r\ndirectly calling its address (if not running under WOW64) or by utilizing a combination of call stack spoofing,\r\nHeaven's Gate, and direct syscalls (if running under WOW64).\r\nCall stack spoofing\r\nCall stack spoofing is used to mask the origin of function calls such as API and system calls. The figure below\r\nshows a high-level view of how HijackLoader leverages call stack spoofing:\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 2 of 10\n\nFigure 1: Diagram showing how HijackLoader uses call stack spoofing to mask the origin of function calls. \r\nHijackLoader uses the base pointer register (EBP) to navigate the stack by following the chain of EBP pointers.\r\nThe malware retrieves the return address pointer (EBP+4) from the stack frames. If the return address is not\r\nlocated in the text section of NTDLL or kernelbase, HijackLoader collects both the return address pointer and the\r\nreturn address of the stack frame. The return address pointer is then patched with a random address from the text\r\nsection of a legitimate system DLL. This activity is repeated until the stack limit is reached or when three adjacent\r\nstack frames have the return address in the text section of NTDLL or kernelbase. The process is illustrated in the\r\ndiagram below:\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 3 of 10\n\nFigure 2: Diagram depicting how HijackLoader traverses the stack to retrieve and patch the return addresses to\r\nspoof stack frames.\r\nThe name of this legitimate system DLL is specified in the HijackLoader  SM module. After this, HijackLoader\r\nemploys the Heaven’s Gate technique, which allows it to switch from executing 32-bit (x86) code to executing 64-\r\nbit (x64) code. Once in 64-bit mode, HijackLoader performs the direct syscall. HijackLoader uses the syscall\r\nnumber ( ssn ) and the necessary parameters for the native system service API to execute the direct syscall.\r\nFollowing the syscall, HijackLoader transitions back to x86 and patches the return address pointers with the actual\r\nreturn addresses.\r\nPreviously, HijackLoader utilized direct syscalls for process injection and to remap the  .text section of the\r\nx64  ntdll.dll in memory with the  .text section of the x64  ntdll.dll from disk. In addition to\r\nremapping  ntdll.dll , HijackLoader now also remaps the  .text section of the x64  wow64cpu.dll from disk\r\nto memory to remove user-mode hooks.\r\nOther than the  ti module, the modules  modCreateProcess ,  modUAC , and  modTask also use call stack\r\nspoofing. However, these modules do not use Heaven's Gate or make direct syscalls, but instead invoke Windows\r\nAPI functions directly.\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 4 of 10\n\nThe figure below shows the call stack for a call to  CreateProcessW after the return addresses have been patched\r\nby the  modCreateProcess module. In the call stack, the return addresses outside of the text section of NTDLL\r\nand kernelbase are patched with addresses from the text section of a legitimate system DLL ( shdocvw.dll ) until\r\nthree adjacent stack frames have the return address in the text section of NTDLL or kernelbase.\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 5 of 10\n\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 6 of 10\n\nFigure 3: Example of HijackLoader spoofing the call stack with the fake frames enclosed in a red square.\r\nRecent HijackLoader modules\r\nThe table below lists information about the more recent HijackLoader modules.\r\nCRC32 Module Name Description\r\n0x4dad7707 ANTIVM\r\nContains the configurations HijackLoader uses for anti-VM checks\r\n(explained in detail in the following section).\r\n0x1999709f MUTEX\r\nContains a mutex name. If a mutex with this name exists,\r\nHijackLoader will exit.\r\n0x6703f815 CUSTOMINJECT\r\nContains a legitimate executable file which is used for injecting code\r\ninto its process memory. The process is created in a custom path\r\nspecified by the  CUSTOMINJECTPATH module.\r\n0x192a4446 CUSTOMINJECTPATH\r\nContains a file path used to create the legitimate file in\r\nthe  CUSTOMINJECT module. \r\n0x3115355e modTask\r\nCreates a scheduled task for persistence (explained in detail in the\r\nnext section).\r\n0x9bfaf2d3 modTask64 A 64-bit version of the  modTask module.\r\n0xa2e0ab5d PERSDATA\r\nContains the configuration used by the  modTask module to create\r\nscheduled tasks.\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 7 of 10\n\nCRC32 Module Name Description\r\n0xd8222145 SM\r\nContains the name of the system DLL used in call stack spoofing to\r\npatch the return addresses.  TinycallProxy module is also copied to\r\nthis system DLL.\r\n0x455cbbc3 TinycallProxy\r\nActs as a proxy to execute API calls. The call to the  TinycallProxy\r\nmodule will have the address of the API function, number of\r\nparameters for the API call, and parameters for the API call as its\r\narguments.\r\n0x5515dcea TinycallProxy64 This module is a 64-bit version of the  TinycallProxy module.\r\nTable 2: Description of more recent HijackLoader modules.\r\nVirtual machine detection module\r\nThe virtual machine detection module  ANTIVM contains a configuration used by HijackLoader to identify virtual\r\nmachines and analysis environments. This configuration is stored in a structure which we will refer to as\r\nthe  ANTIVM_STRUCT , as shown below.\r\nstruct ANTIVM_STRUCT {\r\n uint32_t antiVMType;\r\n uint32_t timeThreshold;\r\n uint32_t minPhysicalMemory;\r\n uint32_t minProcessorCount;\r\n uint32_t antiVMType2;\r\n wchar_t username[20]; // Hardcoded to \"george\" (may change between samples)\r\n byte PhysicalMemory;\r\n byte ProcessorCount;\r\n};\r\nThe first member,  antiVMType determines the type of anti-VM check to be performed. These checks employ\r\ncommon anti-VM techniques. The  antiVMType can include multiple values combined using bitwise OR\r\noperations. The values supported are listed in the table below.\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 8 of 10\n\nValue Check Performed\r\n0x1\r\nCalculates the average time taken to execute the CPUID instruction using the RDTSC instruction\r\nand compares it against the timeThreshold member of the  ANTIVM_STRUCT . If the measured time\r\nequals or exceeds the timeThreshold, HijackLoader exits.\r\n0x4\r\nCalls the CPUID instruction with EAX set to 1 and checks if the 31st bit of the ECX register (the\r\nhypervisor present bit) is set. If the bit is set, HijackLoader terminates.\r\n0x8\r\nRetrieves the maximum input value for hypervisor CPUID information by calling the CPUID\r\ninstruction with EAX set to 0x40000000. If this value is greater than or equal to 0x40000000,\r\nHijackLoader exits. For instance, on Microsoft hypervisors, this value will be at least 0x40000005.\r\n0x10\r\nRetrieves the total physical memory of the system in gigabytes and compares it to\r\nthe minPhysicalMemory member of the  ANTIVM_STRUCT . If the total physical memory is less than or\r\nequal to minPhysicalMemory, HijackLoader exits.\r\n0x20\r\nRetrieves the number of processors on the system and compares it to the minProcessorCount\r\nmember of the  ANTIVM_STRUCT . If the processor count is less than or equal to minProcessorCount,\r\nHijackLoader exits.\r\n0x40 Encompasses multiple checks, determined by the antiVMType2 member of the  ANTIVM_STRUCT.\r\nThe supported checks are:\r\n0x1 - Verifies if the computer name consists only of numbers. \r\n0x2 - Verifies if the username matches the username member of the  ANTIVM_STRUCT . \r\n0x4 - Verifies if HijackLoader is executed from the Desktop folder or any of its subfolders.\r\n \r\nANALYST NOTE: These three checks appear to be in development, as HijackLoader does not exit\r\neven if the conditions are met.\r\n \r\nAdditionally, irrespective of the antiVMType2 value, HijackLoader compares the system's total\r\nphysical memory in gigabytes with the PhysicalMemory member of the  ANTIVM_STRUCT and the\r\nnumber of processors with the ProcessorCount member of the  ANTIVM_STRUCT . If both of these\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 9 of 10\n\nValue Check Performed\r\nchecks are equal (which may be a specific configuration for a malware sandbox), HijackLoader\r\nexits.\r\nTable 3: Description of values supported by the HijackLoader virtual machine detection module.\r\nPersistence module\r\nBefore transferring control to the  modTask persistence module, the  ti module copies itself to a new address\r\nand the ti module copy is XOR’ed with the performance counter value obtained by calling\r\nthe QueryPerformanceCounter API. The new address of the XOR’ed ti module and the XOR key are stored for\r\nrestoration purposes.\r\nWhen control is transferred to the  modTask module, HijackLoader begins by overwriting the entire plaintext  ti\r\nmodule with zeros. HijackLoader then performs call stack spoofing as previously described. Next, the  modTask\r\nmodule copies the  TinycallProxy module into the text section of the system DLL specified in the  SM module\r\nand uses this copied  TinycallProxy module to call APIs. \r\nThen, HijackLoader creates a scheduled task for persistence using the configuration in the  PERSDATA\r\nconfiguration module. The configuration is stored in a structure which we will refer to as the  PERSDATA_STRUCT ,\r\nwith the definition shown below.\r\nstruct PERSDATA_STRUCT {\r\n uint32_t triggerTaskOnLogon; // If set, the task will be triggered when the\r\n // user logs in, otherwise the task will execute\r\n // at regular intervals.\r\n uint32_t TaskFlag; // Flag used in ITask::SetFlags method\r\n uin32_t MinutesInterval; // Task execution interval in minutes\r\n uin32_t wRandMinutesInterval;// Unused by the TASK_TRIGGER structure\r\n wchar_t taskName[50]; // Name of the task\r\n};\r\nMore information about HijackLoader’s modules are available in our previous blog.\r\nSource: https://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nhttps://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics"
	],
	"report_names": [
		"analyzing-new-hijackloader-evasion-tactics"
	],
	"threat_actors": [],
	"ts_created_at": 1775434412,
	"ts_updated_at": 1775791290,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9b42cad386604341069d03d7c6845dbe710d268e.pdf",
		"text": "https://archive.orkl.eu/9b42cad386604341069d03d7c6845dbe710d268e.txt",
		"img": "https://archive.orkl.eu/9b42cad386604341069d03d7c6845dbe710d268e.jpg"
	}
}