Last updated at Tue, 05 Dec 2023 19:08:27 GMT
The neverending fight with malware forced researchers and security firms to develop tools and automated systems to facilitate the unmanageable amount of work they've been facing when dissecting malicious artifacts: from debuggers, monitoring tools to virtualized systems and sandboxes.
On the other side, malware authors quickly picked them up as easy indicators of anomalies from their target victims' systems.
This has initiated a still ongoing arms race between malware writers and malware analysts, during which a lot of new tricks and technologies that came up were respectively defused by the opposite side: an anti-debugging mechanism can be evaded by hiding the debugger, detection of a virtualization software could possibly be defeated by choosing another product, obfuscation can be reversed with plugins for static analysis tools and dead code eliminated with differential debugging.
So basically whenever a new "anti" functionality appears in malware, researchers try to adapt their methods to evade or defeat it. However there is a trade-off in this arms race: often we can more easily classify an executable as malicious by the detection/evasion it implements. If the detection mechanism has false positives, the attacker could miss out on potential victims.
With malware analysis sandboxes and virtualization becoming increasingly popular for automated analysis and processing of suspicious files, the adoption of anti-virtualization technigues by malware authors is becoming just as common. As sandbox developers ourselves this can get quite frustrating, but what if we subvert this trend to our advantage?
If all workstations in a company would look like virtualized analysis environments, they would not get infected by most VM-aware malware. Consequently we could use this as proactive countermeasure by placing common indicators into our systems and thereby "vaccinate" them against a large amount of malware. We could also increase our chances by introducing fake indicators of debuggers or other analysis tools.
As an example, the screenshot on the right shows the output of "pafish", a tool that checks for artifacts typical of a virtualized environment. After putting several indicators into place, pafish detects them successfully.
One can find these detection and evasion features in several malware families. Looking at an instance of the "Rebhip" trojan, we find several of these methods being used as shown in the flow graph below.
After identifying one of the malware's string comparison functions we can trace its usage and quickly verify that it compares running process names against "VBoxService.exe" as one of its detection techniques.
... call from 0x407819 strcmp("VBOXSERVICE.EXE",
"[SYSTEM PROCESS]") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "SYSTEM") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "SMSS.EXE") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "CSRSS.EXE") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "WINLOGON.EXE") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "SERVICES.EXE") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "LSASS.EXE") = 0 call from 0x407819
strcmp("VBOXSERVICE.EXE", "VBOXSERVICE.EXE") = 1 call from 0x40d6fc
ExitProcess
Therefore in a VirtualBox virtual machine with guest utilities installed, this specific malware sample would not conduct any malicious activity in order to evade automated analysis. Also using a debugger without hiding its presence will have the same effect.
Building a small proof-of-concept tool for placing similar indicators can be trivial. We put together an example that contains a few VirtualBox and VMWare indicators and pushed it to a Github repository. It installs a few registry keys, directories, files and spawns some processes with names related to these products as well as a fake Olly Debugger. The repository has a built binary as well.
This idea is by no means new or unique - others have used similar approaches before. Tillmann Werner and Felix Leder created "nonficker", a tool that pre-registers Conficker mutexes on a system in order to inoculate it against Conficker infections. As a high percentage of malicious samples uses mutexes to limit double infection, one could imagine a tool that uses this technique for protecting against all those samples at the same time. Sadly it is quite time-consuming to reconstruct the correct mutex generation algorithm that is used in the malware itself.
What do you think of the technique and the tool? Would you run this on your employee workstations to thwart infection by some VM-aware malware?
If largely adopted such techniques could make it more expensive for attackers to be successful and force them to either choose to give up on infecting "vaccinated" systems or to abandon the use of such anti-virtualization techniques, making life of malware analysts and security firms way easier.
While being just a simple trick targeting a specific subset of malware in the wild, it wants to be an example on how using out-of-the-box techniques and being dynamic enough could let us gain an upper hand in the struggle against malware.
UPDATE: We were pointed to a paper containing this technique from 2008. They did even go further and put in more indicators and evaluated the concept on a larger set of malware. While I did not know the paper before, I already mentioned that people had been doing similar approaches and we did not invent the method. This post's focus was to bring up the discussion again and on the quick creation of a small poc that people could actually run if they wanted to. It's good that we have a source promising decent effectiveness of the technique - so thanks!
This is a Rapid7 Labs research brought to you by Mark Schloesser and Claudio Guarnieri. Greetings to Tillmann and Felix for their great work on Conficker .
