A new day, a new way to steal bank data in Brazil. Scammers are calling and urging victims to install a supposed update of the bank's security module. In fact, it is a malicious extension of Google Chrome capable of capturing the information entered by the user during access to the bank account.
Figure 1 - Zero Detection Rate in VirusTotal
The Phone Call
This is not the first time we have noticed the use of telephone calls as a social engineering tool by fraudsters . Generally, they map the company and people involved in the financial sector via social networks and contact them as if they were bank employees.
This time, they called the person in charge of the financial sector of a company and informed that a new version of the bank's security module would be available. If the installation was not done at that time, the company could lose access to the account.
In the sequence, they provided the address for installing the alleged module. In Figure 2, a screenshot of the site provided by the criminals.
Figure 2 – “Security Module” update
By clicking "Install," the user is directed to the installation page for a Chrome extension, as shown in Figure 3. Note that the extension is properly hosted in the official browser app store, which helps to give credibility to the procedure.
Figure 3 - Chrome malicious extension install screen
Once the victim has followed the guidelines and installed the fake module, the fraudster guides the victim to a test access to the company’s bank account. It is at this moment that the information is stolen, as detailed in the next session.
In this section I will deal with some more technical aspects of the malicious activity of capturing and sending the bank's data of the victim performed by the malicious extension. The following steps were taken in a controlled and monitored environment.
As can be seen in Figure 4, the newly installed extension can read and change all data on the websites visited by the user. This obviously includes agency, account, and password data used in bank account authentication.
Figure 4 - Malware extension permissions details
After installation, the malicious extension will then monitor in the background all web accesses made with Google Chrome. The malware activation trigger happens when a specific URL of the database is accessed, as seen in Figure 5.
Figure 5 - Monitoring the bank URL
Using a lab computer with the extension installed, I started with dynamic analysis. I visited the bank's website and entered some fictitious data while monitoring network traffic, filesystem, Windows registry records, and so on. After a few attempts, nothing suspicious was identified. I wasn’t certainly triggered the malware in the right way. Time to migrate to static analysis.
I then accessed the expected address while monitoring the malicious extension action again. When I entered the username and password, I verified that the "window.top.Dummy.document.forms.G4" (G4) field was being fed with a coded value, according to Figure 6.
Figure 6 - Creation of a coded value as user and password were entered
Comparing the behavior of this same procedure in an environment without the malicious extension, I realized that this value was not changed, indicating that the malicious code had come into action.
Analyzing the code in Figure 7, I verify that the encoding of this value is done through the "window.btoa" function, which converts text content to base64 - a function widely used for serializing data that needs to be transmitted over the network, for example. Note that the function is applied twice - perhaps with the goal of disguising the base64 value that could easily be converted to its original value during a preliminary analysis.
Figure 7 - Capturing bank access data
By doing the inverse encoding path, I find that the encoded value contains the credentials (username and password) to the dummy account typed earlier, as shown in Figure 8.
Figure 8 - Decoding the value created by malware
So far, I have identified the malware's intent to collect the information, but I had not yet identified the theft of the information, I mean, sending it to the attacker.
Returning to the extension source code, I identified a connection routine that is triggered under two conditions: when the contents of a given variable have a number of characters greater than 10 (ten) and when the value of variable G4 is different from " Ok1 ", as shown in Figure 9.
Figure 9 - Condition for sending information
I note that the variable that is expected to have a size greater than 10 is exactly the one that stores the password entered by the user at the time of login "document.forms  .pwd" (pwd). Since the password input field on the login page only supports 8 characters, I had just found out why the data send function had not been triggered.
It is very likely that the value of the pwd variable will actually have a length greater than 10 characters after a successful login. Maybe it's converted into a password hash value. If our suspicion is correct, the objective of the fraudsters with this is to avoid receiving information from failed authentication attempts.
To bypass this restriction, I manipulated the value of the password field size to accommodate a larger number of characters. To do this, I use Chrome's own inspection module that allows you to make changes to the content of the page locally, as seen in Figure 10.
Figure 10 - Changing the maximum size of the password field
After this changing, when I submitted the form, I finally identified the outgoing connection of the collected data to an address contained in the malware code, as seen in Figures 11 and 12.
Figure 11 - URL for receiving the data
Figure 12 – DNS name resolution
After the name resolution, an HTTPS outgoing connection to the address embedded in the malware code for sending the data occurs was seen. As the connection as done using SSL encryption, I had to use a well-known attack strategy in this scenario called man-in-the-middle or MITM. It allowed me to intercept the contents of the connection in plain text, as can be seen in Figure 13.
Figure 13 – Information theft
Note: By doing this type of attack, by default Google Chrome does not allow unrestricted access to secure content (SSL) - especially when the site uses HSTS. To bypass this control, I use the "- ignore-certificate-errors" Google Chrome parameter.
By decoding the value (2 x base64-decoding) posted by the malware over the SSL connection, I obtained exactly the user credentials used in the experiments, as shown in Figure 14.
Figure 14 – Decoding sent data
In addition to username and password data, malware sends out two session variables (sessionStorage.pm_fp and sessionStorage.ksc). They are likely to be used by attackers to authenticate into the bank portal.
The analysis of this case led me to some reflections and final considerations:
Indicator of Compromise (IOCs)
MD5 (background.min.js) = f87aea66b827630ce34ee96d009503c5
Aug 15th 2017
3 months ago