{
	"id": "2c9edfc3-9b1f-483b-a56f-f3be47bd85e5",
	"created_at": "2026-04-06T00:21:28.984244Z",
	"updated_at": "2026-04-10T03:22:11.423175Z",
	"deleted_at": null,
	"sha1_hash": "112b9eeaf3fc3091af0708e9c4976e6f78078d9d",
	"title": "Evade Sandboxes With a Single Bit – the Trap Flag",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 178029,
	"plain_text": "Evade Sandboxes With a Single Bit – the Trap Flag\r\nBy Mark Lim\r\nPublished: 2021-07-19 · Archived: 2026-04-05 18:17:47 UTC\r\nExecutive Summary\r\nUnit 42 has discovered a specific single bit (Trap Flag) in the Intel CPU register that can be abused by malware to\r\nevade sandbox detection in general purposes. Malware can detect whether it is executing in a physical or virtual\r\nmachine (VM) by monitoring the response of the CPU after setting this single bit.\r\nSandboxing is a popular technique used to detect whether a sample is malicious. A sandbox analyzes the behaviors\r\nof the binary as it executes inside a controlled environment. To overcome the challenge of analyzing a large\r\nnumber of binaries with limited computing resources, virtual machines are used to build sandboxes. To evade\r\ndetection, malware will try to determine whether it is executing in a physical or virtual machine. When the\r\nmalware finds out it is executing in a virtual machine, it will terminate its execution or provide fake outputs to\r\nhide its real intentions.\r\nSome of the most common evasion techniques involve malware conducting various system checks against the\r\nenvironment it is executing in. For example, malware will often look for abnormal screen resolution, hard disk\r\nand physical memory size. Sandboxes can build countermeasures, such as returning fake information to the\r\nmalware during these checks.\r\nThis blog documents how malware can detect the differences in CPU behaviors in a virtual or physical machine\r\nwith only a single bit in the CPU register.\r\nPalo Alto Networks customers are protected from malware families using similar sandbox evasion techniques with\r\nCortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions.\r\nSingle-Step Mode With a Single Bit — the Trap Flag (TF)\r\nTo detect the use of a VM in a sandbox, malware could check the behavior of the CPU after the trap flag is\r\nenabled.\r\nThe trap flag (TF) is the 8th single bit in the EFLAGs register of the Intel x86 CPU architecture. If the TF is\r\nenabled before a single instruction is executed, the CPU will raise an exception (single-step mode) after the\r\ninstruction is completed. This exception stops the CPU execution to allow the contents of the registers and\r\nmemory location to be examined by the exception handler. Before allowing code execution to continue, the CPU\r\nalso has to clear the TF.\r\nTo determine whether a VM is used, malware can check whether the single-step exception was delivered to the\r\ncorrect CPU instruction, after executing specific instructions (e.g. CPUID, RDTSC, IN) that cause the VM to exit\r\nhttps://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/\r\nPage 1 of 5\n\nwith the TF enabled. During VM exits, the hypervisor – also known as Virtual Machine Monitor (VMM) – will\r\nemulate the effects of the physical CPU it encounters.\r\nThe following sequence of instructions explains the CPU’s behavior after enabling the TF in a physical machine.\r\nFigure 1. CPU instructions to enable TF.\r\nThe first three instructions enable the TF bit in the EFLAGs register of the CPU. RDTSC is executed with the TF\r\nenabled. In a physical machine, the exception would be delivered to the first no operation (NOP) instruction\r\n(0x00401073). Take note that the exception occurred on the instruction immediately after the execution of the\r\ninstruction with TF enabled.\r\nFigure 2. Execution in a physical machine.\r\nExecuting the same sequence of instructions in a VM would have a different effect. In a VM, executing RDTSC\r\nwould result in a VM exit. The hypervisor will carry out its usual tasks of emulating the behaviors of the RDTSC\r\ninstruction. However, an implementation of the hypervisor with incorrect emulation of the TF would result in the\r\nTF being ignored and the code execution will continue to the first NOP instruction. During the execution of the\r\nfirst NOP instruction, the TF is still enabled as the TF was not handled by the hypervisor. This results in an\r\nexception occurring on the second NOP instruction (0x00401073). The correct implementation will require the\r\nhypervisor to inject a debug exception after emulating the instruction that caused the VM exit and clearing the TF.\r\nFigure 3. Execution in a virtual machine.\r\nAs a sandbox evasion technique, malware will use an exception handler in addition to the above instruction\r\nsequence to examine which instruction the exception occurred on. The next section describes a real-world\r\nexample of a malware family that made use of this technique to evade sandboxes.\r\nhttps://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/\r\nPage 2 of 5\n\nReal-World Example\r\nLampion is a malware family that was targeting users in Portugal. Lampion employed multiple system checks to\r\nevade sandbox detection. One of the techniques is making use of the single-step mode with TF, as discussed in the\r\nprevious section.\r\nLampion implemented all its system checks with x86 assembly instructions and minimal Windows API calls. This\r\nallowed the Lampion samples to conceal their behavior from the sandboxes. The Lampion samples would\r\nterminate if the malware determined it was executing inside a VM. The system checks are also intertwined with\r\nmultiple anti-reverse engineering techniques to hide from human analysts.\r\nThe following screenshot shows a snippet of instructions hidden in the Lampion sample that conducts the system\r\ncheck.\r\nFigure 4. Instructions in Lampion used to evade sandboxes.\r\nThe following is pseudocode to demonstrate how Lampion carries out one of its sandbox system checks by\r\nenabling TF on an instruction that causes the VM to exit.\r\nhttps://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/\r\nPage 3 of 5\n\nFigure 5. Pseudocode of Lampion carrying out anti sandbox check using TF.\r\nThe instruction right after the instruction RDTSC is NOP. The byte code for the NOP instruction is 0x90. The\r\nexception handler would traverse the ContextRecord structure to locate the address of the instruction in the\r\nExtended Instruction Pointer register (EIP) when the exception occurred. The instruction is then compared against\r\nthe 0x90 byte and the malware will exit if the check fails.\r\nThe following screenshot shows the EIP=0x7F0E4E when the exception happened.\r\nhttps://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/\r\nPage 4 of 5\n\nFigure 6. Address of the instruction where the exception occurred.\r\nMalware vs Sandbox Authors\r\nFor many years, there has been an ongoing cat and mouse game between malware authors crafting evasion\r\ntechniques to prevent effective analysis, and sandbox authors who research novel ways to defeat those evasions.\r\nThis is one of the main drivers that led us at Palo Alto Networks to build our own custom hypervisor for malware\r\nanalysis. Since we have full control over the software stack, including the virtualization layer, we can react to new\r\nand emerging threats. In this particular case, once we had identified the issue with the incorrect emulation of the\r\ntrap flag, our hypervisor team was able to test and deploy a fix. This evasion issue has since been resolved for any\r\nmalware sample using this technique.\r\nPalo Alto Networks customers are further protected from malware families using similar sandbox evasion\r\ntechniques with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security\r\nsubscriptions. AutoFocus customers can track the malware discussed here using the Lampion tag. Other similar\r\nsandbox evasion techniques that rely on abusing Intel CPU instructions or registers will not work against\r\nWildFire.\r\nIndicators of Compromise\r\nLampion Sample\r\nEB3F2BE571BB6B93EE2E0B6180C419E9FEBFDB65759244EA04488BE7C6F5C4E2\r\nSource: https://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/\r\nhttps://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/"
	],
	"report_names": [
		"single-bit-trap-flag-intel-cpu"
	],
	"threat_actors": [],
	"ts_created_at": 1775434888,
	"ts_updated_at": 1775791331,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/112b9eeaf3fc3091af0708e9c4976e6f78078d9d.pdf",
		"text": "https://archive.orkl.eu/112b9eeaf3fc3091af0708e9c4976e6f78078d9d.txt",
		"img": "https://archive.orkl.eu/112b9eeaf3fc3091af0708e9c4976e6f78078d9d.jpg"
	}
}