The Setup
A specialty chemical manufacturer came to us for a straight answer on the health of their WordPress site. They’d been hacked before, more than once, and each time the response had been the same: clean it up, get back online, move on. Nobody had ever gone back to figure out how the attacker got in, whether the door was actually closed, or what else might still be sitting on the server from previous incidents. They wanted a real audit instead of another reactive fix.
The Problem
On the surface, the site looked fine. WordPress core was untouched, every plugin matched its official release, and two independent malware scans, one offline against a recent backup, one live against the production site, came back clean. That alone would have been an easy report to write and an easy one to feel good about.
It also would have missed almost everything that mattered. A closer look at the database and the server configuration turned up a security setting that looked like it was working but wasn’t, a complete backup of the site’s source code sitting in a publicly reachable folder anyone could download without logging in, and an old, powerful file-management plugin still installed and active, the kind that turns a single compromised admin account into full read-and-write access across the entire server. Security notifications for the site, including alerts about new admin accounts, were also being routed to an outside vendor’s inbox instead of anyone at the company, so even if something went wrong again, the client would be the last to know.
Our Approach
We ran two independent scans: an offline deep scan of a recent backup inside an isolated environment, and a live scan of the production site, comparing every core file and every plugin against official releases byte for byte. Six files flagged by the live scanner turned out to be false positives once checked individually, so we ran that down before ruling anything out.
Then we went looking for history. Four separate details in the database and login logs lined up to point at the same date, months earlier: a second, abandoned WordPress installation left sitting inside the database, a large batch of files all replaced within the same few minutes, two blank files planted somewhere they had no reason to exist, and a login log showing a flood of password-guessing attempts from unrelated networks around the world, with exactly one login that actually succeeded, during that same window. Taken individually, none of it would have proven much. Together, it reconstructed a clear timeline: the site had been compromised, then quietly rebuilt from a backup, without anyone ever identifying how the attacker got in or making sure the same path was closed.
The Outcome
The client walked away with something they’d never had after any previous incident: an evidenced timeline of what had actually happened, and a prioritized, cost-estimated list of fixes instead of vague advice. Some of it was cheap and immediate, correcting the broken security setting, removing the exposed files, tightening the server configuration.
The bigger fix is structural. The site is migrating onto our own hosting, closing the exact gap that let security alerts and account activity go to an outside vendor instead of anyone who could act on them. We’ve also rolled out two-factor authentication and tested it end to end. For the first time, the decision about what to fix and in what order belongs to the client, made with real information instead of another guess.