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.
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:
Figure 1 – IDKEY Malware Analysis
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
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 (myinside.dll) = 574322a51aee572f60f2d87722d75056
IDKEY STOR malicious extension deployed
Aug 29th 2017
Aug 29th 2017
3 years ago