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.
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:
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:
- 2015 Impacts of a Hack on a Magento Ecommerce Website
- 2015 Magento Platform Targeted By Credit Card Scrapers
- 2016 Magento Credit Card Swiper Exports to Image
- 2016 Fake SUPEE-5344 Patch Steals Payment Details
- 2017 Database and Image Tricks in Magento Malware
- 2018 Magento Credit Card Stealer Reinfector
- 2019 Magento Killer
Kyle Knight
Rianna MacLeod
Tony Perez
Krasimir Konov
Ben Martin
Rodrigo Escobar
Luke Leal
Puja Srivastava