Our team recently observed a significant uptick in malware campaigns leveraging fake CAPTCHA pages to deploy info-stealers, loaders and remote access trojans (RATs). These lures are part of evolving social engineering chains that culminate in the delivery of threats like Lumma Stealer, Sliver, and Emmenhtal.

Some variants including ClickFix and ClearFake, which utilize a novel technique known as Etherhiding, demonstrate how threat actors are innovating in their use of obfuscation, blockchain infrastructure, and clipboard-based payload execution. This post offers a brief technical breakdown of these campaigns and focuses on behavioral detection opportunities relevant to defenders.

Threat Overview

These fake CAPTCHA pages are often part of malvertising chains or SEO poisoning tactics designed to lure users searching for specific types of content. Some common examples were from users searching for:

ClickFix:

• Free/Pirated Movies: Torrent sites, streaming mirrors, or forums linking to "free" content often serve as initial redirectors.

• Manuals or Technical Documentation: Especially obscure or niche product manuals, user guides, and troubleshooting PDFs. These are frequently SEO-optimized to rank high in Google searches.

• Travel Booking and Reservations: Sites mimicking airlines, hotels, or booking confirmations that ask the user to "verify they’re human" before showing blurred booking details.

• Storage and Shipping Service: Mimicked storage or courier service platforms.

ClearFake + Etherhiding:

• Infected WordPress websites: Cases of ClearFake typically involve legitimate WordPress websites that have been infected with malicious JavaScript.

The fake CAPTCHA pages are convincingly designed and typically include:

• A blurred document or video frame behind a CAPTCHA widget.

• Phrases like "Click to verify you're human" or “Complete these Verification Steps.”

• Often hosted on recently registered domains with names that mimic legitimate services or tech brands.

• Sometimes embedded in PDFs or accessed via shortened links in phishing emails.

Campaign Architecture

1. JavaScript-Based Delivery (ClearFake/ClickFix)

Malicious JavaScript is embedded in compromised sites:

• Encoded using Base64

• Windows OS detection before CAPTCHA render

• Obfuscation via multiple techniques such as:

  • Indirect function calls

  • Arithmetic decoding

  • Random variable names

  • Hex-based string reconstruction

2. Blockchain-Based Payload Hosting (Etherhiding)

ClearFake variants now embed payload references directly in Binance Smart Chain (BSC) contracts:

• PowerShell/MSHTA command embedded in BSC smart contract

• Webpage fetches and auto-copies payload to clipboard

• The same contract address observed in multiple cases from this Atea Report

Exploitation Techniques

ClickFix: Clipboard Abuse for Execution

ClickFix leverages clipboard manipulation:

• Payload auto-copied to clipboard

• User instructed to paste into the Run dialog using Win + R

• Delivered command executes MSHTA or PowerShell

The Payload: MSHTA + Homoglyph Social Engineering

The command payload is disguised to look like a CAPTCHA verification:

• In many cases the attack uses homoglyphs—characters that look legit but evade static detection.

• There are no html file extensions being executed in the command which is likely another attempt to evade detection.

• In every case Explorer.exe is the parent when using the run dialogue (This can be advantageous in detection writing).

Obfuscated PowerShell Download Cradles

Dynamic download techniques (TL;DR):

• Uses [Net.WebClient]::New() object
  Avoids hardcoded methods like DownloadString

• Applies Get-Member with fuzzy logic (e.g., -clike '*wn*g')

• Fully in-memory execution with Invoke-Expression or InvokeScript

Dynamic download techniques (Long Version):

The script creates a WebClient object and uses fuzzy logic to identify the method used for downloading content—DownloadString—without referencing it by name. It does this by calling Get-Member to list available methods on the object, then filters them using the -clike operator (case-insensitive wildcard match) to find something resembling “*wn*g” (matching “DownloadString”).

This approach helps evade static detection by avoiding hardcoded method names and relying on dynamic discovery instead. Ultimately, it builds a download cradle that fetches and executes a remote payload in memory, without writing anything to disk.

Another interesting variation using the same technique, but using a slightly different way of running Get-Member and execution parameters of the encoded PowerShell. Finding the similarities between each variant will be helpful for building detections.

One more variation where PowerShell uses the -like function to call DownloadString without case sensitive matching. You can also spot multiple interesting ways the script calls Invoke-Expression (or InvokeScript) in these events. All of which are spawned from Base64 encoded PowerShell commands (which is important for detection opportunities later).

AMSI Bypass Technique Modifying CLR.DLL in Memory

Some variants dynamically disable AMSI:

• Builds byte signature for AmsiScanBuffer

• Locates and modifies clr.dll in memory

• Effectively disables AV scanning of PowerShell scripts

Reference: AMSI Bypass Research

Post-Exploitation Behavior

Across all variants, there was consistent use of one or more of the following:

• Info Stealers (Lumma, Vidar, etc): Credential theft, session tokens, browser data, crypto wallets

• Remote Browser Debugging: PowerShell initiating debug mode on Edge/Chrome

• Sliver RAT: Open-source C2 framework for persistent access

• Loaders: Including Emmenthal, with others reported in the wild

• RunOnce Persistence: Lengthy binaries (≥26 characters) creating RunOnce keys with known Lumma Stealer

Remote Browser Debugging:

Many samples initiate remote debugging sessions on all installed browsers. This allows them to extract cookies, session tokens, and other sensitive artifacts without triggering typical browser protections.

Execution of Lumma Stealer via RunOnce key

In a couple of instances we observed very lengthy executables creating RunOnce registry keys for executables that have been identified as Lumma Stealer. The character length does appear to vary, but this does create a detection opportunity for us as well as it does appear to be over 26 characters in length which should be rare.

Detection & Hunting Opportunities

While these techniques leverage some sneaky tactics and heavy obfuscation there are several detection opportunities. Below are some useful Sigma rules that can be used for detection and hunting (you can convert some of these to queries using something like uncoder.io for validation and tuning). Each rule should be carefully evaluated and assigned a threat level based on your validation process.

Homoglyph Social Engineering

The following Sigma rule detects the use of homoglyphs in conjunction with highly suspicious binaries. It is unlikely to have many false positives in regions that do not frequently use Cyrillic text. This rule eliminates some of the false positives from the Sigma project's Potential Homoglyph Attack Using Lookalike Characters by pairing it with often-abused binaries.

title: Homoglyph Attack Using Lookalike Characters Used With Highly Suspicious Binary
id: 2bd01836-ab65-4897-b3f9-9981e7c04394
status: experimental
description: Detects homoglyphs being used with highly suspicious binaries. 
references:
    - https://www.joesandbox.com/analysis/search?threatname=clickfix
    - http://www.irongeek.com/homoglyph-attack-generator.php
author: Luke Rusten
date: 2025/04/07
tags:
    - attack.defense_evasion
    - attack.t1036
    - attack.t1036.003

logsource:
    category: process_creation
    product: windows
detection:
    suspicious_binary:
        CommandLine|contains:
            - 'powershell'
            - 'cmd'
            - 'wscript'
            - 'cscript'
            - 'mshta'
            - 'rundll32'
            - 'regsvr32'
            - 'wmic'
            - 'schtasks'
            - 'certutil'
            - 'msiexec'
            - 'bitsadmin'
    selection_upper:
        CommandLine|contains:
            - "\u0410" # А/A
            - "\u0412" # В/B
            - "\u0415" # Е/E
            - "\u041a" # К/K
            - "\u041c" # М/M
            - "\u041d" # Н/H
            - "\u041e" # О/O
            - "\u0420" # Р/P
            - "\u0421" # С/C
            - "\u0422" # Т/T
            - "\u0425" # Х/X
            - "\u0405" # Ѕ/S
            - "\u0406" # І/I
            - "\u0408" # Ј/J
            - "\u04ae" # Ү/Y
            - "\u04c0" # Ӏ/I
            - "\u050C" # Ԍ/G
            - "\u051a" # Ԛ/Q
            - "\u051c" # Ԝ/W
            - "\u0391" # Α/A
            - "\u0392" # Β/B
            - "\u0395" # Ε/E
            - "\u0396" # Ζ/Z
            - "\u0397" # Η/H
            - "\u0399" # Ι/I
            - "\u039a" # Κ/K
            - "\u039c" # Μ/M
            - "\u039d" # Ν/N
            - "\u039f" # Ο/O
            - "\u03a1" # Ρ/P
            - "\u03a4" # Τ/T
            - "\u03a5" # Υ/Y
            - "\u03a7" # Χ/X
    selection_lower:
        CommandLine|contains:
            - "\u0430" # а/a
            - "\u0435" # е/e
            - "\u043e" # о/o
            - "\u0440" # р/p
            - "\u0441" # с/c
            - "\u0445" # х/x
            - "\u0455" # ѕ/s
            - "\u0456" # і/i
            - "\u04cf" # ӏ/l
            - "\u0458" # ј/j
            - "\u04bb" # һ/h
            - "\u0501" # ԁ/d
            - "\u051b" # ԛ/q
            - "\u051d" # ԝ/w
            - "\u03bf" # ο/o
    condition: suspicious_binary and (1 of selection_*)
falsepositives:
    - Commandlines with legitimate Cyrillic text; will likely require tuning (or not be usable) in countries where these alphabets are in use.
level: low

MSHTA/PowerShell

The following Sigma rule detects Mshta.exe getting launched with Explorer as the parent and no HTML file specified which is highly suspicious. In addition, the Sigma project's Remotely Hosted HTA File Executed Via Mshta.EXE will detect mshta.exe reaching out over common internet protocols (http, https, or ftp).

title: Highly Suspicious MSHTA.exe Execution From Explorer Parent
id: 5fa3b3df-7bed-4bea-b144-22d7b8f59af1
status: experimental
description: Detects MSHTA.exe being launched from explorer without specifying an html file which is highly unusual
references:
   - https://www.joesandbox.com/analysis/search?threatname=clickfix
tags:
   - attack.execution
   - attack.defense_evasion
   - attack.t1218.005
author: Luke Rusten
date: 2025/04/10
logsource:
   category: process_creation
   product: windows
detection:
   selection:
       Image|endswith: '\mshta.exe'
       ParentImage|endswith: '\explorer.exe'

   filter:
       CommandLine|contains:
         - '.hta'
         - '.htm'

   condition: selection and not filter
falsepositives:
   - Unknown
level: low

PowerShell Download Cradles

Our PowerShell Webclient With Get-Member Matching Launched From Encoded PowerShell detection is great to start off as a threat hunt in your environment to develop a baseline and start to tune. You will not likely find many encoded PowerShell scripts running this combination of commands if at all.

title: PowerShell Webclient With Get-Member Matching Launched From Encoded PowerShell
id: 5068d424-4d35-412f-aa8b-9a49bf8183dd
status: experimental
description: PowerShell Webclient With Get-Member Matching Launched From Encoded PowerShell
references:
   - https://www.joesandbox.com/analysis/search?threatname=clickfix
tags:
   - attack.execution
   - attack.defense_evasion
   - attack.t1218.005
author: Luke Rusten
date: 2025/04/10
logsource:
   category: process_creation
   product: windows
detection:
   selection_webclient:
       CommandLine|contains:
           - 'Net.WebClient]::New()'

   selection_get_member:
       CommandLine|contains:
           - '|GM|'
           - 'Get-Member'
           - '|GM)'

   selection_like:
       CommandLine|contains:
           - 'Value.Name -clike'
           - 'Value.Name -like'
           - '$_.Name -clike'
           - '$_.Name -like'

   selection_parent:
       ParentCommandLine|contains:
           - 'powershell'

   selection_parent_encoded:
       ParentCommandLine|contains:
           - ' -e '
           - ' -en '
           - ' -enc '
           - ' -enco '
           - ' -encod '
           - ' -encoded '
           - ' -encodedcommand '

   condition: all of selection*
falsepositives:
   - Unknown
level: low

AMSI Bypass

This detection is pretty specific and has only had minor tweaks to make it resilient for variable changes.

title: Potential AMSI Bypass Technique Modifying CLR.DLL in Memory
id: b9cfffb2-f4f8-455d-a167-21f59495f8f4
status: experimental
description: Detects use of AMSI Bypass Technique Modifying CLR.DLL in Memory
references:
   - https://practicalsecurityanalytics.com/new-amsi-bypss-technique-modifying-clr-dll-in-memory/
   - https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell
author: Luke Rusten
date: 2025/04/12
tags:
   - attack.execution
   - attack.t1059.001
   - attack.t1106
logsource:
   product: windows
   category: ps_script
   definition: 'Requirements: Script Block Logging must be enabled'
detection:
   selection:
       ScriptBlockText|contains|all:
           - '0x02'      # PAGE_READONLY
           - '0x04'      # PAGE_READWRITE
           - '0x40'      # PAGE_EXECUTE_READWRITE
           - '0x20'      # PAGE_EXECUTE_READ
           - '0x100'     # PAGE_GUARD
           - '0x1000'    # MEM_COMMIT
           - '260'       # MAX_PATH
           - 'if ($path.EndsWith("clr.dll"))' # We want to look for clr.dll in the script. This may be too specific for variations, but it works in every case we observed
           - '$signature = [System.Text.Encoding]::UTF8.GetBytes' # Matches variations of $signature = [System.Text.Encoding]::UTF8.GetBytes($a + $b + $c + $d)

   condition: selection
falsepositives:
   - Unknown
level: low

PowerShell spawning remote debugging

This detection may require some tuning for your environment, but it is unlikely to have a high false positive rate. If your detection engine supports it, you could supercharge this detection by alerting on 2 or more browsers with remote debugging initiated by PowerShell in a 30 second period. That would be highly unusual in most environments. In addition, the Potential Data Stealing Via Chromium Headless Debugging Sigma rule looks for similar behavior but may be more false positive prone.

title: Browser Started with Remote Debugging Initiated By PowerShell
id: 3dfa8836-67c8-4658-bf6f-01d26cec6b4f
status: experimental
description: Detects browsers starting with the remote debugging flags initiated by PowerShell. This is a technique often used to perform browser injection and infostealer attacks
references:
   - https://www.joesandbox.com/analysis/search?threatname=clickfix
   - https://github.com/defaultnamehere/cookie_crimes/
   - https://github.com/wunderwuzzi23/firefox-cookiemonster
author: Luke Rusten
date: 2025/04/10
tags:
   - attack.credential_access
   - attack.t1185
logsource:
   category: process_creation
   product: windows
detection:
   parent:
       ParentImage|endswith: '\powershell.exe'
   selection_chromium_based:
       CommandLine|contains: ' --remote-debugging-'
   selection_firefox:
       Image|endswith: '\firefox.exe'
       CommandLine|contains: ' -start-debugger-server'
   condition: parent and 1 of selection_*
falsepositives:
   - Unknown
level: low

Run Key Persistence From a Lengthy Parent

This rule may generate some false positives although it should not be many. Verify that your detection engine supports this type of regex and tune for your environment. The binaries observed in the Lumma Stealer cases were 26 and 28 characters, but baselining showed 23 was a pretty good sweet spot and only required a couple of tunes. You should baseline this in your environment and decide if you should increase the character count and tune out false positives.

title: Potential Persistence Attempt Via Run Keys Using Reg.EXE With Lengthy Parent
id: a6d9b48b-4394-4d5e-b026-9df096bfa186
status: experimental
description: Potential Persistence Attempt Via Run Keys Using Reg.EXE With Lengthy Parent
references:
   - https://www.joesandbox.com/analysis/search?threatname=clickfix


author: Luke Rusten
date: 2025/04/10
tags:
   - attack.persistence
   - attack.t1547.001
logsource:
   category: process_creation
   product: windows
detection:
   selection:
       CommandLine|contains|all:
           - 'reg'
           - ' ADD '
           - 'Software\Microsoft\Windows\CurrentVersion\Run'
       ParentImage|re: '\\[a-zA-Z0-9]{23,}\.exe'

   condition: selection
falsepositives:
   - Some legitimate software although executable names are not typically that long


level: low

Recommendations

User Awareness & Training: Educate users on recognizing deceptive prompts and CAPTCHA-like lures. Encourage hesitation before pasting clipboard content into Win + R.

Behavioral-Based Detection: Static IOCs change quickly. Behavioral detections will likely provide more resilience across several variants.

Restrict Use of Run Dialog: Disable or restrict Win + R functionality for non-administrative users using Group Policy. (This should be thoroughly researched and tested before implementing). Guide: Disable Run Command

References

• HHS Alert on ClickFix

• Joe Sandbox Analysis - ClickFix

• Microsoft Security Blog: Booking.com Phishing

• ClearFake + Etherhiding Deep Dive

• Etherhiding on Blockchain

Over the years, I’ve had the privilege of speaking with many Security Analysts and Threat Hunters, each with their own approach to threat hunting. Some methods have been truly impressive, and others have been a little less so. While I don’t believe there is necessarily a wrong way to perform threat hunting, there are certainly ways that are more effective. In this post, I will outline some concepts that make for an efficient and impactful threat hunt.

Before we dive into the mechanics of effective threat hunting and work through an example, it’s essential to understand why threat hunting is so important. Framing this will help guide how we approach our hunts. Here are some reasons threat hunting is critical:

• Threats are often discovered after a compromise has occurred or a vulnerability is disclosed.

• Detections are typically based on past observations, leaving gaps for novel attacks.

• Threats can linger undetected for days, weeks, months, or even years before they’re uncovered.

While there are other reasons, these three points lead to one crucial concept: we won’t always detect new threats before they’ve been discovered. Knowing this helps us become more strategic in our approach to finding malicious activity, and in this post, I’ll explain how to hunt with these concepts in mind.

The Pyramid of Pain

If you are unfamiliar with The Pyramid of Pain by David Bianco you are in for an earth shattering revelation in your threat hunting! Okay, maybe not earth shattering, but if your threat hunting is based strictly off searching for hashes, IPs and domains, you may benefit from understanding the concepts behind it.

If you want to read more about it you can read about it here, but the TL;DR: “This simple diagram shows the relationship between the types of indicators you might use to detect an adversary's activities and how much pain it will cause them when you are able to deny those indicators to them.”

When applied to threat hunting, we understand that searching for an IP address or Hash, may not be the best way to find the threat as these things frequently (and easily) change. Instead, focusing your threat hunting on indicators toward the top of the pyramid is far more productive.

Prioritizing The Hunt

Another common mistake I see threat hunters make is looking for a shiny object without really considering whether or not the threat is actually relevant or just something they personally found interesting. If there is some scary sounding Linux exploit out there, but your organization has one Linux server in the basement that isn’t exposed to the internet, it may not be the most important place to hunt.

Consider - Does this threat target my sector or industry? Is there a high probability I may be impacted? Do I have a lot of exposure to this threat?

If the answers to these questions are “no,” it might be worth re-prioritizing your hunt. Of course, if you have the resources to investigate more obscure threats, go for it—but for most, focusing on high-probability, high-impact threats is the most effective use of time and resources.

Continuous Improvement

The last and one of the most important components of threat hunting is ensuring that each hunt has some form of output and a way to measure them. These should be part of a continuous improvement philosophy that drives your hunts. If you are simply hunting for a threat and not building new detections, improving telemetry, or improving your controls - you are doing it wrong.

I recommend tracking the following at a minimum:

• Hunt Environment: (Windows, MacOS, Linux, Cloud, etc)

• Number of new detections added

• Number of telemetry improvements

• Threat found (Yes/No)

Also, be sure to document your hunt and what you’ve learned. Your documentation will help describe what is normal for your environment, which can be valuable if you’re ever investigating an incident. Documenting your hunts is also important for both rerunning them in the future and continuously improving them over time. 

Putting It Together: A Practical Example

So we have covered why we hunt, what to hunt for, and how to prioritize our hunts. Next let's walk through an example hunt.

First let's pretend we are the threat hunters responsible for protecting a hospital. We receive this advisory related to BlackSuit (Royal) Ransomware who is known to target healthcare. That checks one of our priority boxes!

In this report there are tons of IOCs (indicators of compromise) and TTPs (tactics, techniques and procedures) that are utilized by the ransomware group. Should we search for the hashes, filenames, IPs or domains? That might work. Instead I am going to focus on something at the top of the pyramid of pain.

In the report we see the threat actors use a tool called Chisel.

Chisel is a tool that can be used by attackers for various nefarious purposes. It can be used for C2 (command and control), data exfiltration, bypassing firewalls, etc. A few TTPs that map back to MITRE are:

T1071.001 - Application Layer Protocol: Web Protocols

• Description: Adversaries may communicate using the application layer protocols associated with web traffic to avoid detection/network filtering by blending in with legitimate traffic. They often use port 443 (HTTPS).

• Relevance: Since the connection is happening over port 443, the use of a common web protocol like HTTPS to conceal malicious traffic is a common technique.

T1090.002 - Proxy: External Proxy

• Description: Adversaries may use external proxies to obfuscate their command and control communications by routing traffic through an external proxy such as a SOCKS proxy.

• Relevance: The command includes :socks, indicating the use of a SOCKS proxy to relay traffic, which is common for masking communications between an infected host and the attacker’s infrastructure.

T1036.005 - Masquerading: Match Legitimate Name or Location

• Description: Adversaries may use masquerading by placing an executable in a legitimate path, using a legitimate-sounding name, or leveraging built-in system executables (e.g., conhost.exe).

• Relevance: The path C:\Users\Public\ combined with a legitimate-sounding executable like conhost.exe suggests potential masquerading.

Observations and Focus Areas

With these techniques in mind, here are some key indicators to investigate for this threat hunt:

• Network connections initiated from binaries in C:\Users\Public\ or its subfolders. In my experience, very few legitimate executables should be making network connections from this location. Common false positives may include certain VPN clients or educational tools.

• SOCKS client commands that are running throughout your environment.

• Common Windows binaries executing from unusual directories.

Continuous Improvement: Close Visibility Gaps

For this threat hunt, we must confirm our visibility into these activities:

• Do we have process creation/process tracking events that include command-line activity?

• Are we monitoring network connection events, specifically those originating from our areas of concern?

While performing your threat hunt, you may find that you do not have the visibility, telemetry, or access required to answer important questions. That’s a great finding! Threat hunting will force you to identify and confront these types of gaps before an incident.

Continuous Improvement: Implement Better Detections

For detections, I highly recommend utilizing SigmaHQ—a fantastic resource for threat research and detection development. Each detection is mapped to the MITRE ATT&CK framework and comes with references for further exploration. Here are some relevant detections that could enhance our coverage against the threat from our example:

• Network Connection Initiated From Users\Public Folder

• System File Execution Location Anomaly

• PUA - Chisel Tunneling Tool Execution

Useful tip: Tools like uncoder.io or sigconverter.io will allow you to input a Sigma rule and output a hunting query that works with various tools. Check them out!

Conclusion

Threat hunting is about more than just chasing down the latest exploit or investigating novel malware. It’s about focusing your efforts where they matter most—on threats that pose a legitimate risk to your environment. By understanding the Pyramid of Pain, prioritizing relevant threats, and approaching each hunt with a structured strategy, you can vastly improve the effectiveness of your threat hunting program.

As I mentioned earlier we won’t always detect new threats before they’ve been discovered. Using the above methodology, we may find Chisel, or we may find any number of tools used by threat actors that share similar TTPs (regardless of hash, filename, destination IP, etc). We've also improved our detection capabilities, so whether it's Chisel or an entirely new tool, if it shares the same TTPs, we have a strong chance of detecting it.

By being methodical and purposeful in your hunts, you'll not only improve your detection capabilities, but also increase the difficulty for adversaries to operate undetected in your environment.

I started my journey working in IT for many years. Fixing computers was cool. Building them was even cooler (who doesn’t love building a monster computer?!). I have done everything from setting up O365 tenants to running all of the Cat6 cables from the wall plate to the switch.

Then one day, a customer got phished and needed our help. Going through the sign-in logs and finding the bad guy’s IP was exciting. It was an aha! moment. I felt like a digital Sherlock Holmes, and I had just defeated Professor Moriarty! Okay, maybe I am exaggerating a little, but I was hooked. After that, I started learning what I could about hacker techniques and cybersecurity.

Fast forward a year or so, and an opportunity to work with my good friend (and cyber-rockstar) Eric at his cybersecurity company fell into my lap. I started off as a Security Analyst and got to learn from some of the best people in this space. I am so grateful for the experience and knowledge I gained from such a great mentor.

Now it’s my turn to pay it forward. I hope you enjoy the ramblings of a cyber-dad.