Follow the Operator · 02 — The Planted Key: The Signature Left on the Victim

Follow the Operator — Case 02. This register takes a cloud of unrelated-looking attacks and follows one forensic thread back to the single hand behind them, closing each case on the signal that clinched it: SHARED KEY · SHARED MALWARE · SHARED FINGERPRINT · SHARED INFRASTRUCTURE · SHARED BEHAVIOR · NAMED IDENTITY.

The first case read a key the operator offered — the credential his own machines presented at the login, a key he held and reused across his fleet. This case reads a different key entirely: not one the operator offers, but one he leaves. When an intruder takes a machine and wants to keep it, he writes his own public key into the machine's list of trusted keys, so that from then on he can walk back in without a password, whenever he likes, for as long as the machine stands. That planted key is a backdoor, and it is also a signature — because the operator, planting it on victim after victim, reuses the same key, and so brands every machine he takes with the same mark. This case follows that mark, and it is a subtly different kind of attribution than the last: the first case identified the operator by the key on his own hands; this one identifies him by the key he left on the hands of others.

The honeypot sees this mark 81 times, on 81 hosts, scattered across 52 autonomous systems and 29 countries — from Brazil to Nigeria to Korea to Russia to Vietnam to the United States, one of the most geographically dispersed operations the sensor holds. By every surface attribute these are 81 unrelated compromises, spread across the whole world, sharing nothing. But they share the planted key. Each of the 81, at some point in its capture, had the same public key written into its authorized_keys — the same backdoor, the same operator's re-entry credential, left behind as the intruder moved on. The scatter is even wider than the last case's, because these are not the operator's rented machines but his victims, taken wherever he found them; and yet the single mark ties all 81 into one collection, one operator's inventory of backdoored hosts. Linkage signal: SHARED KEY — but read, this time, off the victim rather than off the attacker.

The distinction matters, and it is the reason this case sits second, immediately after the offered key, rather than being folded into it. An offered client key is a passive thing: the SSH protocol makes the client present it, whether the operator thinks about it or not, so the first case's key was a byproduct the operator leaked without acting. A planted authorized key is the opposite — a deliberate act the operator performs, by choice, on every host he decides to keep, writing the key with his own command. So this key is not a byproduct; it is an intention, captured. And reusing one such key across 81 victims is not a passive leak but an active branding: the operator chose, 81 times, to leave the same mark, because generating a fresh backdoor key per victim would be one more thing to manage. The convenience that betrayed him in Case 01 betrays him again here, at the far end of the intrusion — the same blind spot, moved from the login to the backdoor.

1. The Key He Leaves Behind

Begin with the mechanism, because the planted key is one of the oldest and most durable techniques in intrusion, and understanding it is understanding why it makes such a good signature. When an attacker compromises a Linux host and wants persistence — the ability to return after the initial access is closed, after the password is changed, after the machine reboots — one of the simplest and most reliable methods is to write his own SSH public key into the account's authorized_keys file. That file is SSH's list of keys permitted to log in without a password; any key in it is a standing invitation. Add your key, and you have a passwordless door that survives everything short of someone noticing the extra line and removing it. MITRE ATT&CK catalogues this as technique T1098.004, SSH authorized_keys manipulation, an account-manipulation form of persistence, because it is common enough and effective enough to warrant its own entry.

The honeypot captures the planting as it happens, which is what makes the key available as evidence rather than inference. The intruder does not plant the key by magic; he does it with a command — an echo of the public key appended to the file, a cat into it, a curl or wget that fetches the key onto disk and writes it in. The honeypot records the command, and in recording the command it records the key, exactly as the operator left it. So the planted key is not something reconstructed from side effects; it is captured in the act of planting, the operator's own backdoor credential written in his own session, preserved in the log. Where Case 01's key was volunteered by the protocol, this key is volunteered by the intruder himself, typing it onto the victim in front of the sensor that is recording him.

And here is the property that turns a persistence technique into an attribution signal: the operator reuses the key. He could generate a fresh backdoor key for every host he takes — it would cost nothing in effectiveness, and it would make each backdoor anonymous, unlinkable to the others. But that would mean managing a growing pile of private keys, one per victim, matched to the right host, never confused — the same inventory burden that drove the Case 01 operator to reuse his client key, now at the persistence stage. So he reuses. One backdoor key, planted on victim after victim, because one key is manageable and 81 keys are not. And the moment he reuses it, the key stops being merely a backdoor and becomes a brand: every host carrying it is a host he took, and the honeypot, seeing the same planted key on 81 hosts, reads them as one operator's collection. The persistence technique and the attribution signal are the same act — he brands his victims in the course of keeping them.

2. Attribution Through the Taken

Now the conceptual turn that distinguishes this case, because reading a key off the victim rather than off the attacker changes what the attribution is about. In Case 01, the shared key identified the operator's own machines — the fleet of hosts he controlled and launched from, tied together by the credential they all presented. The attribution was of the attacker's infrastructure: these 124 launching points are one hand's. This case attributes something different: not the operator's own machines, but the machines he took. The 81 hosts sharing the planted key are not the operator's launch points; they are his victims, the collection of boxes he compromised and backdoored, wherever in the world he found them. The shared key does not say "these 81 attacking machines are one operator's"; it says "these 81 compromised machines were taken by one operator." Attribution runs through the taken, not the taker.

This is a strictly more powerful thing to be able to say, and also a subtler one. It is more powerful because it maps an operator's reach — not where he launches from (which he varies for disguise) but what he has captured, the actual footprint of his operation across the internet. An operator's rented fleet is a rented convenience; his backdoored collection is his real estate, the machines he has taken and can return to, and the planted-key signal maps that estate directly. When the honeypot ties 81 hosts by a shared planted key, it is not counting the operator's disguises; it is counting his conquests, across 52 networks and 29 countries, which is a truer measure of the operation than any number of launch IPs. The mark on the victim reveals the extent of the victimization, and ties it to one hand.

It is subtler because the victims are, themselves, victims — and the register must hold that distinction carefully, exactly as the prior series did. The 81 backdoored hosts are not the operator; they are the operator's prey, machines belonging to other people, compromised and marked without their owners' knowledge. The shared key attributes the operator, not the hosts — it says one hand took all 81, not that the 81 are complicit in anything. This matters for how the attribution is used: the planted key identifies the perpetrator by the trail of his persistence, while the hosts that carry it are the injured, whose owners are owed the knowledge that their machine bears a stranger's backdoor. The register centers that, as it always has. The planted key is the operator's signature, and each host that carries it is both a clue to the operator and a victim to be warned — a machine that needs the extra line in its authorized_keys found and removed, a door quietly closed.

3. The Density of the Mark

Now the scale, because the planted key is not a boutique signal but a broad substrate, and its breadth is what makes it a workhorse of operator attribution. The honeypot's entity graph holds 3,240 shared_authorized_key edges — 3,240 links between hosts that were backdoored with the same planted key. That is a dense fabric: thousands of persistence keys, each planted across multiple victims, each edge a small piece of evidence that two backdoored hosts belong to one operator. The 81-host cluster of this case is one large, coherent knot in that fabric, but the fabric itself is vast, because planting a reused key for persistence is one of the most common things intruders do, and reusing the key is one of the most common ways they do it. Every reused persistence key is another operator brand, and 3,240 edges is a great many brands.

This density is why the planted key, like the offered key, is a base-tier attribution signal rather than an exotic one — it is available constantly, because the behavior that produces it is nearly universal among persistence-seeking intruders. An operator who takes machines and wants to keep them will, overwhelmingly, plant a key; an operator who plants keys at scale will, overwhelmingly, reuse one rather than manage many; and so the mark is there to be read on victim after victim, cluster after cluster. The 3,240 edges are the raw material from which planted-key operator attribution is built, and they exist because the technique is convenient in exactly the way that generates a signature: the convenience of one reusable backdoor is also the convenience of one traceable brand.

But density is also where the failure mode lives, and the register names it before trusting the signal, because a shared planted key has a specific way of lying. Some backdoor toolkits — mass-distributed persistence tools, worm payloads, botnet installers — ship with an embedded public key, and every unrelated operator who runs that toolkit plants the same embedded key on their own victims. In that case a shared planted key would tie together the victims of many different operators who happen to use the same off-the-shelf tool, not the victims of one operator — the attribution would be to the toolkit, not the hand. So the shared planted key, like every invariant in this register, must be tested against its failure mode: is this key a bespoke credential one operator reuses, or a toolkit's embedded default that everyone reuses? The test is corroboration, as always. This cluster's 81 hosts share not only the planted key but a coordinated timing and a consistent behavioral profile — the signature of one operation, not of a toolkit's diffuse, uncoordinated userbase planting the same default at random across the world. So the register attributes this cluster to one operator, at HIGH confidence, while holding that a shared planted key in general can also be a toolkit's mark, and that telling the two apart is exactly the analyst's job.

4. SHARED KEY — The Brand on the Collection

The linkage signal is SHARED KEY, as in Case 01, but the register distinguishes the two readings because they attribute different things by different routes, and the distinction is part of the method. Case 01's SHARED KEY was the offered client key — the credential on the operator's own machines, identifying his fleet, leaked passively by the protocol. This case's SHARED KEY is the planted authorized key — the credential on the operator's victims, identifying his collection, left deliberately by his own hand. Same signal name, because both are a shared cryptographic key tying scattered hosts to one operator; different mechanism, because one is offered and one is planted, one is on the taker and one is on the taken. The register uses the same word to mark that both are the strongest tier of invariant — a specific key is hard to share by coincidence — while noting that the planted key carries the extra weight of intention: the operator chose to leave it, 81 times.

That intention is what makes the planted key, in one respect, an even better signature than the offered one. An offered client key is a byproduct; a careful operator might, in principle, not realize the protocol announces it. But a planted key is an act the operator performs consciously, with a command, as a considered step of his operation — and reusing it is therefore a considered choice, made again on every victim. He knows he is planting a key; he simply does not think of the key as an identifier, because to him it is a backdoor, a tool for getting back in, not a brand. That is the blind spot, the same one as Case 01 in a new location: the operator defends what he knows is visible and reuses what he thinks of as functional, and the functional thing — the backdoor he needs to keep — is the identifier he did not know he was leaving. He brands his whole collection with one mark because the mark is useful to him and its cost is invisible to him, and the honeypot reads the brand.

And so the two key cases, taken together, bracket the intrusion. Case 01 caught the operator at the door he came in by — the offered key at the login. This case catches him at the door he built to come back through — the planted key in authorized_keys. Between them they show that an operator leaks his identity at both ends of the intrusion: entering, by the credential he presents; persisting, by the credential he leaves. The reused key is the operator's signature coming and going, and the register opens with both because they are the base tier of attribution — the invariants that are hardest to share by accident and easiest for the sensor to read — and because they establish the register's recurring truth from two angles at once: the operator is caught by the credentials he cannot help reusing, whether he is offering them or leaving them behind.

5. Reading the Backdoor, Closing the Door

The register owes the defender and the analyst, and the planted key gives both an unusually direct lesson, because it is the one attribution artifact that sits, literally, inside the defender's own machine. For the defender, the operational point is stark: the authorized_keys file is a persistence surface and an attribution surface at once, and both readings start with actually looking at it. An unexpected key in authorized_keys is a backdoor — a standing, passwordless invitation that some intruder left, that survives your password changes and your reboots, and that will let him back in until you find and remove it. Auditing authorized_keys — knowing exactly which keys should be there and treating any others as compromise — is the direct defense, and it is one defenders neglect precisely because the file is quiet and the extra line is easy to miss. Pin the file, monitor it for changes, disable key auth on accounts that do not need it, and the backdoor is closed.

The attribution reading is the same act seen from the other side, and it is available to any defender who finds a planted key: the key itself is a clue to who took the machine. If the same unexpected key appears in authorized_keys across several of your hosts, they were taken by one operator, and the key is that operator's brand — a fact that turns a scattered set of compromises into a single incident with a single perpetrator, which is exactly what an incident responder needs to know. Sharing that key as an indicator lets others check their own hosts for the same mark, mapping the operator's collection collaboratively. The defender who finds a planted key holds, without any special tooling, the same invariant this case is built on: a credential that ties every host carrying it to one hand. Reading it is not the honeypot's privilege; it is available in any authorized_keys file, to anyone who looks.

The honest bound, stated for the analyst, is the toolkit failure mode named above, and it generalizes into a discipline the register will lean on repeatedly: a shared artifact attributes a shared source only if the artifact is bespoke, not off-the-shelf. Before treating a shared planted key as one operator, ask whether the key could be a toolkit's embedded default — a key that many unrelated operators plant because they all run the same tool. Distinguishing bespoke from default is done by corroboration (do the hosts sharing the key also share timing and behavior, as one operation would, or are they diffuse and uncoordinated, as a toolkit's userbase would be?) and, where possible, by checking the key against known toolkit defaults. This cluster passed — coordinated, consistent, one operation — so the register attributes it at HIGH. But the discipline is the point: the planted key is a strong signature precisely when it is bespoke, and the analyst's job is to establish that it is before believing it, because a register that mistook a toolkit's default for an operator would be attributing a tool to a hand, and that is the failure this whole series is built to avoid.

6. The counter-narrative, steelmanned

The strongest objection to this case is that a planted authorized key is the weakest possible attribution artifact, not the strongest — because unlike a client key, which at least sits on the attacker's own machine, a planted key sits on victims, is trivially copied and shared, and is exactly the kind of thing that mass toolkits distribute by default, so tying 81 victims to "one operator" by a shared backdoor key is attribution built on the most shareable evidence imaginable.

The argument runs like this. A planted key, the objection notes, lives on compromised hosts that anyone can access — so once one operator plants a key, any other intruder who later compromises the same host sees that key, can copy it, and can plant it themselves elsewhere, deliberately or by scavenging. Backdoor keys, the objection continues, are traded and leaked exactly like any other credential; a good persistence key that works is worth copying, and the very fact that it grants access means many hands may come to hold it. And embedded toolkit keys make it worse: the most common reason a single key appears across scattered victims is not one operator but one tool, run by hundreds of unrelated operators, each planting the identical embedded default. On this view the shared planted key is the artifact most likely to be shared without a shared operator — the register has chosen, for its second case, the very signal most prone to the failure mode it claims to guard against.

The register concedes that the planted key is more shareable than the client key and argues that this is precisely why the case is built the way it is. Yes — a planted key sits on victims, can be scavenged by later intruders, can be traded, and can be a toolkit default; all four are real, and all four are versions of the one failure mode the case names explicitly, the toolkit/scavenging problem. The register does not wave these away; it builds the attribution to survive them. The defense is, again, corroboration, and it is decisive here for a specific reason: the alternative hypotheses all predict incoherence, and the cluster shows coherence. If the 81 hosts shared a scavenged key, the actors planting it would be many unrelated intruders with different tools, different behaviors, and uncoordinated timing — a diffuse mess, not an operation. If the key were a toolkit default, the same: hundreds of unrelated users, planting at random across a long span, with no shared behavior beyond the tool. What the honeypot actually sees in this cluster is the opposite — 81 hosts backdoored within a coordinated window, by consistent behavior, forming one coherent operation. That coherence is exactly what the scavenging and toolkit hypotheses cannot produce and a single operator can, which is why the register attributes this cluster to one hand despite the planted key's general shareability. The objection correctly identifies the planted key as the more dangerous signal; the register's answer is that a dangerous signal is safe to use only when corroboration excludes its failure modes, that here it does, and that the register's own later case on scavenged keys — where the corroboration does not hold and the attribution is refused — is the proof that this discipline is real and not decorative.

7. Linkage Signal — SHARED KEY

Case 02 read the key the operator leaves rather than the one he offers. A single operator — cluster actor-6f199858ed7e — stands behind 81 backdoored honeypot hosts across 52 ASNs and 29 countries, resolved by a shared authorized key: the same public key planted into each victim's authorized_keys for passwordless persistence, MITRE ATT&CK T1098.004, captured by the honeypot in the act of planting. Where Case 01's key was offered at the login — a passive byproduct of the protocol, on the attacker's own machines — this key is planted at the backdoor: a deliberate act, on the attacker's victims, reused across the collection because managing one backdoor key is convenient and managing 81 is not. The reused key brands every host the operator took, and the mark ties the collection to one hand.

The linkage signal — the thread that clinched the attribution — is SHARED KEY, at HIGH confidence, read this time through the taken rather than the taker. The honeypot captures the planting command and draws shared_authorized_key edges — 3,240 across the graph — that collapse the scattered victims into one operator's collection. The planted key is more shareable than the offered one (it can be scavenged from victims or shipped as a toolkit default), so the register tests it against those failure modes and finds them excluded: the 81 hosts share not only the key but a coordinated window and a consistent behavior, the coherence of one operation, which scavenging and toolkits cannot produce. HIGH, not absolute — because the register's later case on a genuinely scavenged key, where the coherence fails and the attribution is refused, is what keeps this HIGH honest.

For the defender, authorized_keys is a persistence surface and an attribution surface in one: an unexpected key is a backdoor to close and, if it recurs across your hosts, an operator's brand to read — the same invariant this case is built on, available in any machine to anyone who looks. For the analyst, a shared artifact attributes a shared source only when it is bespoke, not off-the-shelf, and establishing that is the job. The two key cases together bracket the intrusion: the operator leaks his identity coming in, by the key he offers, and going out, by the key he leaves — caught at both doors by the credential he could not help reusing. The vectors do not lie, and neither does the brand: 81 victims across 29 countries carried the same stranger's backdoor, and the backdoor said one hand had been in all of them. We do not judge. We record. We let people judge — and we show that the operator signed his work, on every machine he kept, in a key he thought was only a door.

Follow the Operator — Case 02. Linkage signal: SHARED KEY (planted authorized key). Confidence: HIGH — 81 backdoored honeypot hosts across 52 ASNs and 29 countries resolved to one operator (cluster actor-6f199858ed7e) by a shared authorized key planted for persistence (MITRE ATT&CK T1098.004), captured by the honeypot in the act of planting and corroborated by a coordinated activity window and consistent behavior. The planted-key substrate is broad (3,240 shared_authorized_key edges in the graph). Attribution is bounded honestly at HIGH, not absolute: a shared planted key can be scavenged from victims or shipped as a toolkit's embedded default, failure modes excluded here by the cluster's coherence and treated directly in the register's later scavenged-key case. The operator cluster and its victim hosts are kept abstract; no real individual is named, victims are centered as injured parties, and presumption of innocence is preserved. Classification: TLP:WHITE. Include everything — the vectors do not lie, and they do not judge. The reader judges the brand the operator left on every machine he kept, and the door he did not know was a name.