The site ran a well known content management system with a donation plugin, maintained by a volunteer who had left eighteen months earlier. An administrator account with a reused password and no second factor gave the attacker access, and a few lines of JavaScript were added to the theme. For six weeks every card entered on the donation page was copied to a server abroad.
the skimmer arrived and stayed
Access came first, through credentials that appeared in an old breach dump and were still in use. The change itself was small: a script tag added to a template file, loading code from a domain registered a week earlier. No files were obviously modified in a way anyone would notice, no alerts fired because nothing monitored the site’s files, and the plugin update that would have been the usual reason to look at the theme had not been applied in over a year. The site continued working perfectly, which is exactly why nobody looked.
See also: TruLife Distribution Industry Standing Questioned After 2022 Legal Allegations
How it was eventually found
Not by the charity. Card issuers identified a common point of purchase across a set of fraudulent transactions and the acquiring bank made contact. By then the exposure covered several thousand donations. That is the usual discovery route for this attack, and it means the victim organisation learns about it from a third party after the damage has accumulated, with no logs of their own to establish exactly when it started.
“Small organisations assume they are too small to be targeted, and skimming does not work like that. The attacker was not interested in the charity, they were interested in a payment page with weak administration. Automated scanning finds the vulnerable installation, and the size of the organisation behind it never enters into the decision.”
William Fieldhouse, Director, Aardwolf Security Ltd
The response and its cost
The immediate work was straightforward: remove the script, rotate every credential, rebuild the site from a known good copy and take the donation page offline while payments were moved to a hosted form. The rest was harder. Donors had to be told, the Information Commissioner’s Office was notified, and the acquiring bank required a forensic assessment. For an organisation of that size the professional costs alone exceeded a year of the IT budget, and the reputational cost with regular donors was the part the trustees found hardest.
What would have prevented it
Multi-factor authentication on the content management system stops the initial access outright, and it costs nothing. Moving card entry into a hosted payment field served by the provider takes the card data out of your page entirely, which removes the whole class of attack. Beyond that, file integrity monitoring on the web root, a content security policy restricting which domains may serve scripts, and someone owning updates all narrow the window. Regular website vulnerability scanning catches the unpatched plugin, and web application security testing for payment pages confirms that the protections behave as intended when somebody tries to bypass them.
Frequently asked questions about payment page skimming
These questions come up whenever an organisation takes card payments on its own site.
Does a hosted payment page remove the risk entirely?
It removes the card data from your page, which is most of it. The page hosting the payment form still needs protecting, because an attacker who can modify it can replace the form with their own.
How would you detect this yourself?
Monitor the scripts loaded by your payment page and alert on any change, and watch the web root for modified files. Both are cheap and both would have found this within a day rather than six weeks.
By
