We get this call regularly, and it is always the same story. A small online shop, often on PrestaShop, has been running the same version for years on the principle of “don’t touch it while it works”. It has an iFrame or a redirect to its payment provider, so it validates with SAQ A, the shortest questionnaire there is, and it has read that as “nothing to protect”.
Then a critical vulnerability in the old software is exploited. The attacker redirects the shop’s customers to a fake payment page, or installs a skimmer on the real one. The payment provider sees transactions drop, works out why, and suspends card payments. Its letter to the merchant says: come back with a clean external vulnerability scan and a compliance assessment signed by a QSA. The merchant, now losing most of its sales, calls us.
Three shops
Three recent cases, all small shops on the same platform, all legitimately on SAQ A, all compromised. In one, the attacker did not need a software flaw at all: they logged in with valid stolen administrator credentials, installed a module with a backdoor, then web shells, then two card skimmers and an encrypted channel to send the data out. Across the three, the common ground was an out-of-date platform with known critical vulnerabilities, and server settings nobody had looked at since installation: passwords that never expire, root allowed to log in over SSH, that kind of thing.
The shop owners all say the same thing on the first call, almost word for word: we need to get our ability to process payments back as soon as possible, we are losing sales. Nobody asks about the standard. That is fair. The standard is our job; their job is the shop.
What we do, and in what order
The merchant is in a hurry. It can still take some payments through alternative methods, but not cards, and that is most of its turnover. So our approach is quick and, honestly, a little dirty. It is also the right one.
- Rebuild from a known-good backup. Not “clean up”. Once an attacker has had administrator access and installed modules and shells, you do not know what else is there. Rebuild, from a backup taken before the compromise, and go straight to the current version of the platform.
- Check the SAQ A requirements against the rebuilt shop. SAQ A is short, but it is not empty. It asks about administrator accounts and passwords, about the software being patched, and about the integrity of the page that hands the customer to the payment provider. In these cases, every one of those was the problem.
- Write a short recommendation report. The minimum set of controls the merchant has to put in place to sign SAQ A truthfully, plus the handful of things we would do anyway: a patching routine, a dedicated administrator account per person, a backup that is actually tested.
- Come back when it is done. We verify the corrections, run the external scan, and release the SAQ A with its Attestation. The provider turns card payments back on.
We recommend; we do not fix. The fixing is usually done by the merchant’s web agency, and that is as it should be. Our job is to say what is needed, check it was done, and sign only when it was.
In most cases, the single change that mattered most was upgrading the shop software. Everything else was hygiene around it.
The hosting provider
One part of this is never in the questionnaire. Small merchants and their hosting providers do not speak the same language. The merchant knows its products. The hosting provider’s support desk knows its platform, and answers in those terms. Getting a backup restored, a server setting changed or a version upgraded can stall for days on that gap, while the shop is losing sales. We sometimes step in just to translate: here is what we need, here is why, here is the setting. It is not assessment work. It is what gets the shop back on its feet.
What people get wrong
They read “SAQ A” as “the payment provider handles security”. The questionnaire is short because the merchant does not touch card data. But the server that delivers the payment iFrame or the redirect is exactly what the attacker goes after, because whoever controls that page controls where the customer’s card details go.
They treat the external scan as the fix. The provider asks for it, so it must be done, but a passing scan of a freshly rebuilt server tells you very little about whether the shop will still be clean in six months. The patching routine does that.
They wait. Every week on an old version is a week in which a published vulnerability is being scanned for by people who do this at scale. The shops that get hit are not chosen. They are found.
The shops that get hit are not chosen. They are found.