Card theft at the checkout: formjacking and Magecart
The shop works. Orders come in, the bank pays out, nothing looks wrong. And for weeks or months, someone else has been collecting your customers' card details.
What it is
Formjacking is the theft of what a customer types into a payment form. Magecart is the name given to the groups that have been doing this to online shops since the mid-2010s, first on Magento and then on every platform.
The attack does not break the shop, because a broken shop gets fixed. It changes one small thing in the payment path and leaves everything else alone.
The four ways it is done
1. The payment address is changed
Your shop sends the customer to the bank's payment page. The attacker changes that address to a page of their own that looks the same, often on a domain one letter away from the real one. The customer types the card there, and is then passed on to the real bank page, where the payment completes normally. The customer thinks they typed it twice. You see a paid order.
2. Code is added to the checkout page
A few lines are added to a checkout file or template in your shop. They copy whatever is typed into the card fields and send it elsewhere, while the form carries on as usual.
3. The payment settings are changed
Nothing changes in the files. The attacker changes the gateway address or the merchant details stored in the shop's database, through the admin area or directly.
4. A third party's script is changed
Your checkout loads a script from another company, such as a chat or statistics tool. That company is breached and the script is altered on their server. Nothing in your shop has changed.
Two cases that became public
- British Airways, 2018. Code added to the airline's payment page collected customers' card details. In 2020 the UK data protection authority fined the company 20 million pounds.
- Ticketmaster UK, 2018. The code arrived through a third-party chat tool on the payment page. In 2020 the same authority fined the company 1.25 million pounds.
Large companies make the news. The same method is used every day on small shops, where nobody is watching.
Why ordinary tools miss it
- Antivirus looks for known malicious code. A changed web address is not a virus.
- A firewall blocks suspicious traffic. Once the attacker is in with a stolen password, the change looks like normal work.
- An external scan, including the quarterly PCI scan, looks at the server from outside. From outside, the shop looks fine.
- You see orders being paid.
How shops usually find out
- The bank or the card processor tells them that cards used in their shop were later used for fraud.
- Customers write that they were asked for their card twice, or that they saw charges they do not recognise.
- They do not find out at all.
By then the change has usually been in place for a long time. What follows is an investigation, a possible suspension of card payments, and the question of whether customers and the data protection authority must be told.
What HachiGuard does about each one
Detected at the next check. The clean file is put back automatically and you are told.
Detected: every change to a checkout file is reported, and known theft patterns raise a critical alert. Restored automatically when the change adds an unknown destination.
Detected and reported as critical when an unknown address appears. Settings are not changed back automatically.
Partly covered. Our outside check notices a new third-party domain on your public pages. A change made inside a script that was already there, on the third party's own server, is not detected.
What else you should do
- Keep the platform and its extensions up to date.
- Give each administrator their own account, with a strong password and two-step sign-in where the platform offers it. Remove accounts nobody uses.
- Where you can, send the customer to the bank's own payment page instead of taking the card inside your shop.
- Load as few third-party scripts as possible on the checkout.