A recent website security audit uncovered a highly deceptive WordPress infection involving a fake Google reCAPTCHA overlay that hijacked user clipboards and attempted to deliver malware.
At first, the website owner thought it was a legitimate spam-prevention feature. However, when visitors reported that “verification” kept failing, it quickly became clear that something more serious was happening.
This attack was not another infected plugin or theme file. The payload lived inside the WordPress database, disguised as a harmless script and completely invisible to most internal malware scanners.
Incident snapshot
Visitors to the site encountered a full-screen fake reCAPTCHA that visually mimicked Google’s official UI and blocked normal browsing. The overlay used the familiar logo, checkbox, and layout, which made it appear authentic at a glance.
When users clicked the verification checkbox, the page copied a malicious command into the clipboard and displayed step-by-step instructions to run it in Windows. That instruction sequence explicitly guided users to open the Run dialog, paste the clipboard contents, and execute the command. The clipboard payload would launch a headless browser command that fetched and executed a remote HTA file.
How we detected it
1. Fake reCAPTCHA identified
Inspecting the HTML confirmed our suspicion. The reCAPTCHA was not coming from Google’s official domains but was built entirely with custom code that replicated the interface. The familiar layout and logo were copied, but the underlying source was fake.
2. Manual review uncovered encoded script
Internal plugin-based scanners were run to locate the source of infection, but they failed to detect any malicious files or suspicious changes within the theme or plugin directories. During manual front-end inspection, we noticed an inline script element that looked out of place. It contained a very long Base64-encoded string loaded through a data: URI. Decoding it revealed an obfuscated JavaScript payload. The script contained several helper functions, including _0x2d17 and _0x5229, and one main function that connected to an external endpoint at:
3. Analyzing blockchain-based payload delivery
The decoded function made repeated JSON-RPC eth_call requests to the Binance Smart Chain Testnet. Browser network logs showed a sequence of POST requests to this endpoint. Each response contained a small JSON object with hexadecimal data in the result field. When converted from HEX to Base64 and decoded, the data produced another JavaScript stage that was executed dynamically using .
This pattern confirmed that the attacker used the blockchain as a command-and-control channel to host and deliver malicious JavaScript in small, hard-to-detect stages.
4. Clipboard hijack verified
We ran the fake reCAPTCHA in a sandboxed environment to safely observe its full behavior. When clicking the verification checkbox, the script silently replaced the system clipboard with a predefined command. On the page, the attacker displayed “verification” steps that instructed users to open the Windows Run dialog, paste the copied command, and press Enter.
Captured clipboard contents revealed the exact payload:
If executed, this command would launch Microsoft Edge in headless mode, open cmd.exe, and download an HTA file from the remote domain a.o-y3ii.ru. That file could then install additional malware such as information stealers or remote access tools.
5. Source of injection located in the database
Since no infected PHP or plugin files were found, we turned to the WordPress database. A focused SQL query exposed the injected code inside the wp_options table in a custom header script field:
Finding the script inside the database explained why internal scanners missed it. Logs also revealed brute-force login attempts prior to the incident, which likely gave attackers access to the WordPress admin area where they injected the malicious script.
7. Immediate containment and documentation
Once the malicious payload and injection point were confirmed, we immediately reset all admin credentials, invalidated sessions, and isolated the site for further cleanup. Network captures, decoded scripts, and clipboard payloads were preserved for forensic analysis and indicator documentation.
How the Infection Entered
Initial Foothold
The breach began with a critical vulnerability in one of our installed plugins, which exposed an authenticated-to-administrator privilege escalation pathway. The attacker exploited this flaw to gain complete administrative access. Our log analysis indicates the first successful admin session occurred within minutes of an external IP scanning the vulnerable plugin, a timeline consistent with a typical exploit-and-login attack pattern.
Weaponization of a Legitimate Plugin
Once the attacker secured administrator privileges, they installed “Insert Headers and Footers” (WPCode), a legitimate plugin that provides a graphical interface for site-wide script injection without requiring direct modifications to theme files. This approach was strategically chosen to circumvent file-integrity monitoring systems and ensure persistence even through theme or core WordPress updates.
Database-Resident Payload
The attacker then added a new header snippet containing Base64-encoded JavaScript loader code. The plugin stored this snippet in the database options table, and the theme header rendered it as a data: URI on every page load. Because no PHP files were modified during this process, traditional file-based security scanners continued to report the site as clean, while the malicious loader executed silently on the front end.
Why Internal Scanners Missed It
Popular malware scanners such as Wordfence did not detect the infection because:
- No infected PHP files existed
- The malicious script was stored inside the database as encoded text
- The payload fetched executable code from a blockchain network dynamically
Internal scanners typically focus on server files, not on encoded JavaScript stored in database records.
This is where remote security scanners, such as the SecureWP Scanner, can make a difference.
Remote scanners analyze a website from the outside in, detecting malicious overlays, obfuscated scripts, and behavioral anomalies that file-based scanners might overlook.
Takeaways for WordPress security and malware defense
- WordPress malware has shifted from PHP backdoors to database‑resident, front‑end JavaScript that executes only in the browser.
- ClickFix‑style social engineering has matured; blockchain C2 and headless browser chains reduce takedowns and telemetry.
- Relying on a single, plugin‑based scanner is no longer sufficient; pair internal scanning with an external, remote scanner that renders pages, inspects the DOM, and records client‑side network calls.
- Content Security Policy is now table stakes; a well‑scoped CSP breaks inline/data loaders without harming legitimate scripts when properly whitelisted.
