01 Starting point
The tip came from outside: a back door was running on the server of a long-standing customer. The online shop — B2B and B2C, connected to the ERP — had not received security updates for years; not out of carelessness, but because nobody was responsible for it. The vulnerability the attacker used was publicly documented and had been closed for months. Just not on this system.
The situation was typical of such cases: the shop was running, orders were coming in, nothing was visible from outside. Only the analysis showed two entry routes, foreign files in several places and traces of earlier access. On top came legacy issues that had nothing to do with the attack but became visible in the same pass: unprotected services, credentials in plain text, extensions that had been failing silently since the last PHP change.
The customer had two questions: how quickly is the shop safely online again — and what has to happen so that this does not happen again.
02 Solution
Secure first, then understand: shop taken off the network, files, database and logs quarantined with checksums, foreign keys removed, passwords changed. The logs read backwards until both entry routes and the point in time were established. Nothing was deleted before it was secured — the back door, as almost always, was not where the first suspicious file was.
Then the rebuild: shop system brought to the current security level, foreign files removed, all admin accounts with new passwords and a second factor, interface credentials reissued, web server hardened — upload and installation paths closed, administration reachable only from known networks. Less than two days after the tip the shop was online again.
In front of it, a firewall: both shop domains behind Cloudflare, with rules against the known attack paths, rate limits for login and interfaces, exceptions for payment providers and ERP, real visitor addresses at the server. In the following days the security events showed further probing from several countries — all ran into the rules, none reached the server.
And afterwards the unspectacular half: monitors for file changes, interfaces and origin of access, a daily audit across both shop frontends, backups with restore tests. The legacy issues found during the analysis were worked through in the same week. Since then the shop has been under a maintenance contract with fixed check intervals — the form in which the incident would never have happened.
03 Result
The shop is running again — up to date, behind a firewall, with access that deserves the name, and with monitors that report before customers notice. What has been closed is the cause, not just the symptom.
The most important insight is uncomfortable: the patch against the vulnerability used had been available for months. A maintenance contract with security updates at fixed intervals would have prevented the incident — at a fraction of what forensics, rebuild and follow-up work cost. Ongoing maintenance is not a convenience. It is the cheapest form of security.
That also applies legally: Article 32 GDPR requires technical measures appropriate to the risk, and regular security updates are part of that. Whoever installs them verifiably fulfils this obligation and, in an emergency, stands differently before the supervisory authority and customers than an operator with years of backlog. Whether and what has to be reported is decided case by case by the data protection officer — the technical facts for that are delivered by an orderly procedure like this one.