Deep Instinct is revolutionizing cybersecurity with its unique Deep learning Software – harnessing the power of deep learning architecture and yielding unprecedented prediction models, designed to face next generation cyber threats.

Anti-Sandboxing Malware

Malware Evasion Techniques Part 3

Nov 24, 2019 | Shaul Vilkomir-Preisman

This blog, which follows up on our previous blog and is part of our series on different malware evasion techniques, will focus on various methods employed by malware to detect and avoid Analysis/Sandbox environments which are unrelated to the virtualization infrastructure itself and are aimed more generally at dynamic analysis avoidance.

 

Analysis environment/Sandbox detection and avoidance

Time-delay based avoidance

One of the simplest and long-lasting methods of analysis and sandbox avoidance is based on the simple premise that any sandbox will only allocate a finite amount of time (usually only several minutes) for each given analysis before moving to the next sample in its queue.

By delaying its execution beyond this timeframe malware can hide its malicious actions and activities from the sandbox. This is commonly accomplished either by using the “Sleep” or “NtDelayExecution” Windows APIs, which some sandboxes patch in order to circumvent this behavior. As a result of this, some malware has evolved to detect these patches as an additional indicator of an analysis/sandbox environment. This is done by taking a timestamp, going to sleep, and checking the timestamp upon waking up. If the time difference from the previously taken timestamp is substantially different than the time the malware was programmed to sleep, the malware will avoid or adjust its execution. An example of a similar timestamping mechanism can be found in MyloBot, which Deep Instinct discovered during the summer of 2018.

User checks

Over time malware developers have also added methods to avoid sandboxes and analysis environments by performing various checks to see if there is an actual user operating the machine the malware is being executed on.

Examples:

  • Mouse cursor position – by checking for mouse cursor position changes over time, malware can detect machines which aren’t operated by actual users, if the mouse cursor position is found to be permanent, the machine is much more likely to be a sandbox.
  • Recent file count / Desktop file count – if the executing machine is found to have a low count of recently opened files or files on the desktop, it is much more likely to be a sandbox.
  • Screen resolution – if the executing machine’s display resolution is found to be unusually low (for example 800×600), something a contemporary user will not likely tolerate, the machine is more likely to be a sandbox.
  • Running an application count / Active window count / Process count – if the count of currently running applications or currently active windows or currently running processes is found to be unusually low, the machine is much more likely to be a sandbox, as a normal user will usually have at least one or two applications running at any given time.
  • Low CPU core count / RAM – if the CPU core count and/or amount of available system RAM is found to be low (for example a single CPU core, and 1GB of RAM) the machine is much more likely to be a sandbox, as a contemporary user is unlikely to tolerate such a machine.

Anti-Researcher checks

Over time malware developers have gained insight into the tools commonly used by malware researchers and analysts and have modified their malware accordingly to avoid or adjust its execution if such tools are detected as present or active on the executing machine. These tools include debuggers, disassemblers, networking monitoring utilities/sniffers and other utilities.

Examples:

  • Wireshark.exe
  • Fiddler.exe
  • Procmon.exe / Procmon64.exe
  • Procexp.exe / Procexp64.exe
  • Sysmon.exe / Sysmon64.exe
  • ProcessHacker.exe
  • OllyDbg.exe
  • ImmunityDebugger.exe
  • Windbgx86.exe / Windbgx64.exe
  • x32dbg.exe / x64dbg.exe
  • Python.exe

Summary & Conclusion

By employing any number of combinations of the above and previously described checks, methods, and techniques, malware can gain a substantial degree of environmental awareness and avoid or adjust its execution if it detects it is being executed in an undesirable environment.

The cat and mouse game between malware developers and malware researchers and analysts is constantly afoot, with each side developing their own ways and means to either avoid or improve detection.