Magento Credit Card Stealer Disguised in an <img> Tag

Recently, we had a client come to us concerned that their website was infected with credit card stealing malware, often referred to as MageCart. Their website was running on Magento, a popular eCommerce content management system that skilled attackers often target to steal as many credit card numbers as possible. The goal of attackers who are targeting platforms like Magento, WooCommerce, PrestaShop and others is to remain undetected as long as possible, and the malware they inject into sites is often more complex than the more commonly found pieces of malware impacting other sites.

In this case, the malware affecting the client follows the same goal — staying hidden. It does this by disguising malicious content inside an <img> tag, making it easy to overlook. Let’s take a look at this sneaky and well hidden piece of malware.

Encoded <img> tag code

In order to find this malicious code, we must first go to the infected website, add an item to the cart, and observe the page source at the end of the checkout process, once it is time to submit credit card details. Most MageCart malware only loads on the checkout page in order to try to avoid detection, so it’s important to follow the whole process during investigation.

It is also important to be at the portion of the checkout process that includes the input field for credit card information. After following the steps above, reviewing the page source shows the following code:

(Note: This is only a partial snapshot of the code.)

It’s common for <img> tags to contain long strings, especially when referencing image file paths or base64 encoded images, along with additional attributes like height and width. However, upon closer inspection, you’ll notice that following the <img> tag is a large chunk of Base64-encoded content, with no reference to an actual image file or indication that it is actually an image.

Typically, references to images in an <img> tag are file paths or URLs, whereas in this case, the data is embedded directly as Base64-encoded content that doesn’t represent actual image data. While using Base64 in an <img> tag is technically legitimate and commonly used when we’re talking about very small images like icons, it definitely stands out in this context.

What makes this even more suspicious is its location—on the checkout page and nowhere else on the site. The <img> tag is essentially a decoy that has malicious JavaScript hidden inside the base64 encoded data. The location of this code and the utilization of base64 within an <img> tag makes it clear that this code warrants further investigation.

Activation of the payload within the browser

Before decoding the base64 encoded content, let’s first go over how this code activates in a victim’s browser.

The base64 encoded content is followed by a onerror function, which is a function that is triggered if an error occurs when attempting to load a file or image. This can be seen below:

(Note: This is only a partial snapshot of the code.)

If an image fails to load, the onerror function will trigger the browser to show a broken image icon instead. However, in this context, the onerror event is hijacked to execute JavaScript instead of just handling the error.

This attack is harder to detect because the browser inherently trusts the onerror function. Since it’s a standard event handler used for legitimate purposes (like handling image loading errors), security tools may overlook it. Additionally, <img> tags are often overlooked because they’re generally considered harmless, can contain large amounts of content, and are typically used for displaying images. This malware is unique because oftentimes, anyone looking at it would think it is a legitimate image and overlook it. However, the malicious actor exploited this trust in the <img> tag to execute a malicious script while remaining undetected.

Decoded <img> tag code

Once it is determined that the content is encoded in Base64, the decoding process is straightforward. An online tool like https://www.base64decode.org can be utilized to decode the content found in the sample above. Here is the first chunk of the decoded content:

Followed by parts of the second chunk:

(Note: This is only a partial snapshot of the code.)

Analyzing the decoded version of the script reveals that it first checks whether the user is on the checkout page and ensures the script hasn’t run yet in the current session. This is done by two condition checks: checkout page validation, and previous execution checking. Once that has been confirmed, it waits for the user to interact with the page, typically by clicking a submit button. At that point, the script monitors the credit card fields for input. If the required credit card fields are filled, the magictrick() function is called. This function is crucial, as it collects and sends sensitive user data to a remote server. The function can be seen below:

Then, the script dynamically inserts a malicious form into the page, making sure users don’t notice any unusual changes. The form collects the user’s credit card details. This code creates a form with three fields: Card Number, Expiration Date, and CVV, as seen below:

The script also tries to avoid detection by monitoring the page for changes. Specifically, it watches for the payment-method-content section and inserts the malicious form if it isn’t already present. In the last chunk of code, the function valixxcdy processes the form input to allow only numeric characters, removing any non-numeric ones. This makes sure only credit card numbers are accepted. See the described code below:

Finally, in the last chunk of code, the script utilizes the magictrick() function, which collects the credit card information, encodes it, and sends it to a remote server. See the last chunk of code below:

Finally, the sendMetric() function sends the encoded data to a remote server. The malicious domain the data is exfiltrated to is wellfacing[.]com. The stolen credit card details are stored on this server and used for malicious purposes:

(Note: Certain information has been redacted for security purposes.)

The attacker accomplishes two impressive goals with this malicious script: avoiding easy detection by security scanners by encoding the malicious script within an <img> tag, and ensuring end users don’t notice unusual changes when the malicious form is inserted, staying undetected as long as possible. We have found similar cases in the past using this same method.

Wrapping it up

There are multiple important details that can be remembered from this piece of malware. Let’s summarize what has been learned:

1) E-commerce credit card skimming malware (also known as Magecart) is typically more sophisticated than other types of malware, making it harder to detect.

2) Malware can be hidden in many ways, including within <img> tags. Attackers are getting more sophisticated as time goes on, and their tactics change often.

3) Base64 within an <img> tag can be used for legitimate purposes, but requires further investigation, especially when a compromise is suspected or has been confirmed, and if located on a checkout page.

4) Injected credit card forms can be integrated in a way that keeps them undetected, ensuring that end users don’t notice any unusual changes.

5) Not every piece of information inputted on a website actually goes to where you intend it to go.

Credit card theft will likely rise as more businesses move their products online for purchase. Not only does this type of infection harm the customer whose details are stolen, but it also severely damages the business owner’s reputation. In addition to harming a business owner’s reputation, the business could have their website flagged by major vendors like Visa or marked as malicious by Google or other security vendors.

It is vital that ecommerce owners stay on top of software updates, change their site administrator passwords often, and limit access to their administrator panel. If there is any suspicion of an ecommerce site being targeted by credit card theft, the website will need to be scanned right away.

Mitigation steps

Below are ways to protect your site from credit card theft.

1. Keep your website software up to date: Monitor software patches from the vendor your site is utilizing. Magento includes an up to date security patch release page.
2. Get a web application firewall (WAF): Firewalls can help mitigate bad bots, prevent brute force attacks, and detect attacks in your environment, which are features the Sucuri firewall provides.
3. Enforce unique passwords for all of your accounts: That includes credentials for sFTP, database, cPanel, and Magento admin users.
4. Remove Magento admin users no longer in use.
5. Periodically check Magento admin users in your dashboard: Ensure that you recognize all Magento admin users in your dashboard and remove any that are unrecognizable.
6. Ensure 2FA is enabled on your Magento dashboard: Our firewall also has a protected page feature to limit access to the Magento dashboard.
7. Disable guest checkout: If possible, disabling guest checkout requires visitors to sign in before submitting payment details, which can help to reduce automated attacks where bad actors will inject malicious SQL queries into the forms allowing further access via backdoors.