It’s common for malware to target e-commerce sites, and these attackers are usually seeking to steal credit card details. In most cases, they will insert scripts that extract data from the checkout forms to siphon fields like the cardholder name, card number and expiration date. Once they have that information, their job is done and they’ll use the data for other nefarious purposes (usually putting it up for sale on the black market). However, every now and then we encounter a case where in addition to that they are also looking to steal details for accounts that customers have created on these sites along with admin account credentials. We’ll explore one such case.

The malware

Magento is quite complex and allows for heavy customization of the core files. We encountered a suspicious script loading in the following file:

./pub/static/adminhtml/Magento/backend/en_US/mage/dataPost.js.

In the usual fashion, the malware is heavily obfuscated making use of randomly named variables and hex encoded function names.

Once decoded using a js deobfuscator, we can begin to piece together what the script is doing:

Breaking it down

We can see some key components that give away the script’s intent. We already know the script was located in Magento/backend/en_US/mage/dataPost.js. This file is used by Magento for processing AJAX requests via forms, like we would see with customer signup and login forms.

Knowing what this Magento component does, these variables are of particular interest.

g: 'aHR0cHM6Ly9jZG4uanF1ZXJpLmF0L3I=
l: '#username'
p: '#login'
b: '.action-login'

Among other things, the action-login function in Magento processes login requests by validating user credentials. So what we are seeing is that the script waits for that action to trigger and then scrapes the data entered into the form. But where is the password, you might ask?

Looking at the form on the site, we can see that the username and password are both configured as elements in the login array.

At the bottom of our malicious script, we can see a function to iterate through the form array values.

Remember from above, dBNA73C was the malicious script’s container name, and .p was designated for login – the site’s form array containing the values the attackers are interested in.

That leaves us with one last value.

g: 'aHR0cHM6Ly9jZG4uanF1ZXJpLmF0L3I=

This is a simple base64 encoding for the domain where they will be sending the login details:

hxxttps://cdn[.]jqueri[.]at/

This domain is known to be a malware provider associated with previous attacks and is hosted on a server along with other domains known to be associated with customer account and credit card theft.

A point to make here is that attackers will often use domains that are very similar to known good domains. In this case, they use a variation of known JQuery repositories in an attempt to evade detection – this domain could easily blend into a network resource analysis.

One thing that strikes me as particularly interesting in this case is that, unlike many cases of malware that generically target sites, this appears to have been tailored specifically for the site where this malware was injected – the malware looks for specific variables in the login form design.

Once the attackers have login details, specifically for admin accounts, they can make any number of changes to the site design and even install malicious modules or modify payment gateway settings.

Maintaining a safe and clean site

• Keep your admin passwords updated regularly. It is not enough to change passwords only after an attack has occurred, the more often passwords are changed the more difficult it will become for attackers to cycle through previous passwords. A free online tool for generating secure passwords can be found at LastPass.
• Keep all software up to date. Vulnerabilities are documented regularly, but attackers quite often find exploits in outdated software where vulnerabilities have not been documented. Updated plugins, themes and modules will implement security best practices that may not have been a standard when previous versions were released.
• Review your admin accounts and implement the principle of least privilege. Admins accounts do not need the same access across the board. Each account should be limited to a verify specific set of roles. In that way, if one account is compromised, the attackers do not have unchecked control of the entire site.
• Restrict admin logins to trusted IPs. Quite often we see CPanel, FTP/SSH and the site admin panel accessible to the public with no login restrictions. IP restrictions for FTP/sFTP/SSH and CPanel can be implemented directly on the server. The site admin panel can be locked down using a plugin or Firewall. The Sucuri Firewall provides features for limited access to the site admin panel to trusted IPs.

If you suspect that your site has been compromised, our team of experts is available to assist 24 hours, 7 days per week.