From Ethereum to DNS C2: Reverse Engineering the ClickFix Payload
In Part 1 we followed a large ClickFix campaign from compromised WordPress websites through an Ethereum-backed JavaScript loader, PowerShell and a Cloudflare R2 bucket.
The final payload was presented as:
IntelSoftwareUpdaterV8.exe
Its SHA-256 was:
d4ec082b2b2112796bc5dc94835cad9536762da738ba3a2af638efa6d2f76b49
The executable turned out to be quite interesting. It was not simply a conventional Windows binary containing the malware. Instead, it was an Inno Setup package carrying its own Python 3.11 runtime.
A Python RAT inside an installer
After extracting the installer, we found an embedded Python environment:
python311.dll
python311.zip
libcrypto-3.dll
libssl-3.dll
python.exe
pythonw.exe
...
run.pyw
The directory chosen by the attacker was clearly deliberately Microsoft-looking:
%LOCALAPPDATA%\Microsoft\WindowsApps\
Microsoft.PythonApp_code$GetMachineHash\
The interesting file in all of this was run.pyw. It was itself another wrapper. The script contained a 16-byte RC4 key and an encrypted blob. After decrypting that blob offline, we recovered approximately 64 KB of readable Python implementing a remote-access trojan.
The recovered RAT identifies itself internally as version 1.3 and supports arbitrary execution through three task types:
cmd
powershell
python
This means the attacker can execute shell commands, PowerShell or arbitrary Python on the infected endpoint and receive the resulting output.
Persistence and victim profiling
The malware creates a hidden scheduled task named IntelSoftwareUpdater which launches pythonw.exe run.pyw every ten minutes. The RAT gathers host information including:
MachineGuid
system volume serial
user SID
hostname
username
Windows version/build
architecture
antivirus product
domain/workgroup information
It combines several of those values to generate a deterministic victim identifier. This is where Ethereum reappears.
A second EtherHiding layer
The RAT contains another Ethereum configuration, completely separate from the Sepolia contract used in the compromised website (see part 1).
The malware queries Ethereum mainnet contract:
0x5d04ed162c548fc4508cbb59266b02afbaf3ebc1
using function selector:
0x1dcf296b
It includes a list of public Ethereum JSON-RPC providers and cycles through them until one answers. The value returned by the contract is encrypted using ChaCha20. From the malware we recovered the key material and the logic required to decrypt it. The resulting value was:
DNS 91.92.240.100:53
Essentially, the blockchain was acting as a resilient pointer to the RAT's real command-and-control infrastructure. That result was reproducible even with a synthetic victim identifier, because the contract supports a global fallback value.
Reconstructing the contract
The contract bytecode gave us a little more insight into the attacker's design. Its important functions correspond broadly to:
1dcf296b(bytes16)
Return victim-specific configuration if one exists, otherwise return the global configuration.
71c28139(bytes16)
Return victim-specific configuration only.
c474520d(bytes)
Set the global configuration.
502d6db7(bytes16, bytes)
Set configuration for a specific victim.
The setters are owner-restricted. This gives the operator two levels of command-and-control configuration.
Most infected machines can use one global C2 address, while selected victims can silently be redirected to entirely different infrastructure. That is a useful feature for an operator who wants to segregate high-value victims, testing environments or different backend systems without rebuilding the malware (we thought this was pretty neat!)
DNS that isn't really DNS
After resolving its C2 through Ethereum, this build uses DNS as its transport.
Importantly, the RAT does not send these queries through the system's configured recursive DNS resolver. Instead it constructs DNS packets itself and sends them directly via UDP/53 to the C2 (currently 91.92.240.100). The names inside those packets end in microsoft.com. So on superficial inspection the traffic can look like ordinary Microsoft-related DNS activity. But the destination IP of the DNS server is attacker controlled.
That creates a useful behavioural detection:
Endpoints sending UDP/53 directly to arbitrary Internet hosts, particularly with queried names ending in microsoft.com, rather than using the organisation's approved DNS resolvers.
What goes over the DNS channel?
Initial registration includes information about the victim such as:
domain
antivirus
operating system
hostname
malware version
campaign tag
The RAT then polls for tasks. Commands are delivered using DNS TXT responses and can request:
cmd
powershell
python
Large tasks are split into multiple DNS chunks. Results are sent back over the same DNS channel, with stdout and stderr encoded into DNS query names and transmitted in chunks to the C2 server.
stdout and stderr are Base64-encoded, transformed into a DNS-safe representation and divided into query-name-sized chunks.
The protocol distinguishes output using prefixes such as:
o- stdout
e- stderr
r- result/status
The attacker therefore gets a functional interactive tasking channel using nothing more than packets that parse as DNS.
This is not "DNS tunnelling through microsoft.com". No Microsoft DNS infrastructure is touched in any of this. The malware is speaking its own DNS-shaped protocol directly to an attacker-controlled server and merely using microsoft.com inside the question name as camouflage.
Related activity
This activity appears closely related to work published by other researchers. Google Threat Intelligence Group has documented UNC5142 using compromised WordPress sites, ClickFix and EtherHiding as part of its CLEARSHORT malware-distribution ecosystem, while noting that the final payloads may be operated by separate actors.
More recently, SOCRadar documented DOUBLECUP, a ClickFix Loader-as-a-Service delivering a previously undocumented RAT they named DeviceManager. Their description of DeviceManager is very close to the payload we recovered, including persistence, host profiling, EtherHiding-based C2 resolution and DNS or HTTP command and control.
ThreatFox also lists 91.92.240[.]100:53, the C2 address we independently recovered from the Ethereum contract, with the tags ClickFix, DeviceManagerAgent, DNS-C2, etherhiding and PythonC2. These reports provide useful independent corroboration for the malware and infrastructure we observed, although we do not currently have enough evidence to attribute the DeviceManager backend itself directly to UNC5142.
Whilst the karburatorotzhigi[.]com domain used during the initial delivery (see Part 1) had only been registered a matter of days before our analysis, the wider infrastructure appears to pre-date it. The Ethereum contracts and associated wallets were provisioned weeks earlier, suggesting that the delivery domain was only one component of a broader, longer-running operation.
Following the blockchain backwards
Once we knew the current C2, we wanted to determine who had published it.
The use of Ethereum makes investigating that possible - changing contract state requires a signed transaction which remains permanently visible on-chain. The transaction setting the C2 occurred at:
2026-06-24 13:18:35 UTC
from:
0x820f3b366bb5cb03ad25f7190c16acf152bdbb82
to the malware's contract.
The call used:
c474520d(bytes)
and supplied ciphertext:
a0145a80e7bf9a6abec040caea37
which we independently decrypted to:
91.92.240.100:53
We also went back through the contract history to look for earlier C2 values rather than assuming the address we recovered was the only one ever used. By tracing the transactions that modified the contract’s configuration, we could identify when new encrypted values were published and test them using the same decryption logic recovered from the malware. In this case, we did not recover any additional C2 addresses from the contract history, but the process gave us a way to check for historical command-and-control infrastructure rather than relying only on the current contract state.
The wallet had deployed the contract only 84 seconds earlier. Even more interestingly, it had itself been funded shortly before deployment by:
0x62da4cc20f1ef83e853a17439e00738dbf1d8e14
That wallet became our next pivot.
Finding sibling infrastructure
Following meaningful outbound payments from the funding wallet revealed another freshly funded address:
0xb9170160532c700f8d948aa9835ff060e58bde56
Within minutes that wallet deployed four contracts containing the exact same function-selector fingerprint as the contract used by our malware:
1dcf296b
c474520d
502d6db7
71c28139
The four sibling contracts were:
0x031c490c01d913852e9c2dce2b5393d449841da2
0x58bd4e239a3f8330a58c891765ba0018b1d4de7d
0xf2e857eee82cbef7d37a30e869a1db99694b9a99
0x5dbadd2e1be28f6142ebff9778c82603e81bae68
All four were deployed within roughly 4.5 minutes. The wallet was initially funded by the same upstream wallet before its first deployment and was topped up during the provisioning sequence. Only the fourth was subsequently configured.
Its encrypted global value differs from the one used by our sample and cannot be decrypted with the key material recovered from IntelSoftwareUpdaterV8.exe.
That suggests we are looking at a sibling deployment for a different build or campaign rather than four copies of precisely the same configuration.
The wallet-clustering exercise identified five contracts sharing the complete EtherHiding contract fingerprint across these two directly related deployer wallets.
Why the blockchain is both useful and dangerous for attackers
There are obvious benefit to EtherHiding: Ethereum is globally available, replicated across thousands of nodes and accessible through numerous public RPC providers. So there is no single traditional hosting account that defenders can suspend to remove the information from the chain.
But there is a trade-off: Blockchain state changes are public and permanent. The attacker gained resilient configuration storage, but in doing so left us an immutable trail connecting:
malware
|
Ethereum contract
|
C2-setting transaction
|
contract deployer
|
funding wallet
|
sibling deployment wallet
|
additional matching contracts
That is more information than we would normally get from a hardcoded C2 domain.
IOCs
Web delivery
karburatorotzhigi[.]com
*.karburatorotzhigi[.]com
pub-b7e3d7ad9f6e4b08a24cde45feeb417e.r2[.]dev
IntelSoftwareUpdaterV8.exe
SHA256:
d4ec082b2b2112796bc5dc94835cad9536762da738ba3a2af638efa6d2f76b49
The PowerShell chain and R2 location were directly recovered from the compromised-site delivery infrastructure.
Browser EtherHiding
Sepolia contract:
0x0321C73150543FAa9D016c9c46Abf293Eb6839e4
Function selector:
3bc5de30
Malware EtherHiding
Ethereum mainnet contract:
0x5d04ed162c548fc4508cbb59266b02afbaf3ebc1
C2:
91.92.240[.]100:53/UDP
Wallets
Known contract deployer:
0x820f3b366bb5cb03ad25f7190c16acf152bdbb82
Infrastructure funding wallet:
0x62da4cc20f1ef83e853a17439e00738dbf1d8e14
Sibling deployment wallet:
0xb9170160532c700f8d948aa9835ff060e58bde56
Host artefacts
Scheduled task:
IntelSoftwareUpdater
Directory:
%LOCALAPPDATA%\Microsoft\WindowsApps\
Microsoft.PythonApp_code$GetMachineHash\
Closing thoughts
EtherHiding is often discussed in the context of making malicious web infrastructure harder to take down, but in this campaign it was being used for more than that.
Ethereum was used to retrieve and update browser-side code on compromised websites, and then used again by the malware to locate its command-and-control infrastructure. That gave the operator a way to change parts of the attack without having to constantly redeploy the underlying infrastructure.
There is a trade-off though. Putting configuration on-chain also leaves a permanent record. In this case that allowed us to trace when contracts were deployed, when C2 information was written, which wallets were involved and how some of that infrastructure was funded.
So while EtherHiding can make parts of an operation more resilient, it can also leave behind a useful historical record for defenders and researchers.Start writing here...