{
	"id": "9182b42e-d687-4467-9196-1bc050af8f12",
	"created_at": "2026-04-06T00:22:17.766634Z",
	"updated_at": "2026-04-10T03:20:23.402266Z",
	"deleted_at": null,
	"sha1_hash": "4d5ba51feba2d839b957305a77691ba3513b7ae6",
	"title": "2017 Volume 6 Evasive Malware Tricks How Malware Evades Detection by Sandboxes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 199306,
	"plain_text": "2017 Volume 6 Evasive Malware Tricks How Malware Evades\r\nDetection by Sandboxes\r\nArchived: 2026-04-05 16:26:33 UTC\r\nAuthor: Clemens Kolbitsch\r\nDate Published: 1 November 2017\r\nespañol\r\nSandboxes are widely used to detect malware. They provide a temporary, isolated and secure environment to\r\nobserve if a suspicious file attempts anything malicious. Of course, criminals are well aware of sandboxes and\r\nhave created a wide range of techniques to detect if there is a malicious file in a sandbox. If the malware detects a\r\nsandbox, it will not execute its true malicious behavior and, therefore, appears to be another benign file. If all goes\r\nwell from the criminal’s point of view, the sandbox then will release the file, deliver it to its intended user and the\r\nmalware can launch the attack against the real user’s environment.\r\nIt is a cat-and-mouse game where sandbox vendors add new techniques to detect malware, and criminals develop\r\ncreative ways to evade detection and respond to the new detection techniques added to the sandbox.\r\nThis article describes a representative sample of the techniques criminals use to evade detection, including the\r\nmost recently developed methods.1 This is not meant to be comprehensive, especially considering that new\r\nevasion techniques are continually being created. With every sandbox revision, criminals respond with a new\r\nevasion technique.\r\nThis article provides specific examples of three types of evasion techniques:\r\nUser behavior-based evasion—Used to detect user actions that indicate the presence of a real user or\r\ninaction that indicates a sandbox. Examples of user behavior-based evasion include using\r\nApplication.RecentFiles.Count and triggering macro code on close.\r\nhttps://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandboxes\r\nPage 1 of 5\n\nVirtual machine (VM)-based evasion—Used to detect artifacts that are indicative of a VM-based\r\nsandbox. Examples of VM-based evasion include looking for Zone:Identifier and Windows Management\r\nInstrumentation (WMI) based evasions.\r\nTiming-based evasion—Used to evade sandboxes by delaying execution of malicious behavior or\r\ndetecting sandbox timing artifacts. Examples of timing-based evasion include using delay application\r\nprogramming interfaces (APIs), sleep patching and time bombs.\r\nUser Behavior—Based Evasion Examples\r\nCriminals deploy a range of techniques to detect user activity that, they assume, would not be present in a\r\nsandbox. Two of the most recent examples of this are using Application.RecentFiles. Count and triggering\r\nmalicious code when a document is closed.\r\nUse Application.RecentFiles.Count\r\nA recent Dridex malware dropper (malware that is designed to subsequently install additional malware) was\r\ndistributed as a document file containing macros. As background, Dridex is known as Bugat and Cridex (a form of\r\nmalware specializing in stealing bank credentials via a system that utilizes macros from Microsoft Word). The\r\nmacros use Application. RecentFiles.Count to check how many files have been accessed recently. A low count\r\nsuggests that there is not a person using the machine and, therefore, the machine is more likely to be a sandbox.\r\nTrigger Macro Code on Close\r\nEarly sandboxes did little to emulate user activity beyond opening a file inside Microsoft Office. As a result, only\r\ncode registered for the Document_Open event would be triggered within the sandbox. However, real users\r\ntypically interact with a document much more. They scroll as they read, and once they are done, they close the\r\ndocument. This discrepancy between a real user’s behavior and a sandbox can be observed, and malware now\r\noften triggers its code via the Document_Close event, meaning it will only execute the code once the document is\r\nclosed.\r\nVM-Based Evasion Examples\r\nIn addition to looking for user activity, criminals program their malware to detect when it is running in a virtual\r\nmachine and, therefore, likely is a sandbox. As with user activity, there is a long list of techniques criminals use,\r\nthe most recently detected examples of which are described here.\r\nLook for Zone:Identifier\r\nWhen a file is downloaded from the Internet onto a computer running Microsoft Windows, the operating system\r\nadds an alternate data stream (ADS) to the file to store Zone:Identifier metadata. This metadata includes\r\ninformation about the file, such as information about the URL from which the file was downloaded, and Windows\r\nuses it to show appropriate warning messages to the user before opening potentially untrusted content.\r\nOn the other hand, when a file is copied into a sandbox for analysis, this Zone:Identifier metadata is usually not\r\npresent, as the sandbox cannot know where the file originated. Malware will check for this discrepancy. The\r\npresence of the Zone:Identifier ADS hints at a real user machine. If it is not found, the malware concludes that it is\r\nin a sandbox.\r\nhttps://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandboxes\r\nPage 2 of 5\n\nWMI-Based Evasions\r\nThe WMI interface allows Microsoft Windows machines and any service running on them to query information\r\nabout running processes, available services, hardware (e.g., disk) information and more. Typically, system\r\nadministrators use WMI to automate tasks.\r\nAt the very least, sandboxes have to monitor the primary subject, i.e., the program that is to be executed, and the\r\nprocesses with which it interacts. Interactions can be as simple as one program starting another or injecting new\r\ncode into a target process. WMI is simply another type of inter-process communication (IPC), but it uses a more\r\ncomplicated client-server model. More precisely, it uses advanced local procedure calls (ALPC) to send queries to\r\nbe executed in the context of system server processes.\r\nIf a sandbox is not able to intercept this type of communication, it will miss the activities performed by malware\r\nusing WMI. Examples of malware using WMI to evade sandboxes include:\r\nChecking cores count—Due to resource constraints, sandboxes attribute the minimum required central\r\nprocessing unit (CPU) cores to a VM, typically just one, so they can run in parallel on as many VMs on a\r\nserver as possible. However, most modern computers have multiple CPU cores. Malware will execute a\r\nWMI query to fetch the cores count, and if the value is one, it concludes that it is running inside a sandbox.\r\nChecking disk space and physical memory—Just like the case for CPU cores, VMs are typically\r\nallocated a limited amount of disk space and physical memory. To detect if it is running on a VM, malware\r\nchecks if the total disk space of the drive is low, such as below 80 GB. Similarly, it checks to see if there is\r\na small amount of physical memory, such as less than 1 GB of RAM. These configurations are not\r\ntypically found on end user machines.\r\nWithout the ability to see this type of IPC, a sandbox is unable to intercept (and manipulate) the data returned by\r\nthe server process. Thus, malware finds the limited hardware resources and detects the sandbox.\r\nBIOS Info\r\nBasic Input/Output System (BIOS) information for VMs and emulators is different from BIOS information for a\r\nreal system, and it often contains strings indicative of VMs. Malware can create a list of strings found in BIOS\r\ninformation for VMs and can check if the current system BIOS information contains those strings. If so, malware\r\ncan be fairly certain that it is running in a VM.\r\nGeolocation Blacklisting\r\nThe Internet offers various services that allow a user to request geolocation data based on the client’s IP address.\r\nMaxmind is one such service, and malware can query this service to get information about the system on which it\r\nis running. One piece of available information is the company to which the IP is assigned. Malware compares this\r\ndata to a list of known vendors, e.g., security companies. A match will indicate that it is executing inside a\r\nsandbox.\r\nCheck Username\r\nMalware also fingerprints the sandbox using the name of the logged-in user. This trick works because some\r\nvendors do not randomize the Windows user under which the analysis is run. The malware simply checks the\r\nusername against a list of well-known usernames attributed to sandboxes. For example, older versions of two\r\nwell-known public sandboxes, Hybrid Analysis and Malwr. com, used to have fixed usernames, KR3T and\r\nhttps://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandboxes\r\nPage 3 of 5\n\nPSPUBWS, respectively. This makes it easy for malware to detect these sandboxes based on the name of the\r\ncurrent user.\r\nUsing Specific Instructions\r\nModern virtualization technologies support instructions that will unconditionally provoke a “VM Exit” into the\r\nhypervisor (a system that creates and runs VMs). This allows a VM to modify how the instruction triggering the\r\nVM Exit behaves, similar to an interrupt handler. However, this interrupt introduces a discrepancy in the execution\r\ntime: When executed on a real machine, such instructions are faster than when they are executed inside the\r\nhypervisor managing VMs. Malware can use this discrepancy to detect the hypervisor, thereby tipping it off that it\r\nis running inside a VM. For example, it can measure the execution time of the CPUID instruction and compare it\r\nto the expected execution time of this instruction on a real machine.\r\nTiming-Based Evasion Examples\r\nA final category of evasion includes techniques that use a variety of timing mechanisms. Recently detected\r\nexamples include using delay APIs, sleep patching and time bombs.\r\nUsing Delay APIs\r\nSome sandboxes are programmed to simply wait and watch for a period of time, and if a file does not do anything\r\nmalicious, it will release the file. To avoid this, malware uses the Sleep and NtDelayExecution APIs available in\r\nWindows. Malware calls these functions to sleep for a period of time to outwait the sandbox.\r\nSleep Patching\r\nSandboxes will patch the sleep function to try to outmaneuver malware that uses time delays. In response,\r\nmalware will check to see if time was accelerated. Malware will get the timestamp, go to sleep and then again get\r\nthe timestamp when it wakes up. The time difference between the timestamps should be the same duration as the\r\namount of time the malware was programmed to sleep. If not, then the malware knows it is running in an\r\nenvironment that is patching the sleep function, which would only happen in a sandbox.\r\nTime Bombs\r\nAnother way that malware tries to outwit sandboxes is to include code that will only run on a specific date\r\nsometime in the future—criminals can be very patient—especially for targeted attacks. The goal is simply to\r\noutwait any timing delays introduced by a sandbox.\r\nRecommended Techniques for Detecting Malware\r\nTo be effective, security technologies must be able to detect malware that uses these and many other techniques to\r\navoid detection, including new evasion strategies that criminals continue to develop in response to ever-improving\r\nsecurity systems.\r\nThe good news is that while evasive malware poses a challenge to traditional sandboxes, modern analysis\r\nsandboxes are built on a technique called full system emulation. The key difference between sandboxes based on\r\nvirtual machines and those based on code emulators is that VMs typically do not fully virtualize the CPU used to\r\nrun malware code. Instead, it passes most instructions through to the underlying hardware-supported hypervisor\r\nfor execution.\r\nhttps://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandboxes\r\nPage 4 of 5\n\nA code emulator, on the other hand, directly handles each instruction executed within the analysis system and is\r\nthus able to tamper with the execution in any way the system wants to. This is done in a way that is completely\r\ntransparent and invisible to the malware program under analysis.\r\nFor example, a full system emulator can tamper with the outcome of string comparison instructions (e.g., when\r\nused to compare the username of the system) and force execution down a path that reveals a program’s true intent.\r\nSimilarly, it can detect when a program is executing instructions that allow fingerprinting the hardware\r\nconfiguration and manipulate the effect of this code in a way to trigger additional behavior, helping it to correctly\r\nclassify malware.\r\nEven more, using full system emulation gives the sandbox complete visibility into the inner workings of programs\r\nrunning inside the analysis sandbox. That is, instead of only observing how a program interacts with the operating\r\nsystem (e.g., via system calls), a code emulator can also track data that are processed by the instructions making\r\nup the malware program. As a result, the sandbox can not only track what type of data are read from the operating\r\nsystem, but also how they are used, to what values they are compared (e.g., in code fingerprinting the system), to\r\nwhere the data are sent (when leaking confidential data) and much more.\r\nLast, but not least, by having instruction-level visibility into the programs under analysis, a code emulator can also\r\nreason about code paths that the malware program did not execute in a particular analysis run. For example, the\r\nsystem can see what other potential behavior may be lurking in the malware that was not triggered during the\r\ndynamic analysis, giving the sandbox even more information for classifying a piece of malware.\r\nConclusion\r\nCriminals are motivated, creative and persistent. For every sandbox enhancement used to detect evasive malware,\r\ncriminals will develop a technique to avoid being detected and often use multiple techniques in combination to\r\nimprove their success with detecting a sandbox. Security companies must offer, and their customers must\r\nimplement, advanced malware detection technologies that are effective regardless of who has made the most\r\nrecent move—the cat or the mouse.\r\nEndnotes\r\n1\r\n Lastline, An Introduction to Advanced Malware and How It Avoids Detection, 2017\r\nClemens Kolbitsch\r\nIs leading the antimalware group at Lastline and works on various projects related to analysis and detection. As\r\nsecurity researcher and lead developer of Anubis, he has gained profound expertise in analyzing current, malicious\r\ncode found in the wild. He has observed various trends in the malware community and successfully published\r\npeer-reviewed research papers. In the past, he also investigated offensive technologies, presenting results at\r\nconferences such as BlackHat.\r\nSource: https://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandb\r\noxes\r\nhttps://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandboxes\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/evasive-malware-tricks-how-malware-evades-detection-by-sandboxes"
	],
	"report_names": [
		"evasive-malware-tricks-how-malware-evades-detection-by-sandboxes"
	],
	"threat_actors": [],
	"ts_created_at": 1775434937,
	"ts_updated_at": 1775791223,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4d5ba51feba2d839b957305a77691ba3513b7ae6.pdf",
		"text": "https://archive.orkl.eu/4d5ba51feba2d839b957305a77691ba3513b7ae6.txt",
		"img": "https://archive.orkl.eu/4d5ba51feba2d839b957305a77691ba3513b7ae6.jpg"
	}
}