TI-2026-097A — Count Is a Lie: The Honeypot's Top Malware Is a Newline

Classification: HIGH · Forensic threat intelligence · Dropped-sample corpus · Series: Reading the Drop

A honeypot's most satisfying artefact is the download table — the list of files attackers pulled onto the machine, ranked by how many of them pulled each one. It looks like a malware chart, and the temptation is to read the top row as the most important threat. This letter reads the bytes behind that table instead, and the result is almost comic. The single most-downloaded "payload" across a hundred attackers is not malware. Neither is the second. Neither is the fourth. The real prize — a complete, self-propagating worm — sits at number five, four attackers deep, where a count-based eye would never look. The lesson is old and the corpus is new: you cannot rank malware by counting hashes. You have to open the file.

1. The Table That Looks Like a Chart

Over roughly thirty days (2026-06-24 to 07-23) the honeypot captured 318 downloads, resolving to 94 unique SHA-256 hashes across 191 IPs, and the daily rate is climbing (thirteen drops on the final day alone). Rank those hashes by how many distinct IPs fetched each one — "payload reuse", the natural proxy for which malware is most widespread — and the top of the table reads:

Read that "What it actually is" column and the chart falls apart. Two of the top four are degenerate non-files. The number-one entry is a key, not a binary. And the only row a malware analyst should care most about — the severity-100 worm — is dead last of the five. The table is not wrong; it is answering a different question than the one it appears to answer. It ranks what got written to disk most often, and most of what gets written to a honeypot most often is not malware.

2. The Bytes, One Degenerate at a Time

None of this is interpretation. Every claim in that last column is verifiable to the exact byte, and I verified it.

e3b0c442… is the empty string. e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is the canonical SHA-256 of zero bytes — recomputable in one line (printf '' | sha256sum). Five IPs "downloaded" this. They downloaded nothing. The capture is an empty file: a wget that 404'd, a cat of a path that didn't exist, a transfer that produced no output. Recorded, hashed, and counted as a shared payload.

01ba4719… is a single newline. printf '\n' | sha256sum returns 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b exactly. Sixty-seven IPs and seventy-one downloads share this "payload." It is one \n character — the output of an echo, a bare Enter, a command that emitted a newline and nothing else. By the count-ranked table this is the second most widespread piece of "malware" in the entire corpus. It is a keystroke.

9f86d081… is the word "test." printf 'test' | sha256sum → 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08. Two IPs. An operator typing echo test > /tmp/x to check that redirection works before dropping the real thing.

9a45029b… is dd complaining. This one is subtler, because the classifier gave it a name. It is labelled "Network logging utility" — which sounds like a tool. Open it (85 bytes, plain text) and the entire content is:

0+0 records in
0+0 records out
0 bytes transferred in 0.695821 secs (0 bytes/sec)

That is the stderr of a dd command that copied zero bytes. It is not a network utility, not a payload, not a tool of any kind — it is the console spew of a failed transfer, captured as a sample and handed a plausible-sounding family name by auto-classification. The name is more dangerous than the empty file, because the empty file announces itself as junk and this one wears a costume.

3. The King That Isn't a Binary

Now the number-one row, which is the most interesting of all because it is not junk — it is just not what the table implies.

a8460f44… is 389 bytes, and its file type is ssh_key. Its entire content is one line:

ssh-rsa AAAAB3NzaC1yc2E…RK+oRw== mdrfckr

This is the mdrfckr key — one of the most widely documented indicators in the whole SSH-attack landscape, the signature authorized_keys entry of the Outlaw / Dota cryptomining worm family. When one of these bots lands on a host, it appends this public key to ~/.ssh/authorized_keys so the operator can walk back in without a password, forever. A hundred distinct honeypot IPs wrote the same key. That is a genuinely valuable finding — a single operator's backdoor stamped across a hundred machines, one of the strongest operator-linking IOCs in the corpus.

But notice two things. First, it is not a downloaded binary — it is a persistence artefact written through the session, which is why the corpus's top "download host" is the pseudo-host sshd (64 captures written straight through the SSH channel, not fetched from any URL). Second, the classifier scored this key severity 0. The single most operationally meaningful item in the table — a hundred-machine shared backdoor — was rated harmless, while dd spew got a tool name. The auto-labels are not just noisy; on the two most important rows they are inverted.

4. Where the Real Malware Was Hiding

Filter out the key and the artefacts and rank what remains by content and severity, and the actual threat picture — the one the count-table buried — appears:

• XMRig cryptominers. 94f2e4d8… (severity 65, thirteen IPs, ATT&CK T1496 resource hijacking) and siblings, plus a multi-architecture RedTail miner delivered as redtail.arm7, redtail.arm8, redtail.i686, redtail.x86_64, redtail.riscv, redtail.armv5/armv6 — a build for every CPU a compromised IoT device might have.
• An SSH-PAM backdoor — a persistence module, distinct from the mdrfckr key.
• The prize: 6d1fe6ab…, severity 100 — a complete Raspberry Pi IRC worm. It joins channel #biret on undernet, verifies RSA-signed commands from its operator, kills competing miners, appends its own authorized_keys backdoor, and self-propagates by scanning the internet with zmap and brute-forcing pi@ hosts with sshpass -praspberry. It ranks fifth by count — four IPs — and it is, by a wide margin, the most dangerous single artefact the honeypot caught. Its full teardown is the subject of the next letter, TI-2026-097B.

The real malware was always there. It was just never at the top of the count, because the top of the count belongs to keys, newlines, and empty files.

5. This Is Not Data Hygiene — It Is Attribution

It would be easy to file all this under "clean your data" and move on. That undersells it, and this program has the receipt. TI-2026-052A built a shared_malware graph — attackers linked by delivering the same payload — and its own as-of note records what happened next: the graph "was later corrected to exclude junk/trivial hashes that had inflated it," dropping from 2,089 links across 82 IPs to roughly 68 links across 16 IPs. A thirty-fold deflation.

That is the stakes, stated in the program's own history. A newline shared by 67 IPs does not just add noise — it manufactures a phantom 67-node campaign, a super-cluster of "operators delivering the same malware" who in fact share only the fact that each once emitted a newline. An empty file links everyone who ever failed a download. Treat count as signal and you do not merely overcount; you fabricate operator clusters that never existed and then attribute activity to them. Mis-ranking becomes mis-attribution. The degenerate hashes are not the rounding error at the bottom of the analysis — left in, they are the loudest thing in it.

6. The Counter-Narrative

Steelman. "You have discovered that honeypots capture junk. Everyone knows honeypots capture junk. Stripping empty files is table stakes, not a finding — and you've buried a perfectly good real-malware inventory under a lecture about newlines."

Fair pressure, and the finding holds against it:

• "Everyone knows." Then everyone should stop publishing count-ranked malware tables — and they don't. The proof that this is not table stakes is 052A's own thirty-fold correction: the graph shipped with the junk in it and had to be walked back. "Everyone knows" and "everyone filters" are different claims; the second is the one that is false, and this letter is the worked example of why it matters.
• "It's just hygiene." Hygiene that changes a 2,089-link graph to 68 is not hygiene; it is the analysis. When the cleaning step moves the headline number by 30x, the cleaning step is the result. Naming the exact degenerate hashes — this newline, this empty string, this dd spew wearing a tool name — is what makes the correction reproducible instead of a hand-wave.
• "You buried the real inventory." It's here, ranked correctly by severity, and it gets its own letter. The point is not that the real malware is uninteresting; it is that you cannot find it by the metric the table invites you to use. The real inventory is the reward for filtering, not an alternative to it.

What is not claimed: that the honeypot's capture is broken (it correctly retains everything a session writes — that is its job); that the auto-classifier is useless (it is right about XMRig and the worm); that the mdrfckr key is unimportant (it is a top-tier IOC — just not a binary). The claim is narrow and provable: rank the drop corpus by count and the head of the list is artefacts and a key, not malware.

Confidence: HIGH that the top count-ranked "payloads" are an SSH key, a newline, and an empty file (byte-verified), that a dd-output artefact was misclassified as a tool, and that the real malware ranks low by count; MEDIUM on the downstream claim that count-based ranking fabricates operator clusters at scale (strongly supported by 052A's 30x correction, but that is one graph's history).

7. Defence Response

• Rank drops by severity and file type, never by count. The only honest first sort of a dropped-sample corpus is file_type + content classification + severity. Download count answers "what got written most," which for a honeypot is dominated by keys, echoes, and failed transfers.
• Filter the degenerate hashes explicitly, by value. Maintain a denylist of known trivial hashes — SHA-256 of "", "\n", "test", common dd/echo outputs — and drop them before any graph or cluster is built. They are identifiable to the byte; there is no excuse for letting them into an attribution graph.
• Trust auto-labels only after reading the bytes. The classifier scored a hundred-machine backdoor key severity 0 and named dd spew a "utility." On the highest-value rows, check the retained content by hand — the label is a hint, not a verdict.
• Keep the mdrfckr key as an IOC, not a payload. A shared authorized_keys entry across 100 IPs is a first-class operator link — mine it for attribution — but count it as persistence, not as a downloaded binary, or it will distort every payload metric it touches.

8. A Note on Method

Built through the honeypot MCP tools — honeypot_downloads_intelligence for the corpus and its count-ranked table, honeypot_sample_analysis to pull the retained bytes, file types, and strings of each top hash — plus local SHA-256 recomputation to prove the degenerate hashes are the empty string, a newline, and "test." No SQL touched the investigation. The retained samples are the evidence; the whole letter is a demonstration that reading them is not optional.

9. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence