Fake “Verify You Are Human” Page on Your Site? How to Remove a ClickFix Infection

A visitor tells you something strange happened on your website. A box that looked like a Cloudflare security check said “Verify you are human”. When they checked it, it asked them to press the Windows key and R together, press Ctrl+V and then Enter. On a Mac it asked them to open Terminal and paste something. Or a page claimed their browser needed a fix and offered a button to copy the fix. You open the site yourself and see nothing unusual.

Your site has almost certainly been hacked to show a ClickFix lure. The “verification” is fake. Pressing those keys pastes a command the page silently copied to the visitor’s clipboard, and running it downloads malware, typically software that steals saved passwords, browser sessions and cryptocurrency wallets. A real Cloudflare challenge, and any real CAPTCHA, never asks anyone to run a command on their computer.

This is urgent for two reasons: your visitors are being infected through your site, and once browsers and security vendors spot it, your site can be flagged as dangerous or your host can suspend it. This guide is for site owners and the developers who clean up after them. It covers how to see the lure when it hides from you, where the injected code usually lives, how to clean up and close the hole, and what to tell visitors.

What is happening

ClickFix is a social engineering technique, not a single piece of malware. Microsoft, the New Zealand National Cyber Security Center (NCSC), the Swiss National Cyber Security Center, Rapid7 Labs and Sekoia have all published research on campaigns that plant ClickFix lures on legitimate, compromised WordPress sites. The pattern they describe:

• The attacker gets in through an outdated plugin or theme, a stolen administrator password or another vulnerability.
• They inject a small piece of JavaScript into the site: into the database (an option, a widget, a code snippet), into a theme or plugin file, or as a fake plugin. That script loads the real lure from a server the attacker controls, so the lure can be changed without touching your site again.
• The lure is shown selectively. The NZ NCSC notes that some variants target only Windows or macOS browsers and show clean content to automated scanners. Many also skip logged-in administrators and visitors who have already seen it, using a cookie or browser storage. That is why you see nothing.
• The page copies a command to the clipboard and tells the visitor how to run it. The command fetches and runs the malware on their computer.

Some related campaigns fetch their next stage from unusual places, including public blockchain records, so the visible lure changes even though nothing on your server does. The fix is the same: remove the injected loader and close the way in. The NZ NCSC stresses that removing the visible prompt is not enough; you must also fix the original entry point and remove anything the attacker left to get back in.

Step 1: Make the lure show itself

You need to see the site the way a first-time visitor sees it. Following the NZ NCSC’s suggestions, try several of these:

• A private or incognito window in a browser where you have never logged in to the site.
• A different internet connection, such as a phone on mobile data.
• Both a Windows computer and a phone or Mac, since lures may target one system.
• Several pages, not only the home page, and a short wait after each page loads, because some overlays appear after a delay.

When the lure appears, do not follow its instructions. Take a screenshot, then open DevTools (F12) on the Network tab and reload to see which external domains load scripts. The DevTools cheat sheet explains the panels.

Check from the command line

On your own computer (Terminal on macOS or Linux, or PowerShell on Windows, where you type curl.exe instead of curl), fetch the page as a Windows browser would and list the scripts it loads:

curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36" https://example.com/ | grep -oiE '<script[^>]*src="[^"]*"' | sort -u

Placeholder: replace https://example.com/ with your page. What each part does: -s hides progress output, -A sends a Windows Chrome user agent so the server treats the request like a normal visitor, grep -oiE pulls out every script tag that loads a file (case-insensitive) and sort -u removes duplicates. Good output: scripts from your own domain and services you recognize. Bad output: a script from a domain you have never heard of, especially an odd-looking or newly registered one. Then look for tell-tale words in the raw page:

curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36" https://example.com/ | grep -ioE 'clipboard|powershell|mshta|verify you are human|ic-tracker-js|atob\(' | sort | uniq -c

What it does: counts how often each suspicious word appears in the page. clipboard, powershell and mshta are almost never needed on a normal page. ic-tracker-js is a marker Sekoia reported in one large ClickFix framework. atob( decodes hidden text and is common in obfuscated scripts, though some legitimate scripts use it too. Good output: nothing. Bad output: any hit that is not explained by a plugin you know. A blank result does not clear the site, because the loader may be in an external script or only shown to some visitors.

If you see the lure and nothing else is clear, treat the site as compromised and work through the first hour hack guide alongside the steps below. If you are not comfortable doing this yourself, the NZ NCSC’s advice is to take the site offline, reset your WordPress credentials and get help from an IT provider.

Step 2: Contain it and keep evidence

1. Stop serving the lure. Put the site into maintenance mode, or ask your host to block public access, while you clean. Visitors seeing a holding page is better than visitors being infected.
2. Copy everything first. Download the files and a database export as they are, label them infected and keep them off the server. Save access logs before they rotate.
3. Change the passwords that matter most from a computer you trust: WordPress administrators, hosting control panel, SFTP and SSH, database. Turn on two-factor authentication where it is available.

Step 3: Find the injected code in the database

Connect over SSH and cd into the site folder, the one that contains wp-config.php. Use wp, or wp-cli on hosts that name it that way. These commands only read. Check the table prefix first with wp db prefix and replace wp_ below if yours differs.

wp db search 'clipboard' --all-tables-with-prefix --stats
wp db search 'powershell|mshta|ic-tracker-js' --all-tables-with-prefix --regex --stats
wp db search '<script' wp_options --stats

What each does: the first two look through every table with your prefix (--all-tables-with-prefix) for words linked to ClickFix lures; --regex lets | mean “or”; --stats prints how many matches were found in each table and column. The third lists script tags stored in the options table, where many injections sit. Good output: zero matches for the first two, and only scripts you recognize in options. Bad output: any match in an option, widget, post or snippet you did not create. Remove the --stats flag to print the matching text so you can see exactly where it is.

Then look at the places that run custom code on every page:

• Snippet and header script plugins. Code Snippets keeps snippets in its own table (wp db query "SELECT id, name, active, modified FROM wp_snippets ORDER BY modified DESC LIMIT 20;"), WPCode stores them as a hidden post type (wp post list --post_type=wpcode --post_status=any --fields=ID,post_title,post_status,post_modified), and other plugins keep header and footer code in their settings. If a command says the table or post type does not exist, that plugin is not installed.
• Widgets. wp option get widget_block --format=json prints every block widget, and the Custom HTML widget can carry scripts too.
• Theme and builder custom code boxes. Check your theme’s header and footer script settings and your page builder’s custom code or site settings area in the admin.
• Recently changed content. wp post list --post_type=any --post_status=any --orderby=modified --order=DESC --posts_per_page=20 --fields=ID,post_type,post_title,post_modified lists the 20 most recently modified items of any type, including hidden ones.

Step 4: Check the files and the users

wp core verify-checksums
wp plugin verify-checksums --all
wp plugin list --fields=name,title,status,version
wp plugin list --status=must-use
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

What each does: the checksum commands compare core files and WordPress.org plugins with the official copies and list anything changed or added (premium plugins cannot be verified this way, which is normal). The plugin lists show every plugin, including must-use plugins that load automatically and do not appear on the Plugins screen. The last line lists administrators with their creation dates. Bad output: modified core files, plugins you did not install (watch for names that imitate WordPress or a well-known plugin), unknown must-use plugins, or an administrator you do not recognize.

find . -type f -name '*.php' -mtime -30 -not -path './wp-content/cache/*' | head -n 100
find wp-content/uploads -type f -name '*.php'
grep -rl "wp_head\|wp_footer" wp-content/mu-plugins 2>/dev/null

What each does: the first lists PHP files changed in the last 30 days, skipping the cache (widen -mtime -30 if needed; attackers can fake dates). The second finds PHP files inside uploads, where there should be none. The third lists must-use plugins that hook into the page header or footer, a common way to inject scripts on every page; 2>/dev/null hides the error if the folder does not exist. Also open your active theme’s header.php, footer.php and functions.php and look for script tags or encoded strings you did not add. The scanner false positive guide helps you judge a suspicious file, and the Linux and SSH cheat sheet explains find and grep.

Check the hosting account too: unknown FTP or SSH users, cron jobs you did not create, and application passwords in each administrator’s profile in WordPress.

Step 5: Clean up and close the hole

1. Restore or rebuild. Restoring a backup taken before the infection is the fastest route if you know when it started; the restore guide explains how to keep new orders or form entries. Otherwise reinstall WordPress core, every plugin and every theme from official sources, and delete anything you cannot trace to a source.
2. Remove the injected entries you found in options, widgets, snippets and posts, after taking a fresh backup. Record what you removed.
3. Delete rogue users, plugins and access: unknown administrators, application passwords, FTP and SSH accounts, cron jobs.
4. Rotate every secret: all administrator passwords, hosting and database passwords, and the salts in wp-config.php, which logs everyone out.
5. Patch the entry point. Update WordPress, every plugin and theme, and remove anything abandoned or nulled. The Swiss NCSC linked many ClickFix compromises to known WordPress vulnerabilities on sites that had not installed available patches. Use the reinfection guide to find backdoors and the plugin vulnerability guide to check what you run.
6. Purge every cache: the cache plugin, the server cache and any CDN. Cached pages can keep serving the lure after the site is clean.
7. Harden. Set DISALLOW_FILE_EDIT to true in wp-config.php (also an NZ NCSC recommendation), require two-factor authentication for administrators, and consider a Content Security Policy that only allows scripts from domains you use. The security headers cheat sheet shows how.

Step 6: Confirm it is gone and clear any warnings

• Repeat the checks in Step 1 from several devices and networks over a few days. Selective lures can take a while to reappear if anything was missed.
• Open Google Search Console and check Security issues. If the site was flagged, request a review once it is clean. Browser warnings and blocklists are covered in the Deceptive site ahead guide.
• If your host suspended the account, the suspension guide explains how to get reinstated.
• Run the WordPress check and the headers check to confirm what the site now sends.

Step 7: Help visitors who may have run the command

You usually cannot tell from your logs who saw the lure, let alone who ran the command. If you have reports, or the site was serving the lure for some time, consider a short notice on the site or to your mailing list once it is clean. Keep it factual and helpful:

• Between which dates the site may have shown a fake verification prompt.
• That anyone who pressed Windows key + R or pasted a command into Terminal should disconnect that computer from the internet and have it checked by an IT professional or a reputable security tool.
• That they should change important passwords from a different, trusted device, starting with email, banking and any password manager, and sign out of other sessions.
• That they should turn on two-factor authentication, and move any cryptocurrency from wallets used on that computer.

Whether you have a legal duty to notify anyone depends on what happened and where you and your visitors are. If your own systems or customer data were also accessed, breach notification rules may apply. This is not legal advice; the rules vary by country, so check with a lawyer licensed where you operate. Organizations in New Zealand can report incidents to the NCSC; elsewhere, your national cyber security center or cybercrime reporting service is the place to start.

If you cannot find it

If visitors keep reporting the fake check after you have cleaned, the loader is still somewhere, or the attacker still has a way in. Ask your host for a malware scan and access logs, and send them:

• Screenshots of the lure, with dates, times, the page, the device and the network it appeared on.
• Any external script domains you found in the Network tab or with curl.
• The results of the checksum, database and file checks above.
• A request for a list of files changed and new FTP or SSH logins in the period.

A professional incident responder can help when the infection keeps returning. For other symptoms of a hacked site, start at the I was hacked emergency page; if visitors are seeing warnings of any kind, see the visitors see a warning page.

See also

• WordPress site hacked: the first hour
• Site redirecting visitors to spam
• Admin account compromised
• Card skimmer on a WooCommerce checkout
• Taking over an inherited WordPress site