Analyzing Environment-Aware Malware
A look at Zeus Trojan variant called Citadel evading traditional sandboxes
Fighting traditional sandboxes (or dynamic analysis systems in general) typically comes in the form of detecting the analysis environment or evading analysis through means of behavior triggers as mentioned in a previous blog post: Using High-Resolution Dynamic Analysis for BHO Trigger Detection. Some variants of the notorious Zeus trojan family use a different approach to hinder analysis: Host fingerprinting.
In this evasion technique, the malware sample computes a unique fingerprint of the host when it infects the system and embeds this fingerprint inside the malware binary. Whenever the malware starts execution, a new fingerprint of the host running the program is computed and compared to the original host’s fingerprint. This enables the malware sample to detect if it is running in an unexpected environment, and to take different set of actions in this case.
As a consequence, whenever security vendors try to analyze a copy of a suspicious program in a (even slightly) different environment than the one where the sample was captured, the malware program can detect the different environments and will not reveal any malicious behavior, defeating correct classification. In a way, this technique resembles Digital-Rights-Management (DRM) that prohibits the use of illegal copies of licensed content.
Others have identified this as a very difficult problem, but clearly, modern dynamic analysis systems, such as Lastline, must be able to handle environment-aware or -sensitive malware programs. Using High-Resolution Dynamic Analysis, our Lastline CPU emulation engine is able to defeat this kind of attacks, as we explain in the rest of this blog-post as well as our whitepaper on multi-path execution.
Defeating Host Fingerprinting
The Zeus variant we are looking at in this blog-post is called Citadel . The way Citadel does host fingerprinting is by using a binary key and a randomly generated application directory and program name during the initial infection phase. More precisely, the code derives an installation fingerprint by encrypting the application’s name and path. This encrypted data is then embedded inside one of the resource sections of the malware program for later use.
Whenever the malware is launched (for example on reboot of the infected host), the code generates a new host fingerprint and compares it to the decrypted value stored in its resources.
Citadel host fingerprint check function
If the two fingerprints are different, it means the program is executed on a new host (such as an analysis environment). As a result, the program can behave differently — for example terminate immediately or hide any malicious behavior.
The high-resolution CPU emulation engine of Lastline has full visibility into the instructions executed by Citadel and can detect the fingerprint calculation. As a consequence, the engine can find the environment-aware code regions and redirect the control flow to execute the malicious behavior of the Trojan.
Say My Name!
A related technique of environment-aware malware is to make exhibited behavior depend on the execution context, such as the process in which the malware code is running. A common trick used by Trojans is to register one of the malware components using App-Init Dlls. These Dlls get loaded as part of any process running on an infected host, including Internet browsers or Anti-Virus software.
When the Trojan code is started in the context of another program, it can use the process name (such as the executable name or command-line) to determine its execution environment. Typically, when running as part of AV software, malware disables the security tool and terminates the Anti-Virus service. On the other hand, when executed as part of a browser, the attacker can steal confidential data of the user as described in a previous blog-post.
Similar to the Citadel example above, Lastline is able to determine that the execution context is used for making a decision that affects the control flow of the program. More concretely, the CPU emulation engine can determine which execution context would yield the most interesting behavior and enforce execution of the corresponding behavior as seen in the example report generated by our system below :
Ironically, we can even use the fact that malware code is environment-sensitive against the attacker, as this sort of behavior is very uncommon in benign applications… turning the bad guys’ tricks against them.
 Link to VT for a recent Citadel sample:
- MD5 cb8a849e9e4df6e9103063d6e67d4ab0
- SHA1 9bc4b2104032925bc031399647a62a3d79938e99
- SHA256 2a6416fb876d4e8220a5514c7248dfa7546cefc00d87e77f075ce4fe7dabb739
 Link to VT for sample
- MD5 c9b2affe8a926d9b5ba3b0ba32d63807
- SHA1 f21b5c7eb01201fbc1d48071fbc81d8509dfefd1
- SHA256 6d105610ff6297deb483962dba0286769ece3dba5f34984e3d02dceddfa4ae9b
Latest posts by Clemens Kolbitsch (see all)
- Ransomware: Too Overt to Hide [Part 2] - April 13, 2017
- Party like it’s 1999: Comeback of VBA Malware Downloaders [Part 3] - November 10, 2016
- Lifting the Seams of the Shifu “Patchwork” Malware - September 4, 2015