Your site was hacked: a step-by-step response plan

Your host sends a spam notice, the browser shows a red "Deceptive site" warning, and pages you never created are showing up in search under your domain. Panic is the most expensive part: half the damage comes not from the attacker but from frantic decisions in the first few hours. Here is the order we follow on real incidents.

Hour one: isolate, do not delete

The first instinct is to wipe the suspicious files. Do not. Along with the shell you destroy the evidence, and you will never learn how the attacker got in. Two weeks later they return the same way. The correct order: take a full filesystem snapshot and database dumps, then take the site down behind a holding page or switch it to static. Copy the web server logs separately — many hosts rotate them every 24 hours, and by day two the picture is gone.

Hour two: rotate every credential

• SSH and FTP passwords, including technical deployment accounts.
• The database user password and the connection string in the config.
• Every CMS administrator account, not just the compromised one.
• API keys for payment gateways, mail services and external integrations.
• The hosting panel, domain registrar and DNS — these are forgotten most often, and they are exactly where mail gets intercepted.
• Secrets in the repository: if a key ever reached git, treat it as public forever.

Day one: finding the entry point

Restoring from a backup before investigating is a classic mistake. If the backup was taken after the compromise, you bring the backdoor right back. Look for the entry point along three lines: access logs for the week before the first anomalies, file modification times, and CMS and plugin versions. In the overwhelming majority of cases the way in is an outdated component with a public exploit. Once you have a vulnerability number, check it against the CVE database to see which versions are affected and whether a patch exists.

Day two: cleanup and recovery

The CMS core is reinstalled from the official distribution, not patched by hand. Template and upload files are compared against a reference copy with diff. In the database, check the user tables for extra administrators and autoloaded options for injections. Pay separate attention to the uploads directory: there should be no executable files there, and access to them is blocked at the web server level. If you have no in-house team, bringing in technical support is wiser than fixing things blind.

Winning back search engines' trust

After a breach the site often lands on a dangerous-sites list. The recovery order: confirm the malware is gone, request a review in the Yandex and Google webmaster consoles, and wait for the flag to be lifted. That usually takes 1–3 days. In parallel, check whether doorway pages and spam redirects have entered the index — those need to be submitted for removal and served a 410 status. Lost positions come back more slowly, and here steady work on technical optimisation is what helps.

So it does not happen again

• An update policy: critical patches within 72 hours, everything else once a month on a schedule.
• Backups on external storage with at least 30 days of retention and regular test restores.
• Two-factor authentication on every administrative login.
• Least privilege: a content manager has no business having file manager access.
• File integrity monitoring with alerts on any change in system directories.

What it costs

Handling an average incident, including cleanup and recovery, takes between 8 and 40 hours of engineering time. Prevention — updates, backups, monitoring — costs roughly one hour of incident response per month. The arithmetic is obvious, though it usually sinks in only after the first breach. We cover cases like this in the security section, and examples of infrastructure we have maintained for years are in our portfolio.