Over the last few months, we’ve noticed several credit card-stealing scripts that use variations of the Google Analytics name to make them look less suspicious and evade detection by website owners.
The malicious code is obfuscated and injected into legitimate JS files, such as skin/frontend/default/theme122k/js/jquery.jscrollpane.min.js, js/meigee/jquery.min.js, and js/varien/js.js.
The obfuscated code loads another script from www.google-analytics[.]cm/analytics.js. The URL looks very similar to the real Google Analytics location – www.google-analytics.com/analytics.js – but has the .cm top-level domain instead of .com.
Update: On January 17, 2019, the attackers created another domain with the same script on the same server (188.8.131.52): googlc-analytics[.]cm/analytics.js. This server also hosts the analytic[.]is domain registered on December 28, 2018.
If someone views the script, they’ll find this obfuscated code that also tries to mask itself as GoogleAnalytics.
However, if you take the time to decode it, its malicious nature becomes obvious–stealing credit card details from checkout forms.
Fake Angular Script
On some sites, the obfuscation is less obvious. At first glance, it looks like it contains legitimate Angular code.
In this particular case, the URL is hxxps://www.gooqletagmanager[.]com/gtm.js. Again, the domain pretends to be a legitimate service. It looks like it belongs to the popular Google Tag Manager service, but has Q replacing the second G in Google’s name. This is a credit card stealer as well.
Another variation that can be found on compromised Magento sites is hxxps://googletagmanager[.]eu/gtm.js.
More Angular Stealers
These fake Angular scripts are typically injected into the Magento database and can be found in the HTML source of web pages on compromised Magento sites. At the time of writing, PublicWWW finds 40 sites containing these fake Angular scripts.
In most cases, they are not formatted as well as the above sample and occupy just a long, single line of code.
Each site has its own version of the script, with different decryption keys and encoded URLs. It’s worth mentioning that the majority of these script tags have various misleading references to google/analytics/magento/conversions, such as:
Fake Analytics Scripts on Hacked Sites
All of these scripts load the credit card stealers from different URLs. Unlike the previous examples seen above, which reside on the domains created specifically for the attack, these payloads are hosted on compromised third-party sites.
These hacked sites are not limited to Magento. URL structure analysis tells us that these sites are powered by different CMSs, mainly by WordPress, Joomla, and Bitrix. The malicious scripts are hidden deep inside subdirectories and have names that include words like google/analytics/conversion/magento in them.
Not all of these files still exist — some have been deleted. A few of the domains of these compromised sites have expired since last summer. In the files that still exist, we see heavily obfuscated code with very few human-readable keywords. The keywords that are recognizable give the false impression that the script is related to an analytics service ( e.g. Analytics, AnalyticsId). However, when analyzed, we see code that sends payment form data to a PHP script in a different directory on the same compromised site.
Overall, this attack shows a significant level of customization, where attackers have taken an individualized yet very consistent approach to every compromise.
Each site has its own set of injected scripts, compromised sites, misleading variables and file names, and unique variations of obfuscation. At the same time, at each level, they consistently try to make an impression that they do something useful, are related to Google Analytics or Magento conversion tracking, or are built with reputable JS frameworks.
An analysis of the compromised sites shows that at some point they were infected with several different malicious scripts. Eventually, their webmasters discovered and removed some malware — but they failed to remove the malware we described in this article.
On some sites, we find the scripts of this malware commented out. This makes us think that the site administrators noticed them but were unsure if they were a part of a legitimate code, deciding instead to just comment it out. This proves that this approach is quite successful in increasing the period of time between the site infection and malware removal.
This malicious campaign demonstrates the importance of integrity control for both server files and database records, especially those that contain code used for web page generation and payment processing.
We strongly encourage website owners to scrutinize every change or addition of new code to their website. Even if you don’t understand what the code does, you can assume its malicious nature if it wasn’t added by anyone responsible for site maintenance.
This is not the only case where this approach could help identify e-commerce site compromises. If you believe your site is being used for phishing campaigns and you need a hand cleaning up the infection, we’d be happy to help.