The fake CAPTCHA attacks hitting WordPress sites, and how to stop them

The most damaging attack I have cleaned up this year does not deface a website or steal its database. It turns the site into a trap for its own visitors. A fake CAPTCHA appears, says "verify you are human", and tells the visitor to press a key combination and paste a command. That command installs malware on their computer. Security researchers call this pattern ClickFix.

I have removed versions of it from law-firm, finance and small-business WordPress sites on four different hosts. Here is how it works and how to stop it.

How the attack works

1. Access. Attackers get in through a stolen admin password, a vulnerable plugin or a weak hosting account.
2. Persistence. They plant several ways back in: a hidden admin user, a backdoor file in uploads, a fake plugin with a believable name, or a drop-in such as wp-content/db.php that loads before WordPress itself.
3. Injection. A small loader script is added to pages, often stored in the database rather than in a file.
4. The trap. The loader fetches the fake CAPTCHA and the command it asks visitors to run.

Why it is hard to find

Older malware lived in files, so a file scanner could find it. These campaigns spread out:

• Database options and post meta hold the payload, sometimes with innocent-looking names.
• Must-use plugins load automatically and do not appear in the normal plugin list.
• Blockchain hosting. Some loaders fetch their next stage from a smart contract on a public blockchain. There is no server to take down, and the attacker can change the payload whenever they like. This technique is known as EtherHiding.
• Visitor targeting. The trap may only show to first-time visitors or to Windows users, so the owner logged in on a Mac never sees it.

How to check your site

• Open the site in a private window on a different device, and look for any "verify you are human" prompt you did not add.
• List every administrator account and remove the ones nobody recognises.
• Look in wp-content/mu-plugins and for a db.php or object-cache.php you did not install.
• Compare WordPress core files with the official release; any difference is suspicious.
• Search the database options table for long encoded strings and unfamiliar script URLs.

Cleaning up properly

Removing the visible script is not a clean-up. If the backdoor stays, the site is reinfected within days. I have seen it happen. A real clean-up:

1. Takes a full backup first, then works from a copy.
2. Removes every persistence point: users, files, drop-ins, mu-plugins and database payloads.
3. Replaces core files with clean copies and reinstalls plugins from official sources.
4. Resets every password: WordPress admins, hosting, FTP, database and email.
5. Deletes any public backup or database dump left in the web root.

Hardening that actually helps

• Two-factor authentication for every admin account.
• Disable file editing in the dashboard and lock permissions on custom code.
• Remove abandoned plugins. Most infections I see start with one nobody remembered was installed.
• Block username enumeration and limit login attempts.
• Monitor: a scheduled check that alerts on new admin users, changed core files and new scripts in the page source.

I packaged these checks into a WordPress plugin, Inovista Shield, after the same malware families kept coming back across client sites. Whatever tool you use, the principle is the same: assume the attacker left more than one door open, and close them all.