Follow the Operator · 17 — The Merge Problem: Two Campaigns, One Hand

Follow the Operator — Case 17. 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 graph case established that attribution is one evolving structure rather than a set of frozen verdicts, and this case and the next draw out the consequence: the graph is revisable in both directions, and revising it is not a failure but the method working. This case treats the first direction — the merge, the correction of under-clustering. It happens when two operator clusters, documented separately, each attributed to its own hand, turn out to be one hand after all, because a new edge appears that bridges them. Two campaigns the register had recorded as distinct operations, two dossiers filed apart, are revealed to be a single operator running both, and the register must merge them — combine the two clusters into one, supersede the two dossiers with one, and revise its own record to reflect the hand it had, until now, seen as two.

Under-clustering is a natural and common error, because an operator has good reasons to look like two operators. He runs different campaigns at different times, so the activity windows do not overlap and the temporal signal keeps them apart. He uses different tools for different targets — a scanner for one operation, a different toolkit for another — so the fingerprints diverge. He deliberately separates his operations for operational security, keeping his ransomware work and his cryptomining work on different infrastructure precisely so that a defender who catches one does not find the other. So the two operations present entirely different surfaces, form as two separate clusters in the graph, and get documented as two operators — which is the correct reading of the evidence available at the time, and wrong only in a way that later evidence reveals. The clusters were apart because the operator kept them apart, and the merge happens when he fails, once, to keep something apart.

The thing he fails to keep apart is a heavy edge — an unshareable invariant that appears in both operations, bridging the two clusters the way nothing else did. He used the same bespoke SSH key in both campaigns, because it was his key and he reused it as operators do; or he planted the same authorized key on victims in both; or both operations' payloads beaconed to the same bespoke C2. That one reused invariant is the bridge: it appears in cluster A and cluster B, drawing a heavy edge between two regions the graph had kept separate on all their divergent surface attributes. And because the edge is heavy — a bespoke key, near-unshareable — it is trusted to merge, where a thousand light edges (both used a common tool, both rented from the same big provider) would not be. The operator disguised his two operations perfectly in every cheap attribute and reused one expensive one, and the expensive one is the merge. Linkage signal: SHARED KEY — the bridging invariant that unifies the two.

1. Why One Operator Looks Like Two

Begin with the legitimacy of the under-clustering, because the merge is not correcting a sloppy error but a reasonable reading that new evidence overturns. When cluster A and cluster B first formed, the evidence genuinely supported two operators: they were active at different times, used different tools, hit different targets, ran from different infrastructure, and shared no observed heavy edge. An analyst attributing them as two hands was not being careless; he was reading the evidence correctly, and the evidence, at that moment, said two. The merge does not mean the original attribution was wrong given what was known; it means what was known was incomplete, and the completion — the later-observed bridging edge — revealed a unity the earlier evidence could not show. This is the ordinary condition of attribution: it is always provisional on the evidence gathered so far, and a merge is the arrival of evidence that was not there before.

The operator's reasons for the separation are worth cataloguing, because they explain why merges are common and where to expect them. Temporal separation: he runs campaign A in the spring and campaign B in the autumn, so their activity windows do not overlap and the timing signal, which would have coordinated them if simultaneous, instead keeps them apart. Tooling separation: he uses one toolkit for scanning and another for exploitation, or switches tools between operations, so the fingerprints diverge. Target separation: he hits IoT devices in one operation and enterprise servers in another, so the wordlists and behaviors differ. And deliberate compartmentalization: the sophisticated operator separates his lines of business on purpose — keeping his access-brokering and his ransomware on unlinked infrastructure — precisely so that catching one does not expose the other. Each of these produces two genuinely distinct-looking clusters from one hand, and the more disciplined the operator's compartmentalization, the more convincing the separation, and the more the merge, when it comes, reveals.

And this is why the merge is often the more valuable correction than it first appears, because it reveals scope. Two clusters, seen separately, are two medium operations; merged, they are one large operation, and the large operation is a truer and more consequential picture than either half. The merge shows that the operator the register thought ran one campaign actually runs several, that his estate is larger than any single cluster suggested, that his capabilities span the union of both clusters' tools and methods. The greatest value of a merge is frequently this revelation of true size: an operator who compartmentalized precisely to look small is revealed, by his one reused invariant, to be large, and the defender who thought he faced two modest threats learns he faces one significant one. The merge does not just correct a count; it corrects an assessment of scale, and scale is what determines how seriously an adversary must be taken.

2. The Discipline of Merging

Now the discipline, because the merge is dangerous in exactly the way the split-discipline warned about, and the register must be as careful merging as it is splitting. The danger is obvious once stated: merging is the operation that creates super-nodes, so an undisciplined merge — merging clusters on any shared edge — rebuilds the exact false mega-operator the graph case warned against. If the analyst merges cluster A and cluster B because they both used a common tool, or both rented from the same big cloud, he has bridged them on a light edge, and light edges do not warrant merges, because a shared commodity artifact ties a market and not a hand. Do that repeatedly and every cluster merges into one super-node, the graph collapses, and the "one giant operator" is pure noise. So the merge, powerful as it is, is precisely the operation that must be gated most strictly, because it is the operation that, misapplied, destroys the graph.

The gate is the same one that governs the whole graph: merge only on a heavy edge. A merge is warranted when the bridging invariant is unshareable — a bespoke key, a bespoke C2, a planted authorized key — the kind of edge that genuinely ties two regions to one hand because it could not be shared by coincidence or planted cheaply. A merge is never warranted on a light edge — a common tool, a public wordlist, a shared legitimate cloud — because those are shareable and bridge markets, not hands. This is exactly the edge-weighting of the graph case applied to the merge decision: heavy edges may merge, light edges may not, and the analyst who wants to merge must first ask whether the bridging edge is heavy enough to bear the weight of unifying two operations. The 284 reused SSH keys in the honeypot are heavy bridging material; a shared HASSH between two clusters is not. The merge decision is the edge-weight decision, made at the moment of unification.

And even a heavy bridging edge must survive the failure modes before the merge is final, which is the second half of the discipline. A heavy edge is strong but not immune: the bridging key could be a planted false flag (the operator of A planted B's key to frame B, or a third party planted a key in both to create a false merge), or a leaked key (both A and B scavenged the same leaked credential, so they share a key but not a hand). So the merge, like every strong attribution in the register, is confirmed not on the single bridging edge but on corroboration: do the two clusters, once bridged by the key, also share behavior, timing, or a second heavy invariant? If the merge is real — one operator ran both — then the bridged clusters should agree on more than the key, because they are one operation and one operation is internally consistent. If they agree only on the key and contradict on everything else (different behavior, contradictory timing), the "merge" is a false bridge — a plant or a leak — and must be refused. The heavy edge proposes the merge; corroboration confirms it; and the merge is made only when the bridge is heavy and the bridged clusters cohere.

3. Revising the Record

Now the consequence that distinguishes the merge from an ordinary attribution: it supersedes prior conclusions, and the register must revise its own record rather than hide the correction. When two clusters merge, the two dossiers that documented them as distinct operators become wrong — not wrong when written, but wrong now, superseded by the merged picture. An honest register does not quietly leave the old dossiers standing while the new merged reality diverges from them; it revises them, marking the two former operations as one, updating the record to reflect the hand the graph now shows. This is uncomfortable, because it means publicly correcting a prior attribution, admitting the register had it as two when it was one — but that admission is exactly the forensic honesty the whole series is built on, applied to the register's own past conclusions.

This revisability is not a special provision for merges; it is the register's fundamental epistemic stance, made visible. The false-flag case already established that no attribution is final, that all of them are the best current reading of the evidence and revisable when new evidence contradicts them. The merge is that principle in action: new evidence (the bridging edge) contradicts the prior reading (two operators), so the prior reading is revised (to one operator). A register that could not revise — that treated its published attributions as permanent truths — would be unable to incorporate the bridging edge, would leave two dossiers standing that it now knows are one operation, and would be lying by omission about what it currently knows. The willingness to merge, and to revise the record when merging, is the register's honesty about the provisional nature of all attribution, and it is what lets the graph stay true as evidence accumulates.

And the revision, done honestly, strengthens the register rather than weakening it, which is the constructive point. A register that never corrected itself would be either perfect (impossible) or dishonest (hiding its errors). A register that corrects itself — that says "these two operations we documented separately are now known to be one hand, here is the bridging evidence, the prior dossiers are superseded" — demonstrates that its attributions are responsive to evidence, that it updates when the graph updates, and that its current conclusions can be trusted precisely because it has shown it will revise them when warranted. The merge is thus a demonstration of the register's method working as intended: the graph grew, an edge appeared, a correction followed, and the record now reflects reality better than it did. The operator who compartmentalized to look like two is now, correctly, one, and the register's willingness to say so — to revise its own past to match the evidence's present — is the integrity that makes its unrevised attributions worth believing.

4. SHARED KEY — The Bridge Between Operations

The linkage signal is SHARED KEY, because the bridging invariant that warrants a merge is almost always a heavy credential edge — the reused key that the operator carried across his compartmentalized operations, the one thing he failed to keep separate. And the merge illuminates something about the key signal that the isolated key cases could not: the reused key does not just cluster an operator's simultaneous fleet; it bridges his operations across time and compartmentalization, tying together campaigns he ran months apart and deliberately kept unlinked. The key is a longer-lived and further-reaching invariant than the opening cases showed — it survives not just the operator's scattering of addresses but his deliberate separation of operations, because it is the same convenience in both, reused across the whole of his activity rather than within a single campaign. The merge shows the key doing its deepest work: unifying not a fleet but an operator's entire body of operations.

This is why the heavy edge, and specifically the bespoke key, is the only edge trusted to merge — because merging is a claim of unity across deliberate separation, and only the most unshareable invariant can support a claim that strong. To say "these two compartmentalized operations are one hand" is a strong claim, stronger in a sense than clustering a single fleet, because it overrides the operator's active effort to appear as two. A claim that strong needs the strongest evidence, and the strongest evidence is the bespoke key, because it is the one thing that could not be shared by coincidence or planted cheaply, so its appearance in both operations is the operator's own reuse, betraying the unity he tried to hide. The register merges on the key (or an equally heavy invariant) and nothing lighter, because nothing lighter can bear the weight of overriding the operator's deliberate compartmentalization — a light edge bridging two compartmentalized operations is far more likely a coincidence than a genuine unity, and treating it as a merge would be the super-node error in its most seductive form.

And the merge completes a symmetry the register will finish in the next case: the graph can be corrected in both directions, and the correction is gated by edge weight in both. The merge corrects under-clustering by adding a heavy edge that unifies; the split (next) corrects over-clustering by removing a light edge that falsely unified. Both are the same discipline — trust heavy edges, distrust light ones — applied to the two ways a cluster can be wrong: too small (missing a real unity) or too large (containing a false one). The merge is the too-small correction, made when a heavy edge reveals a real unity the graph had missed, and it is trustworthy exactly because it requires a heavy edge, which is exactly what a real unity produces and a false one does not. SHARED KEY is the merge's signal because the key is the heaviest edge, and the heaviest edge is the only one strong enough to say, against the operator's own effort to hide it, that his two operations were always one hand.

5. Merging Well (and the Cost of Merging Wrong)

The register owes the analyst a merge discipline, and it is a short, strict procedure. First, propose a merge only on a heavy cross-cluster edge — a bespoke key, a bespoke C2, a planted authorized key appearing in both clusters — never on a light one, because a light-edge merge rebuilds the super-node. Second, confirm the merge on corroboration: check whether the bridged clusters, once joined by the heavy edge, also cohere on behavior, timing, or a second heavy invariant, because a real merge (one operator) produces coherence beyond the single edge while a false bridge (plant or leak) does not. Third, if confirmed, merge fully: combine the clusters, and update the assessment to reflect the operator's true, larger scope. Fourth, revise the record: supersede the prior separate dossiers, honestly marking the correction rather than leaving contradictory conclusions standing. The merge is powerful and dangerous in equal measure, and the discipline is what keeps its power (revealing true scope) without its danger (building super-nodes).

For the defender, the merge carries a specific and sobering lesson: the adversary you caught may be larger than you caught. When a defender detects and characterizes one of an operator's compartmentalized operations, he is seeing one cluster of a hand that may run several, and the operator's deliberate separation is designed precisely to make the defender think he has seen the whole when he has seen a part. So the defender's discipline is to look for the bridging edge — to check whether the operation he caught shares a heavy invariant (a key, a C2) with any other known operation — because finding that bridge reveals the true size of the adversary and, often, additional infrastructure to block and additional victims to warn. The merge is, for the defender, the difference between disrupting one campaign of an operator and understanding the operator, and the heavy edge is the thread that turns the first into the second.

The honest close is the risk that governs the whole case: merging wrong is as harmful as splitting wrong, and in a specific way worse, because a wrong merge over-attributes. To merge two genuinely distinct operators into one is to attribute to one hand the actions of two — to build a false picture of a single large adversary where there are really two smaller ones, which misdirects defense, inflates threat assessments, and (if it reaches naming) risks attributing one operator's crimes to another. So the register merges conservatively, on heavy edges and corroboration only, and treats a proposed merge on a light edge or an uncorroborated heavy edge as more likely a false bridge than a real unity. The default, when a bridging edge is light or uncorroborated, is to keep the clusters separate, because under-clustering (two hands seen as two) is a smaller error than over-clustering (two hands seen as one) — the first misses a connection, the second invents one. The register would rather leave a real operator split across two clusters than merge two real operators into one false hand, and it merges only when the heavy edge and the corroboration together make the unity as certain as the operator's own reused key can make it. The vectors do not lie, and a bespoke key reused across two compartmentalized operations does not lie either: it says, against the operator's own effort to appear as two, that the hand was always one. We do not judge. We record. We let people judge — and we revise our own record, honestly, when the graph reveals the two we saw were always one.

6. The counter-narrative, steelmanned

The strongest objection to this case is that the merge is a license for exactly the over-attribution the register claims to fear — by allowing clusters to be combined, it opens the door to building ever-larger "operators" from tenuous connections, and the "heavy edge" gate is too easily satisfied by an analyst who wants a bigger, more impressive attribution.

The argument runs like this. The whole thrust of the register, the objection notes, has been caution against over-attribution — the super-node, the shared-tool trap, the bulletproof-landlord conflation. The merge runs directly against that caution: it is the operation of making attributions bigger, combining hands into larger hands, and every incentive in threat intelligence pushes toward bigger attributions (a large sophisticated operator is a more impressive finding than two medium ones). So the merge, the objection continues, is where the analyst's bias toward significance meets a mechanism for satisfying it, and the "heavy edge" requirement is a weak gate, because "heavy" is a judgment the same biased analyst makes — he can call an edge heavy enough to merge when he wants the merge, exactly as the graph-case objection worried he could weight edges to fit his theory. The merge, on this view, is the register handing the over-attributing analyst the tool he most wants, wrapped in a discipline he can talk himself past.

The register accepts the danger and points to the asymmetry it built in to counter exactly this bias. Yes — the merge is the over-attribution operation, the analyst's bias runs toward bigger attributions, and a loosely-gated merge would rebuild the super-node; the register agrees so completely that it gated the merge more strictly than any other operation and defaulted against it. The disagreement is whether the gate is real, and here the register points to two features the objection understates. First, the "heavy edge" is not a free judgment the biased analyst makes per merge; it is fixed by the same external shareability gradient the graph case established, which ruled in advance and independent of any merge that a bespoke key is heavy and a common tool is light — so the analyst who wants to merge on a shared tool is not exercising judgment the gradient permits, he is violating a fixed rule, and that is checkable by anyone applying the gradient. Second, and more decisively, the register defaults against merging: it states explicitly that under-clustering (two hands seen as two) is the smaller, preferred error and over-clustering (two hands seen as one) the larger, avoided one, so the burden is on the merge to prove itself, not on the separation to justify itself. A merge requires a heavy edge AND corroboration AND coherence beyond the single edge, and absent all three the clusters stay separate — which is the opposite of a license, it is a high bar with a conservative default. The objection is right that the merge is where over-attribution bias would act; the register's answer is that it therefore made the merge the hardest operation to perform, fixed its gate externally so bias cannot loosen it, and set the default to refuse — so that the analyst who wants a bigger attribution must clear the register's strictest bar to get it, and cannot get it by wanting it. The merge is not the over-attributer's tool; it is the operation the register hedged most heavily precisely because it knew the over-attributer would reach for it.

7. Linkage Signal — SHARED KEY

Case 17 treated the merge — the correction of under-clustering, the first of the graph's two error-correcting operations. Two operator clusters, documented separately as distinct campaigns, are revealed to be one hand when a heavy cross-cluster edge appears: the same bespoke SSH key offered in both, the same planted authorized key, the same bespoke C2 — a single unshareable invariant bridging two regions the graph had kept apart. The operator kept his operations separate for real reasons — different times, tools, targets, deliberate compartmentalization — so the clusters formed apart, correctly given the evidence, until the one invariant he failed to keep separate revealed the common hand.

The discipline is strict, because merging is the operation that builds super-nodes: merge only on a heavy, unshareable edge (a light-edge merge rebuilds the false mega-operator), and confirm only on corroboration (a real merge coheres beyond the single edge; a false bridge — a planted or leaked key — does not). The linkage signal is SHARED KEY, the bridging invariant, because only the heaviest edge can bear the weight of a claim that overrides the operator's deliberate effort to appear as two. The merge's greatest value is often the revelation of scope — an operator who compartmentalized to look small revealed as large — and its obligation is honesty: it supersedes the prior separate dossiers, and the register revises its own record rather than hide the correction, which is the false-flag case's revisability applied to the register's own past.

The register merges conservatively and defaults against it, because over-clustering (two hands seen as one) is a worse error than under-clustering (two hands seen as two) — the first invents a connection, the second only misses one. So a proposed merge on a light or uncorroborated edge is refused, the clusters kept separate, and the merge made only when a heavy edge and corroboration together make the unity as certain as the operator's own reused key. The graph is revisable in both directions, and the merge is the upward revision, gated by edge weight exactly as the split (next) will be — trust heavy edges, distrust light ones, applied to the too-small correction. The vectors do not lie, and a bespoke key reused across two compartmentalized operations does not lie: it says the hand was always one. We do not judge. We record. We let people judge — and we revise our own record, honestly, when the graph reveals the two we saw were always one.

Follow the Operator — Case 17. Linkage signal: SHARED KEY (the bridging invariant). Confidence: HIGH when a heavy cross-cluster edge merges and corroboration holds. The merge corrects under-clustering: two operator clusters documented separately as distinct campaigns are revealed as one hand by a single unshareable invariant appearing in both (a bespoke key, a planted authorized key, a bespoke C2) — the operator having kept his operations apart by compartmentalization (different times/tools/targets) and failed to keep the one reused invariant apart. The honeypot's 284 reused SSH keys are the merge material. Discipline: merge ONLY on a heavy (unshareable) edge — a light-edge merge rebuilds the super-node — and confirm ONLY on corroboration (a real merge coheres beyond the single edge; a planted or leaked key does not), with the default set AGAINST merging because over-clustering (two hands as one) is a worse error than under-clustering (two hands as two). A merge multiplies what is known (revealing the operator's true scope) and supersedes the prior separate dossiers, which the register revises honestly rather than hiding — the false-flag case's revisability applied to the register's own past. The steelmanned objection (the merge is a license for over-attribution) is answered by the externally-fixed heavy-edge gate and the conservative default-to-refuse. No individual named. Classification: TLP:WHITE. Include everything — the vectors do not lie, and a bespoke key across two compartmentalized operations says the hand was always one; we revise our record honestly when the graph reveals it.