Posted on Leave a comment

Second Google Chrome Extension Banker Malware in Two Weeks, (Tue, Aug 29th)

  1. Introduction

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 [1]. 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.

  1. 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

  1. 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://” 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

  1. JavaScript [de]obfuscation

Another part of the malware that caught my attention was how the Google Chrome Extension JavaScript code was obfuscated. It uses an array of strings in hexadecimal followed by a function that reorders the array. The array is then used all over the code, as seen in Figure 5. I saw this approach other times, but now I had to decode the source before advancing. It was not possible to read it otherwise.

Figure 5 – Malicious Google Extension snippet

Using the “nicefier” service JSNice [2], 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 7 – JavaScript decoder

Loading this code, we had the decoded JavaScript printed to the console, as seen in Figure 8; it was finally possible to understand the malicious intentions prepared and described in this article.

Figure 8 – Source decoded

  1. 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 [1], 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


  1. IOCs



Malicious Google Chrome Extension Files

MD5 (1.js) = 1d91e021e5989029ff0ad6dd595c7eb1
MD5 (2.js) = d996bdc411c936ac5581386506e79ff4
MD5 (3.js) = 59352276c38d85835b61e933da8de17b
MD5 (manifest.json) = c6157953f44bba6907f4827a1b3b4d0a

Other files

MD5 (myinside.dll) = 574322a51aee572f60f2d87722d75056
MD5 ( = bae703565b4274ca507e81d3b623c808



File System

%userprofile%appdataroamingmicrosoftwindowsstart menuprogramsstartup.vbs

Google Chrome

IDKEY STOR malicious extension deployed

  1. References


Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on Leave a comment

VU#403768: Akeo Consulting Rufus fails to update itself securely

Vulnerability Note VU#403768

     <h2>Akeo Consulting Rufus fails to update itself securely</h2>
     <p class="meta-text">Original Release date: 29 Aug 2017 | Last revised: 29 Aug 2017</p><!-- END SOCIAL BUTTONS -->



Akeo Consulting Rufus fails to securely check for and retrieve updates, which an allow an authenticated attacker to execute arbitrary code on a vulnerable system.


Akeo Consulting Rufus 2.16 and earlier retrieves updates over HTTP. While Rufus does attempt to perform some basic signature checking of downloaded updates, it does not ensure that the update was signed by a trusted certificate authority (CA). This lack of CA checking allows the use of a self-signed certificate. Because of these two weaknesses, an attacker can subvert the update process to achieve arbitrary code execution.


An attacker on the same network as, or who can otherwise affect network traffic from, a Rufus user can cause the Rufus update process to execute arbitrary code.


The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds:

Don't use built-in update capabilities

Because Rufus does not include the ability to securely install updates, any Rufus updates should be obtained from directly, using your web browser.

Avoid untrusted networks

Avoid using untrusted networks, including public WiFi. Using your device on an untrusted network increases the chance of falling victim to a MITM attack.


Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Akeo Consulting Affected 29 Aug 2017

If you are a vendor and your product is affected, let
us know

CVSS Metrics (Learn More)

Group Score Vector
Base 5.8 AV:A/AC:L/Au:N/C:P/I:P/A:P
Temporal 5.2 E:F/RL:W/RC:C
Environmental 1.3 CDP:ND/TD:L/CR:ND/IR:ND/AR:ND




    This issue was reported by Will Dormann of the CERT/CC.

    This document was written by Will Dormann.

    Other Information

    • CVE IDs:
    • Date Public: 28 Aug 2017
    • Date First Published: 29 Aug 2017
    • Date Last Updated: 29 Aug 2017
    • Document Revision: 8


    If you have feedback, comments, or additional information about this vulnerability, please send us email.