Fake Amazon CAPTCHA ClickFix Uses finger.exe to Deliver Doina, Lumma Stealer and NetSupport

Petri's coverage gives the short version. Here is the full chain, what makes it different from a standard ClickFix lure, and what Windows admins can do about it.

The lure: a top sponsored result and a fake Amazon login​

According to Huntress, it investigated multiple incidents stemming from an Amazon-themed ClickFix campaign tied to a sponsored Google search result for the keywords "amazon business." The sponsored result leads to a spoofed Amazon login page with an embedded ClickFix (fake CAPTCHA) that downloads a malicious payload from attacker-controlled infrastructure. The company says the technique has already struck at least three Huntress customers.

Huntress traced the sequence step by step:

• The sponsored ad pointed to a lookalike hostname, orders-amazon[.]com[.]advancedfences[.]com. The domain that actually matters is advancedfences.com. The "Amazon" part is just a subdomain prefix.
• That link sent visitors to a fake Amazon login page hosted on Google Sites, which asked for an email address or phone number.
• After the visitor submitted that, a fake "I'm not a robot" CAPTCHA appeared. Clicking it quietly copied a command to the clipboard, and a pop-up told the user to paste it into the Windows Run box.

The Run dialog was also doctored. Huntress found that the command ended with a long run of spaces and hyphens, so the only text visible in the Run box looked like an instruction to push Enter. The user saw a friendly prompt while the real command sat out of view.

There was a macOS branch as well. Mac visitors were told to run a script in Terminal, but that destination URL was offline when Huntress investigated, so the report doesn't show that the Mac path ever delivered a payload. Everything below is the Windows path.

Section summary: No software vulnerability was exploited. The attack used a paid ad, a spoofed brand and a user who followed the instructions on screen.

Stage one: finger.exe as the download tool​

The finger protocol dates from the era of Unix shell accounts. Users could publish a .plan file, a kind of personal notice board, and anyone could read it with a finger query. Huntress notes that the ClickFix command calls on Window's built-in finger utility, a relic of the early internet, used in this case as a living off the land binary (LOLBIN).

In this campaign the attacker put a Windows script inside the .plan file of a user account on grillrecipespro[.]com. The pasted command asked that account for its .plan and executed whatever came back. Two simple tricks hid what was going on:

• Command-line obfuscation. The characters of the command were broken up with commas, carets, hyphens and underscores, which the Windows command interpreter ignores.
• Hidden script content. 68 extra carriage returns pushed the malicious script below the visible area of a typical console window.

Huntress security operations analyst Reddish told Dark Reading that finger appeals to attackers because it's still present on many systems, yet "few users or defenders expect to see it," and that here "it retrieved attacker-controlled text from a remote .plan file and quietly handed the attack to the next stage."

Finger traffic is plaintext and defaults to TCP port 79, so in theory it's easy to spot. Huntress's point is that almost nobody uses finger any more, so most networks never bother to block it.

This is a trend, not a one-off​

finger.exe has shown up in ClickFix attacks before:

• Coverage by Cybersecurity News of earlier SANS Internet Storm Center research reported that the finger technique has been in use since at least November 2025, and that Internet Storm Center analysts/researchers noted this activity and have been tracking two prominent campaigns employing this technique: KongTuke and SmartApeSG.
• Microsoft's own threat researchers saw it too. In a February 2026 post about a variant called CrashFix, Microsoft wrote that in January 2026, Microsoft Defender Experts identified a new evolution in the ongoing ClickFix campaign, and that a notable new tactic in this ClickFix variant is the misuse of the legitimate native Windows utility finger.exe.
• In a separate detection write-up, Huntress described how finger-based cradles hide behind carets: the caret is cmd's escape character, and it's discarded at parse time, so the command runs normally while matching nothing that looks for those words.

What sets the Amazon campaign apart is how long the chain runs after finger does its job. In Reddish's words to Dark Reading: "The difference here is the depth of the chain."

Stages two and three: IronPython, Doina, Node.js and a stealer​

Here is the rest of the chain as Huntress reconstructed it:

1. IronPython as the interpreter. The .plan script used curl to download the legitimate IronPython.3.4.2.zip from the IronPython GitHub releases. It saved the archive in the user's Temp folder with a .pdf extension, unpacked it with Windows' built-in tar, and ran a Base64-encoded, zlib-compressed Python script through ipyw32.exe in the archive's net462 folder.
2. The timer6 script. Next, the chain fetched timer6 from grillmasterchef[.]com. This is a Base64-encoded Python script in which some Latin letters had been replaced with Cyrillic ones, so a normal decode fails. It reverses the substitution, decodes itself and unpacks a layer protected with a 19-byte XOR key. The result is a Windows PE loader.
3. Doina. The loader reads a URL from a specific .ini file, downloads the v6 payload and decrypts it with RC4. The first 64 bytes of the file are the key. It then injects the result into memory. Huntress says security vendors broadly agree this is Doina, a modular family that can act as a loader, remote-access trojan, infostealer and profiler.
4. A portable Node.js package. Doina pulled down a roughly 52 MB ZIP from kiriosyka[.]com containing a portable Node.js runtime and an obfuscated index.js. It unpacked them to C:\ProgramData\NodeView and ran the script with the legitimate node.exe.
5. The stealer. index.js downloaded two files and decrypted them with AES-256-GCM. The smaller one, about 17 KB, is a shellcode reflective DLL injector. The larger one, over 19 MB, is an infostealer that Huntress describes only as "allegedly" Lumma Stealer. The injector loads it into memory through process hollowing.
6. A rogue RMM tool. The chain also installed a pirated, roughly eight-year-old copy of the NetSupport Client in C:\ProgramData\Prodclear. It talked over HTTPS on non-standard TCP port 725 to 167.148.201[.]106 and requested fakeurl.htm.

According to Huntress, the stealer sends hostname, username and other profiling data to its command server, then switches to WebSocket communications. Strings in that traffic point at:

• Browsers: Chrome, Edge, Firefox and Opera
• Crypto wallets: Ledger, Electrum and Atomic Wallet
• Password managers: LastPass, Dashlane, 1Password, NordPass and RoboForm
• Email clients and PowerShell

Huntress also says the payload server appends a random number of null bytes to each archive, so every download has a different hash, and the payloads inside change once or twice a day. Hash-based blocklists will fall behind this campaign quickly.

Status at publication: Google has removed the malicious ad, but the attacker infrastructure remains online and functional. Attacker infrastructure seems to preferentially use a growing list of domain names that are barbecue themed.

Section summary: One paste into the Run box started a chain that ran through roughly six stages and installed credential-stealing malware plus a persistent remote-control tool. Almost every step relied on legitimate binaries: finger, curl, tar, IronPython and Node.js.

Why traditional defenses struggle​

Petri's write-up makes the main point: tools built to catch malicious files or exploits have little to grab at the start of a ClickFix attack, because the user runs the command. In this chain the opening steps are signed Microsoft binaries and real open-source interpreters downloaded from GitHub. The malicious logic arrives as text, as encrypted blobs or as in-memory injections.

That doesn't make ClickFix unstoppable. It means detection has to look at process behavior rather than file reputation. Huntress's own figures show the trade-off. ClickFix accounted for about 2.2% of the Managed Endpoint Detection and Response (EDR) detection signals Huntress has seen this year so far, but nearly 99% of those detections were high severity. ClickFix doesn't fire often, but when it does, it's almost always serious.

What Windows admins should do now​

Here is a practical checklist built from Huntress's recommendations and the wider reporting:

1. Teach one rule. No legitimate CAPTCHA asks you to paste anything into Run, PowerShell, Command Prompt or Terminal. Huntress says this flatly. If users remember only one thing, it should be this.
2. Hunt for finger.exe. Alert on any finger.exe execution, especially when its parent is explorer.exe (as happens when it's launched from Run) or when it makes outbound connections on TCP 79. On most corporate networks, legitimate use is close to zero.
3. Block TCP 79 outbound unless you have a documented need for it. The SANS-tracked campaigns, the Microsoft CrashFix analysis and this one all depend on it.
4. Watch for suspicious process sequences. Look for curl followed by tar writing into user Temp folders, ipyw32.exe running from extracted archives, and node.exe launching from C:\ProgramData\NodeView.
5. Check ProgramData and odd ports. Investigate unfamiliar folders under C:\ProgramData (including NodeView and Prodclear), unexpected client32.exe NetSupport binaries, and outbound HTTPS on TCP 725.
6. Trace visits that came from ads. Huntress notes that Google ad clicks leave aclk in the URL path and gclid in query strings. Searching proxy logs and browser history for those markers can help rebuild how a user got from an ad to the malicious site. They aren't proof of compromise on their own.
7. Consider restricting the Run dialog for users who never need it. GBHackers' coverage of an earlier Huntress ClickFix investigation lists turning off the Windows Run prompt via Registry or Group Policy as a technical control. Huntress offers a similar toggle in its own product, but admits attackers can simply tell victims to use PowerShell, Command Prompt or the File Explorer address bar instead.
8. Use the indicators, but don't rely on them alone. Huntress has published domains, URLs and SHA-256 hashes for timer6, the Node package and several stealer samples. Because payloads and hashes change daily, treat them as hunting leads rather than a complete blocklist.

The trade-off​

Petri is right that each of these controls comes at a cost. Locking down Run, blocking legacy protocols and adding alerts on built-in tools will annoy some power users, create more alerts for your security team and occasionally get in the way of legitimate troubleshooting. Still, compare the two sides. Blocking finger.exe and TCP 79 costs most organizations almost nothing. A successful infection here leaves an attacker with browser credentials, password-manager data and an RMM agent that lets them return whenever they like.

It's also worth noting that the source of this research has a commercial interest. Huntress sells managed detection and is promoting a Run-dialog lockdown feature alongside its findings. Its technical analysis is detailed and consistent with what the Internet Storm Center and Microsoft's own researchers have reported about finger.exe abuse, but the product mention is marketing. The mitigations above work without any particular vendor.

The short version for users: if a website tells you to press Win+R, paste something and hit Enter, close the tab.