Last Updated: 2017-08-29 14:25:45 UTC
by Renato Marinho (Version: 1)
It seems that Google Chrome extensions have become quite the tool for banking malware fraudsters. Two weeks ago, an offender phoned a victim and asked him to install a supposedly new bank security module that, instead, was a malicious extension hosted at the Google Chrome app store aimed to steal victim’s banking credentials . This week I received a report about a targeted email phishing campaign against another company with a suspicious attachment. The attachments, after the analysis detailed in today’s diary, revealed itself to be another Google Chrome extension prepared to steal banking credentials, credit card, CVV numbers and fraud “compensation tickets” (a popular and particular Brazilian payment method; we call it “boleto”) to divert payments.
To increase the success rate and entice the victim’s attention to the message, scammers used a previously hijacked company email account to threaten employees with a fake layoff list attached to the message in a “zip” file that contained the first part of the malware. I named it IDKEY due to the name of the extension it deploys.
- Threat Analysis
After analyzing many different malware parts and lots of obfuscated code, it was possible to understand the threat’s flow, since the phishing e-mail to the malicious actions, as seen in Figure 1. A textual description can be seen below:
- The e-mail attachment “zip” file contains a “.vbs” obfuscated script that, once executed, collects system information and send to a C&C server;
- Based on the received information, the C&C server decides whether the victim machine is a virtual machine (VM). If so, returns an URL to a non-malicious JPEG file. Otherwise, returns an URL to the second part of the malware;
- The second file, supposedly another “zip”, is, in fact, an obfuscated VBE script, that is downloaded and executed;
- The VBE script makes additional system checks and downloads a “zip” file (a real one this time) which contains a “Chrome” directory and a DLL;
- The DLL is deployed and configured to load during user login;
- The Google Chrome Extension is programmatically loaded into Google Chrome using the parameter “--load-extension”;
- The malicious extensions, called IDKEY STOR (very suggestive name in English) starts to monitor all visited websites to identify sensitive information. When it matches specific strings, the fraud begins;
- Credentials and credit card numbers are snatched and sent to the C&C server;
- When the victim generates a compensation ticket (the “boleto” we talked earlier) which has a barcode, the malware intercepts the page loading, communicates with C&C and asks for a fraudulent barcode number. It then communicates with an open API on another financial institution in Brazil and has it generate a barcode image and overwrites the original one. As result, the payment will be diverted to an account chosen by fraudsters.
Figure 1 – IDKEY Malware Analysis
- Sandbox detection
One of the first malware actions done by the VBS attached to the phishing e-mail is collecting a bunch of machine information and sending it to the C&C server, as shown in Figures 2 and 3.
Figure 2 – Machine information collection
Figure 3 – Machine information being posted to the C&C server
The result for this HTTP Post request was the URL “hxxp://cdn.ahnegao.com.br/2017/07/casa.jpg” which points to a regular JPEG file – a clear strategy to mislead sandboxes. To bypass this control, it was enough to replace “VMWare” terms in the request to something else, as shown in Figure 4. This time, C&C returned us a URL to the next piece of malware.
Figure 4 – Bypassing sandbox detection
Figure 5 – Malicious Google Extension snippet
Using the “nicefier” service JSNice , it was possible to better understand the source, as seen in Figure 6.
Figure 6 – After JSNice deobfuscation
Alas, reading the code is still far from easy because of the array reference approach used. To overcome this, it was necessary to create a “decode” function to map and replace all ‘array[“position”]’ references (like ‘_0xb33d[“0x0”]’), to their respective array position, as seen in Figure 7.
Figure 8 – Source decoded
- Final words
While it is extremely necessary for developers, the option of manually loading Google Chrome extensions may pose a risk to the regular user who should be aware of browser warnings about extensions in developer mode, as in Figure 9. And again , in my opinion, Chrome should restrict extensions access to sensitive form fields, like passwords, unless it is explicitly consented by the user.
Should Google Chrome team be more explicit about the dangers posed by programmatically loaded extensions in their warning?
Figure 9 – Google Chrome Extension in developer mode warning
Malicious Google Chrome Extension Files
MD5 (1.js) = 1d91e021e5989029ff0ad6dd595c7eb1
MD5 (2.js) = d996bdc411c936ac5581386506e79ff4
MD5 (3.js) = 59352276c38d85835b61e933da8de17b
MD5 (manifest.json) = c6157953f44bba6907f4827a1b3b4d0a
MD5 (myinside.dll) = 574322a51aee572f60f2d87722d75056
MD5 (uia.zip) = bae703565b4274ca507e81d3b623c808
IDKEY STOR malicious extension deployed