ProBackend
News & Analysis
4 hours ago5 min read

ClickFix Uses Windows Finger to Deliver Lumma Stealer and NetSupport

A sponsored-search lure and fake CAPTCHA lead to a Windows finger command, IronPython staging, and reported Lumma Stealer and pirated NetSupport payloads. Here are the evidence and defensive steps.

A fake CAPTCHA turns a search click into a command

A familiar shopping search can become the first step in a serious compromise. In a campaign reported by Huntress and covered by Dark Reading, attackers used a sponsored Google result for “amazon business” to route users to a counterfeit Amazon sign-in page. After entering an email address or phone number, visitors saw a fake CAPTCHA. Its instructions were the real trap: the user was prompted to run a command on the machine.

That is the defining ClickFix trick. The page presents a supposed verification or repair action, then asks the target to perform an operation that hands control to the attacker. The victim is not merely clicking a malicious download link; the lure persuades them to execute a command themselves. In this case, the command invokes Windows’ built-in finger utility.

Huntress researcher Sarah Reddish described the significance plainly: “'Old' doesn't mean 'irrelevant.'” The point is worth keeping in view. A decades-old utility can still be useful to an attacker when it is available on a target system and its network traffic attracts little attention.

What the Windows finger request does

The finger utility originated as a way to retrieve information about users on remote systems. In this campaign, attackers put malicious text in a remote .plan file and used a crafted finger request to retrieve it. The command reached out over TCP port 79. Rather than relying on a conventional executable download as the first move, the chain used an existing Windows utility to fetch content that could be passed to later stages.

The command was designed to be less obvious to its intended user. Dark Reading reports that the fake CAPTCHA concealed the malicious instruction behind a seemingly routine request to press Enter. Huntress’ technical account describes obfuscation in the command and a display crafted to make the instruction less apparent. This is not a sophisticated deception of the operating system; it is a deception of the person at the keyboard.

That distinction matters for defense. An employee may believe they are completing an ordinary browser check, while the command they paste or run has a network effect beyond the browser. A CAPTCHA is not a reason to execute a terminal command, and a web page has no legitimate need to ask a visitor to run finger in Windows.

IronPython staging and reported payloads

The retrieved content feeds the next stages of the chain. Huntress reports that the infection uses IronPython for staging and identifies Lumma Stealer and a pirated NetSupport Client among the payloads observed. Lumma is an infostealer; NetSupport is legitimate remote-management software that can be misused when installed without authorization. Their presence represents two different risks: theft of information and an attacker’s potential use of a remote-access tool.

The significance is not that every finger request leads to these programs. It does not. These are the payloads reported in this investigation, and the same delivery technique could be adapted to other malware. Reddish told Dark Reading that the entry point could lead to different types of malicious software, including an infostealer, remote-access trojan, ransomware, or remote management tool. That is a statement about potential, not evidence that all those payloads were deployed in this campaign.

Huntress’ reporting also documents connected campaign infrastructure and observables, including domains used for command-and-control and payload delivery. Several names use cooking or grill references, such as GrillRecipesPro, TheGrillJournal, EmbersAndBites, GrillMasterChef, and HomelyGrill. The investigation describes relationships among infrastructure through shared hosting and DNS details and through observed payload delivery or communications. These are useful indicators for analysts, but defenders should consult the original reporting for the full, current indicator set rather than treating a handful of names as a complete blocklist.

Why this is not an AI threat story

The evidence described here concerns social engineering, a legacy Windows command-line utility, staged malware, and campaign infrastructure. The cited reporting does not establish that artificial intelligence created the lure, selected victims, or operated the payloads. It would be misleading to label this incident an AI-driven attack or use it as proof of a new AI threat trend.

More broadly, “AI in cybersecurity” means applying artificial-intelligence techniques to security work, such as helping analyze signals or identify patterns. But that general definition does not explain this particular campaign. The available account is specific: a sponsored result, a fake CAPTCHA, a user-run command, and malware staging. Keeping those facts separate from wider discussion of AI makes the incident more useful to defenders, not less.

Detection and mitigation: focus on the behavior

Huntress’ technical write-up provides campaign observables and detection context. For organizations, the practical starting point is to investigate unexpected use of finger.exe, especially when it makes outbound connections over TCP/79. Because port 79 is unusual in many environments, defenders should determine whether there is a legitimate business need for that traffic rather than assuming it is harmless simply because it comes from a built-in utility.

Look at the sequence, too. A browser visit followed by an unexpected command interpreter or finger activity, retrieval of remote .plan content, and subsequent staging deserves investigation. Huntress reports IronPython in the chain, so its unexpected execution in this context is another useful lead. Review endpoint telemetry and network records together; a single event may look ordinary while the sequence tells a different story.

The reporting’s indicators can help teams search their own telemetry and block confirmed malicious infrastructure, but indicators change and may not capture every related domain. Apply them alongside behavior-based monitoring, and verify any proposed block or alert against the source’s details. Where an organization has no legitimate use for the utility or protocol, restricting or closely monitoring outbound TCP/79 can reduce exposure; first assess operational dependencies.

User guidance should be direct. Do not copy commands from CAPTCHA pages, search results, or unexpected browser prompts. A verification challenge should not require opening Run or a command prompt. If someone has already followed such instructions, report it promptly and preserve the endpoint and network evidence for investigation instead of trying to clean up manually.

The practical takeaway

This campaign is a reminder that attackers can turn trusted-looking search placements and familiar system tools into a delivery path. Train users to treat command-running instructions on web pages as a stop signal, and make sure defenders can spot unexpected finger use and TCP/79 traffic. The old utility is not the whole story; the handoff from a convincing lure to an overlooked system tool is.