How I Booted a ClearFake Session Hijacker Out of WordPress

If you manage enough WordPress sites, eventually you get to play digital detective. Earlier this week, I had to drop everything to triage a nasty security incident involving a sophisticated malware campaign known as ClearFake.

The goal of this particular breed of digital garbage is to hijack a user’s clipboard under the guise of an anti-bot check, tricking them into natively executing malware right in their Terminal.

Here’s the technical breakdown of how I dissected the payload, tracked down the entry vector, and ultimately kicked the attackers to the curb.

1. The Symptoms: The World’s Worst reCAPTCHA

The attack first showed up on the frontend as a massive modal overlay that looked exactly like a standard Google reCAPTCHA. But instead of asking users to click on blurry pictures of crosswalks or bicycles, it hit them with this:

Complete these Verification Steps

1. Open Terminal application on your Mac…
2. In the verification window, press Command + V.
3. Press Enter on your keyboard to finish.

This is a textbook clipboard hijacking attack. The site’s injected JavaScript forces a malicious PowerShell or Bash script right into the user’s clipboard. The moment the user follows instructions and pastes it into their Terminal, it executes, usually dropping info-stealer malware directly onto their machine. It’s a clever, entirely social-engineered bypass of standard browser protections.

2. Digging for the Payload

I started by pulling the raw HTML of the infected page (curl -sS https://[REDACTED] > index.html). Interestingly, searching the source code for obvious strings like “Terminal application” or “reCAPTCHA” turned up absolutely nothing. The text was being dynamically generated.

But after combing through the DOM, I spotted a highly suspicious script injected right before our analytics tags:

``

Bingo. The ClearFake payload was packed into a massive base64 encoded blob inside an inline script tag.

3. Hunting the Ghost Plugin

Knowing the exact signature I was looking for (data:text/javascript;base64), I SSH’d into the server and ran a recursive grep across the entire wp-content directory to find where this garbage was living:

`grep -rl “data:text/javascript;base64” ~/files`

That search isolated a single, solitary file: /wp-content/plugins/hseo/hseo.php.

Looking at hseo.php, it was obviously a completely rogue plugin functioning as a backdoor and SEO spam injector. The malware hooked into WordPress’s header to deploy the payload, but it had a brilliantly annoying evasion tactic built in:

function wp_smile_face() { 
  $c=wp_get_current_user()->has_cap('edit_posts')?1:0; 
  if ($c == 0){ 
    // Output base64 ClearFake script 
  } 
} 
add_action("wp_head", "wp_smile_face");

Because it checked has_cap('edit_posts'), the fake reCAPTCHA was completely invisible to logged-in administrators. You could be browsing the site, updating content, and never see a thing while your regular visitors were getting hit with malware.

4. The Root Cause: How’d They Get the Keys?

Finding the backdoor is satisfying, but knowing how the attacker got past authentication is the only way to actually fix the problem.

I dove into the server’s Nginx access.log to trace the attacker’s path. The logs showed a very specific, chilling sequence of events:

`[01/Apr/2026:08:04:42 -0400] “POST /wp-admin/update.php?action=upload-plugin HTTP/2.0” 200` `[01/Apr/2026:08:04:45 -0400] “GET /wp-admin/plugins.php?action=activate&plugin=hseo%2Fhseo.php&_wpnonce=…” 302`

The attacker was actively uploading the hseo.zip file directly through the standard WordPress /wp-admin/update.php endpoint.

But here was the smoking gun: There was no POST request to wp-login.php. Because update.php strictly requires administrative privileges, the attacker must have already possessed a valid administrator session cookie. This essentially confirmed a Session Hijacking / Cookie Theft attack.

An administrator’s local machine had likely been compromised by an info-stealer, which silently ripped their active browser cookies. The attacker then just imported that cookie into their own browser and waltzed right through the front door as an authenticated admin, completely sidestepping our passwords and Two-Factor Authentication.

5. The Fix: Scorched Earth

To lock the site down crazy fast, I ran through the following remediation protocol:

1. Eradicate the Plugin: Forcefully deleted the rogue plugin directory (rm -rf wp-content/plugins/hseo).
2. Salt the Earth: Created a read-only, immutable stub directory (chmod 555) and a dummy hseo.php (chmod 444) to block any automated scripts from blindly dropping the same payload in the same spot later.
3. Flush Caches: Hit the WordPress object cache via WP-CLI to rip the malicious payload out of memory instantly.
4. The Killswitch (Invalidate Sessions): Because the root cause was stolen cookies, simply changing passwords isn’t enough. The stolen cookie would still work. I used WP-CLI to regenerate the security salts (wp config shuffle-salts). This forcefully invalidates every single active session token, instantly locking out the attackers.
5. Local Scans: Mandated that all administrative staff run deep malware scans on their local machines to locate and nuke the info-stealer responsible for the initial cookie theft.

By matching the filesystem artifacts against the server telemetry, we figured out exactly what happened. It wasn’t some obscure zero-day vulnerability in our stack; it was a stolen cookie. Stay vigilant, watch your logs, and don’t forget to shuffle those salts when things look weird.