The Named Trap: Attackers Who Check for the Honeypot by Name

Do You Know You're a Honeypot? — Part 1

Classification: MEDIUM · Confidence: HIGH (first-party command capture)

Every letter until now has been the sensor reading the attackers — their keys, their loaders, their reconnaissance, their infrastructure. This series inverts the lens. It is about the attackers reading the sensor — the ones who, having won a shell, stop before doing anything with it to ask a single wary question: is this a real machine, or a trap? A meaningful and apparently growing fraction of the operators who reach a shell do ask, and the honeypot recorded them asking. This first letter is about the simplest way they check: not by clever inference, but by name. They arrive with a list of the known honeypot software, and they look for it, directly, by the artifacts it is known to leave.

A note on discipline, up front, because this series is unavoidably about the sensor that captured it. These letters describe what attackers look for — the general, widely-documented techniques for unmasking SSH honeypots — but they deliberately do not describe what those checks found here, nor the sensor's own configuration. Disclosing which artifacts a given sensor carries is precisely the information an attacker's roll-call is built to gather, and there is no reason to hand it over. The subject is the attackers' checklist, not the answer key.

The roll-call

The clearest specimen is a structured, multi-step probe that reads like an inspection checklist, because that is what it is:

echo '===HONEYPOT_CHECK_START===' && grep '^phil:' /etc/passwd && echo HONEYPOT_USER_PHIL;
echo '===STEP2==='; ps waux | grep -E 'jabberd|ejabberd|cowrie|kippo|dionaea|honeytrap|opencanary|artillery|glutton|heralding' || echo 'NO_HONEYPOT_PROCESSES';
echo '===STEP3==='; ls -d /etc/cowrie /opt/cowrie /home/cowrie /etc/kippo /opt/kippo /opt/dionaea /opt/honeytrap /opt/opencanary

There is nothing subtle here, and the lack of subtlety is the point. The operator is not deducing that the environment might be instrumented from some behavioral tell. It is running a literal roll-call of the honeypot ecosystem — checking for a specific default user, for the running processes of ten named honeypot projects, and for their install directories on disk. This is the exact technique the honeypot itself uses against malware, run in the opposite direction: signature detection by known artifact. The sensor identifies a sample by its build hash or its family strings; the attacker identifies the sensor by its default user and its install paths. Both sides carry the other's indicators of compromise, and this command is the attacker's IOC list for the defender.

phil, the honeypot's most famous fingerprint

The single most telling item is the very first: grep '^phil:' /etc/passwd. The name phil is not random, and an operator grepping for exactly that string is not guessing. It is one of the best-known artifacts in the honeypot world — the kind of default that ships inside a popular SSH honeypot's canned fake filesystem, a leftover user account that exists in the honeypot's imitation of a real machine and, historically, in very few real machines. To an attacker, phil in /etc/passwd is a near-signature: find that specific default account and you have strong reason to believe you are standing inside a well-known honeypot's default image rather than on someone's actual server.

The attacker's logic is exactly the logic of a malware signature. A default artifact that a tool ships unchanged, that appears across many deployments because most operators never bother to alter the defaults, becomes a reliable tell — for the same reason the mdrfckr key's fixed comment or the toolkit's fixed build hash became reliable tells for the sensor. The honeypot ecosystem, like the malware ecosystem, is full of operators who deploy the defaults, and defaults are what signatures are made of. That an attacker greps for phil means the attacker has read the honeypot's source the way the honeypot reads the attacker's binaries: looking for the constant that the lazy majority never changes.

The mirror is worth sitting with. This entire investigation has counted operators by the durable artifacts they could not help leaving — the build hash, the runtime marker, the fixed key. The phil grep is an attacker applying the identical method to us: looking for the durable artifact a honeypot cannot help leaving if its operator ran the defaults. The technique that unmasks the attacker is the technique the attacker uses to unmask the trap. Neither side invented it; both sides run it.

Why a decade-old default is still the best tell

The phil artifact is worth one more moment, because its persistence is the same phenomenon this investigation kept finding on the attacker's side, now on the defender's. The account is old — it descends from the fake filesystem of an early SSH honeypot, inherited forward as the project it seeded was succeeded by newer tools that carried the default image along rather than rebuild it. It has been a documented honeypot tell for years. And it still works as a signature for exactly the reason a years-old malware IOC still works: the population that would have to change it mostly does not.

Most people who stand up a honeypot deploy it the way most people deploy anything — with the defaults. Changing the canned filesystem, renaming the leftover accounts, and scrubbing the install-path tells is optional work that a hurried or inexpert operator skips, so the default artifact survives across the majority of deployments and remains a reliable fingerprint years after it was first published as one. This is precisely the dynamic the Outlaw-key letter described from the other direction: a decade-old, universally-documented indicator that never stopped working because the target population regenerates faster than it hardens. The mdrfckr key still lands because unpatched SSH endpoints keep appearing; the phil default still betrays honeypots because default-configured honeypots keep appearing. Known indicators do not die on either side of the wire. They age into reliable background signal, and the wary operator on each side keeps checking for the other's, because the lazy majority on each side keeps shipping it.

A map of the whole zoo

The second and third steps widen from one artifact to an inventory of the ecosystem. The process grep names ten honeypot projects, and each name is a real, specific tool with a real, specific purpose: Cowrie (the dominant medium-interaction SSH/Telnet honeypot, successor to Kippo); Dionaea (a malware-capture honeypot that emulates vulnerable services); OpenCanary (a lightweight network canary); Honeytrap (a generic low-interaction trap); Glutton (an all-protocol honeypot); Heralding (a credential-capturing honeypot); Artillery (a threat-intelligence and honeypot tool). The ejabberd/jabberd entries reach even for honeypots posing as XMPP servers. This is not a guess at one product; it is a survey of the field, held by someone who knows the field.

An operator who carries the names of ten honeypot projects and their install directories in a single canned command has studied the defensive side of their own trade. They know that a compromised shell might be any of these traps, and they know each one's on-disk footprint well enough to check for it in a single ls. This is the attacker as connoisseur of the defender's tools — the exact counterpart of a defender who can name and fingerprint ten malware families. The honeypot spent this whole investigation building an atlas of the attacker ecosystem; the roll-call shows the attacker arrived already holding an atlas of the honeypot ecosystem. The map is mutual.

And a companion probe checks the same idea from the disk side rather than the process side — ls /opt/cowrie /etc/cowrie /var/log/cowrie /home/cowrie 2>/dev/null && echo FOUND || echo ABSENT — reducing the whole question to a single binary verdict, FOUND or ABSENT, for an automated caller to read. The operator does not even want the directory listing. It wants one bit: is the trap here or not.

The services in the line-up

Two names in the roll-call are not honeypot projects at all — ejabberd and jabberd, real XMPP chat servers — and their presence in a honeypot-detection grep is a subtle tell about how these operators reason. A companion probe pairs the same idea with SSH: grep '^phil:' /etc/passwd … ps w | grep ejabberd … sshd -V. The operator is not only asking is a honeypot process running? but are the services here what they claim to be?

The logic is that a trap often has to impersonate a service to be interesting — to look like a mail server, a chat server, a jump host worth taking. So the checker looks for the seams of the impersonation: a process that should be present if the service is real, a daemon version string that a genuine installation would return. A machine advertising a service it cannot actually prove it runs is as suspicious to a wary attacker as a machine carrying a honeypot's default user. The roll-call, then, is not purely a search for honeypot software; it is also a search for the gaps between what a machine appears to be and what it can demonstrate it is — the first, coarse version of the behavioral tests the next letter is entirely about. Even at the crude signature tier, the smarter operators are already reaching past "is it named cowrie?" toward "does it hold together as a real system?" — which is the question the rest of this series follows them into.

The check is productized

That FOUND/ABSENT reduction, and the ===HONEYPOT_CHECK_START=== / ===STEP2=== / ===STEP3=== delimiters wrapping the roll-call, are the same tell the key-harvest letter identified in a different context: structured markers exist so that code, not a human, can parse the result. No person scrolling a terminal needs ===STEP2=== banners to find the output of a ps | grep. The banners are there because an automated post-exploitation routine runs the roll-call, splits the output on the markers, and decides — on the FOUND/ABSENT verdict — whether to proceed. Honeypot detection here is not a cautious human's improvisation. It is a productized first stage of an automated kit, a gate the payload passes through before it is ever fetched.

That productization is the most consequential fact in this letter, because it means honeypot-awareness has scaled. A wary human checking by hand is a rarity that a sensor might never see; a canned detection stage baked into a widely-distributed kit runs on every shell the kit touches, automatically, forever. The roll-call appearing with machine-parseable delimiters says that some fraction of the automated attack economy now gates on am I in a trap? as a standard opening move — the same way it gates on what architecture is this? The question has become infrastructure.

The first rung of a ladder

The roll-call is the cheapest of the honeypot-detection techniques, and reading it as the first rung of a ladder frames the rest of this series. Signature detection — is the machine named like a honeypot? — costs one grep and one ls. It is fast, it runs first, and it is also the easiest for a defender to defeat: rename the account, move the directory, and every check in the roll-call comes back ABSENT, learning nothing. A detection technique that a single rename defeats is a weak one, and the operators who rely only on it are the least of the threat.

But the roll-call is not where the sophisticated checking stops; it is where it starts. An artifact check asks whether the trap left its name lying around. The harder questions ask whether the environment behaves like a real system and whether it is a real, valuable machine — and those cannot be answered away by renaming a file, because they probe properties a honeypot has to actually possess rather than merely hide. Can this shell do arithmetic? Do its error messages match a real one's exactly? Is there real hardware under it, or a hypervisor's fingerprint? Are there real secrets on disk, or a suspiciously empty room? Each rung up the ladder is more expensive for the attacker to run and far more expensive for the defender to fake, and the operators who climb it are the ones whose payloads a sensor most wants to see and is least likely to. This letter is the bottom rung: the crude, cheap, easily-defeated name check. The letters that follow climb toward the tests that a honeypot cannot pass by changing a default — the ones where the trap has to be genuinely convincing, not merely anonymous.

What the honeypot sees is filtered by the question

There is a selection effect here that shapes everything the sensor records, and it must be stated plainly. A signature check like the phil grep is cheap and it runs first — before the payload, before the real behavior. If an operator's kit runs the roll-call, gets a positive verdict, and bails, then the sensor sees the roll-call and nothing after it: no payload, no C2, no real intent. The most honeypot-aware operators — precisely the most sophisticated ones, the ones worth studying most — are the ones most likely to check first and reveal least.

This means the corpus is filtered by its own nature as a trap. Everything the earlier letters catalogued in full — the toolkits, the loaders, the key operations — was, by definition, deposited by operators who either did not check or checked and proceeded. The operators who checked and left are represented in the record only by their check. The honeypot sees the full behavior of the incautious and only the opening question of the cautious, and that bias runs in the direction of making the observed population look less sophisticated than the true one. The roll-call is not only an artifact to study; it is a warning about what the study cannot see.

The checklist is a gift

The redeeming symmetry — and the theme this whole series will return to — is that the attacker's roll-call is, read from the defender's chair, a free hardening checklist. Every artifact the operators grep for is an artifact a honeypot operator can remove, rename, or hide, and each removal blinds one more of these checks. The attackers have, in effect, published the list of tells worth eliminating, and they republish it every time they run the check.

This is the productive way to read an adversary's detection routine: not as a threat to the sensor but as the sensor's own to-do list, compiled by the people most motivated to make it complete. A defender who watches what attackers check for learns exactly which defaults betray them, in priority order, weighted by how many attackers bother to look. The roll-call that was built to unmask the honeypot is, handed back, the most authoritative guide available to hardening it — and the honeypot that reads its own attempted unmaskings is a honeypot that improves itself from the evidence of every operator who tried to see through it. The named trap is only named until its operator changes the names.

Bounds and limits

DOCUMENTED, first-party: the structured honeypot-detection probes — the grep '^phil:' /etc/passwd check, the ten-project process grep (cowrie|kippo|dionaea|honeytrap|opencanary|artillery|glutton|heralding|ejabberd|jabberd), the install-directory ls checks against those projects' known paths, and the FOUND/ABSENT and ===HONEYPOT_CHECK_START=== machine-parseable framing — captured in the command log, clustering in mid-2026.

INFERRED, high confidence: that these are deliberate honeypot-detection routines (the specificity of grepping exactly ^phil: and of naming the exact install paths of exactly the known honeypot projects is not a coincidence of general reconnaissance); that the delimiter framing indicates automated, productized checks run by post-exploitation kits rather than by hand.

BOUNDED — deliberately: this letter does not state what any of these checks returned on the capturing sensor, nor describe that sensor's configuration, because that is exactly the information the roll-call is designed to extract and there is no reason to publish it. The selection effect is real but its magnitude is unquantifiable from inside the trap — the sensor cannot count the operators who checked elsewhere and never arrived, only the ones who checked here. And "they have read the honeypot's source" is an inference from the precision of the artifacts named, not a claim about any specific operator's knowledge; some may simply carry a checklist someone else compiled, which is itself the productization the letter describes.

None of these bounds change the finding. A portion of the attack economy now opens a compromised shell by asking whether the shell is a trap, and the first way it asks is the crudest and the most telling: it looks for the honeypot by name, greps for the famous default user, surveys the disk for the known install paths, names the whole zoo of defensive tools in one canned command, and reduces the answer to a single bit for a machine to read. The sensor built to fingerprint attackers recorded attackers fingerprinting the sensor — with the sensor's own method, turned around. The next letter turns from what the trap is called to how it behaves, where the checks get harder to defeat and the arithmetic of a shell becomes a test of whether it is real.

This opens Do You Know You're a Honeypot? — a series on the attackers who check whether they are being watched. Part One found them checking by name, with the defender's own signature method. Part Two turns to the behavioral tests — the arithmetic a real shell can do and a fake one cannot — that no amount of renaming a default user will defeat.