Profiling the Prey: The Reconnaissance Layer, and a Binary That Missed the Planet

The Long Tail — Part 3 of the honeypot census remainder

Classification: MEDIUM · Confidence: HIGH (first-party; the specimens are legible)

The two previous letters were about operators who did not want to be counted — one hid its payload off the sensor, the other made its payload unreadable on it. This one is about the opposite instinct entirely: the moment an attacker, having just won a shell, stops to look around. Between the break-in and the payload there is a reconnaissance beat, and the honeypot captured it in two specimens that could not be more different in discipline. One is a beloved open-source utility, used to profile the victim with real care, dropped ten times. The other is a Windows binary, fired four times at a Linux machine that could never run it. The reconnaissance layer holds both the most careful and the least careful behavior in the entire corpus, and each is diagnostic in its own way — because what an attacker looks for, and what their automation fails to check, both tell you more about them than the malware they eventually drop.

Neither specimen is malware in the ordinary sense. Neither mines, backdoors, spreads, or persists. They are the exhaust of attackers operating — the traces left by the act of looking around and the act of firing blind — and a census that files them as noise throws away its clearest evidence of intent.

Neofetch, weaponized by being itself

The sample the classifier labelled "System Info Script" is 376,936 bytes of shell, dropped ten times, and it is not custom malware at all. It is neofetch — the popular, benign, open-source system-information tool from github.com/dylanaraps/neofetch, carried onto the honeypot verbatim, license header and wiki links and all. An attacker downloaded a beloved desktop-Linux ricing utility and ran it as a reconnaissance instrument.

What neofetch harvests is precisely an attacker's triage checklist. It reads the CPU — model, core count, clock speed, temperature — from /proc/cpuinfo. It reads total and free memory from /proc/meminfo. It reads the GPU, and specifically checks /proc/driver/nvidia/version for an NVIDIA card. It identifies the OS, the kernel, the uptime, the package manager, and the terminal, and it resolves the machine's public IP via ident.me over curl or wget. Read that list again as a buyer's inspection rather than a hobbyist's boast: how many cores can I mine on, how much RAM is free, is there a GPU worth the trouble, what OS and package manager do I persist through, and where on the internet did I land. The tool's field list is the attacker's shopping list. Neofetch was built to make a Linux enthusiast's desktop look impressive in a screenshot; it profiles a victim's hardware value with exactly the same fields, and the attacker did not have to write a line of it.

The size is itself a choice. Neofetch is 377 kilobytes of shell — enormous next to the four-hundred-byte loaders and one-line keys elsewhere in the corpus, and vastly larger than the dozen lines of grep /proc/cpuinfo a custom profiler would need to answer the same questions. An attacker who drops the whole bloated utility rather than a tight bespoke script is making the living-off-the-land trade explicitly: paying hundreds of kilobytes of transfer and disk to gain the one property a bespoke script cannot have — being a recognized, benign, publicly-hosted tool that no scanner will flag. In a corpus where every other operator shaves bytes, the recon layer spends them lavishly, because here the currency that matters is not size but legitimacy, and legitimacy is only for sale in the form of the whole real tool.

The NVIDIA check is the tell. Most servers and virtually all honeypots have no GPU, and neofetch's probe of /proc/driver/nvidia/version returns nothing here — but the attacker runs it anyway, on every box, because a GPU is the jackpot. A reconnaissance tool that reaches first for the graphics card is reconnaissance run by someone whose business is mining, triaging hardware before spending a payload. The recon reveals the intent before any miner touches disk.

Living off the land, at the recon stage

The reason to use neofetch instead of a bespoke profiler is the same reason it was dropped ten times: it is legitimate, and legitimacy is invisible.

A custom reconnaissance binary is malware — it can be signatured, its strings can be read, its author can be tracked, exactly as the previous letters tracked operators by their build fingerprints. Neofetch has no such surface. It is signed open-source software with a public repository and a MIT license; a signature-based defense has no honest basis to flag it, because flagging it would flag every legitimate user who runs it. So the attacker gets a thorough hardware-and-network profile of the victim while depositing nothing a malware scanner is entitled to alarm on. The reconnaissance stage is where sophisticated intrusion deliberately goes quiet, using the target's own environment and the internet's own free tools, and neofetch being dropped ten times is the corpus's evidence that this instinct is common, not rare. The attackers who profile before they pounce reach for the tool that cannot be called malicious.

There is a companion behavior in the same layer that must be described carefully. Attackers also run public-IP and geolocation lookups — ident.me, ipinfo.io and their kind — to learn where they have landed: the jurisdiction, whether the host is a cloud instance or a residential connection, whether it is worth keeping at all. This is reconnaissance pointed outward, the attacker checking their own new coordinates. The honeypot captured such self-checks, and their content is by nature the victim's own metadata — the sensor's address reflected back — rather than any attacker indicator. Because that content identifies the sensor rather than a threat, its specifics are deliberately excluded here; the behavior is the finding, not the reflected address. It is worth naming precisely because it is the mirror of the neofetch profiling: one call inventories the machine, the other locates it, and together they are an attacker deciding, before committing a payload, whether this particular shell is worth the bother.

The communal toolbox

There is a structural reason the reconnaissance layer looks different from everything else in this investigation, and it is worth stating because it inverts the method the whole census has relied on.

Every prior letter tracked operators by what they could not help emitting — a build hash, a runtime marker, a fixed key, a self-named loader. Those artifacts work as fingerprints because they are specific to one operator's toolchain. Neofetch is the opposite: it is specific to no one. It is a single public tool that any number of unrelated attackers download from the same GitHub repository and run unchanged. Its ten drops on this sensor almost certainly do not represent one operator returning ten times; they more plausibly represent many operators independently reaching for the same off-the-shelf profiler, because it is the obvious choice and it is free. The reconnaissance layer does not cluster by operator the way the payload layer does, because its tools are communal — shared commodity infrastructure that fingerprints the ecosystem's habits rather than any one hand within it.

That is a finding, not a limitation. It means the recon layer answers a different question than the payload layer. The payloads told us how many operators and which; the reconnaissance tells us what the whole population has in common — that a large, otherwise-diverse set of attackers converges on the same handful of legitimate profiling tools and public lookup services, because reconnaissance rewards blending in and the surest way to blend in is to use what everyone uses. The durable-artifact method deliberately looks past shared tooling to find the operator underneath; the reconnaissance layer is what that method looks past, and looking at it for once shows the shared substrate the operators all stand on. Neofetch is not a fingerprint of anyone. It is a fingerprint of the trade.

The binary that missed the planet

The other specimen is the opposite of careful. The classifier labelled it "Windows API dropper"; it is a 27,648-byte Windows Portable Executable, dropped four times onto a Linux SSH honeypot, and its debug path names it calc.pdb.

Everything about it is Windows. Its imports are KERNEL32.dll, SHELL32.dll, ADVAPI32.dll, msvcrt.dll, and the modern api-ms-win-core-* shims; its entry point is __wgetmainargs, the MinGW C-runtime console entry; it carries a Windows application manifest declaring dpiAware. It is a small MinGW-compiled Windows console program, and calc is the most canonical name in all of offensive tooling — "popping calc," launching the Windows calculator, is the ritual proof that an exploit achieved code execution. A binary named calc is almost always a test payload: the thing an exploit developer fires to confirm the target ran their code.

And it was fired at a machine that cannot run it. A Windows PE on a Linux host does not execute — there is no loader for it, no kernel32.dll to bind, nothing. It landed, four times, and did precisely nothing, because the automation that delivered it never checked what operating system it had broken into. This is the reconnaissance layer's dark twin: not the attacker who profiles carefully, but the attacker who does not profile at all — whose post-exploitation pipeline is so indiscriminate that it sprays a Windows proof-of-execution test at every shell it wins, Linux included, and never notices the shots that hit the wrong planet.

What the misfire reveals is still worth having. It tells us the operator's toolchain is Windows-oriented — they build, carry, and reflexively deploy Windows payloads, which situates them in a different ecosystem than the Go-and-shell Linux operators that dominate the corpus. It tells us their automation validates exploitation with a calc test the way a Windows-focused shop would. And it tells us that automation runs open-loop, without an OS check, because a closed loop would have suppressed a Windows drop against a Linux banner. The careless artifact fingerprints the careless process.

The culture of calc

The calc payload deserves a moment on its own terms, because the name is not incidental — it is a whole subculture compressed into four letters, and reading it tells you what kind of shop fired it.

In offensive Windows tooling, launching calc.exe is the canonical demonstration that an exploit worked. When a researcher or an operator achieves code execution, the reflexive proof is to make the target pop open its own calculator: harmless, unmistakable, instantly visible. Entire exploit-development workflows are built around a calc test payload as the green light — the automated check that says the chain fired, execution is real, proceed. A binary whose debug path is calc.pdb is almost certainly one of these validation payloads, the small program a pipeline drops first to confirm it has a foothold before it commits anything valuable.

Which makes its appearance on a Linux SSH honeypot a small ethnographic report about the operator behind it. This is a shop whose muscle memory is Windows exploitation — whose validation ritual is popping calc, whose payloads are MinGW PEs, whose entire proof-of-execution culture assumes a Windows target. And that muscle memory fired against an SSH service on Linux, four times, because the pipeline that carries it does not gate on operating system. The calc test is meant to run after a Windows exploit lands; here it was delivered as if the SSH brute-force had been a Windows exploit, by automation that treats every won foothold as the same kind of foothold. The misfire is not just carelessness in the abstract. It is a specific carelessness — a Windows exploitation reflex bolted onto an indiscriminate credential-spraying front end, firing its Windows green-light at a Linux shell it will never illuminate. The corpus's most inert artifact is, read this way, one of its most revealing: it caught an operator importing an entire platform's habits into an attack surface those habits do not fit.

Two ends of one spectrum

Set the two specimens side by side and they bracket every operator in the corpus by discipline.

Neofetch is the careful end: an attacker who, before spending a payload, inventories the victim's cores, memory, GPU, and location using a tool so legitimate it cannot be flagged — profiling the prey more thoroughly than some operators profile their own targets. The calc misfire is the careless end: an attacker whose automation does not check the target's operating system before firing a payload that has no chance of running. Between those two poles sits the entire population this investigation has catalogued — RedTail brute-forcing every architecture until one executes, which is breadth with verification; the Windows dropper spraying one architecture at everything, which is breadth without it; the toolkit's disciplined engineering; the opaque toolset's deliberate concealment. The reconnaissance layer is where that spectrum becomes visible, because reconnaissance is where an operator either does or does not bother to look before acting, and the corpus caught one of each in the same two weeks.

The deeper point is that the non-payload layer is not a lesser stratum of the corpus. It is where intent lives. A miner tells you what an operator did; neofetch's field list tells you what they were deciding, and the GPU probe tells you why. A backdoor tells you an operator wanted access; the calc misfire tells you the shape of the machine that decided to want it, and how little it checked. The malware is the verb; the reconnaissance is the reasoning, and the reasoning is usually more legible than the verb — because reconnaissance, to work, has to read the world in the clear.

Defense: the clearest signals are the ones that aren't malware

The reconnaissance layer is, counterintuitively, a detection gift, precisely because its specimens are not malware and therefore behave in ways malware-centric defense does not model.

Neofetch on a production server is anomalous in a way that is nearly free of false positives. Servers do not run desktop system-information ricing tools; developers do not neofetch their fleet. The appearance of neofetch — or any of the living-off-the-land profilers — in a server's process tree or drop directory is a high-signal, low-noise tripwire, and it fires at the reconnaissance stage, before the payload, which is the earliest and cheapest place to catch an intrusion. The instinct to whitelist legitimate tools is exactly wrong here: the legitimacy is what the attacker is exploiting, and the context is what betrays it.

The Windows PE is cleaner still. A Portable Executable in a Linux host's temporary directory is an impossible artifact — it cannot have arrived through legitimate use, because nothing legitimate deposits an unrunnable Windows binary on a Linux server. Alerting on the mere presence of a PE header in a Linux drop path is a rule with essentially no false-positive rate and an unambiguous meaning: automated attack traffic, delivered by a pipeline careless enough to ignore the target OS. The corpus's most useless payload, the one that did nothing four times, is also its most reliable detector — because uselessness, in the right place, is a signature all its own.

Bounds and limits

DOCUMENTED, first-party: the "System Info Script" is neofetch (376,936-byte shell, 10 drops, github.com/dylanaraps/neofetch, harvesting CPU/RAM/GPU/OS/package-manager/public-IP incl. an NVIDIA-driver probe and ident.me lookup); the "Windows API dropper" is a 27,648-byte MinGW Windows console PE (4 drops, calc.pdb, __wgetmainargs, Windows imports and manifest) delivered onto a Linux SSH honeypot.

INFERRED, high confidence: neofetch was used as reconnaissance for hardware/value triage (its field list is an attacker's inspection checklist; the GPU-first probe indicates mining intent); the calc PE is a mis-delivered Windows proof-of-execution test payload fired by OS-blind automation (the canonical calc test name, plus delivery to an OS that cannot run it, plus a Windows-oriented toolchain).

BOUNDED: neofetch is benign software — its presence in an attack context is the signal, not the tool, and this letter attributes no malice to the tool itself. The Windows PE was not executed and is characterized only as a MinGW console binary named calc, the canonical test payload; its full behavior is not established and it is assessed as a mis-delivered test artifact, not as a Linux threat. The outward-facing self-check behavior (public-IP and geolocation lookups) is described generically; its captured instance reflects the sensor's own metadata rather than any attacker indicator and is deliberately not reproduced. Drop counts (neofetch 10, the PE 4) are at this one sensor. These specimens characterize the reconnaissance and misfire layer around the corpus's malware, not that malware's function.

None of these bounds change the finding. The honeypot's most careful attacker profiled the prey with a tool so legitimate it could never be flagged; its most careless one fired a Windows binary at a Linux machine four times and never noticed. Both are the exhaust of intrusion rather than its weapon, and both are more honest about who is operating — and how much they bother to look — than any payload in the corpus. The malware is what the honeypot was built to catch. The reconnaissance is what the malware was built to serve, and it reads in the clear.

This is Part Three of The Long Tail. Part Four closes the series by counting what is left — the genuine fragments and one-line artifacts at the very bottom of the corpus — and by settling the account the whole census opened: how many operators, once the tail has been read rather than weighed, the honeypot has actually been watching.