Banking trojans – true to their name – typically steal web credentials from users of financial services websites. Targeted services can include banks, wealth management firms, investment banks, retirement investment services companies and others – essentially any website where money can be accessed and managed.
Hoping for a lucrative payday, attackers steal credentials by performing a ‘man in the browser’ attack. In this attack, a trojan is used to capture credentials that a victim unwittingly enters when they access their financial account online. Not surprisingly, this type of attack can have a significant impact on the individual as well as the organization operating the service.
Man-in-the-browser attacks have been a popular choice and play a key role in delivering the payload stage (i.e. malware) in numerous campaigns — including the Blackmoon banking trojan that stole credentials of more than 150,000 Korean users in July 2016.
From late 2016 into 2017, Fidelis Cybersecurity Threat Research observed two separate campaigns that delivered the Blackmoon banking trojan while utilizing a unique and interesting framework. A key characteristic of that framework involved the use of three separate downloader pieces that appear to work together to ultimately deliver Blackmoon (aka, KRBanker) malware onto geo-targeted systems. Interestingly, the campaign that we observed is designed to operate on systems operated by Korean users and targets multiple South Korean financial institutions.
In this report, we provide details on the Blackmoon Downloader Framework to assist the threat research community.
- A unique and involved tri-stage framework has been observed specifically delivering the Blackmoon banking trojan. The framework provides multiple capabilities to be deployed in separate, but closely related, components. We’re calling this framework the Blackmoon Downloader Framework.
- The framework is tightly coupled and designed to operate in sequence to facilitate multiple objectives, including evasion as well as geolocation targeting. The multistage downloader serves a practical purpose: It is another tactic used presumably to avoid detection, as functionality is distributed between these separate (but related) components.
- The campaigns we’ve observed using the framework are clearly operating against South Korean targets. The framework itself is configured to only deliver the malware to systems where the default language is set to Korean.
- Numerous South Korean websites are observed in the Blackmoon sample, including Samsung Pay, Citibank Korea, Hana Financial Group, KB Financial Group and others. A full list of observed targets is available at the end of this post.
Stage 1 – Initial Downloader
The initial downloader piece is very small, and some instances can be under <10KB in size. This size is not surprising, however, as the downloader has very basic functionality:
- Perform a GET request against a hardcoded URL,
- Download the response data, and
- Execute the data.
Responses are normally around 8KB in size and the bytecode is transmitted in the clear. While all the instances of this bytecode we found are roughly designed to accomplish the same thing, it should be noted this technique allows the actors to run any code they want on the infected machine. In this respect, this technique essentially serves as a backdoor.
The string for the download location of the bytecode URL is hidden by moving a single character at a time into position.
Stage 2 – Bytecode Downloader
Upon execution, the downloaded bytecode simply resolves any functions it will need. It then decodes an onboard blob of data with a single byte XOR. This contains the URL for the next download, which we observed to be a single-byte XORd PE file named as a jpg.
The naming of this entire structure is interesting. The bytecode is downloaded from the file path ‘/ad_##/cod##’ and the PE file downloaded as ‘/ad_##/test##.jpg’. This caught our attention because the numbers are the same when you go through the entire chain.
This makes us estimate that all of these files are built at the same time, which would make each number a build number. Further, we estimate that, because none of the files appear to be generated on the fly, the XOR keys are all hardcoded in each subsequent section.
Based on this information, we conclude that the stages of the framework were all built to operate together in this sequence of events.
Stage 3 – Fake Image KRDownloader
This bytecode then downloads and runs a PE file that is XORed and has a jpg extension. The file, however, is only pretending to be an image like its name suggested. All related campaigns had similar names revolving around ‘test##.jpg’. This downloader has a specific check to verify that the user’s default system language is Korean. When the user’s language is not Korean, the bot simply dies.
This portion of the framework also uses a string encoding technique that has been previously discussed by researchers from Palo Alto Networks. The framework, related to KRBanker/Blackmoon, encodes the strings with base64, swaps the case of the letters, and replaces the padding character ‘=’ Swith ‘@’.
The decoded strings are interesting — one of a URL to download another ext file, and one of an IP. The bot first downloads the exe file and checks that the downloaded data has a MZ for the first two bytes.
There’s another string, however, that is hidden in a similar manner to those from the initial downloader. This leads us to understand more about this next phase in the infection chain.
This string de-obfuscates to two strings associated with KRBanker check-in traffic from other reports.
This function also creates the URI string that is associated with KRBanker activity from reports /ca.php?m=&h=949. After building the URI string, the malware then decodes the C2 address that it will check-in to. After check-in, the bot writes the downloaded exe file, along with random appended overlay data, to %TEMP% and then executes the program before deleting itself.
This is another downloader with some functionality to customize infections to geographical locations that the actor wishes to target. Since the coding styles between this downloader and KRBanker/Blackmoon are very similar, along with the similar C2 check-in, we decided to call it KRDownloader.
The malware being delivered by the Blackmoon Downloader Framework has been previously reported by researchers as Blackmoon/KRBanker/Banbra. It has been seen being delivered in a variety of ways, including via adware campaigns and exploit kits.
The initial aspects of the malware appear to line up with reports revolving around traffic, whereby the malware gets the IP addresses it needs by using QZone and Pengyou responses to cgi_get_portrait.fcg?uins= requests. By decoding some of the onboard strings, we can quickly compare a recent sample with a previous sample. It should be noted that the strings from both samples are encoded in precisely the same way:
HexToText(Rc4_Encrypt(key, HexToText(Rc4_Encrypt(key, clear_string))))
Psuedocode of string encryption
Further, the similarity is such that the same RC4 keys can be used to decrypt the strings from both samples.
The sample from previous adware based campaigns we used for this exercise is 006cb2c12c577f7d8105a2e8a1bfc9cd13b2a7b8001664e74605bb530cf6a4a4
This allows us to conclusively state that this framework is delivering the Blackmoon banking trojan.
Note: Fidelis Cybersecurity products were used to detect all threat activity described in this report.
Downloaded malware hashes:
Blackmoon/KRBanker target list: