First: delete nothing
The understandable impulse is to delete the suspicious files and change the password. Both destroy evidence and do not close the door. The back door is almost always somewhere other than the visible malware: in a second, inconspicuously named file, in a modified system file, in an additional administrator account, in a cron job, or in an extension that restores itself.
So the first step is: put the site into maintenance mode, make a copy of files and database, lock access, secure the logs. Only then analyse. Whoever works in this order can later say what happened — and does not have to start again in four weeks because the back door was still there.
How we find the way in
We read the access logs backwards: upload paths, login pages, installation tools, unusual requests shortly before the first change. We compare the files with the originals of core and extensions and see what was changed or added. We check the database for foreign accounts and injected content, the installed extensions for known vulnerabilities, and the question of where credentials were stored that should not have been there.
The result is a picture: when it happened, through which route, and what the attacker did. Without this picture every restore is a matter of luck — with it we know which state is clean and which gap has to be closed.
Restore cleanly instead of tidying up
The cleanest route is a backup from before the break-in, plus all updates released since. For a shop we reconcile the data created since the backup — orders, customer accounts — and carry them over after checking. If there is no reliable backup, we set up core and extensions fresh from the original sources and take over only content and uploads, after checking them.
After that all credentials are changed, without exception: administrators, database, FTP and SSH, API keys, payment providers, mail sending. A password the attacker knows makes the best restore worthless.
Afterwards: close the gap and win back trust
The actual cause — an outdated extension, an open installation tool, a form without validation, a server on a PHP version without updates — is closed and the system hardened: updates, a second factor for admin access, rights by task, and on request a firewall in front of the server with Cloudflare.
Then we win back trust: in Google Search Console we check the security issues and request a review so that the warning disappears. If the domain is on block lists for mail or browser warnings, we start the removal. If personal data was reachable, the GDPR requires notification of the supervisory authority within 72 hours (Article 33) — we provide the technical facts, the legal assessment stays with you or your data protection officer.
What it costs and what we do not promise
Emergency help is billed by effort, after a short first conversation in which we assess the situation. We do not give a time or price commitment without looking at the system — whoever does is guessing. What we do commit to: the order of steps, transparency about every step, and a short report at the end that records what happened and what was done.
And we do not promise one hundred percent security. What we offer is the state in which mass attacks come to nothing and an incident stays an incident — with ongoing support that takes care of updates, backups and monitoring so that you never need this page again.