Exposing Rombertik - Turning the Tables on Evasive Malware

Waves of evasive malware keep rolling in. The latest in the series: Rombertik. This malware variant uses a whole arsenal of ways to hide its functionality, including multiple layers of obfuscation to hinder static analysis, as well as stalling code to bypass execution in a sandbox.

But even beyond the obfuscation techniques, this family uses nifty tricks to stay under the radar of security solutions, as we cover in this post.

Stealthy Data Stealer

In most cases, Rombertik spreads via well-crafted emails that use social engineering to dupe a victim into opening an email attachment. The attachment contains an exploit that, once executed, downloads and infects the local machine with Rombertik malware.

The goal of this malware is to steal data the user enters into the browser. For this reason, the malware injects itself into various browsers, including Internet Explorer, Firefox, and Google Chrome. There, it intercepts confidential user data entered in web forms (such as name, address, credit card information, usernames, and passwords) and leaks it to the attackers behind Rombertik:

Analysis overview showing browser injections (View Full Size)

The malicious code intercepts user-input through hooks in browser memory (described in more detail below). Once a user enters confidential information the attackers are interested in, the malware forwards a copy of this data through its command & control channel (contacting, for example, www.centozos[.]org.in). Interestingly, the attackers also disable the use of the SPDY protocol to simplify extraction of the confidential data (SPDY uses compression and enforces the use of SSL/TLS). This is done in secret so the user is none the wiser that personal information has been stolen.

Browser Injection

The way Rombertik injects its hooks into the correct browser on the host is by iterating over all running processes on the system. The malware uses the CreateToolhelp32Snapshot API to enumerate all processes, injecting hooks when it finds Chrome, Firefox, or Internet Explorer.

(View Full Size)

Interestingly, the malware continuously searches for running browsers to hook. It does this by reading from the browser process memory and checking if the 0xe9 JMP instruction, which forms the start of the hook (created in function CreateFileW for Firefox, WsaSend for Chrome, and HttpSendRequestW for Internet Explorer), is in place. If the browser-memory already contains a hook - for example, because an analysis sandbox injected one itself - the malware will skip revealing its payload.

Our analysis environment does not tamper with process memory, and is invisible to the malware under scrutiny. Therefore our analysis is not affected by this problem.

Evasion via Stalling Code

Another interesting point about this malware family is that it does not only conceal itself by executing within a browser, but Rombertik also tries to evade execution in a sandbox. It does so using stalling loops, in which it accesses process memory many millions of times.

(View Full Size)

As we described in our anti-stalling code whitepaper in more detail, this busy-waiting approach evades analysis in some traditional sandboxes. The overhead of logging the behavior inside the loop slows down execution to a point where the sandbox analysis times out.

Since the Lastline sandbox uses FUSE (full-system emulation), our virtual CPU can identify this stalling loop, and adjust our analysis to get around this code, revealing the entire behavior of the malware.

Information Overload

Another significant obstacle that Rombertik throws at human reverse engineers is that it complicates static analysis by adding many (many!) different functions to its executable. These functions do not add meaningful logic to the program, but merely make finding relevant code-regions (that contain the actual, malicious payload) very tedious.

Rombertik call-graph; 99% of functions were removed to fit in a screenshot (View Full Size)

Because the sandbox automatically extracts full-process dumps from the execution and pinpoints code-regions containing functionality of interest, analysts can quickly find the needles in the haystack Rombertik malware authors so arduously hid.

Summary

Advanced and evasive malware families like Rombertik are on the rise. The frequency in which we see new variants appear that attack analysis inside sandbox-based systems is rapidly increasing. What was once a rare occurrence has become common, and the good news is there are security technologies available to stop evasive malware like Rombertik.

Many of the evasive behaviors, such as stalling code, require a FUSE analysis environment to overcome the obstacles the malware authors build to defeat sandboxes that do not effectively mimic target machines. Only when the analysis system is able to bypass these evasions by functioning like a complete target machine from CPU to web browser can it extract the behaviors necessary to identify these new malware families.

Our analysis revealed many if not all of the evasive maneuvers hidden within the mountains of code packed inside Rombertik and exposed its true nature. Importantly, we were able to automatically detect and dissect these evasive  behaviors. While some of these behaviors have been previously discovered and discussed by other researchers and malware analysts,  in most other cases that requires lots of tedious manual analysis. Additionally, the destructive wiping behaviors triggered by other sandboxes did not occur in our analysis environment, indicating Rombertik is not able to detect our sandbox and therefore does not attempt to destroy it. When it comes to detecting and stopping evasive malware, being able to automatically detect malicious behavior within millions of executions rapidly without tipping off the malware that it is in an analysis environment is critical. Only then can we turn the tables on evasive malware authors: forcing them to spend more time and resources crafting attacks than we spend defeating them.