Follow the Operator · 01 — The Reused Key: One Key, One Hundred Faces

Follow the Operator — Case 01. 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 previous register, Follow the Access, ended on a promise it did not keep, and this register exists to keep it. Across twenty-six cases it insisted that behind the indifferent, automated, seemingly infinite swarm stand real, specific, countable operators — that the graph is where the swarm stops being weather and becomes people again. But it never named one. It followed the intrusion to the foothold's fate and stopped at the edge of attribution, because attribution is a different discipline: not what happened to the machine, but who did it. This register is that discipline. It starts where the last one deferred — at the question of identity — and it starts with the single hardest thing about attributing anything on the internet: that the attacker controls almost everything you would use to identify him.

Consider what the honeypot sees when this case's operator arrives. It does not see one attacker. It sees 124 of them — 124 distinct IP addresses, scattered across 56 different autonomous systems, originating in 15 countries: the United States, the Netherlands, Germany, Romania, Ukraine, Singapore, France, and more. By every surface attribute the honeypot could use to sort its attackers, these are 124 unrelated hosts, a small crowd of independent adversaries who happen to have visited the same sensor. That is exactly what the operator wants the honeypot to see. He has changed every attribute he controls — the address, the network, the hosting provider, the country — precisely so that his one operation looks like a scattered many, because the analyst who counts 124 attackers is an analyst who has not found him.

But there is one thing the operator did not change, and this case is about that one thing. Every one of those 124 hosts, at the moment it tries to authenticate, offers the same SSH key. Not a similar key; the identical key — the same public key fingerprint, presented from Bucharest and Singapore and Ohio alike, the same credential the operator reused across his entire fleet because managing 124 machines with 124 different keys is harder than managing them with one. The key is the thing he could not afford to vary. And so the key is the thread: the one invariant that survives every transformation of address and geography, the handle by which the scattered 124 collapse back into the single hand that holds them. Linkage signal: SHARED KEY. This is the register's first and most fundamental lesson — that attribution is the search for what the operator could not change — and the reused key is the purest example of it.

1. The Attributes the Operator Controls

Begin with why the obvious identifiers fail, because understanding that is understanding the whole problem. When a defender thinks "who attacked me," the first fact they reach for is the IP address — it is what the logs record, what the firewall blocks, what the abuse report names. But the IP address is the single least reliable identifier of an operator, for a reason this case makes vivid: it is the attribute the operator controls most completely and changes most freely. IP addresses are cheap, rented by the hour, discarded and replaced without cost. An operator who wants 124 addresses buys 124 addresses; when they are blocklisted he buys 124 more. The address identifies the machine that sent the packet, which is exactly what the operator wants you to focus on, because the machine is disposable and the operator is not the machine.

The same is true, one level up, of the network and the country. The 56 ASNs the fleet spans are 56 hosting providers and networks the operator rented space in — DigitalOcean, OVH, a dozen bulletproof and semi-bulletproof hosts, cloud tenancies, compromised boxes. Spreading across 56 of them is a deliberate act: it defeats attribution-by-network (no single provider sees more than a fraction of the operation), it defeats blocklisting (banning one ASN stops one-fifty-sixth of the fleet), and it manufactures the appearance of geographic diversity that makes the cloud look like an international crowd rather than one actor. The 15 countries are not 15 groups of attackers; they are 15 flags of convenience, chosen for cheap hosting and lax abuse handling, worn and discarded as freely as the addresses. Country-of-origin, the attribute that drives so much lazy attribution, is here pure misdirection — the operator is "in" 15 countries in exactly the sense that he is in none of them.

This is the scattered operator's entire strategy, and it is a good one: maximize the variance of everything the analyst can see, so that no visible attribute correlates with any other, and the operation dissolves into noise. If attribution depended only on the visible attributes, it would work perfectly — 124 uncorrelated hosts are indistinguishable from 124 separate attackers, and the operator would be 124 ghosts. The reason it does not work, the reason this operator is one entry in the honeypot's cluster list rather than 124, is that the strategy has a cost the operator was not willing to pay. Making everything visible vary is easy for the attributes that are external to the operation — addresses, networks, flags. It is much harder for the attributes the operation actually runs on, because those the operator has to reuse to function. And that is where the thread is.

2. The One Thing He Could Not Vary

Now the key itself, and why it, alone among the operator's attributes, stayed constant. To operate a fleet of 124 machines — to log into them, deploy to them, coordinate them, collect from them — the operator needs a credential, and the natural credential for machines is an SSH key. He could, in principle, generate a unique key for every one of the 124 hosts, and if he did, the reused-key thread would not exist. But a unique key per host is a real operational burden: 124 private keys to store, track, match to the right host, rotate, and never confuse — an inventory problem that scales with the fleet and that buys him nothing he can see. So, like almost every operator running a fleet, he did the convenient thing: one key, reused everywhere. One credential to hold, one to deploy, one to remember. The convenience is enormous and the cost is invisible to him — until the honeypot reads it.

And the honeypot does read it, because of a specific property of the SSH protocol that this case turns on. In SSH public-key authentication, the client does not wait to be asked; it offers its public key to the server, along with a signature proving it holds the matching private key, as part of the authentication attempt — and it does this before the server has decided whether to accept the connection. The honeypot, sitting where the server sits, sees the offered public key from every connection that attempts key authentication, whether or not that authentication would have succeeded. So the key fingerprint is not something the honeypot had to extract by trickery or infer from side channels; it is volunteered, by the client, on every one of the 124 connections, as a routine part of the protocol. The operator's fleet announces its shared identity at every login, because the protocol requires the announcement and the operator reused the identity being announced.

This is the invariant, and it is worth naming precisely what kind of invariant it is, because it is the conceptual heart not just of this case but of the whole register. The operator applied a transformation to his operation — he varied the address, the network, the country, scattering the visible surface across 124 points — and the key is the quantity that transformation left unchanged. In the language of the geometry that underlies this kind of analysis, the key is the invariant of the operator's transformation group: whatever he does to disguise the operation, moving it from address to address and flag to flag, the key is preserved, because preserving it is what lets the operation keep functioning. Attribution, in this frame, is not the search for the operator's location or identity in any surface sense — those he controls — but the search for the invariant: the quantity that his disguise cannot alter without ceasing to be a disguise of the same operation. The reused key is the cleanest invariant there is, because it is both perfectly constant and perfectly observed, and that is why this case opens the register.

3. Reading the Cloud Back to the Hand

Now the attribution itself — how the honeypot turns 124 observations of one key into one operator — because the mechanism matters and its limits matter more. The honeypot records, for each connection, the offered key fingerprint alongside the source IP, the ASN, the country, the timing, the credentials tried, and the commands run. Most connections offer no reused key, or a key seen only once; those tell the linker nothing about shared identity. But when the same key fingerprint appears from a second IP, and a third, and eventually 124, the linker draws an edge between them: these hosts share a credential, and sharing a credential is evidence of sharing an operator. Accumulate the edges and the 124 IPs, uncorrelated by every surface attribute, form a single connected component in the graph — a cluster, tagged actor-c0fefc598e16, that the linker reports as one operator. The scattered cloud has been read back to the hand.

But a shared key alone is a claim to be tested, not a conclusion to be trusted, and the register will be disciplined about this from its first case, because over-attribution is the cardinal sin of the whole enterprise. A shared key is strong evidence of a shared operator, but it is not proof, for a reason that gets its own case later in this series: a private key can leak or be stolen, and a leaked key can appear under two genuinely different hands — the operator who generated it and the thief who took it. So the linker does not rest on the key alone. For this cluster, it checks whether the other attributes corroborate: do the 124 IPs share more than the key? They do. They share a coordinated activity window — 2,466 hits concentrated between the 21st of May and the 16th of June 2026, not scattered randomly across a year but pulsing together as a single operation. They share a consistent threat profile — an average score of 74.5, high and stable across the fleet, the signature of one method rather than 124 independent skill levels. The key drew the edges; the timing and the profile confirm they belong to one operation rather than a leaked key wandering between several. That convergence is what lifts the attribution to HIGH confidence, and the register states it as HIGH and not ABSOLUTE, because the difference between those two words is the difference between forensics and assertion.

The discipline here generalizes into the register's method, so it is worth making explicit. Attribution proceeds by finding an invariant (the key), drawing the links it implies (the 124-IP cluster), and then testing whether independent signals corroborate the link (the timing, the profile) or contradict it (which, for this cluster, they do not). A single invariant is a hypothesis; corroboration by independent invariants is a case. This is the same evidentiary structure the dossiers have always used — direct evidence plus multi-source corroboration equals HIGH confidence — applied now to identity rather than to events. The reused key is the strongest single invariant the register will meet, which is why HIGH confidence is available here on nearly the key alone; later cases will work with weaker invariants and will have to be correspondingly more cautious, and some will honestly fail. But this one holds, because the operator gave the analyst the one thing he could not afford to vary, and then gave it 124 times.

4. SHARED KEY — The Self-Inflicted Handle

Now the linkage signal, and SHARED KEY earns its place as the register's opening disposition because it captures the deepest structural fact about attribution: that operators are caught not by what analysts extract but by what operators cannot help repeating. The key was not stolen from the operator or recovered by clever forensics. It was volunteered — offered freely at every login, by the operator's own software, because the operator chose to reuse it and the protocol chose to announce it. The handle by which he is attributed is a handle he attached to himself, and keeps attached, because detaching it — generating a fresh key per host — would cost him more in operational friction than being attributed costs him in a world where attribution rarely leads to consequences. SHARED KEY is the name of that trade: manageability purchased at the price of a durable identity, paid by nearly every operator who runs a fleet.

The trade is worth dwelling on because it explains why shared-key attribution works at all, against adversaries who are otherwise careful. The operator in this case is not incompetent; scattering across 56 ASNs and 15 countries is real tradecraft, more than most attackers bother with. He understood that the address betrays the machine and varied it aggressively. What he did not do — what almost no one does, because the cost is real and the benefit is invisible — is extend that discipline to the credential, because the credential is not something you think of as an identifier. It is a thing you use to log in, a convenience, and reusing a convenience feels like efficiency, not exposure. The whole of shared-key attribution lives in this blind spot: the operator hides what he knows is visible (the address) and reuses what he does not think of as visible (the key), and the analyst attributes him on exactly the attribute he was not defending. The honeypot's 284 reused keys, each spanning multiple IPs, are 284 instances of this same blind spot — 284 operators who varied their addresses and reused their keys, each leaving the self-inflicted handle that makes attribution possible.

And this is why the register opens here rather than with a more sophisticated thread. The reused key is the base case of attribution: the invariant the operator did not know to hide, observed directly by the protocol, corroborated by timing and behavior, yielding a single operator at HIGH confidence from a cloud that was engineered to look like 124. Everything the register does afterward is a variation on this move — find the invariant, draw the links, test the corroboration, bound the confidence — against invariants that are progressively harder to read and operators who are progressively more careful. But the shape is set here. The operator controls the address and loses on the key, because the address is what he defends and the key is what he uses, and attribution lives in the gap between the two. He wore 124 faces. He kept one key. The key is the case.

5. Defending Against Your Own Key (and Attributing With It)

This register owes two things at once — a word to the defender who wants to avoid being the attributable operator's next victim, and a word to the analyst who wants to attribute — because the reused key cuts both ways, and the honest treatment gives both. For the defender, the operational lesson is a mirror of the operator's mistake: your own reused keys are your own attribution handle, and the same convenience that betrays the attacker betrays you. An organization that deploys one SSH key across its fleet, or one that lets a key sprawl uncontrolled across servers and laptops and CI systems, has built exactly the invariant this case exploits — a single credential whose compromise unlocks everything and whose reuse ties all of it together. The defensive measures are the operator's discipline turned to good use: unique keys per host or per purpose, short-lived certificates instead of long-lived keys where possible, tight inventory of which key authorizes what, and prompt rotation. The point is not only that key reuse is a compromise risk (it is), but that it is an identity leak, and both the attacker and the defender are safer when a credential identifies exactly one thing.

For the analyst, the lesson is method, and it is the method the whole register will run on: attribute on the invariant, not the surface. The temptation, always, is to attribute on what is loudest — the IP that sent the packet, the country it geolocates to, the ASN that hosts it — because those are what the logs foreground and what a report demands. This case is the standing warning against that temptation, because those are precisely the attributes the competent operator controls and varies to defeat you. The analyst's job is to look past them to the quantity the operator could not vary without breaking his operation, and to build the attribution on that. The reused key is the easiest such quantity to find and read, which is why it is first; but the discipline — ignore the disguise, find the invariant — is the same for every case that follows, whether the invariant is a key, a malware build, a tool fingerprint, a piece of shared infrastructure, or a behavioral tic. Attribution is the refusal to be misdirected by the attributes the adversary chose to show you.

The honest complication, which the register states here and will keep stating, is that the invariant can lie, and the analyst who forgets that becomes the mirror-image of the lazy attributor — confident on a thread that does not hold. A key can be shared not because two hosts share an operator but because two operators share a leaked key; a tool fingerprint can be shared because two unrelated actors use the same off-the-shelf tool; infrastructure can be shared because two tenants rent from the same provider. Every invariant this register uses has a failure mode in which the invariant is real but the shared-operator inference is false, and the discipline of attribution is not just finding the invariant but testing it against the failure mode before believing it. For this case the failure mode — the leaked key — was tested and did not apply, because the timing and behavior converge on one operation; the register assigns HIGH, not ABSOLUTE. That reservation is not weakness. It is the thing that separates an attribution register from an accusation, and it is why the reader can trust the cases that say HIGH: because the register is willing, when the thread breaks, to say so — as several later cases will.

6. The counter-narrative, steelmanned

The strongest objection to this case is that a shared SSH key proves far less than the register claims — that keys are shared for many innocent reasons, that a honeypot cannot distinguish an operator's reused key from a leaked or default one, and that collapsing 124 IPs into "one operator" on the strength of a shared credential is exactly the over-attribution the register claims to guard against.

The argument runs like this. SSH keys, the objection notes, are shared all the time without a shared operator behind them: a key leaks and is scavenged by many unrelated actors; a compromised host's key is harvested and reused by whoever found it; automated toolkits ship with embedded keys that everyone who runs the toolkit then presents; a key posted in a paste or a breach becomes common property. In any of these cases, 124 IPs offering the same key would be not one operator but many, unrelated, sharing only a credential that fell off a truck. And a honeypot, the objection continues, is especially ill-placed to tell the difference: it sees the offered key but not the operator, so it cannot know whether the shared key means shared control or shared scavenging. Attributing the 124 to a single hand, on this view, is precisely the invariant-can-lie failure the register itself describes — and dressing it in the language of affine invariants does not make the inference sound.

The register accepts the mechanism entirely and shows why, for this cluster, the inference survives it. Yes — a shared key can mean shared scavenging rather than shared control, and the register does not merely concede this but has built an entire later case around it (the leaked-key coincidence), precisely because it is the central failure mode of shared-key attribution. The objection is not a hole in the register; it is a principle the register operates by. The question is whether this cluster is a case of scavenging or of control, and that is exactly what the corroboration test is for. A leaked or scavenged key, presented by unrelated actors, produces a characteristic signature: the actors differ in everything but the key — different tools, different targets, different behaviors, different and uncoordinated timing, because they are genuinely different operators who happen to hold the same credential. This cluster does not look like that. Its 124 IPs share not only the key but a tight, coordinated activity window (2,466 hits pulsing together across a single month), a consistent method and threat profile, and — in the fuller graph — shared behavioral and tooling signals beyond the key alone. Scavengers of a leaked key do not coordinate their timing or converge on one method; one operator running a fleet does. So the register's claim is not "shared key, therefore one operator" — that inference it explicitly rejects — but "shared key, plus coordinated timing, plus consistent behavior, none of which the leaked-key hypothesis predicts, therefore one operator at HIGH confidence." The honeypot's inability to see the operator directly is real, which is why the attribution rests on convergent invariants rather than on the key alone, and why the confidence is HIGH rather than absolute. The objection describes the trap; the method is the way around it; and the register's willingness to fail this test in later cases is the evidence that, here, it passed.

7. Linkage Signal — SHARED KEY

Case 01 opened the register on the reused SSH key, the base case of attribution. A single operator — cluster actor-c0fefc598e16 — stands behind 124 honeypot IPs scattered across 56 ASNs and 15 countries, a cloud engineered to look like scores of unrelated attackers. Every surface attribute is varied: the address, the network, the hosting provider, the country, all cheap and disposable and changed freely, because those are the attributes the operator controls. But one attribute stayed constant, because the operation could not run without it — the SSH key, reused across all 124 hosts and offered, by the protocol, at every login. The key is the invariant beneath the disguise: the quantity the operator's transformation of address and geography left unchanged, because preserving it is what let the fleet keep functioning.

The linkage signal — the thread that clinched the attribution — is SHARED KEY, at HIGH confidence. The honeypot reads the offered key from every connection, draws an edge between every pair of IPs that share it, and finds the 124 collapsing into one connected component. The key alone would be a hypothesis; the register tests it against the leaked-key failure mode and finds corroboration the failure mode does not predict — a coordinated activity window (2,466 hits, 21 May to 16 June 2026), a consistent high threat profile, shared behavior beyond the credential — so the attribution is one operator, not many scavengers, at HIGH and not ABSOLUTE. That reservation is the register's method in miniature: attribute on the invariant, draw the links, test against the failure mode, bound the confidence honestly.

The lesson cuts both ways. For the defender, your own reused keys are your own attribution handle and your own single point of compromise; unique keys, short-lived certificates, and tight inventory turn the operator's mistake into your discipline. For the analyst, attribute on what the operator could not change — not the address he varies to misdirect you, but the credential he reuses to function — and never trust the invariant until an independent invariant agrees. The operator wore 124 faces and kept one key, and the key was the case, because the whole of attribution lives in the gap between what an adversary defends and what he cannot help repeating. The vectors do not lie, and neither does the key: 124 addresses said "we are strangers," and one key said "we are the same hand." We do not judge. We record. We let people judge — and we begin, here, by showing that the crowd was always one, and the one was always holding a key he could not put down.

Follow the Operator — Case 01. Linkage signal: SHARED KEY. Confidence: HIGH — 124 honeypot IPs across 56 ASNs and 15 countries resolved to one operator (cluster actor-c0fefc598e16) by a shared SSH key offered at authentication, corroborated by a coordinated activity window (2,466 hits, 2026-05-21 to 06-16) and a consistent high threat profile that the leaked-key failure mode does not predict. The reused-key phenomenon is broad (284 keys each seen across multiple unrelated IPs in the honeypot), making it the base case of the register. Attribution is bounded honestly at HIGH, not absolute: a shared key can indicate a shared leaked credential rather than a shared operator, a failure mode treated as its own later case and tested-and-excluded here by convergent timing and behavior. The operator cluster is kept abstract; no real individual is named, 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 crowd that was one hand, and the key it could not put down.