The store of German political party CSU contains an identity skimmer that was planted on or before Oct 5th, right before the Bavarian election on Oct 14th. Personal identifyable information of customers gets sent to a remote server during the checkout process.
Because the CSU shop uses an off-site payment provider (Amazon & Paypal), no credit cards are stolen. However, session cookies and other private data are actively intercepted. The attackers likely used an unpatched flaw in the store software, or used brute force to guess a staff password. A quick MageReport scan yields:
The German coalition party is not the only one affected. I have been monitoring global stores for some time and counted the 40,000th compromised shop last week. The modus operandi is commonly known as “Magecart” and has hit high profile targets such as British Airways, Ticketmaster and ABS-CBN.
Just flagged the 40,000th store that got Magecart'ed, since I started counting 3 years ago. That's unique stores (domain names).— Willem de Groot (@gwillem) October 11, 2018
Here is the proof that the identity stealer is active and working.
The obfuscated malware is found at the bottom of https://www.csu-shop.de/js/infortis/jquery/jquery-1.7.2.min.js. This file was last modified on Fri, 05 Oct 2018 14:45:47 GMT, suggesting the malware is in place since at least 9 days. It fetches a dynamic payload drop server from records.nstatistics.com/records.php?standart, at the moment it will return b0b127c6.ngrok.io/checkpayment.php but the malware authors anticipate that they will have to change this, as Ngrok (free proxy for developers) will likely shut them down soon. The decoded malware reads:
Back in 2016, Magecart skimmers would evade detection by sleeping if any developer tools were found running. Then, their malware would 404 without correct Referer or User-Agent header. And now, Magecart sounds the alarm when it finds you snooping around, and collects a fingerprint of you on an external server.
When developer tools are open and you start debugging, the tripwire will send your timezone, IP, browser and a whole lot of other info about you to an external URL, such as sslvalidator.com/tools.php and rellicform.com.
It disables all kinds of logging to the console.
It won’t do any reporting on mobile devices.
The malware itself has a nodejs hook, probably for the malware author.
Ramifications: the Magecart authors now likely have a list of IPs of interested parties, and may use those in future evasion techniques.
The obfuscated tripwire is attached to a (dummy) copy of jQuery-Mask that is served on non-checkout pages. Here’s a reverse engineered copy:
The fingerprint receivers are hosted on 126.96.36.199 and 188.8.131.52, a dodgy network spanning NL/IE/RU/UA. According to VirusTotal, the following hostnames resolve there, which have been added to the Magento Malware Scanner list of IOCs.
While Filipinos are recovering from typhoon Mangkhut, another misfortune awaits them online. I found their broadcasting giant ABS-CBN − a $740 million conglomerate & top-500 global Internet destination − to be hacked. Criminals are running a payment skimmer on ABS-CBNs online store since at least August 16th. Personal information and credit cards are intercepted while people shop for merchandise for one of the 90+ television shows. The stolen data is sent onwards to a server registered in Irkutsk, Russia. The credit cards and identities are then (presumably) sold on the black market.
ABS-CBN is the latest target in a series of high profile skimming operations. Previously, British Airways and Ticketmaster admitted massive credit card theft of their customers. The methodology found at these crime scenes is the same: browser-based interception during the checkout process. This method is quickly gaining popularity because it defeats the security of encrypted connections (https/SSL).
Filipinos are recommended to carefully check their credit card statements for unauthorized payments.
I have notified ABS-CBN of the breach, but have not received a response.
I discovered the fraud campaign when I implemented new heuristics for my malware detection system this week. The (obfuscated) malware is located at store.abs-cbn.com/js/lib/ccard.js (archive.org). This specific file has not been modified since four weeks, suggesting the malware was injected on or before August 16th.
However, you just skimmed over an ingenious impersonation. The domain g-analytics.com is not owned by Google, as opposed to its legitimate google-analytics.com counterpart. The fraud is hosted on a dodgy Russian/Romanian/Dutch/Dubai network called HostSailor. The malware behaves pretty much like the real Google Analytics, and it wouldn’t raise any dev eyebrows while monitoring Chrome’s waterfall chart. It requests __utm.gif, just like other Google Analytics trackers:
Upon closer inspection, the utm.gif request is a POST (uncommon). And it sends a suspicious amount of data over:
Voila, my address, email and credit card info out in the open.
The g-analytics malware has spread to various websites. Interestingly, some websites embed a versioned copy, such as:
I enumerated all possible copies and checked for the “Last-Modified” header:
$ for i in $(seq 1 20); do
wget --mirror https://g-analytics.com/libs/1.0.$i/analytics.js;
$ ls -rtl */* | cut -b28-
130744 jun 23 04:47 1.0.1/analytics.js
30866 jun 27 06:25 1.0.3/analytics.js
32258 jun 27 13:06 1.0.4/analytics.js
32231 jun 28 17:11 1.0.6/analytics.js
34288 jun 28 18:03 1.0.7/analytics.js
31330 jun 28 19:25 1.0.5/analytics.js
75557 jun 30 15:41 1.0.8/analytics.js
30838 jul 2 08:51 1.0.9/analytics.js
31098 jul 4 17:41 1.0.11/analytics.js
56946 jul 5 07:29 1.0.10/analytics.js
57603 jul 5 09:43 1.0.12/analytics.js
24069 jul 7 05:58 1.0.14/analytics.js
31234 jul 7 14:27 1.0.13/analytics.js
35515 jul 10 11:44 1.0.15/analytics.js
The malware creator seemed to have created 14 different copies over the course of 3 weeks. At least versions 1.0.10 and 1.0.12 include a fake payment popup form that was built for a specific website. These instances are still harvesting passwords and identities as of today.
A single group is responsible for planting skimmers on 7339 individual stores in the last 6 months. The MagentoCore skimmer is now the most successful to date.
Update 2018-09-07: Because Google Chrome has added the campaign to its blocklist last Saturday, the skimmers are now rapidly replacing “magentocore.net” with “magento.name”. In the last 24h, they have updated at least 190 compromised stores.
Online skimming - your identity and card are stolen while you shop - has been around for a few years, but no campaign has been so prolific as the MagentoCore.net skimmer. In the last 6 months, the group has turned 7339 individual stores into zombie money machines, to the benefit of their illustrious masters.
The average recovery time is a few weeks, but at least 1450 stores have hosted the MagentoCore.net parasite during the full past 6 months.
The group hasn’t finished yet: new brands are hijacked at a pace of 50 to 60 stores per day over the last two weeks (source: daily scans of yours truly).
The victim list contains multi-million dollar, publicly traded companies, which suggests the malware operators make a handsome profit. But the real victims are eventually the customers, who have their card and identity stolen.
How it works
This script (backup) records keystrokes from unsuspecting customers and sends everything in real-time to the “magentocore.net” server, registered in Moscow.
The malware includes a recovery mechanism as well. In case of the Magento software, it adds a backdoor to cron.php. That will periodically download malicious code, and, after running, delete itself, so no traces are left.
The file clean.json (backup) is PHP code that removes any competing malware from the site, searching for ATMZOW, 19303817.js and PZ7SKD.
The file clear.json (backup) changes the password of several common staff user names to how1are2you3 (see below for list).
What you can do
If you are a merchant and found the MagentoCore.net skimmer in your store, this is the to-do list for your ops team / forensic investigator.
Find the entry point: how could attackers gain unauthorized access in the first place? Analyse backend access logs, correlate with staff IP’s and typical working hours. If suspicious activity is recorded from staff IPs, it could be that a staff computer is infected with malware, or that the attacker has hijacked an authorized session.
Find backdoors and unauthorized changes to your codebase. Usually there are a few, both in frontend/backend code and the database. My opensource Magento Malware Scanner can be useful here.
Once you have established all means of unauthorized access, close them all at once.
Implement secure procedures that cover timely patching, strong staff passwords etcetera. A good starting point.
If your team has little experience with forensic analysis, it generally pays off to hire a professional investigator. S/he will find the entry vector faster and perhaps more important, has a lower risk of leaving any undetected backdoors. One missed backdoor and you can start all over in a few weeks.
Admin user names
The MagentoCore malware will set the password to how1are2you3 for the following admin accounts periodically: