Database and Image Tricks in Magento Malware

Magento malware that steals details of customer credit cards is a prevalent problem during the last couple of years. We write a lot about various modifications of such malware and the tricks hackers use. When you look back, it’s interesting to see how common ideas may be reused in different steps of the attack.


Database

It’s a common trick to inject malware directly into the Magento database, which helps avoid modification of files on the server. The most typical target is the design/head/includes rows of the core_config_data table. The HTML code from those records is used to build the site pages, so it’s a perfect place for injection of JavaScript code that monitors form input and sends entered data to third-party servers.

Images

Another common theme is using image files to transfer stolen data. Since 2015 (the notorious Visbot malware), we’ve seen many different variations of the server-side malware that would save stolen data in files with image extensions (.jpg, .png, .gif). Files with such extensions raise little suspicion since they are not executable. At the same time, they can be easily downloaded from the compromised sites. Some malware saved the data in plain text. More complex attacks appended the data to existing legitimate image files. Visbot and its "Fake SUPEE-5344 Patch" modification used public keys to encrypt the saved in the .jpg files data, which also helped them make the files look like real binary images.

The "Fake SUPEE-5344 Patch" malware also had a backdoor functionality. It executed arbitrary shell commands passed in the “jpg” request parameter. Apparently, everything related to images is considered benign. Another JavaScript malware sends stolen data to a third-party server, but instead of making a direct AJAX call to that remote URL, it builds an <img> tag with that remote URL as its src parameter. The result is the same, but now it looks as if it’s loading an image from a remote server, not sending data to a remote server.

Recently, we came across a combination of all the above tricks. An obfuscated script was found in the design/footer/absolute_footer row of the core_config_data table.