Fake CAPTCHA Malware on WordPress Websites Explained
A fake CAPTCHA overlay is often a symptom of a deeper WordPress compromise, not a harmless glitch.
This guide shows how to recognise the pattern, what to do immediately if it appears, and which practical hardening controls reduce the chance of reinfection, including access controls, file integrity monitoring, and hosting level security checks.
Guide overview
Purpose:
To explain how fake CAPTCHA malware works and provide practical steps to reduce the risk of it appearing on a WordPress website.
Structure:
Part 1 provides immediate actions if you encounter it.
Part 2 explains how it works and how layered protection reduces risk.
Outcome:
By the end of this guide, you should understand the mechanism behind fake CAPTCHA malware and the practical controls that reduce the likelihood of compromise.
Part 1. Quick actions if you see this on a website
If you see a page that:
• Displays a message asking you to “verify you are human”
• Instructs you to press Windows + R
• Tells you to paste something into PowerShell
• Asks you to click Allow to continue
Do not follow the instructions on the page.
If it is your own website:
Do not interact with the fake prompt.
Take the website temporarily offline if possible.
Contact your hosting provider.
Restore the site from a known clean backup.
Change all WordPress administrator passwords.
Review installed plugins and remove anything unfamiliar.
Scan the site using a security plugin such as Wordfence.
Do not assume it is harmless. A fake CAPTCHA overlay is usually a symptom of a deeper compromise.
Part 2. Plain English explanation
A real CAPTCHA system is used to distinguish humans from automated bots.
Fake CAPTCHA malware imitates that idea. It places a convincing overlay on a compromised website and instructs the visitor to run a command on their own device. Often, the instructions involve copying and pasting a PowerShell command.
If the visitor follows those steps, they may unknowingly install malware on their own computer. This could lead to:
• Credential theft
• Remote access installation
• Browser session hijacking
• Further lateral compromise
The attack is designed to bypass traditional website security controls by persuading the user to execute the malicious code themselves
How fake CAPTCHA malware ends up on a WordPress website
Fake CAPTCHA overlays do not appear randomly. They are usually the result of one or more weaknesses.
Common causes include:
• Outdated WordPress core, themes, or plugins
• Vulnerable or poorly coded plugins
• Compromised administrator credentials
• Weak passwords
• No multi factor authentication
• No Web Application Firewall
• Insecure file permissions
• Inadequate hosting level security
• Incorrect file permissions such as 0777 on plugin directories, allowing unauthorized file uploads.
In most managed hosting environments, default directory permissions are 0755 and files are 0644. WordPress does not normally create plugin directories with 0777 permissions.
If 0777 is observed, it is usually the result of a manual change, an insecure script, a migration error, or post-compromise alteration. Publicly writable directories significantly increase risk and should be corrected immediately.
Once an attacker gains access, they may inject malicious JavaScript into:
• Theme files
• Plugin files
• The database
• The header or footer of pages
This injected code then displays the fake verification overlay to visitors.
How to reduce the risk on WordPress
No single control prevents every compromise. Risk is reduced through layered protection.
Practical measures include:
• Keep WordPress core, plugins, and themes updated.
• Enable automatic updates where appropriate.
• Remove unused plugins and themes.
• Use a properly configured security plugin such as Wordfence.
• Enable file change monitoring.
• Enforce strong administrator passwords.
• Enable multi factor authentication for all administrator accounts.
• Disable file editing from the WordPress dashboard.
• Use a Web Application Firewall such as Cloudflare.
• Maintain regular off site backups.
Maintain regular off-site backups stored independently from the hosting account. Backups stored only within the same compromised environment may be altered or deleted during an attack.
Ensure all related service accounts, including hosting control panel, FTP or SFTP, and email accounts, use strong, unique passwords and multi factor authentication where available.
Security should not depend on one plugin alone. It should combine update discipline, identity controls, firewall protection, and monitoring.
Layered protection. No single feature is enough
A WordPress security plugin alone does not guarantee protection.
Cloudflare alone does not guarantee protection.
Strong passwords alone do not guarantee protection.
Security works when multiple controls operate together:
• Firewall filtering
• Identity protection
• Reliable backup and recovery
• Monitoring and alerting
• Application hardening
The objective is risk reduction and early detection, not absolute immunity.
When to contact IT support or your hosting provider
Professional investigation may be appropriate if:
• You are unsure whether malicious code has been fully removed.
• The infection returns after cleanup.
• Administrative accounts appear to have been altered.
• File integrity monitoring shows repeated changes.
• You do not have a clean backup available.
• You do not know how the initial compromise occurred.
If your website is hosted with a managed hosting provider, contact them immediately. Many hosting companies can:
• Review server level logs
• Check for additional malicious files
• Scan the hosting account
• Help restore a clean snapshot
• Identify unusual access activity
In addition, all associated accounts should be reviewed and secured:
• WordPress administrator accounts
• FTP or SFTP accounts
• Hosting control panel accounts
• Database users
• Email accounts linked to the domain
All passwords should be changed to strong, unique passwords.
Multi factor authentication should be enabled wherever supported.
If possible, consider changing usernames for administrator level accounts.
A website compromise should be treated as a security incident, not just a technical fault. It is important to understand how the compromise occurred so that similar weaknesses are not repeated.
If you are uncertain about containment or root cause, it may be appropriate to seek assistance from an experienced web developer or website security specialist. While professional investigation can involve cost, it can also provide clarity, strengthen long term security, and prevent recurring incidents.
If you are currently experiencing this issue, early assistance is often better than delayed action.
Further Guidance and Support
This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.
For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.
