Your organization’s leadership is 12 times more likely to be the target of a security incident and nine times more likely to be the target of a data breach than they were last year. Find out how they can be protected.
Read the Datasheet
Gift Cardsharks: The Massive Threat Campaigns Circling Beneath the Surface
Learn about the attack group primarily targeting gift card retailers and the monetization techniques they use.
Get the Report
Threat Hunting Workshop Series
Join one of our security threat hunting workshops to get hands-on experience investigating and remediating threats.
Attend an Upcoming Workshop
Inside Magecart: New RiskIQ & Flashpoint Research Report
Learn about the groups and criminal underworld behind the front-page breaches.
Threat Hunting Guide: 3 Must-Haves for the Effective Modern Threat Hunter
The threat hunting landscape is constantly evolving. Learn the techniques, tactics, and tools needed to become a highly-effective threat hunter.
In November of 2018, we published the cornerstone report “Inside Magecart,” in which we disclosed the existence of seven distinct Magecart groups and described in detail their operations and the different ways they skim payment information. Since then, we’ve detailed even more groups, such as Group 11 and Group 12.
After our researchers surface more Magecart instances in RiskIQ’s automated detection, attribution is usually the final step in our analysis. However, we also spend a lot of time keeping up with each group and how it evolves. In this article, we’ll get back to a group we covered in the “Inside Magecart” report: Magecart Group 4.
We shed a big, bright light on Magecart Group 4’s operation and in the process described how their skimming attacks worked. However, more importantly, we took down crucial parts of their infrastructure. By taking down this infrastructure, we forced them to change their tactics and rebuild everything. Fortunately, this did not affect our ability to track them.
Magecart Group 4 has registered close to a hundred new domains and set up a large pool of servers with which to route these domains and supply victimized websites with skimmers. When we described Magecart Group 4 in the Inside Magecart report, we noted them as one of the most advanced groups we’ve encountered given their rich history in the e-crime ecosystem. This has proven to be even more true with their actions since:
The group only puts a maximum of five domains on one IP address and makes sure these don’t route to any other IPs that could cause overlap with any domains outside that group.
We explained that Magecart Group 4 used the jQuery mask library as a coverup when a visitor was not on the payment page as not to leak their skimmer until it was needed. Now, they no longer rely on just the one library and have added a multitude of different benign libraries.
Previous Magecart Group 4 infrastructure was fixed on bulletproof hosters or hosters that often turn a blind eye to illegal activities on their infrastructure. In their renewed operation, Magecart Group 4 moved its infrastructure around a bit. They’ve incorporated pools of approximately ten sequential IPs at five different hosters in an attempt to reduce the risk of server takedowns.
Just as it’s our job to protect our customers, it’s Magecart Group 4’s job to maximize their income with web-based skimming. Likewise, just like we’re professionals in cybersecurity, they’re professionals in cybercrime. We may not hold their ‘job’ in high regard, but Magecart Group 4 is an advanced group of professional criminals and a dangerous adversary.
Magecart Group 4’s tactic of pooling of domains, which we mentioned above, is just one example of this professionalism. The group’s typical setup used to be a mash-up of domains randomly spread across IP address. Now, they’re pooling a maximum of five domains on a single IP address, which looks like this:
The domains associated with Magecart Group 4’s skimming operation are simply proxies pointing towards a large internal network. After applying some initial filtering, these proxies upstream skimmer requests towards a backend that provides the skimmer script (or benign script when a visitor isn’t performing a payment).
This type of infrastructure is unlike that used by other Magecart groups operating in the wild. Many of these groups rely on “kits” that are a combination of PHP and MySQL-based backends. With these, the same server that obtains the stolen data also functions as the source of the skimming code and includes a backend for the Magecart operators to log in to see their earnings. However, Magecart Group 4 has advanced far beyond skimming kits to developing their own organizational skimming infrastructure.
Magecart Group 4 not only updated their infrastructure, but they also spent time updating key elements of their skimmer. We won’t go through the entire skimmer but will break down the important parts that changed.
One thing to note is that Magecart Group 4 actively updates their skimmer code. RiskIQ sees legacy elements of the old skimmer in the new skimmer, but this old functionality is entirely unused. Additionally, certain features in the skimmer are enabled with feature flags; the skimmer that is used in their live operation has “new” features turned off by default. This gives a sense of Q&A for Magecart Group 4.
The previous version of Magecart Group 4’s skimmer wasn’t actually a skimmer—it was an overlay payment phishing system. However, in the updated version, they are skimming existing payment forms instead of building up their own payment forms. Magecart Group 4’s skimmer now goes through page forms and pulls out the payment data, which significantly reduced the skimmer from over 1,500 lines of code to a little over 150 lines.
Magecart Group 4’s new skimmer also adds one more event listener to hook into the process of the payment-completion process. Usually, this involves a ‘submit button’ of some kind, but In this case, they hook the keyboard key-events and search for usage of the return/enter key. This is just one more option they added to the skimmer with a feature flag which, until now, we have only seen turned off, which likely indicates Magecart Group 4 is still experimenting with it.
Previously the exfiltration URL used by the Magecart Group 4 skimmers was a concatenation of: <website scheme>://<exfil domain>/<checkout path of victim website>/saveOrder.The new method of exfiltration is more simplified:
(.jpg file path)
The data the skimmer infiltrates was just base64 encoded previously, but in the new version, they make use of RSA public/private key cryptography. The skimmer now has a hardcoded public key:
—–BEGIN PUBLIC KEY—–
—–END PUBLIC KEY—–
This key is used with the JSEncrypt library to encrypt the skimmed data. The encrypted data is then encoded with base64 and added with URL parameters:
As with our previous reporting, we have taken up the help of ShadowServer and AbuseCH to perform takedowns and sinkholing of the Magecart Group 4 infrastructure we disclose with this report. Their continued efforts in taking down this malicious infrastructure are highly appreciated as always!
With this update on Magecart Group 4, we are also providing the infrastructure that has been set up since our publication of “Inside Magecart.” The following RiskIQ Community project contains just the domains:
As we explained briefly, the infrastructure for Magecart Group 4 is a proxy-based network with the domains we provided being the contact point for proxies. The domains themselves are of higher value than the IP addresses as they simply pool and swap those around quickly. For this reason, we did not put the IP addresses in the RiskIQ Community Project. However, we will share them below for those interested in investigating this more.
The IP addresses we provided are clear sequenced hosts. While some numbers in the sequences are missing we do have high confidence these missing sequence IP addresses are also owned by Magecart Group 4; we just haven’t seen a skimming domain resolve to it. Here is a list of the confirmed IP addresses hosting the skimming infrastructure from Magecart Group 4 since November 2018 after our reporting:
Some organisations have a mature attack surface management programme, others are just starting on the journey, evaluating the scope of their programme and identifying where to start, notes Aaron Mog of @RiskIQ
#informationsecurity #GDPR #CyberSecurity
Get your #RSAC 2020 party started by joining RiskIQ at IGNITE, hosted by @FlashpointIntel! Register now: https://t.co/XhmW7kUCY8
Now you can see why we named it Magecart 🙃 it’s where it started in 2014. A group normally skimming data through Mage.php when a cart checkout is done, started pioneering a client-side JS skimmer.
The rest of the story can be read in our 2018 report: https://t.co/aGlU984pTU https://t.co/AwDlwdb36p
Based on data from @riskiq it appears this campaign by the Russian GRU to hack and breach Burisma in Ukraine started around 11-11-2019 (and possibly earlier) with the registration of the domain kub-gas[.]com cc @Ushadrons @file411 @IdeaGov #infosec #phishing #malware #disinfo
RiskIQ is excited to announce that growth expert Christophe Culine has joined our team as Chief Revenue Officer, leading our sales organization to great things in 2020 and beyond https://t.co/DYCAOfYeIa