Diving Into Buhtrap Banking Trojan Activity

Cyphort recently published an article about the Buhtrap banking trojan [https://www.cyphort.com/banking-malware-buhtrap-caught-action/], targeting users of Russian and Ukrainian banks as reported in March of 2016 by Group-IB [http://www.group-ib.com/brochures/gib-buhtrap-report.pdf]. Cyphort’s insightful article analyzes the compromise chain from the website eurolab[.]ua, directing users via an apparently injected HTML script src attribute to rozhlas[.]site which served exploit code for CVE-2016-0189 (Internet Explorer 11 VBScript Engine Memory Corruption).

Detonation of the exploit code leads to the download of the first stage malware, which is responsible for profiling the system, then downloading the actual Buhtrap malware or a non-malicious binary depending upon the execution environment. Systems that show indications of being involved in certain banking operations will receive the malware (sometimes in the form of an NSIS installer package), and other systems will receive the non-malicious binary. In some cases, sandboxes won’t execute the malware properly.

The first stage malware discussed has the SHA-256 hash value of cd703f7bd0e449fbc9ccdaaae85beef2f874988236a50cd40d3f93b817d5b670. The website rozhlas[.]site (now offline) was a generic staging ground, used to host the Buhtrap malware and the non-malicious binary as well as the exploit code.

Figure 1: One Example of a General Workflow for Buhtrap Malware Installation

Selectively downloading second-stage malware depending upon target profiling is a tactic that has also been deployed by other generic malware staging/loading systems, such as Andromeda, that in some cases specifically hunt for Point of Sale operations. Analysts and incident responders need to be able to follow threat and exploitation activity to reach second stage payloads in order to gain full insight. The popularity of automated analysis environments via sandboxing unfortunately means that threat actors are continuing to invest in malware execution tactics that will decrease visibility when the payload is detonated in such an analysis environment.

While the Cyphort blog does a nice job analyzing the first stage, there is additional context and other indicators surrounding this first stage of threat activity that may be of interest to network defenders and threat intelligence analysts.

Regarding the profiled sample discussed by Cyphort - the C2 domain rozhlas[.]site appears to have only been used to serve malicious content, based on a variety of search engine inquiries that showed nothing other than threat actor activity. In addition to the aforementioned site eurolab[.]ua that pointed towards rozhlas[.]site on August 19, 2016, other sites in Russia and Ukraine were redirecting users there as well, via script src redirections. While we do not have the actual page contents in question, a list of other sites using the script src tactic during the same timeframe is as follows:

Since rozhlas[.]site is clearly used by threat actors associated with Buhtrap, it is interesting to look at additional malware samples that initiate network connectivity to rozhlas[.]site.

Sample #1: Knock

a0c428ae70bfc7fff66845698fb8ce045bffb3114dde4ea2eac19561a619c6c8

This sample makes an outbound connection to http://rozhlas[.]site/knock.html, which corresponds in name to the PDB string found inside the binary C:\Users\dev\Documents\Visual Studio 2015\Projects\knock\Release\knock.pdb.  This sample also contains an interesting HTTP User-Agent value used in the outbound connectivity to the knock URL. The HTTP header observed during analysis is as follows:

GET /knock.html HTTP/1.1 Accept: text/* User-Agent: Mozilla/5.0 (compatible; MSIE 273.0; Windows NT 6.1; WOW64; Trident/5.0; MASP) Host: rozhlas.site

This User-Agent has never been observed in the wild (based upon the ASERT HTTP corpus that contains nearly 120 million HTTP client headers collected from a global vantage point) and therefore may be worthy of additional research as a reasonable part of network and/or YARA-based detection mechanism. While only one sample of this malware has been discovered so far, it may appear again. Therefore, a YARA rule to detect this sample is as follows

rule buhtrapknock {

meta:

 author = "Curt Wilson"
 org    = "Arbor Networks ASERT"
 hash   = "a0c428ae70bfc7fff66845698fb8ce045bffb3114dde4ea2eac19561a619c6c8"
 desc   = "connects to C2 and issues HTTP client request for knock.html"

strings:

 $s1 = "C:\\Users\\dev\\Documents\\Visual Studio 2015\\Projects\\knock\\Release\\knock.pdb" ascii wide
 $s2 = "User-Agent: Mozilla/5.0 (compatible; MSIE 273.0; Windows NT 6.1; WOW64; Trident/5.0; MASP)" ascii wide
 $s3 = "/knock.html" ascii wide

condition:

uint16(0) == 0x5a4d and 2 of ($s*)

}

This sample, which appears to be a downloader according to anti-malware detection schemes (which can of course be generic and inaccurate), was discovered in the wild using the filename cache.bin.

Based on the presence of “Knock” in the code and in the network communications, it is possible that the purpose of this sample is merely to notify the coordinating threat actor (aka “botmaster”) that another machine has been compromised. It is also possible that a connection to the C2 with this unique HTTP client request triggers some other type of process, although without access to the server side code or a live C2 this is difficult to determine.

The sample was created during the execution of two other malware samples, 6e43b7aff8a151eef979493b98eec3ce447489e9ec4deab656a40ef3ed0ca6ab, and 97f80175fb58cc514bdcb79d11fe1bcec1b74422171d9493d179a90dcacd7d93 which will be profiled as sample #2 and sample #3 in this set.

Sample #2: Buhtrap Profiler, drops Knock

6e43b7aff8a151eef979493b98eec3ce447489e9ec4deab656a40ef3ed0ca6ab

This file was found at URL http://rozhlas[.]site/news/business/cache.bin on 9-7-2016.

This sample was observed to connect to http://rozhlas[.]site/news/business/release.bin with the User-Agent Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0).

Analysis of a memory dump reveals a listing of 120 distinct EXE files including filename and extension. All of the extensions were .EXE, except for one instance of .ex and one instance of a .dll extension. In total, 122 files were in the list. All of these filenames match the list of banking software that Buhtrap is looking for (as provided by Cyphort at https://www.cyphort.com/wp-content/uploads/2016/09/Files.png) with the exception of the name wclnt.exe. Wclnt.exe appears to be associated with Sberbank of Russia. Sberbank is described on Wikipedia as such:

Sberbank of Russia is a Russian banking and financial services company headquartered in Moscow. Sberbank has operations in several European and post-Soviet countries.

While the Buhtrap first stage malware is only looking for the presence of the wclnt.exe software in order to trigger the download and execute of stage two, the Sberbank software wclnt.exe has also been specifically targeted by other banking malware, such as Carberp. We can see this from reviewing the Carberp source code published in mid 2013 at https://github.com/hzeroo/Carberp/blob/master/source%20-%20absource/pro/all%20source/BJWJ/source/RuBnk/Sber.cpp

The same filename wclnt.exe appears in an analysis of the Ranbyus banking Trojan, mentioned in early 2013 by Xyliltol at http://www.xylibox.com/2013/01/trojanwin32spyranbyus.html.

Sample #3: Buhtrap Profiler, drops Knock

97f80175fb58cc514bdcb79d11fe1bcec1b74422171d9493d179a90dcacd7d93

This appears to be another instance of the Buhtrap first stage malware that profiles the system and downloads either an innocuous payload or the second stage Buhtrap malware.

In the original sample, which is packed or encoded in such a manner as to obfuscate some aspects of functionality, we can observe what appears to be some type of key.

A YARA rule to trigger on the presence of this key and some other identifying characteristics is as follows:

rule buhtrapkey {

meta:

 author = "Curt Wilson"
 hash   = "97f80175fb58cc514bdcb79d11fe1bcec1b74422171d9493d179a90dcacd7d93"
 desc   = "Buhtrap Related Malcode"

strings:

 $s1 = "1A59D5ABEBFD652D826A976C3C81CC6C"
 $s2 = "ReturnValue" ascii wide

condition:

uint16(0) == 0x5a4d and all of ($s*)

}

In practice this YARA rule works best when applied against memory dumps of the first stage Buhtrap malware component, but may work on primary malware samples as well, depending upon their structure. A filesize parameter could be added into the condition section, however this value should be larger than the largest memdump in question.

Sample #4

04e473e49695503226bcc16e74765a700c53a0ed185228ac40ba371ace71e8e8

The fourth Buhtrap related sample we examine contains a URL pointing towards a known benign payload at rozhlas[.]site/news/business/release.bin.

This sample, like others, uses the filename LogParser.exe in an attempt to masquerade as the Microsoft Log Parser utility, and uses the following icon:

File properties of the malware are also intended to mimic the presence of Log Parser 2.2:

The legitimate LogParser.exe has similar properties:

This sample is signed Bit-Trejd, a point that will be discussed further in a pending writeup. The real LogParser.exe binary is signed by Microsoft, not Bit-Trejd. This suspicious signature should be a dead giveaway of a problem.

Analysis of other malware signed by this certificate will be covered in part two.

YARA Rules: http://www.netscout.com/sites/default/files/asert-blog/uploads/2016/11/Buhtrap_yara_ASERT.zip

sha-256: 681a9de3918b987302b895b29b0bba6c8d430847d5a8234d9e4ab748a4885624

IOC's in CSV format: http://www.netscout.com/sites/default/files/asert-blog/uploads/2016/11/buhtrap_ioc.csv

sha-256: 3fa6f753fd195ced50e40ff5fd366e8586c6752ab3b371ad8b19a6c04f5fe21f

Conclusion

This post is intended to provide additional context around the Buhtrap threat, and has provided additional indicators and data useful to incident responders and other threat researchers.