Fake reCAPTCHA Phishing: When Good Intentions Go Wrong

6 min read3 days ago

Phishing attacks are constantly evolving, and techniques like ClickFix and fake reCAPTCHA phishing have been on the rise. These scams exploit our trust in common web interactions, tricking users into running malicious code. The real issue? The instructions and code to execute these attacks are readily available, making it far too easy for threat actors to launch phishing campaigns at scale. This has made a bad situation even worse for a phishing method that was already pretty successful.

Understanding ClickFix & Fake reCAPTCHA

ClickFix is a social engineering tactic where attackers trick users into running malicious commands on their devices. This could be through fake browser alerts or update messages on compromised sites, urging them to copy and paste commands into their systems. Once they gain access, malware such as remote access trojans or info-stealers is installed to facilitate credential theft and serve as an entry point for attackers.

In contrast, fake reCAPTCHA phishing plays on users’ trust in CAPTCHA systems. Attackers create phishing pages mimicking Google’s reCAPTCHA, taking advantage of user trust in a feature designed to protect against spam and website abuse. After interacting with the fake CAPTCHA, similar to the ClickFix method, users might be prompted to run malicious commands or give away sensitive info. This method takes advantage of the trust people have in CAPTCHA verifications. The steps outlined below provide a general description of this phishing method:

A user visits a compromised website or receives an email with an urgent message (e.g., a fake browser update alert).
The message instructs them to copy and paste a provided command into their system’s command interface (such as Win + R on Windows).
Once executed, the command downloads and installs malware — often a remote access trojan (RAT) or an info-stealer like Lumma Stealer.

Interestingly, ClickFix came before fake reCAPTCHA, highlighting how social engineering strategies have evolved over time. Unfortunately, this development came with the help of the security community. Below, I will try to explain how threat research can work to its own detriment.

The Big Mistake: Making Phishing Plug-and-Play

One of the biggest concerns with fake reCAPTCHA is just how easy it is to incorporate into a phishing webpage. The code, along with instructions on how to use these techniques, is freely available. Open-source tools, scripts, and tutorials on platforms like GitHub lay out step-by-step guides for setting up phishing pages with fake reCAPTCHAs. As a result, threat actors have everything they need pre-packaged and ready to deploy, no technical skills required, no complex setup involved.

The widespread availability of these phishing methods, developed and refined, has provided an effective attack vector for threat actors. The easy access to these resources has backfired, causing a huge spike in phishing scams that take advantage of these methods. As we speak, thousands of phishing emails are sent out, using tricks that were once shared as part of security research.

Opinion: The Responsibility of Red-Teaming Tools

I fully support open-source red teaming tools that highlight new attack techniques leveraging operating system loopholes or legitimate tools for nefarious purposes, as long as they are released with due diligence in providing solutions. These methods are crucial for pressuring vendors to improve the security of their products.

However, this case was different. Unlike traditional red teaming tools, this method involved a phishing approach that exploited a legitimate Windows feature and made readily available code easily accessible for threat actors to plug and play, significantly reducing the effort needed to execute attacks.

I have immense respect for John Hammond, who is the author behind the reCAPTCHA phish method. I respect and admire the work he is doing in the InfoSec space. That said, when an InfoSec “celebrity” like him releases a tool, the reach is massive. The sheer number of eyes on his work, both ethical hackers and threat actors, means that whatever he shares is likely to be used quickly in the wild. His social media presence and reputation amplify this effect, making his tools widely known within hours of release.

This is where the issue lies. With great power comes great responsibility. A tool meant to educate can easily become a tool for exploitation when it is essentially a plug-and-play phishing kit. The moment something like this is published, threat actors don’t just learn from it, they use it, often with minimal to no modifications. The difference between exposing a vulnerability to improve security and handing over a fully functional attack method is subtle but important. We need to be mindful of where we draw the line.

To his credit, John Hammond acknowledged the unintended consequences of his release and took steps to mitigate the issue by providing a method for IT departments to disable the feature. This was a responsible move and showed his commitment to the security community. However, in practice, disabling this feature is incredibly difficult for large organizations. Many enterprises lack a well-structured division between admin and non-admin users or operate in environments where implementing such a control would require significant restructuring. For organizations with poor access management or outdated security policies, mitigating this risk is far from straightforward. While efforts to fix the problem are appreciated, the reality is that once a tool like this is in the wild, it becomes nearly impossible to contain.

Detecting and Investigating ClickFix and Fake reCAPTCHA Phishing

A critical step in mitigating these threats is early detection and thorough investigation when a potential incident arises. One of the most effective detection methods is leveraging the RunMRU registry key (Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU). This registry key logs all commands executed via the Win + R method, allowing security teams to monitor for suspicious command execution.

Detection Methods

Monitor the RunMRU Registry Key: This key holds the exact commands executed, which can help detect suspicious activity. This Sigma rule is designed to detect suspicious commands executed through RunMRU. You can find it here.

Investigation Steps

Check the RunMRU Key: Check the registry Key under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU and review contents of possible malicious executed commands.
Correlate with Browser Activity: Check the user’s browsing history for any URLs accessed just before the suspicious execution. Look for unusual domains, redirects, or known phishing URLs. Gather network-related indicators of compromise (IOCs) that could signal a larger phishing campaign targeting the organization. If multiple users report similar activity, it could indicate a broader attack that needs immediate containment.
Contain the Incident: If a compromise is detected, isolate the affected system and remove malicious executables. DON’T forget to remove the RunMRU entry so the user won’t accidentally run the malicious command again.

For more information on the attack chains that have been reported in the wild and a more detailed explanation of the execution chain, check the articles below:

Conclusion

Awareness is important when releasing security tools that could potentially be misused. While transparency and open-source research are vital to improving information security, it’s important to consider the consequences of making powerful attack methods widely available. Unfortunately, in this case, it provided threat actors with a plug-and-play phishing technique that has been rapidly adopted for malicious purposes.

That said, mistakes happen, and it is nice to see security researchers like John owning up to them. The security community is full of dedicated professionals working overtime to mitigate threats and develop better defenses. Mistakes like these are valuable learning experiences, reminding us that responsible disclosure should always come first before putting new tools out into the wild.

Going forward, striking a balance between research, awareness, and security is very important, in my opinion. The goal should always be to help defenders, not attackers while ensuring that security knowledge is shared responsibly.

This blog post serves as my opinion and view on this issue. I understand that it might not sit well with everyone, and that’s okay. Healthy debate and differing perspectives are what drive the security community forward.