A Safe Browsing blocklisting that file cleanup could never have fixed

The problem

Every visitor to a client's business website hit a full-page "Deceptive Website Warning" in Safari and Chrome. Google Safe Browsing had blocklisted the domain.

The obvious reading is that the site was hacked and needs cleaning. That reading was half right, and acting on only that half would have produced a site that looked clean, passed a scan, and stayed blocklisted.

What I found

Four active phishing kits in an old, forgotten directory on the server. One was a cryptocurrency wallet seed-phrase stealer that exfiltrated to a Telegram bot. Another was a fake corporate login page harvesting passwords and MFA codes. One used ASN-based cloaking — serving benign content to networks belonging to security vendors and the real payload to everyone else, which is why automated scanning had not flagged it.

The entry point: three abandoned WordPress installations dating from 2014 to 2020, left on the account with known-vulnerable plugins. Nobody had thought about them in years, which is precisely the point.

The actual root cause, which no amount of file cleanup would have touched: a malicious wildcard DNS record pointing the domain's subdomains at an attacker-controlled server. The phishing pages Google was flagging were being served from the attacker's own infrastructure, under the client's domain name. Deleting every file on the client's server would have changed nothing.

I found it by working backwards from the sample URLs Search Console had flagged. They did not correspond to anything on the server — which is the tell. I then removed the record and verified the change at the authoritative nameservers rather than trusting the control panel's display.

What I did

Rebuilt the site as pure static HTML and CSS. No server-side code means nothing left to exploit, and for a brochure site there was never a reason to run PHP in the first place. The contact form moved to a serverless backend, since the host had disabled outbound mail after the spam abuse.

Then the unglamorous half: blocked script execution in asset directories, audited all JavaScript and third-party resources, rotated every credential, documented the full DNS zone before making any change, and prepared the Search Console review request to get the warning lifted.

Why it mattered

Two prior assumptions were both reasonable and both wrong — that a Safe Browsing warning means infected files, and that a clean server means a clean domain. A domain is not a server. Control of the DNS zone is control of the name, and a wildcard record turns every subdomain that was never created into an asset the attacker owns.

The diagnostic that mattered cost nothing: read the URLs Google actually flagged, and check whether they exist on the origin. When they do not, stop cleaning files.