Adrian Hada
ATI Security Researcher

Escaping the Matrix—How Malware Evades Researchers (Part 1 of 3)

July 26, 2016 by Adrian Hada

Ixia’s Application and Threat Intelligence (ATI) Research Center is always on the lookout for new threats and better ways of analyzing them to protect our customers. This is not an easy task as malware authors are doing the same from their side – improving their capabilities and means of evading researchers’ attempts at understanding their tools. Supplying the latest threat intelligence for customers of our ThreatARMOR and BreakingPoint devices requires that we stay on top of their tactics.

One of the most important things a piece of malware must do to reach its objective is to remain hidden from security products for as long as possible. Specialized software and hardware will try to identify a malicious application by analyzing its contents (static analysis) or executing it inside a limited, secure environment called a sandbox (dynamic analysis). With static analysis being easy to bypass by packing (encoding and/or encrypting parts of the executable), more and more security solutions rely on sandboxed execution. As a result, more malware authors have started researching means of fooling security products and researchers into believing that an application is harmless. The latest example of this comes with the reports on Furtim malware. SentinelOne’s analysis of this advanced threat is an excellent example of these methods in practice.

The only requirement on the malware side is that the malicious executable discovers that it is being analyzed. There are four principal means that malware can use for analysis detection:

  • Detecting debuggers – an analyst wanting to see the application in action will probably need step-by-step execution at some point; malware detects debugger presence and exits instantly
  • Forensics tool detection – a researcher will require specialized tools (Wireshark, Fiddler, and others) when analyzing the malware; malware detects these and quits, assuming it is being analyzed
  • Detecting commonly used sandboxes – commonly used sandboxes have particularities that can be used to identify them; malware authors will check for known usernames, file paths, Windows product keys, and other such artefacts to determine if they’re being run inside a sandbox
  • Detecting a virtualized environment – analysts could resort to custom sandboxes and tools to avoid the first couple of checks; malware authors can then check whether they’re running in a virtual machine or not, given the fact that most malware detonation is done this way; they might miss out on some targets because of this, but they will avoid prying eyes for longer

In this series of posts I'll introduce you to some examples of how each of these is done. The list of possible means is only limited by the knowledge and imagination of the malware writer so we'll have to settle for a limited set of examples. Seeing these evasion and detection techniques in action should offer a good introduction to the subject. I'll also track samples of detection code that are implemented using an open-source application called Paranoid Fish (Pafish, for short). Sometimes I'll rely on the Pafish helper functions this is to reduce the complexity of some parts of the code (especially WMI/COM).

Paranoid Fish Intro

Paranoid Fish is an open-source project that executes a set of checks that some malware samples in the wild use to detect if they’re running in a sandbox. The application is a Windows executable that does a couple of common checks and logs their results. It doesn't get as many updates as there are new detection methods in the wild, but it's a great starting point.

Here's a screenshot of a run of the app:


This is an execution on a physical machine, so all checks should normally pass. The reason the "mouse activity" check failed is that I wasn't moving the mouse at the time. The screenshot is suggestive of the way the application works – runs the tests and then prints whether it discovered traces of sandboxing or not. After execution, you'll find a text dump in the execution folder as well as several files entitled "hi_<text>" depending on which environment was detected ("hi_virtualbox").

Debugger Detection

Debugger detection can be done in multiple ways. The easiest of them all is using the IsDebuggerPresent() Windows API function. More complex means involve searching through running processes for known debuggers, analyzing some advanced and undocumented Windows data structures to detect debugger presence, trying to crash the debugger by a known flaw, or relying on differences in execution depending on debugger presence.

Paranoid Fish comes with two debugger detection methods. The first is using the Windows API function IsDebuggerPresent:


The second means is more advanced and relies on the different behavior of the OutputDebugString function when running with and without a debugger:This tells you all you need to know about the check itself as well as the way new checks are implemented in Paranoid Fish one function returning an integer value, TRUE when the debugger (or VM/sandbox/...) has been detected, FALSE otherwise.


Forensics Tool Detection

When a debugger is present, the SetLastError function doesn't get called inside OutputDebugString. Without a debugger present, the function will execute but set an error code different from the random error. Note that both of these checks could be fooled by a researcher by hooking into the two functions and modifying their behavior on the debugging machine. This means more advanced checks might be necessary to protect against debugging. These are just two simple examples if you're interested in more advanced topics, use this excellent page as a starting point.

There are a lot of different tools that can be used in the process of analyzing a running executable. There are also multiple ways of detecting the running app either by checking window names, loaded executable modules names, running processes, and others. There aren't any such checks in Paranoid Fish so you won’t get any code snippets for this one but, to exemplify, here are a couple of process names that Furtim malware checks:

  • apispy.exe
  • autoruns.exe
  • autorunsc.exe
  • dumpcap.exe
  • emul.exe
  • fortitracer.exe
  • hookanaapp.exe
  • hookexplorer.exe
  • idag.exe
  • idaq.exe
  • importrec.exe
  • imul.exe
  • joeboxcontrol.exe
  • joeboxserver.exe
  • multi_pot.exe
  • ollydbg.exe
  • peid.exe
  • petools.exe
  • proc_analyzer.exe
  • procexp.exe
  • procmon.exe
  • regmon.exe
  • scktool.exe
  • sniff_hit.exe
  • sysanalyzer.exe

The list of processes includes more than just forensics tools. However, you can easily see how a lot of them might help in analysis tools such as Process Explorer and Process Monitor of the Sysinternals suite track all running processes, API calls, and other information; dumpcap is used by Wireshark to grab network traffic; regmon will track all Windows registry actions; PEiD can detect packers and cryptors used to obfuscate an executable file, and so on. When detecting any of these, the executable encrypted a part of itself and exited, leaving the analyst wondering what had happened. Without an analyst present, an automated analysis application might conclude that the file is harmless and let it pass.

As stated in the beginning, detecting a malware is just one part of the image. It can help avoid manual analysis but automated sandboxes are a different matter – we'll discover how those are avoided in the next chapter of the series.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.