# Hacked PrestaShop: checkout skimmers, fake admins and how to spot them

A hacked brochure site usually gets noticed: redirects to spam sites, the browser's red warning, Google flagging it. A hacked PrestaShop store often doesn't. The most profitable attack on an online store doesn't want to be seen: it wants to stay hidden in the checkout as long as possible, copying customers' card details while the store keeps selling as usual.

In this article we look at how these attacks work, which signs give them away, what to do in the first hours and how to stop them from happening again.

How an attack gets into a PrestaShop store

The ways in are almost always the same:

• modules with known vulnerabilities never updated, especially those receiving external data (imports, forms, search);
• old PrestaShop versions, missing years of fixes, as we saw when discussing stores staying on PrestaShop 1.7 or 8;
• back office passwords that are weak or reused, attacked by trial and error;
• an admin area reachable at an easy-to-guess address.

A real case: in July 2022 PrestaShop warned merchants of a campaign exploiting an SQL injection, a way to make the database run unintended commands, present in old versions and in a widespread module. The attackers created a file in the site root, took control of the server and added a fake payment module to the checkout that sent card details to them.

What a skimmer is and where it hides

A skimmer is a small script that reads what the customer types in the card fields and sends it to an external server. The name comes from devices secretly fitted to cash machines. In a PrestaShop store it can sit:

• in a theme or module file, modified by adding a few lines;
• in the database, inside a setting or a content block printed on the payment page;
• in a fake payment module, posing as an extra method or replacing the real one.

It often activates only on the payment page, only for some visitors or only on mobile, precisely to avoid being noticed by whoever runs the store.

Signs not to ignore

• Customers reporting odd charges after a purchase: often the first sign, and it comes late.
• The checkout looks different: an extra field, a new step, a payment method nobody configured.
• Unknown admins in the back office, or logins from countries where nobody works.
• New PHP files in folders that shouldn't contain any, such as image or cache folders.
• Sudden slowdowns with no obvious reason: they can have plenty of innocent causes, but also foreign code running on every page.
• External warnings: Google Search Console, the payment provider, the host reporting unusual traffic.

The first hours: what to do and what not to do

Do: back up the current state before touching anything, because it helps understand what happened and since when; change every password, back office, database, hosting, FTP; tell your payment provider if you suspect card details were read.

Don't: hastily restore an old backup without finding the hole, because the attacker comes back through the same door within days; delete files at random, losing the traces; wait "to see if it happens again". If personal data is involved, GDPR requires notifying the authority within 72 hours of becoming aware of the breach, even if the picture isn't complete yet (the notification can be supplemented later), and in many cases telling customers too: we covered this in GDPR on the infrastructure side.

Close the door, don't just clean up

Removing the skimmer is half the job: it's what we do in PrestaShop malware removal, together with finding the entry point. The other half is finding how it got in and closing that path: updating or replacing the vulnerable module, updating PrestaShop, moving and protecting the admin area, limiting login attempts as you would with fail2ban against brute force attacks. And having backups that actually restore, clean and stored elsewhere, so you don't have to choose between an infected store and one months out of date.

In short

A hacked PrestaShop store isn't always visible: the most common attack on an online store targets the checkout and stays hidden. The signs are there, from charges reported by customers to unknown admins. When it happens, you need a backup of the current state, new passwords, a cleanup of files and database and, above all, closing the hole it came through. Regular updates and a protected back office do the rest.

Sources

• Major security vulnerability on PrestaShop websites - PrestaShop Project, July 2022
• Regulation (EU) 2016/679, Article 33 - notification of a personal data breach
• Security policy - PrestaShop 9 - official documentation