Using High-Resolution Dynamic Analysis for BHO Trigger Detection

Using High-Resolution Dynamic Analysis for BHO Trigger Detection

Looking at how malware analysis engines evolved over the last decade, the trend is quite obvious: Dynamic analysis systems are replacing purely static ones or at least combine elements from both approaches. While the advantages of dynamic analysis are convincing – resilience against code obfuscation or encryption – attackers have various techniques at hand to complicate dynamic analysis and possibly evade these systems.

Lastline’s answer to these attacks is what we call High-Resolution Dynamic Analysis. In a series of upcoming blog posts, we want to look at how our high-resolution sandbox tackles evasive code present in most of today’s Advanced Persistent Threats (APTs). These attacks range from environment-fingerprinting, to sandbox evasion, to behavior triggers.

High Resolution Dynamic Analysis

Lastline Analyst – our analysis product allowing forensic and audit teams to analyze zero-day exploits, advanced persistent threats and malware as well as the analysis backend for Lastline Enterprise – has one key-discriminating feature that distinguishes it from traditional analysis sandboxes: The analysis engine is built on top of a CPU emulator, which allows the engine to see every instruction executed by a malware program under analysis.

Traditional dynamic analysis engines only monitor interactions between an analysis subject and the operating system (through native system- or API-function calls) or communication between processes running inside the analysis environment. This is a practical approach for monitoring the behavior of the analysis subject, but suffers from crucial blind spots that an attacker can use to either detect or even entirely evade an analysis system.

Lastline’s engine, available in both Lastline Analyst and Lastline Enterprise, closes this blind spot by combining traditional API call monitoring and CPU emulation to find malicious behavior that does not rely on explicit interactions with the operating system. In addition Lastline is able to deal with the sophisticated evasion attempts that are common in today’s APTs.

Analysis of Evasive Malware

Lastline contains a reporting feature that provides security analysts and network administrators with a fast overview of the analyzed malware’s behavior. This gives a summary of the analysis without having to read dozens of pages of analysis logs and having to understand the meaning of various OS internals such as the Microsoft Windows Registry or Android Service Intents.

In a follow-up blog post, we will show more details about the Activity Summary, for now just consider the following example:

Lastline Evasive Malware Risk Assessment
Analysis report overview showing score, classification, and activity summary

Without having to dig deeply into the report details, the Activity Summary gives the user a fast classification into high-level classes, such as benign or malicious, as well as an overview of the behavior exhibited during the analysis. Additionally, it highlights the key points that experienced researchers should focus on, when drilling further into the detailed analysis results.

For the rest of this blog-post, and as an outlook into a series of follow-up posts, we want to focus on a subset of the events in the above summary concerning evasive malware:

Evasive Malware Event Listing
Analysis report activity summary

These entries highlight a combination of two behaviors found in many of today’s advanced threats: Evasive behavior, i.e., revealing certain actions only in specific circumstances (e.g., the presence or absence of certain programs, such as analysis tools or AV products), as well as stealing a user’s confidential data (such as banking or gaming credentials).

Trigger-Based Dynamic Analysis

Combining environment checks with specific behavior is a major concern for traditional analysis sandboxes based on API-logging alone, as explained earlier. To make things more concrete, let us look at an example:

One common technique used by today’s malware to steal a user’s confidential data is to inject code into the user’s web-browser (such as Internet Explorer, Firefox, or Google’s Chrome Browser). This attack, usually called Man-In-The-Browser, allows the malware to get notifications about the user’s browsing activity without having to worry about secure connections through SSL or other security features (such as 2-factor authentication used by many web services). All the attacker has to do is manipulate the website’s Document Object Model (DOM) and register callbacks on interesting events, such as submissions of forms or loading of specific pages within a web service. By registering event listeners inside the DOM, the browser will notify the attacker’s code of data retrieved from or sent to specific URLs or web services.

An example for this kind of attack are Browser Helper Object (BHO) plugins that the popular botnet Alureon is injecting in Microsoft’s Internet Explorer: These BHOs monitor the URLs that a user browser visits and inject a number of JavaScript functions into the DOM as soon as an interesting URL is found. In the case of Alureon, interesting URLs are a set of (mostly Korean) banking and gaming websites, targeting individuals and companies alike.

Code extracted from Alureon BHO for injecting event listeners

Code extracted from Alureon BHO for injecting event listeners (converted to pseudo-code)

Traditional sandboxes are mostly unable to detect this specific behavior, as their API monitoring techniques are unable to detect the URLs that trigger the injection events in the DOM. Lastline’s CPU emulation technique, on the other hand, can see how the malware’s browser plugin checks for URLs triggering certain behavior, and, as a consequence, can direct the browser to specific URLs for revealing additional behavior otherwise not extracted.

When analyzing a set of BHOs dropped by recent Alureon samples [1], the analysis engine is able to detect and extract the trigger component (checking for the URLs that trigger a certain behavior) as well as the stealing component that injects the event listener functions into the DOM. This happens fully automatically during analysis and is summarized in the analysis report overview and report details.

At the time of analysis, these URLs included online-banking and gaming sites alike, such as:










Additionally, the engine extracts the JavaScript code that is injected when these URLs are visited.

JavaScript event listeners injected into the DOM

The listeners that Alureon registers hook DOM events to extract user data (such as usernames and passwords), temporarily storing them in a cookie named IEPROXY. Later, this data is extracted from the cookie and sent to the attacker. Additionally, the BHO hides specific DOM elements.

Clearly, without Lastline’s high-resolution analysis engine, a sandbox would neither detect the triggers (visiting a URL in this case) or be able to extract the JavaScript code, as it is only injected when one of the triggers hits.

I invite you to register for Lastline Analyst and gain the ability to analyze up to 25 files per day for free. There is no hardware installation needed to try it out.

Register for Lastline Analyst

You can can also request a 30-day evaluation for Lastline Enterprise and gain the ability to analyze files from your network.

Register for Lastline Enterprise

[1] Links to VT concerning a few samples:

Clemens Kolbitsch

Clemens Kolbitsch

Clemens is a Security Researcher and engine developer at Lastline. As a lead-developer of Anubis, he has gained profound expertise in analyzing current, malicious code found in the wild. He has observed various trends in the malware community and successfully published peer-reviewed research papers. In the past, he also investigated offensive technologies presenting results at conferences such as BlackHat.
Clemens Kolbitsch