Malware authors have been developing techniques with the purpose of hiding their creations from Analysis platforms. Hence, we performed a measurement of which of those are used to detect and break analysis systems based on Dynamic Binary Instrumentation (DBI) Tools.
By Mario Polino
Postdoc researcher @Politecnico di Milano
After decades of research and development, the problem of Malware still persists. Certainly, the approach and the motivation behind malware creation and spread are changed. Nowadays there are several platforms and advanced systems that can perform accurate analysis on software and, in particular, on malware samples. For this reason, malware authors have been developing techniques to hide their creations from such platforms. E.g., They conduct some tests to check if the malware sample is running under a virtual machine or if the list, or the running process, on the system are compliant with what they would expect on a real user personal computer. Any difference added by the analysis system w.r.t a bare-metal user computer is called an artifact. If a malware sample detects it is under analysis, it can avoid any malicious actions resulting harmless. Hence, we performed a measurement of which techniques are used to detect and break analysis systems based on Dynamic Binary Instrumentation (DBI) Tools.
We have classified the detection techniques, specific for DBI Tools, in 4 categories: two of these are actually related to artifacts introduced by DBI Tool itself, i.e., Code Cache Artifacts and JIT Compiler Detection. In Fact, DBI Tools works by recompiling (using an internal Just-In-Time Compiler) the binary, adding some extra codes which perform the analysis within the binary itself. This modified code is usually stored and executed from a memory location, called code cache, different from the original code section of the binary under analysis. A malware (or any program actually) can identify the use of a JIT Compiler, for example, by looking at the pattern of memory allocations and Code Cached by changing the code while running (self-modifying code).
Another easier way that a malware sample can exploit to understand if it is under analysis, is to Detect Overheads. In fact, a binary can estimate the execution time of a function. If the execution of this function is much slower than how is expected in a real world machine, it can safely assume that some types of analysis are slowing down the system.
At last, a malware sample can look at Environment Artifacts like parent process or extra libraries loaded inside the process memory. All these small changes are indications that the sample is running in an instrumented environment.
We built a system called Arancino [1] which is able to detect those evasion attempts and mitigate them. We have runned our system against more than 7000 randomly chosen malware samples from VirusTotal. About 15.6% (1093) of this malware samples have shown at least one evasion technique. The most common one is the self-modifying code, followed by the detection of parent process. Arancino is available on GitHub and in the best “rosticcerie”.
[1] Measuring and Defeating Anti-Instrumentation-Equipped Malware – M. Polino, A. Continella, S. Mariani, S. D’Alessio, L. Fontana, F. Gritti, S. Zanero, Proceedings of the Conference on Detection of Intrusions and Malware and Vulnerability Assessment (DIMVA) , Bonn, Germany, 2017
