Tech & Engineering Blog

MallRats: An Analysis of the Natural Fresh Mall Magecart Attack

The Natural Fresh Mall Magecart attack was first reported at the end of January 2022. Researchers discovered a mass infection of a single Magecart strain in one day, which grew to more than 500 compromised stores by early February. By combining SQL and PHP Object injections, the attackers took control of the Magento stores and left as many as 19 backdoors installed in some cases.

Apart from abusing the same Quickview plugin to gain a foothold in the server, all of the hacked sites were injected with a single skimmer served from

The skimmer itself was only lightly obfuscated, using array reference replacements. It contained some cleartext function and variable names, as well as several unused code bits. The skimmer made use of a fake form and saved the stolen data in a cookie between reading, parsing, and exfiltrating it. It did not bother to cover its tracks once the attack was completed.

The Attack Flow

All pages were injected with the skimmer, however two sets of checks kept it from going off early: whether a targeted CSS selector of payment options selection was found in the current page, and whether any of the values it collected included a credit card number and CVV.

When both conditions are met, the attack activates and proceeds as follows:

  1. The skimmer looks for an element containing the payment options selection. Once found, it injects a fake credit/debit payment form into it and hides all of its original child elements, effectively removing all other payment options other than the fake form.
  2. An event listener is placed on all buttons in the page. Once clicked, the heart of the attack is initiated:

    1. The values of all input and select fields on all of the forms found on the page are collected in pairs of field name/id and its value. Each collected pair is immediately stored in a cookie.
    2. Once the collection is completed, the values are extracted from the cookie and parsed, replacing implementation-specific field names with a standardized field description. For example, fields with names/ids such as payment[ps_cc_number], creditCardNum, card[num], or mundipagg_creditcard_1_1_cc_number are all replaced with cc_number. The script receiving the exfiltrated data may require this normalization to verify its content.
    3. After verifying a credit card number and CVV were captured, the data is hex-encoded and then base64 encoded. Next, it is placed within a form-data payload filled with fake fields — with names like products_hash, captcha_hash, and visit_hash — all containing randomly generated strings of different lengths. The actual stolen data is placed in the middle of it all, under the name stat_infos. Wrapping the actual stolen data in a generated noise sandwich is probably meant to hinder detection by “hiding a tree in a forest.” This makes it more difficult to recognize the data in the outgoing request.
    4. The payload is then sent in a POST request to https://naturalfreshmall[.]com/payment/Payment.php.
    5. The data is deleted from the cookie, the fake form is hidden, and all of the previously hidden different payment options are displayed.
    6. A specific cookie value is set to prevent the attack from running again.
    7. An alert is triggered with the message “Selected payment method is currently unavailable, please try again” to lower suspicion from the user who will need to re-enter their payment information a second time — this time into the real form — to complete the checkout process.


Earlier Variations

Further examination of the compromised sites revealed earlier versions of the same skimmer, dubbed “Bom” skimmer. This earlier iteration of variants started to propagate in September 2021. It followed the same basic attack method and even shared most of the code with the Natural Fresh Mall skimmer, though there are a couple of differences worth mentioning:

Injection Type

While the Natural Fresh Mall skimmer is injected as a third-party script, the variants mostly show up as first-party scripts that are either completely new in the site and contain only the skimmer code, or are appended to an existing script.

Some of the injections are strictly inline, and a small percentage of them are third-party, utilizing other compromised vendors as a distribution channel for the skimmer.

Exfiltration Destination

The same applies to the exfiltration destination. Instead of sending the stolen data to, most of the variants use first-party paths such as:

  • /
  • checkout
  • /media/blog/index.php
  • /skin/frontend/default/default/
  • /skin/frontend/default/default/api.php
  • /checkout/onepage/savePayment/

These paths likely point to malicious code injected into the server that receives the stolen payment details. The backend code then either sends them via server-side requests to a fraudster-controlled server, or perhaps saves them to local files to be accessed manually.

Targeted Fields

The Natural Fresh Mall skimmer strictly targeted Magento checkout pages with its fake form injection by searching for a unique checkout-payment-method-load element id. Some of the other variants, however, have a wider bank of targets such as PrestaShop, XPay, WorldPay, and WooCommerce.

Some variants also collected personally identifiable information (PII), such as names and addresses, from the billing form.


  • Once an exploit becomes common knowledge, it doesn’t take long before it is observed being used in the wild. Competing attackers scan the web for sites that are vulnerable to this new exploit and attack them, which sometimes results in more than one backdoor or skimmer script injected to the same site.
  • While attackers keep finding new methods of exploiting their way into e-commerce sites, most of their methods for stealing payment details and PII remain similar to those previously seen.
  • Left untreated, a breached site may be used as a proxy for attackers, serving skimmers to other breached sites, receiving stolen data, or both. These further exploitations of the breached sites may result in high risk scores for the compromised domains, damaging reputation.
  • As previously observed, even if an attack is passively made inert — for example, if the malicious server is down or the script is unavailable — the injected scripts might spring back to life and serve unwanted ads, a new skimmer or other malicious content. Thus, website owners must actively close the breach and remove the offending scripts in order to end the attack.

HUMAN Code Defender gives website owners complete visibility and control into the behavior of first-, third- and nth-party scripts, reducing your risk of a Magecart attack. Book a demo to learn more.

Check out these resources on GitHub to learn more about the skimmer: