{
	"id": "89c0fbb8-9cbb-412d-a360-09f4f7f40539",
	"created_at": "2026-04-06T00:06:18.996155Z",
	"updated_at": "2026-04-10T13:12:27.972602Z",
	"deleted_at": null,
	"sha1_hash": "5f1d470f92f205a25daf6fd7c4376b419e7c93ec",
	"title": "A Deep Dive Into Malicious Direct Syscall Detection - Palo Alto Networks Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1008398,
	"plain_text": "A Deep Dive Into Malicious Direct Syscall Detection - Palo Alto\r\nNetworks Blog\r\nBy By Or Chechik and Ofir Ozer\r\nPublished: 2024-02-13 · Archived: 2026-04-05 14:02:19 UTC\r\nExecutive Summary\r\nIn this blog post we will explain how attackers use direct syscalls to overcome most EDR solutions, by first\r\ndiscussing the conventional Windows syscall flow and how most EDR solutions monitor those calls. Then, we\r\nwill dive into different attack techniques threat actors use to stay hidden from those EDR solutions, including the\r\nuse of direct syscalls.\r\nFinally, we'll go over how Cortex XDR can monitor direct syscalls and detect their malicious uses, as\r\ndemonstrated by a real-world example.\r\nBackground\r\nEndpoint detection and response (EDR) solutions have revolutionized the cybersecurity landscape in recent years.\r\nThese innovative tools were born out of a pressing need to bolster defenses against the growing sophistication of\r\ncyberattacks.\r\nAt their core, EDR solutions serve as a sentry for an organization's endpoints, such as computers and servers.\r\nThey continuously monitor these endpoints by logging different actions taking place in real-time. EDR solutions\r\ncan be a central pillar in cybersecurity strategies, and by collecting and analyzing vast amounts of endpoint data,\r\nthey can uncover patterns, anomalies, and potential threats, thereby fortifying their ability to mitigate risks.\r\nNaturally, threat actors have wanted to find ways to bypass or subvert the EDR detections. To achieve this goal,\r\nthey have targeted one of the most critical functionalities of EDR solutions, including the ability to monitor API\r\ncalls, which tracks process actions on the installed endpoint. This led them to use direct syscalls, which is one of\r\nthe most prevalent techniques to bypass user mode EDR solutions.\r\nLet’s go into the direct syscall technique and how Cortex XDR is able to detect malicious uses of them in the\r\nWindows operating system.\r\nWindows System Call Flow\r\nFirst, we need to understand what a syscall is. A system call, abbreviated syscall, is an assembly instruction that\r\nenables the transition from user mode to kernel mode for the purpose of executing a task by the kernel. Tasks such\r\nas access to hardware peripherals, reading a file or sending packets over a TCP network socket can only be\r\nexecuted by the kernel. In a conventional flow, the system call is implemented inside system call stubs located\r\ninside ntdll.dll or win32u.dll, Windows DLLs, and it is usually called in the context of a Windows API.\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 1 of 10\n\nThe following example is intended to illustrate how system calls work within the Windows operating system:\r\nA user mode application requests the kernel to open a handle to a file. As seen in Figure 1, the application starts by\r\ncalling the Windows API CreateFileW in kernel32.dll. Then, it calls the CreateFileW function implemented inside\r\nkernelbase.dll, which in turn calls the undocumented function CreateFileInternal.\r\nThe latter calls the Native API NtCreateFile in ntdll.dll.\r\nFigure 1. Conventional system call flow\r\nAs seen in Figure 2, the system call stub for NtCreateFile executes the syscall instruction with the syscall index\r\nfor NtCreateFile, populated into the EAX register.\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 2 of 10\n\nFigure 2. System call stub for ZwCreateFile in ntdll\r\nHow Most EDRs Monitor API Calls\r\nMost EDRs monitor system calls and API calls by hooking user mode Windows DLLs. The common method\r\nEDRs use is inline hooking, which is a method of intercepting calls to target functions as a way to prevent or\r\nmonitor potentially malicious operations. An example of EDR inline hooking is shown in Figure 3. By modifying\r\nthe assembly instructions of the prologue of CreateFileW to a JMP instruction, the execution is redirected to the\r\nEDRs proxy function where it can monitor or prevent the operation. In turn, the EDR Proxy jumps to the\r\ntrampoline function which will execute the original CreateFileW prologue and then jumps back to CreateFileW,\r\nright after the prologue, to resume the function execution.\r\nFigure 3. Inline Hooking Example\r\nEDRs commonly inject their DLL as early as the process starts, and this DLL usually hooks Windows API and\r\nNative API functions inside the Windows libraries such as kernel32.dll, kernelbase.dll, and ntdll.dll.\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 3 of 10\n\nHow Attackers Bypass Most EDRs\r\nMost EDRs use user mode hooks for their syscall monitoring, therefore a lot of the EDR bypasses are user mode\r\nhook bypasses.\r\nMost of those EDR bypasses map a clean copy of the hooked DLL or try to restore the hooked DLL to its original\r\ndisk content to avoid the EDR hooks.\r\nOut of the many EDR bypass techniques, the most prominent one is the “Direct Syscall” technique. To achieve\r\nmaximum stealth, attackers frequently use it in conjunction with other evasion techniques, as it is very hard to\r\ndetect and differentiate between malicious and benign use of it.\r\nFollowing are notable bypass techniques:\r\nManual Load DLL From Disk\r\nA technique in which the attacker manually loads a clean copy of a hooked DLL using Reflective DLL Loading.\r\nThis technique allows the attacker to avoid getting through the Windows Loader, and avoid the EDR callbacks\r\nthat effectively install the hooks.\r\nThe attacker implements the Windows Loader functionally on its own, loading the DLL directly from memory,\r\ngiving it a different mapping type than the loader would.\r\nClone DLL\r\nSimilarly to the previous technique, this technique loads a secondary DLL to avoid the EDR hooks. This technique\r\nhowever does go through the Windows Loader and uses the Windows API. The attacker copies the target DLL\r\nfrom %system32% to a new location with a new name, then it uses the LoadLibrary Windows API to load it from\r\ndisk and use it in its code. The cloned DLL will have a different name than the hooked DLL, so the EDR won’t\r\ninstall hooks for it.\r\nDirect Syscall\r\nAttackers use the direct syscall technique to avoid going through the user mode hooks, because it allows an\r\nattacker to execute a system call without going through the Windows and the Native API. Essentially, the attacker\r\nimplements the system call stub in its own application as seen in Figure 4.\r\nFigure 4. Example of system call stub that performs the syscall NtAllocateVirtualMemory\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 4 of 10\n\nThe syscall instruction forwards the execution flow to the corresponding syscall implementation in the kernel\r\naccording to the syscall index. It’s the last step in user mode.\r\nDifferent Windows builds and service packs use different syscall indexes.\r\nTo address this issue, attackers often parse NTDLL in runtime and find the correct syscall indexes out of the\r\nsyscall stubs.\r\nCortex XDR is not affected by any of the mentioned techniques.\r\nCortex XDR Direct Syscall Detection\r\nCompared to other EDR solutions, Cortex XDR employs a kernel mode syscall interception technique, providing\r\naccess into kernel structures, and the ability to synchronously block or record syscalls, ensuring robustness against\r\nuser mode hook bypass methods. Using this method, Cortex XDR detects direct syscalls for many different\r\nsyscalls commonly used by attackers.\r\nCortex XDR leverages the KTRAP_FRAME structure built on top of the base of the thread’s kernel mode stack\r\nupon syscall handling.\r\nThe syscall handler builds the KTRAP_FRAME, a structure in which the kernel saves the state of execution that\r\ngets interrupted, by an exception, an interrupt or a syscall, and stores the initial user mode context, that is, it stores\r\nthe registers to restore execution in user mode once the syscall is done.\r\nTo detect a direct syscall, for every intercepted system call, Cortex XDR extracts the RIP from the\r\nKTRAP_FRAME, which is the return address to user mode, then it resolves the user mode return address to the\r\ncorresponding loaded module the address points to (effectively the user mode module that called the syscall\r\ninstruction).\r\nThe resolution of the address is done by a unique component of Cortex XDR called ImageTracker that can resolve\r\naddresses to image paths and to an image’s closest export. ImageTracker keeps track of the loading and unloading\r\nactions of images for all the processes in the system. Cortex XDR uses ImageTracker to resolve addresses across\r\nthe entire product.\r\nAs we mentioned above, in a conventional Windows syscall flow, the captured return address would be inside the\r\nntdll.dll or win32u.dll modules, so if the return address is inside any other DLL, or can't be mapped into any DLL\r\n(shellcode), then the event is marked as a direct syscall and the path to the initiating module (for a non-shellcode\r\ncase) is recorded as part of the event.\r\nLastly, in order to detect if this is a malicious direct syscall, the event is sent to the cloud for statistical analytics\r\nand anomaly detection and to the Behavioral Threat Protection module which runs on the endpoint.\r\nAre Direct Syscalls Malicious?\r\nUsing direct syscalls is not always malicious. This action can be performed frequently by legitimate software,\r\nsuch as security products, gaming anti-cheat modules, Chromium-based applications and more.\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 5 of 10\n\nIt is very difficult to differentiate between legitimate and malicious direct syscalls, based on single-event\r\ninformation or static signatures.\r\nOur solution to this problem was leveraging the power of the Cortex XDR Analytics Engine.\r\nHow Analytics Detects a Malicious Use of Direct Syscalls\r\nThe Cortex XDR Analytics Engine is a learning mechanism used to detect attacks that are otherwise very difficult\r\nor even impossible to detect using other methods. Analytics capabilities on XDR data relies on collection and\r\ningestion techniques that operate in a highly scalable and efficient manner.\r\nThe Analytics Engine creates aggregations dynamically based on real-time events from Cortex XDR agents. These\r\naggregations are then used to define baselines of \"common\" behaviors for each customer locally and globally.\r\nIn order to establish a baseline using the Analytics Engine, we look for the appropriate questions that will enable\r\nus to determine with certainty whether an action is common or rare for each event. Those questions point us to the\r\nkey artifacts we should aggregate and the relations between them.\r\nThese are the questions that we found to be most effective at profiling direct syscall behaviors:\r\nHow common is this direct syscall?\r\nDoes this process usually execute direct syscalls?\r\nHow often does the mapped memory location call a direct syscall?\r\nUsing local and global aggregations, we answer those questions in real time and conclude whether a direct syscall\r\nevent is benign or malicious.\r\nReal-Life Example - Lumma Stealer\r\nLet's take a look at a real-world attack that we discovered using Direct Syscall Analytics, which detected the\r\ninjection method used by the Lumma Stealer malware.\r\nLumma Stealer is a malicious tool that’s part of a malware-as-a-service campaign that was first seen in 2022 when\r\nit was advertised in dark web forums. It is an info stealer that primarily targets cryptocurrency wallets and two-factor authentication (2FA) browser extensions in addition to exfiltrating sensitive data from its targets.\r\nWe will not go over all stages of the attack, but we will go over the steps it takes to perform the direct syscalls.\r\nIt all starts with a legitimate looking install file called “Setup.exe”, which is the Lumma Stealer unpacker and\r\ninjector. This file contains an expired Kaspersky certificate:\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 6 of 10\n\nFigure 5. LummaStealer signature information\r\nUpon execution, the malware tries to send a beacon to arthritis[.]org - upon failure, the malware stops running.\r\nFollowing the beacon, Lumma Stealer decodes a shellcode, loads the signed Windows DLL “mshtml.dll”,\r\noverwrites the start of the .text section of the DLL with the decoded shellcode and calls the address of the written\r\nshellcode directly.\r\nRunning from mshtml.dll, the shellcode decodes another shellcode that is destined to be executed in a different\r\nprocess - cmd.exe for another loading step.\r\nFirst, the malware loads “ntdll.dll” from disk and extracts the right syscall’s index while parsing the functions it\r\nneeds.\r\nIn order to do that it holds a list of hashes (calculated with MurmurHash2), those hashes are then compared to\r\nhashes of function names extracted from the loaded “ntdll.dll” file. Upon finding the right one, the function\r\nextracts the current syscall index and stores it in a variable for later use.\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 7 of 10\n\nFigure 6. Snippet of syscall index extractor functions\r\nThe syscall indexes extracted are:\r\nZwCreateSection\r\nZwMapViewOfSection\r\nZwWriteVirtualMemory\r\nZwProtectVirtualMemory\r\nNtSuspendThread\r\nZwResumeThread\r\nZwOpenProcess\r\nZwGetContextThread\r\nNtSetContextThread\r\nLumma Stealer uses those syscall indexes for the next stages of the injection. Each syscall index has a dedicated\r\nfunction that sets up the arguments it needs and calls the syscall invoker function:\r\nFigure 7. Lumma Stealer direct syscall invocation chart\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 8 of 10\n\nIn the syscall invoker function, we can see another technique that the malware writers used to wrap the syscall\r\nexecution - Heaven’s Gate.\r\nThis technique enables manual transaction of x86 CPU mode to a x64 CPU and vice versa.\r\nThe “invoke_syscall” function uses two instances of Heaven’s Gate before and after the direct syscall execution. It\r\nswitches the CPU mode to x64 first:\r\nFigure 8. x86 to x64 Heaven’s Gate before direct syscall execution\r\nFigure 8. x86 to x64 Heaven’s Gate before direct syscall execution\r\nThen the direct syscall is executed followed by another instance of Heaven’s Gate that switches the CPU mode\r\nback to x86:\r\nFigure 9. Direct syscall execution and x64 to x86 Heaven’s Gate\r\nUsing this method, the shellcode within mshtml.dll memory space is able to run the listed functions via direct\r\nsyscalls.\r\nIn order to inject the second shellcode to cmd.exe (as mentioned above), LummaStealer executes a Wow64\r\ncmd.exe process, using CreateProcessW (not a direct syscall). Then, it uses the direct syscalls to suspend the\r\nprocess, create memory sections in the target cmd.exe process and write the shellcode to them. Finally, it sets\r\ncmd.exe thread context to execute the written shellcode and resume the thread.\r\nCortex XDR has detected those direct syscall executions as malicious using several aggregations on local and\r\nglobal levels:\r\n“Setup.exe” is not a process that invokes those direct syscalls normally.\r\nThe direct syscalls were executed from the mapped memory of mshtml.dll, which also doesn’t usually\r\nexecute those direct syscalls.\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 9 of 10\n\nConclusion\r\nAs seen in the case above, direct syscalls are used to subvert detection of malicious actions by most EDR\r\nsolutions. This case is only one example of using direct syscall in a malicious manner, as we have seen more uses\r\nof it during our research.\r\nTo detect this elusive attack vector, we had to combine methods for monitoring and enriching direct syscall events\r\nusing the agent with a learning mechanism for detecting rare and malicious direct syscall uses.\r\nPalo Alto Networks customers with Cortex XDR are protected from this kind of attack with Cortex Analytics\r\nBIOC alerts:\r\nFigure 10. Cortex XDR Direct syscall alerts and their source\r\nSource: https://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nhttps://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/"
	],
	"report_names": [
		"a-deep-dive-into-malicious-direct-syscall-detection"
	],
	"threat_actors": [
		{
			"id": "9f101d9c-05ea-48b9-b6f1-168cd6d06d12",
			"created_at": "2023-01-06T13:46:39.396409Z",
			"updated_at": "2026-04-10T02:00:03.312816Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"CHROMIUM",
				"ControlX",
				"TAG-22",
				"BRONZE UNIVERSITY",
				"AQUATIC PANDA",
				"RedHotel",
				"Charcoal Typhoon",
				"Red Scylla",
				"Red Dev 10",
				"BountyGlad"
			],
			"source_name": "MISPGALAXY:Earth Lusca",
			"tools": [
				"RouterGod",
				"SprySOCKS",
				"ShadowPad",
				"POISONPLUG",
				"Barlaiy",
				"Spyder",
				"FunnySwitch"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "18a7b52d-a1cd-43a3-8982-7324e3e676b7",
			"created_at": "2025-08-07T02:03:24.688416Z",
			"updated_at": "2026-04-10T02:00:03.734754Z",
			"deleted_at": null,
			"main_name": "BRONZE UNIVERSITY",
			"aliases": [
				"Aquatic Panda",
				"Aquatic Panda ",
				"CHROMIUM",
				"CHROMIUM ",
				"Charcoal Typhoon",
				"Charcoal Typhoon ",
				"Earth Lusca",
				"Earth Lusca ",
				"FISHMONGER ",
				"Red Dev 10",
				"Red Dev 10 ",
				"Red Scylla",
				"Red Scylla ",
				"RedHotel",
				"RedHotel ",
				"Tag-22",
				"Tag-22 "
			],
			"source_name": "Secureworks:BRONZE UNIVERSITY",
			"tools": [
				"Cobalt Strike",
				"Fishmaster",
				"FunnySwitch",
				"Spyder",
				"njRAT"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "6abcc917-035c-4e9b-a53f-eaee636749c3",
			"created_at": "2022-10-25T16:07:23.565337Z",
			"updated_at": "2026-04-10T02:00:04.668393Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Bronze University",
				"Charcoal Typhoon",
				"Chromium",
				"G1006",
				"Red Dev 10",
				"Red Scylla"
			],
			"source_name": "ETDA:Earth Lusca",
			"tools": [
				"Agentemis",
				"AntSword",
				"BIOPASS",
				"BIOPASS RAT",
				"BadPotato",
				"Behinder",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"Doraemon",
				"FRP",
				"Fast Reverse Proxy",
				"FunnySwitch",
				"HUC Port Banner Scanner",
				"KTLVdoor",
				"Mimikatz",
				"NBTscan",
				"POISONPLUG.SHADOW",
				"PipeMon",
				"RbDoor",
				"RibDoor",
				"RouterGod",
				"SAMRID",
				"ShadowPad Winnti",
				"SprySOCKS",
				"WinRAR",
				"Winnti",
				"XShellGhost",
				"cobeacon",
				"fscan",
				"lcx",
				"nbtscan"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "d53593c3-2819-4af3-bf16-0c39edc64920",
			"created_at": "2022-10-27T08:27:13.212301Z",
			"updated_at": "2026-04-10T02:00:05.272802Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Earth Lusca",
				"TAG-22",
				"Charcoal Typhoon",
				"CHROMIUM",
				"ControlX"
			],
			"source_name": "MITRE:Earth Lusca",
			"tools": [
				"Mimikatz",
				"PowerSploit",
				"Tasklist",
				"certutil",
				"Cobalt Strike",
				"Winnti for Linux",
				"Nltest",
				"NBTscan",
				"ShadowPad"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775433978,
	"ts_updated_at": 1775826747,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5f1d470f92f205a25daf6fd7c4376b419e7c93ec.pdf",
		"text": "https://archive.orkl.eu/5f1d470f92f205a25daf6fd7c4376b419e7c93ec.txt",
		"img": "https://archive.orkl.eu/5f1d470f92f205a25daf6fd7c4376b419e7c93ec.jpg"
	}
}