This post will cover methodology for hunting initial access via ClickFix (fakecaptcha, paste and run) campaigns. The analytics presented are for Microsoft Defender for Endpoint (MDE) using KQL.
Introduction
ClickFix is an initial access technique first observed in early 2024. It involves social engineering users into copying, pasting, and executing malicious code via the Windows Run dialog. Typically, ClickFix infections transpire through weaponized documents or compromised websites hosting malicious JavaScript, which copy commands into the victim’s clipboard. If the command is successfully executed by the victim, post-compromise activity largely involves info-stealer malware. Accordingly, this post will explore the initial access component of ClickFix delivered via compromised websites and present a hunt analytic for detecting the technique based on the latest trends.
ClickFix in the Wild
The initial access vector of ClickFix we will focus on is the copy and paste command delivered through compromised or otherwise malicious websites. To better understand what we will be hunting and creating analytics for, we begin by querying VirusTotal (VT) for the latest ClickFix samples through a VT intelligence query:
(engines:clickfix or engines:fakecaptcha) tag:html p:10+ fs:30d+
At the time of writing, the most recent ClickFix HTML sample observed is the following:

The sample also contains Zenbox sandbox execution artifacts of the rendered HTML file. Zenbox is one of the many virtual machines used to detonate samples and its telemetry is available in VT:

However, when inspecting the process and service actions, process tree, and registry actions, we do not see the initial access commands associated with ClickFix or RunMRU registry artifacts (more on this later):

Inspecting the HTML source code further reveals the ClickFix command is in fact present albeit not executed by the sandbox:

Collectively, these observations suggest sandbox interaction for these samples will likely be limited to rendering and clicking the HTML page but not extracting or executing ClickFix commands. If our goal is to obtain these commands in bulk for analysis and tailor analytics to them, more work will be required on our end. At the very minimum, we can still leverage the fact that VT engines have detection signatures for the files and variants thereof.
Obtaining ClickFix Samples for Analysis
At this stage, we will require a custom solution to utilize against VT samples for extracting ClickFix commands efficiently in lieu of manually debugging HTML and JavaScript. To that effect, we will be using Selenium in conjunction with PowerShell to automate the browser interaction and extract the ClickFix command across samples in bulk. Specifically, some samples required interaction with the HTML before producing the ClickFix command, thus a simplistic solution such as scraping the page for commands was not viable. Once again, we will run the VT intelligence query mentioned earlier and download the first 100 ClickFix samples first uploaded during the past month:

Next, we will run a custom PowerShell script developed for this task named clickfix_extract.ps1. To successfully run the script in your own environment, Selenium and its WebDriver need to be configured. An overview of the script logic is as follows:
- Each HTML file sample is parsed whilst clickable button/checkbox elements (captcha click-box or “im not a robot” buttons) are identified using FindElementsByCssSelector.
- Some samples deliberately avoided using button/checkbox elements, instead employing divs (<div>) with EventListeners for clicks. In these cases, the script searched for common id attribute names of button-like elements using FindElementById. A separate script was used to perform trivial stack counting against our samples to obtain the most prevalent id attribute names incorporated in clickfix_extract.ps1.
- In either case, if a clickable button or id attribute is found, it is clicked. Any non-empty modification to the underlying system’s clipboard is tracked via the Get-Clipboard cmdlet and written to a text file. This file will contain the extracted ClickFix command.
Finally, we can see the script in action. The extracted ClickFix commands from the automated interaction are denoted by the cyan PowerShell console output. In the next section, we will analyze the extracted commands.

Note: If a particular sample required some external web resource containing logic to de-obfuscate the ClickFix command, or contained anti-debugging logic, it was not successfully extracted by the script.
Overview of ClickFix Results
After the script successfully extracts the ClickFix commands from the VT samples, we can begin analyzing the command lines used for initial access. Of the 100 samples analyzed, 62 featured Document Object Models without button or checkbox elements and did not leverage captchas or other verification methods. This suggests that the content may have been injected when the page was originally scanned by VT, making it inaccessible during the offline analysis. Additionally, 6 samples produced command lines but appeared to require a network connection to generate the ClickFix command. Overall, the script extracted 32 unique command lines:

Now, let us dig further into the command line trends to help us build analytics for detecting these techniques. The following results were obtained using simple PowerShell scripts to calculate average command line length, and perform a stack count of the initiating processes:
- Average command length: 179.21 characters
- Initiating process count: PowerShell.exe: 17, Mshta.exe: 13, Cmd.exe: 2
Moreover, we can visualize the command line data through frequency analysis by using Voyant Tools. The terms illustrated in the output will be used later in this post to develop analytics:

ClickFix and RunMRU Analysis
A trademark of ClickFix execution on the endpoint is the use of the Windows Run dialog, which is linked to the RunMRU registry key. This key provides forensic evidence of application execution via the Run dialog. However, registry writes to this key should not be mistaken for persistence. The Windows Run dialog can be accessed by right-clicking the Windows icon on the taskbar and selecting “Run,” using the Windows key + R, or Windows key + X shortcuts, although the latter is not as widely used. Therefore, when a command is entered and executed in the Run dialog, the RunMRU registry key is updated, and the entries are stored in temporal order.
With that in mind, let us analyze what successful Clickfix activity looks like from the endpoint perspective. We start by opening the Windows Run dialog via the Windows key + R shortcut and pasting a ClickFix command extracted previously:

The execution of the command is tracked using Process Monitor:

Inspecting the registry write operation (RegSetValue), we find the entire PowerShell command is written to the RunMRU registry key.

Some key observations from testing we can incorporate into our analytic in the next section are as follows:
- Explorer.exe serves as the parent process for commands executed via Windows Run dialog.
- Explorer.exe writes to the RunMRU registry key immediately after PowerShell.exe is spawned.
- As ClickFix commands are used for initial access, there will likely be some type of network activity from PowerShell or any other LOLBin spawned using ClickFix.
MDE Analytics
At last, we can summarize what behavior our analytic aims to detect based on our analysis and research thus far:
- Explorer.exe performs a registry write action into the SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU* key. The registry key is updated with at least 50 characters. As we saw previously, the average ClickFix command length was roughly 179 characters.
- The registry write action into the RunMRU key contains one of the command line parameters obtained through frequency analysis.
- The result set for registry activity (DeviceRegistryEvents) is then joined with the DeviceNetworkEvents table on any endpoint which also spawns a specific LOLBin within 5 seconds of the RunMRU being updated. The LOLBin must also exhibit a network connection.
Potential Clickfix Execution
//This analytic detects potential clickfix activity by searching for registry modifications to \CurrentVersion\Explorer\RunMRU and subsequent powershell/cmd/mshta execution with network activity during a set time interval.
let ps_keywords = dynamic ([“start-process”, “hidden”, “command”, “bypass”, “new-object”, “http”, “invoke”, “iex”, “-exec”, “verification”, “classname”, “cimmethod”, “methodname”, “win32_process”, “system.diagnostics.process”, “system.management.automation”, “Reflection.Assembly”, “FromBase64String”, “import-module”, “add-type”, “webclient”]);
let script_keywords = dynamic ([“http”, “javascript:”, “verification”, “eval”, “.js”, “.vbs”, .“hta”, “.bat”]);
let window = 30d;
let registry_activity=(DeviceRegistryEvents
| where Timestamp > ago(window)
| where InitiatingProcessAccountName != “system”
| where InitiatingProcessFileName =~ “explorer.exe”
| where ActionType == “RegistryValueSet”
| where isnotempty( RegistryValueData)
| where RegistryKey endswith @“\CurrentVersion\Explorer\RunMRU”
| extend regkey_length = strlen(RegistryValueData)
| where regkey_length >= 50 //filter short strings that are unlikely to contain full commands
| where RegistryValueData has_any (“powershell”, “pwsh”, “cmd”, “mshta”) and (RegistryValueData has_any (ps_keywords) or RegistryValueData has_any (script_keywords)) //LOLBin spawned will always be in the RunMRU, so it does not need to be included as a keyword
| project registry_change=Timestamp,DeviceName, InitiatingProcessAccountName, RegistryKey, RegistryValueData, regkey_length
);
DeviceNetworkEvents
| where Timestamp > ago(window)
| where InitiatingProcessAccountName != “system”
| where InitiatingProcessParentFileName =~ “explorer.exe”
| where InitiatingProcessFileName has_any (“powershell”, “pwsh”, “cmd”, “mshta”)
| where isnotempty(RemoteUrl) or isnotempty(RemoteIP)
| join kind=inner (registry_activity) on DeviceName
| where Timestamp between (registry_change … -5s ) or Timestamp between (registry_change … +5s ) //process creation must occur up to 5 seconds before or after the registry change to account for MDE logging latency.
| project process_execution=Timestamp, registry_change, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemoteUrl, RemotePort, RemoteIPType, ActionType,RegistryKey, RegistryValueData, regkey_length
| order by registry_change asc
Adjust the analytic as needed, with additional keywords or filtering. If the analytic returns results, here is some additional guidance for defenders when investigating a potential ClickFix infection:
- Investigate the contents written to the RunMRU registry key. The presence of commands indicates at least part of the command was successfully executed via Run dialog. For example, if a PowerShell command is executed but the network connection fails, it will still be written to the RunMRU.
- Assess the device timeline for successful outbound connections to the domain(s) referenced in the RunMRU registry key. The network connection will likely be to newly-registered or low-prevalence domain.
- Examine temporal activity in the device timeline occurring after the registry write to RunMRU. If a successful connection is established, the C2 domain may contain additional commands that will be executed. Pay close attention to additional network connections, file downloads, and LOLBin activity.
Summary
In conclusion, I demonstrated methodology for obtaining ClickFix samples through VT. We then extracted and analyzed command line data through a custom script and used frequency analysis. Lastly, we simulated ClickFix within our lab to gain additional insights for modeling successful initial access attempts and developed a high-fidelity analytic for detection.
https://blog.sekoia.io/clickfix-tactic-revenge-of-detection/
https://redcanary.com/blog/threat-intelligence/intelligence-insights-october-2024/
Hunting ClickFix Initial Access Techniques was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: Hunting ClickFix Initial Access Techniques | by Manuel Arrieta | Mar, 2025 | Detect FYI
1 post - 1 participant
Malware Analysis, News and Indicators - Latest topics
Post a Comment
Post a Comment