Autoloaded Server-Side Swiper

Front-end JavaScript-based credit card stealing malware has garnered a lot of attention within the security community. This makes sense, since the “swipers” can be easily detected by simply scanning the web pages of e-commerce sites.

However, this isn’t the only way to steal payment details and sensitive user information from compromised sites. Server-side swipers are almost as prevalent as client-side ones, and our remediation team removes both types of credit card stealers from compromised websites on a daily basis.

Server-side malware is completely undetectable if you don’t have access to the server that hosts the compromised site. This helps keep server-side malware campaigns under the radar, while client-side campaigns (like Magecart) receive ample publicity.

Onfr64_rapbqr Injection in lib/Varien/Autoload.php

In this post, we’ll describe how a simple Magento infection can steal payment information in real time—without leaving any externally visible signs of compromise.

During a recent investigation of a compromised e-commerce website, we found the following code at the top of the lib/Varien/Autoload.php file.

Malware in lib/Varien/Autoload.php
Malware in lib/Varien/Autoload.php

The Varien/Autoload.php file is always loaded by Magento since it has autoloading rules for PHP to find files with certain classes. This means that malware in this file is also loaded by Magento every time and it has access to all the data that the application receives from users.

Let’s take a look at the decoded version of this malware and see what it does:

Decoded server-side credit card skimmer
Decoded server-side credit card skimmer

This simple code checks if a request contains data with payment or login-specific names, such as: billing, cvv, year, cc_number ,dummy, cc_, payment, card_number, username, expiry, firstname, login, shipping, month, securetrading, cvc2.

If the malware detects these keywords, it tries to send all the request and cookie data to the remote server hxxp://requestbit[.]com/testServer.php using the curl shell command.

Basically, this malicious code steals credentials and payment details in the same manner most JavaScript skimmers do. The only difference is you can’t find any indicators of compromise (IoC) by just inspecting the code of web pages or traffic generated by a browser.

Network of Malicious Sites

If we check the requestbit[.]com domain, we’ll see that it was created on February 12th, 2019 and points to a server with the IP 93.158.203.156 (Serverius Holding B.v. in Netherlands).

This same server hosts a few more domains with the word “request” in the name: requestegg[.]com, requestmob[.]com, 99request[.]com – all of which were registered on February 12th, 2019.

When checking the other IPs on the same network, we found even more “request” domains created on February 12th, 2019.

IPs

93.158.203.153
93.158.203.154
93.158.203.155
93.158.203.156
93.158.203.157

Request Domains

requestbit[.]com
requestegg[.]com
requestmob[.]com
99request[.]com
101request[.]com
request101[.]com
drrequest[.]com
rerequest[.]com
tryrequest[.]com
requesttip[.]com
requesthd[.]com
hdrequest[.]com
requestbee[.]com

It’s quite natural to assume that all of these domains are also being used by credit card stealing malware. On the same network, we also located a few domains which had been registered on September 26-27, 2018 and may have also been used in attacks on e-commerce sites.

Their names are designed to blend into other legitimate third-party scripts and services that most sites use. They consist of keywords related to e-commerce: store, product, cart, Mage (common Magento-related keyword), as well as programming related keywords: js, script, java, etc.

IPs

93.158.203.150
93.158.203.151
93.158.203.152
93.158.203.153
93.158.203.155

Domains

itenvoirtech[.]com
javayousave[.]com
mageuserland[.]com
pollocart[.]com
productjstech[.]com
succescripts[.]com
upgradenstore[.]com
straproduct[.]com
userlandit[.]com

Conclusion

Once hackers compromise an e-commerce site, they can inject both client-side and server-side credit card stealing malware.

JavaScript injections may be a bit easier to perform on compromised Magento installations as they don’t always require access to files—it’s enough to have access to the database. However, if access to files is obtained, nothing can prevent attackers from modifying the PHP code of the application to skim for payment information and send it to the bad actors.

The farms of domains and servers revealed in this post demonstrate that this approach is taken as seriously as client-side Magecart campaigns.

Owners and users of e-commerce sites should not rely exclusively on external scanners. They can’t reveal server-side malware, which have access to the majority of payment details—unless a site uses a reliable third-party payment service that processes orders on it’s own server.

Magento users can employ server-side malware scanners and file integrity control tools to meet PCI-DSS Requirements 10 and 11; monitor for any unwanted file modifications, and scan for potential vulnerabilities.

All ecommerce websites must follow the requirements outlined by the Payment Card Industry Data Security Standards (PCI-DSS), even if they don’t process any payments themselves. We’ve put together a helpful PCI Compliance guide to help you navigate these requirements.

Magento users who have been compromised can refer to our helpful guide on how to identify, fix, and protect your Magento website after a hack.

If you’re interested in reading more about server-side Magento malware, you can check out some of our other posts on this topic:

You May Also Like