When a malicious object discovers that it’s under evaluation, it will postpone evil behavior until the sandbox times out. The malware simply hides its harmful capabilities until it’s in a real host. Advanced malware uses a number of techniques to avoid being detected by a sandbox. One method is to stall. When a malicious object discovers that it’s under evaluation, it will postpone evil behavior until the sandbox times out. The malware simply hides its harmful capabilities until it’s in a real host.Less sophisticated malware stalls by employing the operating system’s sleep function. This is probably the easiest way for a malware author to implement a delay as it’s literally one line of code. By calling the sleep function, the malware directs the operating system to suspend its own execution for 10 minutes or so. That’ long enough for most sandbox systems to assume the object is well-behaved and end its evaluation. Evasive Malware is different. Unlike regular malware that simply runs and hopes for the best, Evasive Malware is more like a ninja—it hides in the shadows, constantly looking around to ensure it’s not seen until the moment of attack (and, even then, the attack is usually so silent, no one notices it).
However, as sandbox technologies evolved, they began to monitor calls to the operating system’s sleep function. Now when a program or object makes such a call, unless the reason can be substantiated the object will be tagged as potentially malicious. So, even a basic sandbox can detect stalling tactics that use the operating system’s call to sleep.
Unfortunately, conventional sandbox technology can only see the calls to the operating system and not what malware is doing internally. Consequently, today’s advanced malware evades the detection of its stalling procedures by repeatedly executing meaningless instructions within its own code. By stalling internally, modern malware can outsmart these sandbox technologies.
Unlike conventional sandbox technologies that can only observe when malware makes a call to the operating system, Lastline performs deep content inspection of each object. This unique capability allows Lastline to evaluate what’s going on within the CPU itself. Every instruction the malware performs is evaluated, including stalling evasions. Any object that attempts to stall is detected, even when done internally.
Tactically speaking, Evasive Malware does a number of things to avoid being caught; these include:
It Checks Out the Environment
Before it does anything, Evasive Malware checks to see if it’s running in a virtual machine—this could indicate that it is in the sandbox, where it’s behavior is being observed. It then goes on to look at whether AV or security tools are running (which are generally bad for malware), and for the presence of analysis tools (like Wireshark or Process Explorer). Should the Evasive Malware detect any of these prior to running, it simply doesn’t run.
The thinking is to not have the Evasive Malware run in what it considers a hostile environment, and instead, to wait for another time when the environment is more “malware-friendly.” For example, if your customer has an Email Gateway in place that scans email, Evasive Malware won’t run in the gateway’s sandbox, in the hope that once it gets to the user’s Inbox, it will be relaunched and be able to run successfully.
It Goes Directly to Memory
Endpoint protection and next-gen AV solutions tend to focus on processes running. A new malware instance is a new process and is, therefore, subject to scrutiny. Instead, Evasive Malware uses OS-supported techniques to hollow out existing running processes and inject its own code into the memory location. The end result is your security solutions think it’s NOTEPAD.EXE running, but it’s actually malware.
It Leverages Document Files
The old-school method of infection was to attach a .exe file to an email. The new methodologies leverage document files (e.g., Word, Excel®, PDFs, etc.) that have some ability to execute. For example, I’ve seen an instance of malware where the dropper is a PDF that downloads a Word doc from a compromised website, which then, in turn, uses macro code to pull down the malware payload to infect the machine.
It sounds like a lot of work, but when you’re trying to avoid being detected, these additional steps are necessary.
It Stays One Step Ahead
Cybercriminal organizations are keenly aware of the value of your data and now function like software vendors—just like the good guys—and test their latest variants against current instances of security solutions in an attempt to stay one step ahead.
Three types of evasion techniques:
- User behavior-based evasion—Used to detect user actions that indicate the presence of a real user or inaction that indicates a sandbox. Examples of user behavior-based evasion include using Application.RecentFiles.Count and triggering macro code on close.
- Virtual machine (VM)-based evasion—Used to detect artifacts that are indicative of a VM-based sandbox. Examples of VM-based evasion include looking for Zone: Identifier and Windows Management Instrumentation (WMI) based on evasions.
- Timing-based evasion—Used to evade sandboxes by delaying the execution of malicious behavior or detecting sandbox timing artifacts. Examples of timing-based evasion include using delay application programming interfaces (APIs), sleep patching and time bombs.
User Behavior-Based Evasion Examples
Criminals deploy a range of techniques to detect user activity that, they assume, would not be present in a sandbox. Two of the most recent examples of this are using Application.RecentFiles. Count and triggering malicious code when a document is closed.
- Use Application.RecentFiles.Count
A recent Dridex malware dropper (malware that is designed to subsequently install additional malware) was distributed as a document file containing macros. As a background, Dridex is known as Bugat and Cridex (a form of malware specializing in stealing bank credentials via a system that utilizes macros from Microsoft Word). The macros use Application. RecentFiles.Count to check how many files have been accessed recently. A low count suggests that there is not a person using the machine and, therefore, the machine is more likely to be a sandbox. - Trigger Macro Code on Close
Early sandboxes did little to emulate user activity beyond opening a file inside Microsoft Office. As a result, the only code registered for the Document_Open event would be triggered within the sandbox. However, real users typically interact with a document much more. They scroll as they read, and once they are done, they close the document. This discrepancy between a real user’s behavior and a sandbox can be observed, and malware now often triggers its code via the Document_Close event, meaning it will only execute the code once the document is closed.
VM-Based Evasion Examples
In addition to looking for user activity, criminals program their malware to detect when it is running in a virtual machine and, therefore, likely is a sandbox. As with user activity, there is a long list of techniques criminals use, the most recently detected examples of which are described here.
- Look for Zone: Identifier
When a file is downloaded from the Internet onto a computer running Microsoft Windows, the operating system adds an alternate data stream (ADS) to the file to store Zone: Identifier metadata. This metadata includes information about the file, such as information about the URL from which the file was downloaded, and Windows uses it to show appropriate warning messages to the user before opening potentially untrusted content.On the other hand, when a file is copied into a sandbox for analysis, this Zone: Identifier metadata is usually not present, as the sandbox cannot know where the file originated. Malware will check for this discrepancy. The presence of the Zone: Identifier ADS hints at a real user machine. If it is not found, the malware concludes that it is in a sandbox. - WMI-Based Evasions
The WMI interface allows Microsoft Windows machines and any service running on them to query information about running processes, available services, hardware (e.g., disk) information and more. Typically, system administrators use WMI to automate tasks. At the very least, sandboxes have to monitor the primary subject, i.e., the program that is to be executed, and the processes with which it interacts. Interactions can be as simple as one program starting another or injecting new code into a target process. WMI is simply another type of inter-process communication (IPC), but it uses a more complicated client-server model. More precisely, it uses advanced local procedure calls (ALPC) to send queries to be executed in the context of system server processes.
If a sandbox is not able to intercept this type of communication, it will miss the activities performed by malware using WMI. Examples of malware using WMI to evade sandboxes include:
- Checking cores count—Due to resource constraints, sandboxes attribute the minimum required central processing unit (CPU) cores to a VM, typically just one, so they can run in parallel on as many VMs on a server as possible. However, most modern computers have multiple CPU cores. Malware will execute a WMI query to fetch the cores count, and if the value is one, it concludes that it is running inside a sandbox.
- Checking disk space and physical memory—Just like the case for CPU cores, VMs are typically allocated a limited amount of disk space and physical memory. To detect if it is running on a VM, malware checks if the total disk space of the drive is low, such as below 80 GB. Similarly, it checks to see if there is a small amount of physical memory, such as less than 1 GB of RAM. These configurations are not typically found on end-user machines.
Without the ability to see this type of IPC, a sandbox is unable to intercept (and manipulate) the data returned by the server process. Thus, malware finds limited hardware resources and detects the sandbox.
BIOS Info
Basic Input/Output System (BIOS) information for VMs and emulators is different from BIOS information for a real system, and it often contains strings indicative of VMs. Malware can create a list of strings found in BIOS information for VMs and can check if the current system BIOS information contains those strings. If so, malware can be fairly certain that it is running in a VM.
Geolocation Blacklisting
The Internet offers various services that allow a user to request geolocation data based on the client’s IP address. Maxmind is one such service, and malware can query this service to get information about the system on which it is running. One piece of available information is the company to which the IP is assigned. Malware compares this data to a list of known vendors, e.g., security companies. A match will indicate that it is executing inside a sandbox.
Check Username
Malware also fingerprints the sandbox using the name of the logged-in user. This trick works because some vendors do not randomize the Windows user under which the analysis is run. The malware simply checks the username against a list of well-known usernames attributed to sandboxes. For example, older versions of two well-known public sandboxes, Hybrid Analysis, and Malwr. com used to have fixed usernames, KR3T and PSPUBWS, respectively. This makes it easy for malware to detect these sandboxes based on the name of the current user.
Using Specific Instructions
Modern virtualization technologies support instructions that will unconditionally provoke a “VM Exit” into the hypervisor (a system that creates and runs VMs). This allows a VM to modify how the instruction triggering the VM Exit behaves, similar to an interrupt handler. However, this interrupt introduces a discrepancy in the execution time: When executed on a real machine, such instructions are faster than when they are executed inside the hypervisor managing VMs. Malware can use this discrepancy to detect the hypervisor, thereby tipping it off that it is running inside a VM. For example, it can measure the execution time of the CPUID instruction and compare it to the expected execution time of this instruction on a real machine.
Timing-Based Evasion Examples
A final category of evasion includes techniques that use a variety of timing mechanisms. Recently detected examples include using delay APIs, sleep patching and time bombs.
Using Delay APIs
Some sandboxes are programmed to simply wait and watch for a period of time, and if a file does not do anything malicious, it will release the file. To avoid this, the malware uses the Sleep and NtDelayExecution APIs available in Windows. The malware calls these functions to sleep for a period of time to outwait the sandbox.
Sleep Patching
Sandboxes will patch the sleep function to try to outmaneuver malware that uses time delays. In response, malware will check to see if time was accelerated. Malware will get the timestamp, go to sleep and then again get the timestamp when it wakes up. The time difference between the timestamps should be the same duration as the amount of time the malware was programmed to sleep. If not, then the malware knows it is running in an environment that is patching the sleep function, which would only happen in a sandbox.
Time Bombs
Another way that malware tries to outwit sandboxes is to include code that will only run on a specific date sometime in the future—criminals can be very patient—especially for targeted attacks. The goal is simply to outwait any timing delays introduced by a sandbox.
Recommended Techniques for Detecting Malware
To be effective, security technologies must be able to detect malware that uses these and many other techniques to avoid detection, including new evasion strategies that criminals continue to develop in response to ever-improving security systems.
The good news is that while evasive malware poses a challenge to traditional sandboxes, modern analysis sandboxes are built on a technique called full system emulation. The key difference between sandboxes based on virtual machines and those based on code emulators is that VMs typically do not fully virtualize the CPU used to run malware code. Instead, it passes most instructions through to the underlying hardware-supported hypervisor for execution.
A code emulator, on the other hand, directly handles each instruction executed within the analysis system and is thus able to tamper with the execution in any way the system wants to. This is done in a way that is completely transparent and invisible to the malware program under analysis.
For example, a full system emulator can tamper with the outcome of string comparison instructions (e.g., when used to compare the username of the system) and force execution down a path that reveals a program’s true intent. Similarly, it can detect when a program is executing instructions that allow fingerprinting the hardware configuration and manipulate the effect of this code in a way to trigger additional behavior, helping it to correctly classify malware.
Even more, using full system emulation gives the sandbox complete visibility into the inner workings of programs running inside the analysis sandbox. That is, instead of only observing how a program interacts with the operating system (e.g., via system calls), a code emulator can also track data that are processed by the instructions making up the malware program. As a result, the sandbox can not only track what type of data is read from the operating system but also how they are used, to what values they are compared (e.g., in code fingerprinting the system), to where the data are sent (when leaking confidential data) and much more.
Last, but not least, by having instruction-level visibility into the programs under analysis, a code emulator can also reason about code paths that the malware program did not execute in a particular analysis run. For example, the system can see what other potential behavior may be lurking in the malware that was not triggered during the dynamic analysis, giving the sandbox even more information for classifying a piece of malware.
Avoiding Evasive Malware
Your initial steps to combat Evasive Malware are to ensure AV and/or endpoint protection is on all machines and is ALWAYS up-to-date. Taking things a step further, solutions do exist specifically to address Evasive Malware; these work by telling the malware it’s always in a “hostile environment” so that it never runs. In addition, given that ransomware variants are now adopting some of these techniques, having backups becomes all that much more important as a precaution.
