The Anatomy of Website Malware Part 2: Credit Card Stealers

One of the biggest malicious trends in the last few months and years are credit card stealers — also commonly referred to as credit card skimmers or cc stealers.

In the second part of this Website Malware Anatomy series, I’m going to deconstruct several skimmers and show you what they look like, where they are hiding, and how they work.

What Are Credit Card Stealers?

When a website gets infected, website owners often ask “WHY?!” — this is especially the case with “invisible” malware types like backdoors and similar attacks where the infection’s purpose is not clear. What do attackers gain from these invisible infections?

In the case of credit card stealers, it’s pretty obvious. This is the most “direct approach” malware for generating a profit. With these credit card skimmers, attackers are able to collect valuable personal information along with real credit card information. Once obtained, it’s super easy to abuse this stolen data for online purchases — or even create a credit card copy for other nefarious purposes.

The consequences of credit card stealing infection can be even worse. It’s not only about your client’s money, but also about your site’s reputation. If a user’s money is stolen after buying something on your site, it’s unlikely they’ll trust your e-shop ever again — and they’ll probably go to a competitor the next time they make a transaction. The impact of a credit card skimming infection on a business can be very serious, if not devastating.

Who Is the Target?

The infection mechanism is the same as any other infection type. Attackers may leverage a vulnerability in your system, such as outdated vulnerable plugin, or the CMS itself. Security issues within your hosting environment and compromised credentials can also lead to infection.

Of course, it would be pointless to infect a site with a credit card stealer if it’s not an online merchant or no payments are performed. This is the primary reason why the majority of credit card skimmer infections are found on ecommerce-focused CMS, such as Magento, PrestaShop, or OpenCart.

In the past, we have seen some exceptions and found some “starving” credit card stealers sitting on sites without payments as well. This might be funny until you realize how modern attacks work — most of them are automated “search and infect” attacks which are looking for a vulnerability in your system or a known plugin with a vulnerability. Once found, the infection starts.

This means that finding a credit card stealer on your non-ecommerce site doesn’t mean you are OK. This indicates that your site was already compromised and there are probably several other malware types. Bad luck.

Anatomy of a Credit Card Stealer

Because this malware family is very common, it has almost unlimited variants. The more robust malware is, the bigger the chance of being detected. On the other hand, the more robust it is, the more obfuscation techniques it could implement — and the more features it might have.

The following snippets are real-world examples of credit card stealers. I’ll try to cover the most common types.

Example: Simple Injected Stealer

Let’s start with something simple and straightforward. These are, in fact, four lines of code:

What’s happening here is that the attacker is abusing a pre-existing structure, injecting the malicious code to the legitimate CMS core file to collect the data, and then sending the stolen information to a base64 encoded domain using cURL. Elementary, my dear Watson!

Example: Robust Included Skimmer

Sometimes, attackers store the credit card skimmer code in a standalone file, which is included in the core CMS file — and includes are often just single line injections, making it even harder to spot.

An included file might look something like this:

The principle here is the same as seen in previous cases, only the stolen data is sent to the attacker by email.

Example: Minimalistic Obfuscated Code

Sending unauthorized emails can be easily tracked. To avoid leaving suspicious traces in the server log files, another common method of stealing the credit card data is to store them in a fake, seemingly innocent file.

But how can the attacker actually get them? Let’s look at this example:

This is how the malware looks. One single line. After decoding the base64 encoded block, we get the actual code:

The attacker is storing all the stolen credit card data in following file, appending the stolen transaction details one by one:

/public_html/skin1_original/images/custom/speed_link3.gif

All the attacker needs to do is to access this file directly through the browser by visiting the site. For example, visiting www.infectedsite.xyz/public_html/skin1_original/images/custom/speed_link3.gif.

This type of record in the access log would be very hard to notice when we don’t know how the credit card stealer stores or sends the data, because there will be thousands of similar legitimate records. And once the attacker downloads this fake image, they have all the stolen data needed.

Malware in the Database

Infecting a file with malicious code is very easy when an attacker has access to the system, but this type of infection faces several risks.

One common problem that attackers face is that that an infection can be wiped within a regular CMS update. For example, when the skimmer is stored in a core CMS file and this file gets updated, the infection will be overwritten by legitimate code.

To avoid detection, we’re seeing database injections more and more often. Because of the nature of data stored in the DB (usually content directly loaded in site’s frontend), the majority of these injections are either JavaScript code or third party scripts including the malicious code.

Example: Common JavaScript Code Injection

The example below is just a part of the malicious script that clearly shows what credit card data is collected, as well as the IP address of servers where the data is sent.

Example: Database Injection Loading Malicious Third-Party Scripts

In this example, a tiny JavaScript code has been injected into the DB which is slightly obfuscated.

After deobfuscation, it looks like this:

It’s a nice example of a conditional malicious DB injection. The script is loaded only when the checkout page is open, indicating the payment data will be entered and subsequently collected by malware.

Modern Mass Wave Injections

In recent months, the majority of credit card stealer injections are combining both approaches and infect both files and the database. Malicious code is usually heavily obfuscated, making it hard to decode and identify, and malicious domains with a very short lifespan are usually used. These domains are mostly registered only for these malicious purposes and are replaced by different domains shortly afterwards to make the tracking even harder.

So, what do these infections look like? Here is an example of modern credit card stealer which is injected both to the database as well as the site’s JavaScript files.

At first glance, it’s just a mess.

After deobfuscation, it’s slightly more readable:

In this final example, we can clearly see what credit card information is collected, and that information is being stored using the third party domain “analyt.space.”

Conclusion

Credit card stealers are currently one of the biggest threats for ecommerce owners. The risk to both visitors and brand reputation are high, and these threats have serious implications for site owners.

This malware family is constantly evolving in a more sophisticated manner, with more stealth and more massive infections. Since it’s generating direct income for attackers, we can safely assume the real boom of credit card stealers is yet to come.

Make sure to keep your site protected, perform periodical safety checks, and watch for any suspicious activity on your website. And in the unfortunate case of infection, react as fast as possible. We’re here to help you. Stay safe!