Client-side Magecart attacks still around, but more covert

This blog post was authored by Jérôme Segura

We have seen and heard less buzz about ‘Magecart’ during the past several months. While some companies continue to rehash the same breaches of yesteryear, we have been wondering if some changes took place in the threat landscape.

One thing we know is that if the Magecart threat actors decided to switch their operations exclusively server-side then the majority of companies, including ours, would lose visibility overnight. This is why we often look up to researchers that work the website cleanups. If something happens, these guys would likely notice it.

We followed the trail on two recent reports that proved to be worthwhile. It allowed us to make a connection to a previous campaign and identify new pieces of a pretty wide infrastructure.

For now we can say that Magecart client-side attacks are still around and that we could easily be missing them if we rely on automated crawlers and sandboxes, at least if we don’t make them more robust.

Newly reported domains linked with ‘anti-VM’ skimmer

On June 12, @rootprivilege tweeted about a hacked stored injected with the host js.staticounter[.]net that looked highly suspicious. When originally captured, the JavaScript appeared to be clean but it was confirmed to be malicious by @AffableKraut who posted a screenshot of the skimmer code.

A few days before @rootprivilege posted about this skimmer, @Sansec tweeted about another new skimmer domain at scanalytic[.]org. Comparing the two which are both on the same ASN (AS29182), we concluded that they are related.

We were able to connect these 2 domains with a previous campaign from November 2021 which was the first instance to our knowledge of a skimmer checking for the use of virtual machines. However, both of them are now devoid of VM detection code. It’s unclear why the threat actors removed it, unless perhaps it caused more issues than benefits.

There are other differences with the newest skimmer sample from @rootsecdev such as different naming schemes for important input fields. As you can see, in the former case these are explicitly referenced (i.e. CcNumber) while in the later iteration the names are generic web terms, making them less obvious.

Additional infrastructure

Using the urlscan.io service, we were able to discover additional infrastructure related to this ongoing campaign. We started our search with any recent submissions that made contact with an IP address belonging to AS29182.

The table below shows hostnames, their IP address and the date they were first seen on urlscan.io. Most of those were previously unknown to us until we recently started this investigation. You can click on the hyperlinks to load the corresponding sandbox pages, but note that a majority of them do not contain the actual skimmer code. This is most likely because the malicious infrastructure detected that urlscan.io’s sandbox was not using genuine residential IP addresses.

Hostname IP address First seen
app[.]nomalert[.]org 185.253.32.64 Nov 30, 2021
cdn[.]base-code[.]org 185.253.32.59 Jan 30, 2022
web[.]dwin-co[.]jp 185.253.32.44 Feb 3, 2022
dwin1[.]org 185.253.33.40 Feb 22, 2022
trustedport[.]org 185.253.32.50 March 4, 2022
h[.]lookmind[.]net 185.253.32.42 March 17, 2022
web[.]speedstester[.]com 185.253.33.191 March 25, 2022
search[.]global-search[.]net 185.253.33.188 April 13, 2022
static[.]clarlity[.]com 185.253.33.179 April 20, 2022
static[.]newrelc[.]net 185.63.190.207 April 22, 2022
static[.]druapps[.]org 185.63.190.183 May 26, 2022
js[.]imagero[.]org 185.63.190.144 May 27, 2022
common[.]quatserve[.]com 185.63.190.118 May 30, 2022
static[.]lookmetric[.]com 185.63.190.163 June 3, 2022
cdn[.]boxsearch[.]org 185.63.190.205 June 11, 2022

Validating skimmer activity

For the domains that are still responding, we can use information collected by urlscan.io and replay the attack using a genuine residential IP address and mimicking a real shopper’s experience. The image below shows the difference between a crawler session via VPN and one done manually with real network settings.

This allows us to confirm beyond doubt that the domains are indeed malicious, although their ASN should already be enough to proactively block them.

Connection with previous skimmer activity

Based on one hash, we can connect these skimmers to past activity going back to at least May 2020. One of the hostnames from our previous blog on the anti-vm skimmer, con[.]digital-speed[.]net, was loading this resource as well.

We can see 3 different themes used by the threat actor to hide their skimmer, named after JavaScript libraries:

Less skimmer activity or simply more covert?

There are likely many more skimmer domains on the infrastructure we detailed above, and it is a good idea to keep a close eye on it. Having said that, we have generally seen less skimming attacks during the past several months. Perhaps we have been too focused on the Magento CMS, or our crawlers and sandboxes are being detected because of various checks including at the network level.

As Ben Martin over at Sucuri showed, WordPress with the WooCommerce plugin is outpacing Magento in terms of attacks. In addition, we (as several other companies) can only observe client-side attacks and as such we are oblivious to what happens server-side. Only a handful of researchers who do website cleanups have the visibility into PHP-based skimmers.

While stealing credit cards is still a good business, there are other types of data considerably more worth it. Crypto wallets and similar digital assets are extremely valuable and there is no doubt that clever schemes to rob those are in place beyond phishing for them. For an example of a client-side attack via JavaScript draining crypto assets, check out this blog from Eliya Stein over at Confiant.

Malwarebytes customers are protected against this campaign.

Indicators of Compromise

Skimmer domains

abtasty[.]net
accdn[.]lpsnmedia[.]org
amplify[.]outbrains[.]net
apis[.]murdoog[.]org
app[.]iofrontcloud[.]com
app[.]nomalert[.]org
app[.]purechat[.]org
app[.]rolfinder[.]com
cdn[.]accutics[.]org
cdn[.]alexametrics[.]net
cdn[.]alligaturetrack[.]com
cdn[.]base-code[.]org
cdn[.]boxsearch[.]org
cdn[.]cookieslaw[.]org
cdn[.]getambassador[.]net
cdn[.]hs-analytics[.]org
cdn[.]jsdelivr[.]biz
cdn[.]nosto[.]org
cdn[.]pinnaclecart[.]io
cdn[.]speedcurve[.]org
cdn[.]tomafood[.]org
clickcease[.]biz
common[.]quatserve[.]com
con[.]digital-speed[.]net
content[.]digital-metric[.]org

css[.]tevidon[.]com
demo-metrics[.]net
dev[.]crisconnect[.]net
dwin1[.]org
epos[.]bayforall[.]biz
feedaty[.]org
graph[.]cloud-chart[.]net
h[.]lookmind[.]net
hal-data[.]org
img[.]etakeawaymax[.]biz
js[.]artesfut[.]com
js[.]g-livestatic[.]com
js[.]imagero[.]org
js[.]librarysetr[.]com
libsconnect[.]net
listrakbi[.]io
lp[.]celebrosnlp[.]org
m[.]brands-watch[.]com
m[.]sleeknote[.]org
marklibs[.]com
nypi[.]dc-storm[.]org
opendwin[.]com
pepperjams[.]org
px[.]owneriq[.]org

r[.]klarnacdn[.]org
rawgit[.]net
rolfinder[.]com
s1[.]listrakbi[.]org
sdk[.]moonflare[.]org
search[.]global-search[.]net
shopvisible[.]org
sjsmartcontent[.]org
snapengage[.]io
st[.]adsrvr[.]biz
stage[.]sleefnote[.]com
stat-analytics[.]org
static[.]clarlity[.]com
static[.]druapps[.]org
static[.]lookmetric[.]com
static[.]mantisadnetwork[.]org
static[.]newrelc[.]net
static[.]opendwin[.]com
t[.]trackedlink[.]org
troadster[.]com
trustedport[.]org
web[.]dwin-co[.]jp
web[.]livechatsinc[.]net
web[.]speedstester[.]com
web[.]webflows[.]net


Skimmer IPs

185.253.32.174
185.253.32.42
185.253.32.44
185.253.32.50
185.253.32.59
185.253.32.64
185.253.33.179
185.253.33.188
185.253.33.191
185.253.33.40
185.63.188.59
185.63.188.70
185.63.188.71
185.63.188.79
185.63.188.85
185.63.190.118

185.63.190.144
185.63.190.163
185.63.190.183
185.63.190.205
185.63.190.207
185.63.190.212
194.87.217.195
194.87.217.197
194.87.217.91
212.109.222.225
77.246.157.133
80.78.249.78
82.146.50.89
82.146.50.132
82.202.160.10
82.202.160.119

82.202.160.123
82.202.160.137
82.202.160.29
82.202.160.54
82.202.160.8
82.202.160.9
82.202.161.77
89.108.109.14
89.108.109.167
89.108.109.169
89.108.116.123
89.108.116.48
89.108.123.168
89.108.123.169
89.108.123.28
89.108.126.50
89.108.127.16

The post Client-side Magecart attacks still around, but more covert appeared first on Malwarebytes Labs.

Article Link: Client-side Magecart attacks still around, but more covert | Malwarebytes Labs