Our Threat Intelligence Group recently identified an attack through our FGX-Web solution that upon investigation revealed very clever techniques implemented to both breach and reinfect the target sites. The entry point of these breaches appears to be a vulnerability in unpatched versions of Magento, with the threat actors placing additional backdoors on the site, as well as their card harvesting malware.
Backdoors and reinfection mechanisms are common tools used by attackers to establish and maintain a foothold within their victim's systems. Backdoors allow the attackers unfettered and simplified unauthorised access, and generally offer the ability to run arbitrary remote commands, easily deploy additional malware to a site. Additionally, the reinfection mechanisms identified can reintroduce the malware even in the event that the backdoors are discovered and their entry points removed. Recent incidents investigated by our team led to the discovery of a very crafty method of implementing both of these attack techniques.
Breach through malicious order
Access log analysis was initially inconclusive in determining how the threat actors gained entry, but an affected merchant with an email notification system for failed transactions was able to provide some crucial information. An invalid order was submitted to their site, which contained Base64-encoded code within the shipping details along with calls to built-in Magento functions which were used to execute the payload.
Decoding this Base64-encoded data revealed methods of injecting several of the pieces of malware that were detected on the site. We believe this was achieved through the use of a Magento 2 input validation vulnerability affecting versions prior to 2.4.3-p2 allowing remote code execution. Two security patches were released by Adobe in February 2022. (https://helpx.adobe.com/security/products/magento/apsb22-12.html)
health_check.php Backdoor
One of the files modified by the threat actor was /pub/media/health_check.php. One line of code was added to the file which acted as a backdoor which could execute arbitrary code sent via the POST variable ata.
Interceptor.php Backdoor
One of the more notable pieces of malware introduced to the site following the breach was the following:
/generated/code/Magento/Framework/App/FrontController/Interceptor.php
Interceptors are used by Magento in order to intercept function calls and run additional code. This specific interceptor is for the Front Controller, which is responsible for processing requests. In its original form the file looked like this:
After the breach the file had been modified as shown below:
The malicious code in question works by creating a function utilising the encoded data stored in the variable cryption_block. The function is then called and the variables hash_key and req are passed in as arguments. To understand what the function does the base64 data has to be decoded, as shown below:
By further decoding the base64 encoded values within the function and substituting in the variables passed in as arguments, the code can be further deobfuscated:
The function checks if an encryption key has been sent in the request and whether it matches the hardcoded value. It then checks for the presence of a ‘frontName’ variable and if it exists it will decode its value and run it. This allows an attacker to send requests with the encryption key and encoded commands to be run, providing remote backdoor access to the site.
Access to this backdoor by the attackers was observed in the access logs: numerous POST requests were sent to the URL /catalogsearch/result/?q=bestone. The responses showed varying file sizes, a common indicator of backdoor or webshell activity where the response data changes based on the commands issued.
Card Skimming Malware
The card skimming malware planted by the threat actors was made up of a client-side JavaScript component and a server-side PHP component.
The JavaScript component was either placed in the /lib/web/jquery.js or within the database in the core_config_data table. In both locations, the code would be executed when a customer browses the website and makes a purchase. The malware consists of a large, encoded string and a decoding function which uses a combination of Base35 decoding and XOR.
The decoded malware reveals the code will retrieve the contents of the card data fields on the checkout page, encrypt the data and send it back to the merchant site inside the POST variable cardCheckSumData.
The PHP component of the card skimmer was added to the file /generated/code/Magento/Framework/Message/Session/Interceptor.php. The encoded malware contains a string which has been encrypted using AES, with the decryption key being specified within the aes_decrypt function.
The card data is retrieved from the cartCheckSumData variable, encrypted, then appended to a local file within the /pub/media/wysiwyg directory with a .jpg extension. The contents of this file are then retrieved by the threat actor at a later date.
Reinfection Process
Upon identifying the malware and reaching out to the merchant most of the malware was removed very quickly. However the Interceptor.php file would get reinfected within minutes of removing the malware. As a temporary measure to prevent the reinfection, the write permissions for the Interceptor.php were removed.
The access logs showed no indication of an external user re-breaching the site. The file was monitored using Auditd, although the modifications made to the file during the reinfection were not being recorded in these logs either. After suspecting that the reinfection may be caused by a background process, the merchant was requested to provide volatile evidence, including a process listing and networking information.
When looking through the process listing, two processes stood out as suspicious:
In particular, the php-fpm command had www as an argument, despite the owner of the process not being www-data. The start date of both processes also were the same date as the earliest reference to the backdoor we could see in the access logs. The lsof output for these two processes revealed even more suspicious findings:
The current working directory for both processes was the /pub/media directory within the webroot. This also revealed some files within this directory that have been deleted: sshd:, php-fpm: and 1, as well as another deleted file within the /tmp/ directory: /tmp/phpoQixVt. We were unable to recover these deleted files and observe the contents, although it’s possible these files were used to store a copy of the infected version of Interceptor.php.
Copies of the running executables and the memory dumps for both processes were obtained for both processes. The php-fpm: process contained several references to OpenSSL functions and networking, suggesting it may have been used as a more direct backdoor for the threat actor. The sshd: process was revealed to have been responsible for the reinfection of Interceptor.php, a copy of the entire infected Interceptor.php being found within the process memory.
Defending against this attack
We advocate a defence in depth approach to securing important assets and your eCommerce website is no different. These are a few recommendations that will assist defending against this attack:
- The most effective protective measure you can take against this attack (and many others we have encountered over the years) is to ensure your Magento 2 installation is up to date, and make sure the relevant security patches have been installed. Two stand-alone security patches for the input validation vulnerability can be found here:
https://helpx.adobe.com/security/products/magento/apsb22-12.html - Monitor for changes to Magento core files, especially the interceptor files within the /generated directory.
- Monitor for malware (backdoors, card skimming malware).
- To check for any potential reinfection processes, it is also advisable to look for any unexpected or suspicious running processes. This would include any processes launched from deleted files or from within unusual directories such as the /pub/media directory within the webroot.
If you don’t have a solution to monitor for malware and file changes, you are welcome to sign up to our Free ThreatView Community service - once you have an account, apply to our Early Access Program to get free use of our proactive defence tech to monitor your website for this attack (and many others).
You can get the solution free here: https://www.foregenix.com/threatview
Subscribe to our Blog
