Slaiclind: analyzing a campaign combining ClickFix and EtherHiding

Context

Since its discovery by researchers in March 2024, the ClickFix technique has spread rapidly in cyberattack campaigns. Its goal is to trick users into running malicious commands on their own systems, making them unwitting participants in their own compromise. Attackers achieve this through fake websites that are visually indistinguishable from legitimate ones, or by exploiting web vulnerabilities to alter existing pages. For more details, we recommend our dedicated article on the subject.

A second technique, EtherHiding - first observed in 2023 - involves attackers exploiting the decentralized architecture of blockchains and, specifically, Smart Contracts, to store data immutably (except for the private key holder). This data is subsequently retrieved and used during an attack. For more details, we also recommend our dedicated analysis of this technique.

Following our research into the EtherHiding technique, we began monitoring active campaigns exploiting it. Some have been ongoing for several months and are already widely spread and documented. Using the Validin tool and our detection filters, we identified over 70,000 compromised websites in just a few days. However, since the end of September, a new campaign has emerged and begun to spread, prompting us to conduct a detailed analysis.

Initial Detection

To detect websites compromised by EtherHiding-type campaigns, a practical starting point is to examine the page's source code for functions that retrieve Smart Contract data, such as eth_call function or libraries like ethers.js. However, their use may also be entirely legitimate.

To isolate what is of interest, we observe that these methods are typically found on webpages associated with the blockchain or cryptocurrency ecosystems. If the website's subject matter is unrelated to those domains, it is highly probable that the site is compromised. This was the case in 95% of the sites we examined.

As a reminder, the EtherHiding technique replaces certain traditional C2 functionality with a Smart Contract, particularly the retrieval of data stored by the attackers. Therefore, when assessing a compromised website's code, rather than looking for an IP address or domain, analysts must identify a Smart Contract address and its associated blockchain.

Since the end of September, we have detected a recurring script embedded in a growing number of websites. This article examines that script in detail.

Code Retrieval Through EtherHiding

Connection to the Smart Contract

To analyze the retrieved script, we split it into two parts. The first is as follows:

The structure of this script is interesting and can be summarized as follows:

• [1] The script first verifies that the page is part of a WordPress installation and that the admin bar is not rendered. This is done to reduce the likelihood of detection by the site administrator.
• [2] These are the connection parameters for the campaign's blockchain. This identifies the target chain as Polygon, an Ethereum-based chain.
• [3] This is the attacker's Smart Contract address. The value is 0xB29927B7D854B232D5E58CFC201866376E68C676.
• [4] The script invokes a Smart Contract function, specified by the value in the data field, which serves as the function selector.

Content of the Contract

Before proceeding with the script analysis, we examine this Smart Contract in more detail. What data does it contain? Since we know it is deployed on Polygon, we can use PolygonScan to retrieve the relevant information.

Figure 1: The contract retrieved by the script

The Smart Contract's Solidity code contains the following elements:

PolygonScan also allows us to identify another Smart Contract containing identical Solidity code. Its address is 0xB2A4EA7055B7E2A6B2D96502F0FF85024E72987B. This contract was created by the same user as the one mentioned above. However, we have not found any trace of its use on compromised websites to date.

Figure 2: Similar contract

For each contract, we can retrieve its associated transaction history. This encompasses every call to a Smart Contract method that modifies its stored data. The full list is available at this address, this enables monitoring of attacker activity. Because each transaction is timestamped, it is also possible to analyze the attacker's activity patterns (by time of day). This can be a useful piece of information in certain cases. However, in this campaign, activity is visible at every hour of the day and on every day of the week. It is therefore not possible to draw meaningful conclusions.

Figure 3: The Smart Contract transactions list

The majority of these transactions correspond to calls to the contract function setPayload. For each of them, we can retrieve the input data. For example, the most recent entry at the time of writing is the following list of URLs:

Figure 4: The data sent to the function setPayload

Data Treatment

The JavaScript code inserted into the page calls the contract function getPayload. It then performs the following operations on the returned value:

• [5] The script decodes the content returned by the eth_call invocation and extracts the value of the enabled field. Execution is aborted if the value is false.
• [6] In this section, the script parses the URL list and randomly selects one of the entries.
• [7] Each URL is concatenated with an endpoint pointing to an external JavaScript file.
• [8] The external script is retrieved and injected into the page for execution by the browser. This advances the attack to the next stage, which leverages the ClickFix technique.

The script reveals that the attackers have set up a kill-switch mechanism. It allows them to enable or disable their campaign at will via the enabled field. Notably, within the Smart Contract's transaction history, multiple calls to the setEnabled function are visible. This is significant because the blockchain is used not only for storing and retrieving payloads, but also to act as a trigger for the campaign.

Figure 5: Transaction to the function setEnabled

Now that we know the URLs embedded in the Smart Contract are C2 servers from which a script can be retrieved, we can reconstruct the complete list using the transaction history. This yields a list of domains, available in the IOC appendix at the end of this article.

ClickFix Technique

Fake Captcha Injection

After retrieving the final script hosted on the C2, we observe that it renders a fake Cloudflare CAPTCHA prompt. This is a hallmark of ClickFix campaigns. The rendered content is localized based on the browser's language, with support for the following: English, Portuguese, Spanish, Indonesian, Vietnamese, German, and French. This list does not appear to follow any particular pattern or targeting logic. It may simply be a template copied by the attackers.

Figure 6: Fake Captcha verification

The script also includes a section that restricts execution to Windows systems and filters out all search-engine bots.

PowerShell Execution

Finally, in another section of the code, we observe that a command is directly placed on the clipboard, so that the victim is lured into pasting and executing it in a PowerShell terminal.

The copied command is as follows:

In PowerShell, irm is an alias for the Invoke-RestMethod cmdlet. It is primarily used to send HTTP/HTTPS requests to REST APIs or web servers and to retrieve the response body. The result is piped to iex, an alias for Invoke-Expression. The latter executes the input string as PowerShell code.

The PowerShell script downloaded from the C2 is as follows:

The following actions are performed:

• [1] Use of winget to install the Deno runtime, which is used to execute JavaScript, TypeScript, or WebAssembly code locally.
  • Note that winget is not available on all Windows systems. Because there is no error handling in this script, it will fail on some systems.
• [2] Execution of a JavaScript script via Deno, retrieved from https://checkmybtrobot[.]cc/j/traffic?r=797a. It is analyzed below.

Malware Injection and Execution

JavaScript Loader

This technique allows attackers to execute JavaScript code on the victim's machine, leveraging the system permissions granted to Deno. Once running, the script acts as a loader by downloading and executing two files:

The attacker's C2 is contacted again. We observe that the value of the t parameter in the URL is updated multiple times per minute by the attackers. This can be verified by refreshing the C2 page. Files must therefore be retrieved promptly.

The script performs the following actions:

• [1] Download of the first file, followed by validation checks on its size and content. The file size must be greater than 100 bytes, and the file must begin with the MZ header.
• [2] File creation, with the following parameters:
  • A random filename in the user's temporary directory.
  • Access rights: GENERIC_WRITE | GENERIC_READ | DELETE
  • Share mode: FILE_SHARE_READ | FILE_SHARE_DELETE
  • Create disposition: CREATE_ALWAYS
  • File attributes: FILE_ATTRIBUTE_NORMAL
• [3] Process Ghosting operation, performed as follows:
  • The file is marked for deletion (NtSetInformationFile).
  • The downloaded content is written to the file (WriteFile).
  • An image section is created in memory (NtCreateSection).
  • A process object is created (NtCreateProcessEx).
• [4] Attempt to start the first process.
• [5] Download of the second file.
• [6] Injection and execution of the downloaded content into the memory space of explorer.exe.

Malware Execution

The first file's MD5 hash is b97643bd45522efe9eea175d897787d3. During sandbox execution, we observed that it attempted to read several registry keys containing system information. Its metadata lists the name as "slaiclind", and the version information reads "Slaiclind Labs, LLC 2.6.6.19587, MSVC". An analyst reports a connection from this process to a C2 server (195.63.139[.]180) over TCP port 443 without TLS. The file is also flagged on VirusTotal.

Figure 7: First File Detection by Virus Total

Execution also produces the following dialog box:

Figure 8: The Dialog Box opened by the Script

The message is in Ukrainian (Cyrillic). It translates to: "Is it our fault if we built Ukraine around Odessa?!"

The second file's MD5 hash is 41e66c27fc6202f332e8e0a33aa5f519. It is an encoded shellcode payload, injected by the JavaScript script into the memory of explorer.exe. It is also flagged on VirusTotal:

Figure 9: Second File Detection with VirusTotal

General Scheme

To summarize our observations, the Slaiclind campaign is structured as follows:

Conclusion

This campaign demonstrates a combination of two operational techniques recently observed in the wild. The first, EtherHiding, delegates traditional C2 functionality to a Smart Contract, granting attackers greater resilience and flexibility. However, this also enables analysts to track their activities more effectively. The second, the ClickFix technique, has been widely used for over two years but remains largely unknown to non-technical users, in contrast with traditional phishing campaigns that most users now recognize. We can therefore expect to see a proliferation of similar campaigns in the coming months. We will continue to monitor their evolution.

Appendices

Observed Techniques Mapping (MITRE ATT&CK)

References

• [1] EtherHiding: when blockchain technology becomes a cyber weapon, 03 août 2026 - stormshield.com/news/cti-etherhiding-blockchain-technology/
• [2] The ClickFix technique: a rapidly growing threat, 23 mars 2026 - stormshield.com/news/clickfix-technique-growing-cyberthreat/
• [3] Smart Contract PolygonScan analysis - polygonscan.com/address/0xb29927B7D854b232D5E58CFc201866376E68C676
• [4] VirusTotal analysis - virustotal.com/gui/file/9f7bc41816a0eca3cae34168985d5ad9181a3cf41624cd2bf5c2cc7be2d031f0/community

IOCs