Magecart gang hides PHP-based web shells in favicons

Magecart cybercrime gang is using favicon to hide malicious PHP web shells used to maintain remote access to inject JavaScript skimmers into online stores.

Magecart hackers are distributing malicious PHP web shells hidden in website favicon to inject JavaScript e-skimmers into online stores and steal payment information.

Researchers from Malwarebytes observed threat actors, likely Magecart Group 12, using this technique in attacks aimed at online stores running on Magento 1 websites.

The web shells employed in the attacks are tracked as Smilodon or Megalodon, they dynamically load JavaScript skimming code via server-side requests into online stores. This technique allows bypassing most client-side security tools.

“While performing a crawl of Magento 1 websites, we detected a new piece of malware disguised as a favicon. The file named Magento.png attempts to pass itself as ‘image/png’ but does not have the proper PNG format for a valid image file.” reads the analysis published by Malwarebytes.

Threat actors edited the shortcut icon tags with a path to the fake PNG file. Unlike previous incidents observed by the experts that involved the use of fake favicons to hide malicious JavaScript code, in the last wave of attacks the webshell is written in PHP.

In the latest attacks, the e-skimmer code is introduced into the online store dynamically at the server-side.

The web shell retrieves the e-skimmer from a remote host, the code involved in this attack is similar to a variant used in Cardbleed attacks documented by SanSec researchers in September.

The attribution of the attack to Magecart Group 12 is based on overlaps in TTPs observed in the attacks, experts also noticed that the domain name used in the attack (zolo[.]pw) is associated to the same IP address (217.12.204[.]185) as recaptcha-in[.]pw and google-statik[.]pw, domains previously associated with Magecart Group 12.

“There are a number of ways to load skimming code but the most common one is by calling an external JavaScript resource. When a customer visits an online store, their browser will make a request to a domain hosting the skimmer. Although criminals will constantly expand on their infrastructure it is relatively easy to block these skimmers using a domain/IP database approach.” concludes the analysis.

“In comparison, the skimmer we showed in this blog dynamically injects code into the merchant site. The request to the malicious domain hosting the skimming code is not made client-side but server-side instead. As such a database blocking approach would not work here unless all compromised stores were blacklisted, which is a catch-22 situation. A more effective, but also more complex and prone to false positives approach, is to inspect the DOM in real time and detect when malicious code has been loaded.”

Please vote Security Affairs as Best Personal cybersecurity Blog
https://docs.google.com/forms/d/e/1FAIpQLSer_6yOZrL8OO6XjJ9yj3Mlq9LvuOakdTZN9ZmhkFCy1aQLdw/viewform

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Magecart)