Hacked website repair: three cases from recent months

In recent months I cleaned up three hacked WordPress sites. One was a webshop, another a company presentation site, and the third belonged to a healthcare provider. I will not name the clients, but I will share the details, because hacked website repair takes far more work than it looks from the outside, and the mistakes repeat.

1. Webshop: the stolen passwords of an external contractor

What happened: malware on the computer of an external marketer working on the webshop stole the passwords saved in the browser. Among them were the webshop admin password and the hosting password. Two days later the attacker logged in.

Over three days the attacker:

• used the built-in WordPress theme editor to write a backdoor into one of the theme files
• used a plugin to give administrator rights to two customer accounts that had not been used for a long time
• replaced the jQuery file that ships with WordPress with 1.2 MB of obfuscated code, which ran for every visitor, at checkout too
• finally put up a fake "Cloudflare verification" page asking visitors to copy and run a command on their own computer

According to the logs, the attacker also viewed the user and order lists, so this had to be handled as a data breach. Under GDPR the company then has 72 hours to decide whether to report it to the authority.

What I fixed: I downloaded WordPress core again and compared it file by file with the official checksums. I gave the jQuery file a new version tag, because the browsers of visitors could have kept loading the infected copy from cache for days. I restored the rights of the two customer accounts, deleted the plugins of the attacker and the account of the contractor, logged everyone out, and replaced the WordPress secret keys (salts). I disabled the built-in file editor. Every admin and shop manager got a new password, and two-factor authentication became mandatory. We also changed the keys of the services connected to the webshop (invoicing, newsletter, email sending).

The lesson: the contractor had cleaned up that same morning, but removed only the theme backdoor and the fake verification page. The replaced jQuery and the two new admins stayed. After a partial cleanup the site looks clean, while the attacker can come back at any time.

2. Company site: malware hidden for years that only showed itself to Google

What happened: visitors saw the company site as normal. Google saw gambling spam on it: 17 MB of pages full of keywords in foreign languages. This is called cloaking. The malware checks who requests the page and serves the search robot something different from what a person sees.

When I started tracing it back, I found that:

• the site existed in two copies on two servers. During an earlier migration the infection was moved to the new hosting together with the site.
• the first traces date from 2023. WordPress was reinstalled back then, but the old folders (nearly a thousand PHP files) stayed next to it.
• from 2024, a new snippet was added every week through a code snippets plugin. These did the redirects and the spam.
• among the plugins there were 14 fake gallery plugins with random names. Each was an exact copy of the official plugin, plus one file that was the backdoor. One of them tried to read the mail log, which means it was collecting email passwords.
• in January 2026 someone logged in nine times with the only admin account, from changing foreign IP addresses. So the password had leaked.

The same username and password also worked on the sister site of the company. There I found 17 infected files in the web root: loaders, a phishing page and malware downloads.

What I fixed: I saved everything off the server before touching anything. I removed the 17 files from the sister site. On the infected site I stopped WordPress and disabled PHP execution in the web root, so no code can run there until the site is rebuilt clean.

The lesson: reinstalling WordPress cleans nothing if the old files stay. The owner never notices cloaking either, because they see the human version. The only way to catch it is to regularly request the page the way a search robot does.

3. Healthcare provider: when cleaning is not possible

What happened: the malware spread at the level of the hosting account and infected four WordPress installations on the same account. Even after two cleanups it wrote itself back within minutes.

What I did: here we chose a clean rebuild on a new server instead of cleaning. I did not carry a single file over from the old server. I reinstalled the theme and plugins from official sources, and filtered the database by hand.

In the database I found 20 spam posts (with adult affiliate links) under the name of an unknown user, created in bulk within a few minutes. The malware scan did not catch these, because they were ordinary posts. Meanwhile the virus scanner of the host found more disguised plugin folders with timestamp names, and a fake wp-config.php.

The lesson: the hosting logs only went back to five days after the infection, so the entry point will never be known exactly. In the experience of the hosting provider, the most common route is an outdated plugin or a pirated ("nulled") premium theme. Some of these have backdoors put in on purpose.

Hacked website repair: what did the three cases have in common?

• In two of the three cases they came in with a password. In one it was stolen from the browser of a contractor. In the other the same password had been used on two sites for years.
• The attackers stayed in for a long time. Days, months, in one case years, because nobody regularly checked what changed on the site.
• A partial cleanup is not enough. Hacked website repair means changing passwords, logging out sessions, replacing the secret keys and removing every foreign file, in the database too. Sometimes rebuilding is the faster route.

Here is what I introduced on the sites I maintain. Every team member gets their own account with only the rights they need, and I delete it when the work ends. Two-factor authentication is mandatory for admins. The built-in file editor is turned off. PHP cannot run in the uploads folder.

If someone else built your site and you do not know who has access to it, the first step of a website takeover is mapping exactly that. If you already see suspicious signs, write to me.