In the EXIF metadata of an image that was then sureptitiously loaded by compromised online stores, Malwarebytes reveals, a group of cybercriminals managed to conceal their web skimmer.
While image files have long been used to carry malicious code and exfiltrate data (steganography became a popular hacker trick several years ago), it’s unusual to hide web skimmers in image files.
These scripts are designed to recognise and steal credit card data and other personal information entered on compromised ecommerce websites by unwitting users, and to send the data harvested to campaign operators.
The recently observed attack, claim security researchers from Malwarebytes, not only stands out due to the use of images to conceal skimmers, but also because it uses images to exfiltrate stolen credit card data.
According to Malwarebytes, an initial JavaScript is being loaded from an online store running the WordPress WooCommerce plugin, where international code was appended to a legal script hosted by the retailer.
The script would load a favicon file identical to that used by the compromised store (their brand logo), and the web skimmer was loaded from this image’s Copyright metadata field.
The skimmer was designed to capture the content of input fields where online shoppers enter their name, billing address and details of the credit card, just like other similar code.
The skimmer also encodes the data collected, reverses the string and sends the information as an image file to an external server, via a POST request.
“Probably, the threat actors decided to stick with the image theme to also cover up the exfiltrated data via the favicon.ico file,” notes Malwarebytes.
Throughout their analysis, the security researchers found a copy of the source code of the skimmer toolkit in an open directory of a compromised site, which gave them the opportunity to understand how the favicon.ico file is constructed with the inserted script inside the Copyright sector.
Malwarebytes has also been able to locate an earlier version of the skimmer, which lacked the obfuscation present in the current iteration but had the same code features, and claims it might have connections to Magecart Group 9.
