Attackers Abuse Swap File to Steal Credit Cards
2024-7-20 03:36:19 Author: blog.sucuri.net(查看原文) 阅读量:19 收藏

Attackers abuse swap file to steal credit cards

When it comes to website security, sometimes the most innocuous features can become powerful tools in the hands of attackers. Such was the case in a recent incident we investigated, where bad actors exploited the humble swap file to maintain a persistent credit card skimmer on a Magento e-commerce site. This clever tactic allowed the malware to survive multiple cleanup attempts — that is, until our analysts wrapped up their investigation.

In this post, we’ll peel back the layers of this sophisticated ecommerce attack, offering valuable insights into how you can protect your own online store from similar threats.

Let’s take a look!

Inspecting the malware

When navigating to the compromised website’s checkout page, we could see an interesting script buried way down in the page source.

Interesting script buried in checkout page

The script had all the usual indicators of malware, like base64 encoded variables and hex encoded strings. But once decoded, we could see some clear indicators that the script was watching for credit card details.

Malicious checkout page behavior

The following snippet enables a checkout button and adds custom bindings to the normal click function on the compromised checkout page.

snippet enables a checkout button and adds custom bindings to the normal click function on the compromised checkout page

Once the checkout button is clicked, the script captures data entered into the credit card form via a querySelectorAll function as seen here.

script captures data entered into the credit card form via a querySelectorAll function

Several other variations of the function elsewhere in the script capture sensitive information such as name, address, card number and other data needed by the attackers to utilize the stolen card details. We can also see a domain, amazon-analytic[.]com, used by the attackers to retrieve the stolen credit card details.

amazon-analytic[.]com used by the attackers to retrieve the stolen credit card details

This amazon-analytic[.]com domain was registered in February 2024 and has also been seen used in other previous cases of credit card theft. Note the use of the brand name; this tactic of leveraging popular products and services in domain names is often used by bad actors in an attempt to evade detection.

Tracing the source to bootstrap.php

Once we had the checkout page decoded, it was time to find the source. Further investigation led us to the Magento app/bootstrap.php file which had been completely replaced from the official version.

Replaced Magento app/bootstrap.php file

Decoding that base64 content revealed the exact malicious script found in the checkout page source. We also located the curl function used by the attackers to exfiltrate the stolen data to their external domain.

The ob_filter_callback function is used to add the skimmer script to web pages if their URLs contain the keyword “checkout” and the pages were requested using the GET method.

ob_filter_callback function is used to add the skimmer script to web pages

The malware removal process

We figured that removing the malware should be as simple as replacing app/bootstrap.php with the correct version and then clearing caches, since we know the content there is what we are seeing in the checkout, right? Well, not in this case.

Once we replaced the file with the correct contents, we noticed the script was still loading in checkout. It’s not impossible for files to be reinfected pretty quickly, so we took another look at bootstrap.php with our malware cleanup tools and noticed that the malware was back.

What was especially strange was that when we looked at the file on the server directly via SSH, it was completely clean.

Apparently clean file

However, when we searched the file system for indicators of the malware using our cleanup tools, the malware still appeared.

Malware infection

As a further test, we copied the apparently infected bootstrap.php file to a new file name — bootstrap.php.clean — and viewed that with our malware cleanup tools. The file contents were correct.

So, somehow, it seemed that the file was both clean and infected at the same time (Schrodinger’s malware?).

It doesn’t happen often, but occasionally malware will linger in memory and can hook into file session data. We restarted the Apache and PHP services, and eventually rebooted the entire server to attempt to clear that up. Surprisingly the malware was still there and we were clearly missing something.

Back to the basics: swap files

We went back to review the malware script and file where the script originated and noticed something interesting at the very bottom.

swapme file reference

At first glance, there did not appear to be any file with that name on the server.

Checking for swapme

The swapme part of the file name clued us in that there might be some swap lingering around. When files are edited directly via ssh the server will create a temporary ‘swap’ version in case the editor crashes, which prevents the entire contents from being lost.

While we could not see any ~swapme file with the ls command, running a vi command on bootstrap.php-swapme to directly edit the swap file revealed that the file was indeed there, and it contained the exact same contents as the infected version of bootstrap.php.

It became evident that the attackers were leveraging a swap file to keep the malware present on the server and evade normal methods of detection. We removed that swap file, cleared caches again, and presto: the checkout page source was finally clean.

Mitigating further attacks

The attacker’s misuse of the swap file system highlights the importance of security measures that go beyond surface-level scans and cleanups. In this case, it was clear that the attackers were able to gain access via SSH or some terminal session, otherwise we wouldn’t have found the swap file that was created when the file was edited.

To mitigate the risk of persistent ecommerce malware infections like this one, you can restrict sFTP, SSH, FTP, CPanel and any other admin access to trusted IPs. While FTP and SSH restrictions need to be configured directly on the hosting server, our website firewall also adds additional layers of protection to prevent unwanted access to areas like your WordPress and Magento admin panels. It is also good practice to keep your CMS and plugins or modules up to date. Older versions of website software often contain vulnerabilities that attackers will easily exploit with automated attack tools.

If you believe that your site has been infected, our experienced security analysts are available 24×7 to help clean up malware in your website environment. If you’re more of a DIY type, we also provide free guides with detailed steps to clean up an infected website.

Matt is a Cyber Security analyst who joined Sucuri in 2018. Matt has a long history of working with Linux and Windows servers in a wide context. At Sucuri, Matt's main responsibilities include identifying and removing malware from websites as well as researching emerging malware trends. When Matt isn't focusing his attention there, you will usually find him working on a new piece of music or out in his garden.

Related Tags

文章来源: https://blog.sucuri.net/2024/07/attackers-abuse-swap-file-to-steal-credit-cards.html
如有侵权请联系:admin#unsafe.sh