Single-indicator pivoting is the backbone of infrastructure tracking, and it deserves a fair hearing before we take it apart.

You take one value surfaced in an incident and expand to everything that shares it:

• A JARM or JA3/JA3S TLS fingerprint, pivoted to find servers with the same TLS stack configuration.
• A JA4+ suite fingerprint (JA4 client, JA4S server, JA4H HTTP, JA4X certificate, JA4T TCP — a subset of the full suite), the next-generation suite from JA3's creator (John Althouse), whose JA3 work was originally published at Salesforce.
• A favicon hash or HTTP body/DOM hash, pivoted to find hosts serving the same asset.
• A certificate field — subject CN, issuer organization, serial — or a domain / WHOIS detail.

The tooling for this is mature and good: Shodan (the scan-metadata backbone this doctrine runs on), Censys Adversary Investigation and certificate history, Silent Push Context Graph, Validin, GreyNoise, Hunt.io, and the JA4+ suite from FoxIO. The canonical move — take a Cobalt Strike server's JARM, search for matching hosts, surface the related fleet — is real and has burned a great deal of adversary infrastructure.

It is also, in David Bianco's Pyramid of Pain terms, working near the bottom of the pyramid. IP addresses and domain names are trivial for an adversary to change. Hash values and host artifacts cost a little more. Tools and TTPs cost the most. A single shared indicator is cheap for a disciplined operator to stop sharing. Our own literature says as much. A lone JA3 collides across every host built on the same TLS library, and a server's JARM reflects its OS, TLS libraries and versions, and negotiation/configuration order, so default-tooling JARMs can collide across any hosts that share the same TLS stack, sweeping up benign servers while a tuned configuration shifts out of range. The standard guidance is already to combine fingerprints with SNI, hosting, and session context rather than trust one on its own.

The complaint here is not that we pivot on single indicators and shouldn't. It is that the pivot is a starting move, and against tiered operators it is the only move many of us have. That is enough, up to a point. And then we treat "up to a point" as the finish line.

Walk the RaaS economy. A modern ransomware operation is not one actor; it is tiers. An initial access broker (IAB) sells a foothold. The core operator provides the ransomware, the negotiation portal, and the control infrastructure, and takes a cut. Intel 471 documents this broker→operator chain directly; in the wider RaaS ecosystem an affiliate layer typically runs the intrusion between the two, and Rapid7 and Cyberint have documented the broader division of labor.

Here is the asserted rule, and it is hedged on purpose:

Against an operator who practices tier separation, you will generally not reach the control node by pivoting on the same indicator — domain, certificate CN, favicon hash — that exposed the initial-access tier.

The reasoning is structural, not magical. Tier separation is a deliberate control. The access surface and the control surface are built to share as little as possible, so a thread you pull from one does not lead to the other. Pulling that thread harder will not fix it. The thread genuinely dead-ends. The move is to stop yanking a dead thread and go read a different surface, the one the operator could not help leaving behind.

EvilTokens is the cleanest exhibit of the boundary. It is a Microsoft Device Code OAuth phishing-as-a-service platform whose published 95-IP indicator list resolved, under unlabeled clustering, into a four-tier architecture: a CDN frontend of roughly 75 assets that are 100% Cloudflare (AS13335), a backend of ~19 assets running the actual operation (Apache/nginx, Pure-FTPd, OpenSSH 8.9p1, Exim) deliberately scattered across 15 hosting providers, a five-IP bridge layer set apart by Google Trust Services certificates, and an eight-IP IoT proxy layer of compromised cameras. The article sets the uniform front against the varied, expendable backend, and reads the IoT layer's purpose as exactly this: to "create separation between the operation and its operator."

The front and back share almost nothing an analyst can pivot across. Pivot on the Cloudflare HTTP-config hash and you stay trapped in the CDN tier; the backend never appears. Pivot on the backend's OpenSSH/HASSH stack (HASSH is a fingerprint of an SSH server's negotiated algorithm set: HASSH 41ff3ecd1458b0bf86e1b4891636213e, OpenSSH 8.9p1) and you never see the front. The CDN frontend is homogeneous because "Cloudflare is the product"; the backend is split up on purpose. The single-indicator pivot dies at that boundary, written into one operation's own architecture.

What this exhibit is: EvilTokens' tiers are inferred operational roles surfaced from one IOC set, not a proven, operator-confirmed indicator firewall between two cohorts. The clustering made the roles visible; the article presents them as hypotheses, and the IoT layer's function is explicitly three competing hypotheses (proxy relay / C2 relay / credential exfil), not a settled fact. No published candidate, EvilTokens included, actually measures zero indicator-overlap between two tiers, or proves an operator engineered the tiers to refuse shared indicators. So read tier-death as an analytic pattern EvilTokens illustrates well, not as a confirmed engineering decision: the boundary's hardness is, for now, qualitative. (See EvilTokens: Device Code Phishing Goes Industrial, Chawkr.)

The counter has to be faced. A circular "if you could reach it, they failed at OPSEC" argument can never be proven wrong, so the claim here is deliberately probabilistic, not a statement about hard boundaries. Sloppy reuse does bridge tiers, and often. Plenty of published takedowns reached C2 by pivoting on a shared self-signed certificate, a reused JARM from default tooling, or shared bulletproof hosting; the Conti leaks exposed how much infrastructure and tooling one operation shares across its roles, and Cobalt Strike C2 has been mapped at scale through default certificate serials and stock JARM values. The claim is not that single-indicator pivoting never reaches control infrastructure. It is a claim about recall: across disciplined tier separation, single-indicator pivots reach the control tier in a minority of cases, and the more disciplined the operator, the lower that fraction. The boundary is not a wall; it is a probability that turns against you as OPSEC discipline rises.

And the indicators themselves are getting cheaper to rotate, which erodes the pivot from the other direction:

• JARM randomizers (demonstrated at HITB, 2021) and Cobalt Strike malleable C2 profiles reshape server-side TLS fingerprints per deployment.
• JA3 randomization — cipher-stunting and randomized ClientHello libraries (documented by Vectra, Stamus, and Salesforce themselves) — defeats client-side TLS fingerprinting.
• IP-to-host mappings decay fast; an IOC list goes stale meaningfully within days.

The deeper limit underneath all of this: same-indicator pivoting is blind to behavior and blind to the after-attack state. It chases one fixed feature through space. It never asks what a group of hosts was doing, and it does not know how to read infrastructure once the live attack has moved on and only the residue is left. We keep leaving that part on the table. The residue is right there, already exposed, waiting to be read.

Before the four moves, hold one picture in your head. Most of us show up after the scene has already moved on. That is the part we keep forgetting.

At t₃ — the moment you sit down to analyze — the live attack fingerprint from t₁ is usually already gone. The IP nodes have churned. What is left is the after-attack shape of the infrastructure, and that shape is itself a signature.

Two things follow from the timeline. First, the IP is the most short-lived thing in the picture. The operator's configuration posture, how the host is set up however it got that way, lasts the longest. Second, by the time you analyze, you are almost never looking at the live attack. You are looking at what it left behind. Catching the attack signature itself (panel B) needs a scrape to land inside the attack's live window. That comes down to how often you scrape against how long the host is exposed, not to method, which is exactly why the method leans on the lasting posture instead of betting on that overlap. The work we keep skipping is this: read the residue well. The data is right there. We just have to read it.

The four moves, as a named sequence:

1. Cohort-seed — start from a behavioral population, not a single feature.
2. Persistent-fingerprint — mine that cohort for the lasting configuration posture, not the short-lived IP.
3. Attack-vs-after-attack — read the context around the host to decide whether the live mechanism is still there or only its residue.
4. Multi-method convergence — trust a finding that holds up when you analyze it more than one independent way, and act only on what an independent source then confirms.

This builds directly on the Diamond Model's analytic pivoting and Joe Slowik's (DomainTools) contextual-pivoting methodology, carried forward into the post-incident state. It does not invent post-incident infrastructure analysis. Retro-hunt and historical-pivot tooling already exist. What it does is give that state a method you can repeat. Most teams already do this, but only by feel, one case at a time. The pieces are all here; this just names the order.

Before the principles, one comparison that drives all four moves. Same thread, two ways of working it.

The junior's path is not wrong. It is just unfinished: it stops at the doormat and closes the ticket, because the favicon hash already gave thousands of hits and a blocklist feels like an answer. The layer that matters is just one more pass over the noise away, and that is how EvilTokens' camera proxy tier surfaced. We were handed the whole house and we keep wiping our feet at the door. The four principles below are the rest of the walk.

We were handed a way to find the whole crew, and we keep grabbing one face from the lineup. Stop. Begin the hunt from a behavioral cohort — the set of hosts seen doing the same thing in the same window (one brute-force wave, one tooling footprint) — not from a single shared feature, and not from a list of unrelated IPs.

Here is the contrast a junior needs to learn by heart:

Why a cohort is the better place to start: a single indicator rides on one feature the operator controls. Some of those features are cheap to rotate. A domain is a registration away; a JA3 just follows the client library. Others are stickier, like server-side TLS config or hosting posture. But even the sticky ones fail against a tiered adversary, and for a different reason: a careful operator chooses not to reuse them across tiers, so the pivot finds too little and stalls. A behavioral cohort does the opposite. It hands the clustering engine a whole population with real structure to resolve.

Intent and timing happening together is usually harder to fake consistently than a static fingerprint, but it is not bulletproof. Shared commodity tooling, mass-scan campaigns, shared bulletproof hosting, and randomized scheduling can each throw up a cohort that only looks coordinated and isn't. Cohort seeding reduces, not eliminates, the brittleness of single-feature pivoting. The cohort is a better starting population; it is the persistent-fingerprint mining that follows that earns the confidence.

This is the Diamond Model's analytic-pivoting principle, just applied across a correlated population instead of a single indicator. Population-based pivoting is already standard practice in scan-telemetry and netflow hunting. What we still hardly do is apply it to post-incident metadata: reading the residue to surface persistent fingerprints after the live signature has churned away.

An unsupervised experiment over 2,714 malicious IPs shows this at scale. Chawkr's explorative study took a raw mixed corpus covering 44 distinct C2/malware-family labels (Metasploit 514, Sliver 434, Cobalt Strike 371, Viper 225, GoPhish 218, and a long tail), sourced from the MontySecurity C2-Tracker feed, and fed it into the pipeline with — in the article's words — "no predefined family signatures or prior training." It sorted itself into 60 clusters on operational similarity alone. That is the exact opposite of pivoting on one favicon or JARM: here a behavioral population is the seed, and the structure is discovered, not asserted.

The families separated by behavior, not by any single feature handed in:

• Viper C2 reached 100% purity across three clusters (126 assets).
• Sliver held above 0.90 purity in seven of nine clusters (one cluster at 97.92% purity, 0.146 entropy).
• ShadowPad formed a 100%-purity cluster of eight IPs — 44.4% of all 18 ShadowPad IPs in the corpus.

This is the cohort-seed principle at its largest scale: a population grouped by what it does, with no indicator to pivot on. (See Explorative Clustering of Malicious Infrastructure with ClusterHawk, Chawkr. Its limit on attribution: the article caps confidence at 80–90% even for perfect-purity clusters, and purity tells you how much one family dominates a cluster, not that a single operator is behind it.)

Single-banner seeds are exactly the bad habit this principle warns against, and the casework is full of them, precisely because they are the easy first move. OVERCAST started from a 50-IP composite profile; EvilTokens from a published 95-IP IOC list; the exposed-AI study from a bare "Ollama is running" query; the ICS study from a Modbus/502 tag. Each one is useful. None of them is a behavioral cohort. The cohort earns its keep by handing the engine structure to resolve.

The best cohort of all is the one you watch directly: the set of hosts seen doing the same thing in the same window — every source IP in one brute-force wave, every node touched in one intrusion's telemetry. That cohort is defined by what it did, not by any feature handed in, and it is the cleanest seed this doctrine asks for. (When you have a window like that, seed from it. The published exhibits here are feed- and tooling-seeded because public datasets rarely ship raw same-window activity.)

One step in from that ideal is the tooling cohort: seeding not on a single hash, but on the whole population running the same credential-harvesting toolkit. A GoPhish/Evilginx-style Shodan seed profile captures exactly that population:

http.title:"Gophish - Login"
"gophish" port:3333
ssl.cert.subject.cn:"gophish"
"evilginx"
"HiddenEye"

A seed like this returns a population, usually a few hundred hosts, that the pipeline resolves into clusters, a noise partition ("noise" in the clustering sense: points the algorithm puts in no cluster, set aside instead of forced into one), and the structurally unique outliers a single-favicon pivot would never have reached. A favicon-hash pivot, by contrast, just returns every host sharing a default GoPhish icon, millions of them, mostly beside the point. The cohort hands you a structure; the lone hash hands you a haystack.

The cohort-construction call itself — exactly which behaviorally-correlated hosts belong in a seed, and which are noise that contaminates it — is the analyst's judgment. The principle is public: seed from co-observed behavior; keep the population tight enough that it shares intent and timing, loose enough that there is still structure to resolve. The exact inclusion thresholds are something each deployment has to tune — work any practitioner does against their own data and environment, and the part where our own tuning stays unpublished. Throughout this doctrine the reasoning is taught in full; only the deployment-specific tuned thresholds — the calibration each practitioner must do for their own data, and the values we have settled on for ours — are held back, and we won't repeat that disclaimer at every principle.

A note on method: seeding from a peer's published IOCs. Beyond raw activity windows and tooling cohorts, there is a third seed that is very useful in practice: someone else's confirmed indicator list. When a respected vendor publishes a campaign's IOCs, that set is already checked against ground truth. Their confirmed attribution is the foundation that makes everything downstream possible. Feeding it into the pipeline does two honest things. First, it reproduces the campaign's operational structure, a check that the method recovers what the vendor already showed. Second, it enriches it, adding the cluster tiers, the predictive fingerprint, and the anomaly-led triage the IOC list alone did not carry. What this is: reproduction-plus-enrichment standing on the vendors' attribution, not faster original discovery. Seeding from a confirmed-malicious list shows the method can recover structure; it is not a scientific test, because the input is curated, so the structure is guaranteed to be there. Chawkr's validation casework shows this, with full credit to the foundation each rests on: reproducing eSentire's ClickFix→NetSupport delivery chain and adding a predictive WinRM admin signature; confirming Black Lotus Labs' SystemBC proxy botnet and adding role-based infrastructure tiers and anomaly scores; validating Trellix's SideWinder campaign and, in the same pass, separating ~85% CDN/search baseline noise from a ~15% real nginx lead cluster, the "pivot wide, filter with clustering" move shown working on a published campaign we validated against. One caveat is operational, not about the method: the window is short. Published infrastructure rotates fast, so validation-seeding has to be done quickly after a report drops, before the live infrastructure it describes has churned away.

Treat the IP as the shortest-lived indicator, and the operator's configuration posture as the one that lasts. By "posture" we mean the recurring shape a cohort's configuration shares, whether a provisioning tool stamps that shape, a manual playbook sets it, or it gets re-applied to each host after the host is up. Throwaway front-end nodes cycle far faster than that posture does. The work has to run on fresh scan data you pull yourself; last month's IOC list mostly points at dead nodes. Here is the habit we should be ashamed of: we get handed a list, we block the IPs on it, we close the ticket, and the operator is already gone, because the thing we blocked was the part that was always going to move. This is not an abstract claim. It is measured, and the receipts are public: see The churn, measured below, where OVERCAST's and Nightfall's auto-updated IOC feeds expose the rotation in their commit history for anyone to audit.

Map this onto the Pyramid of Pain, but borrow its spirit, not a false match. Bianco's pyramid ranks indicators by the pain you cause the adversary when you block them. We restate that as a durability gradient for scan metadata: the more it costs to rotate something, the longer that indicator lasts.

Three honest caveats keep this from hardening into a law:

• It is a gradient, not a hierarchy and not a guarantee. TLS fingerprints (JA3/JARM/JA4) and automated certificates (ACME / Let's Encrypt) are getting cheaper to rotate, and the most disciplined operators do rotate them. Durability buys you a higher probability, not certainty.
• Some fingerprint classes stick harder than others. A TCP-stack or network-position signal is far harder to rotate per deployment than an application-layer ClientHello or a cert. Rank durability one class at a time; never on a single slider.
• The most durable row above is durable for a reason that depends on the operator. A cert-CN naming template lasts not because the certificate bytes are sticky on their own (they get reissued all the time) but because the operator's tooling or playbook re-applies the same naming convention onto every fresh node, whether at provisioning time or after the host is up. The durability lives in that repeated habit and the CN template, not in any single cert. Drop the assumption that the operator keeps re-applying it, and that row loses its rank.

The reliability does not come from any one feature lasting. It comes from the composite — the recurring configuration shape across a behavioral cohort — surviving across fresh data. That is why the work has to run on fresh scrapes you serve yourself: once the metadata churns, even the composite loses confidence.

The tightest single-fingerprint exhibit is the KeeneticOS proxy network (tracked in the IOC feed as Nightfall): 832 compromised KeeneticOS SOHO routers, used as clean residential proxy exit nodes across multiple Russian ISPs. We do not know how they were compromised. The published analysis weighs breach, supply-chain, and unpatched-vulnerability hypotheses without settling on one, and nothing here proves a vendor or product defect. "Compromised" describes the state we observe, not a proven flaw in the device. The IPs are throwaway residential endpoints that churn; the rigid fingerprint set on each node does not, though, as the caveat below makes clear, most of that rigidity is the device firmware, not the operator. Every node carries the same set:

• HASSH 12ae3bde05e041d683e7712cd144261f, identical on all 832 nodes.
• Favicon hash 547282364, title hash -1670795305 ("KeeneticOS Web Panel"), robots hash -1022729730, DOM hash -1753752179, headers hash -1031597325.
• Fixed port layout: HTTP/80 (100%), SSH/22 (100%), FTP/21 (~25%); cipher aes128-ctr, key ssh-rsa.

This exhibit forces a caveat, and the more useful lesson sits inside it. We state it as the doctrine's own reasoning, not as a claim from the source, which reports only that the set is uniform across the compromised fleet: most of that fingerprint set is almost certainly vendor firmware, not operator tradecraft. The HASSH, the favicon, the "KeeneticOS Web Panel" title, the DOM and headers hashes are, by their nature, properties of the router's stock web panel and SSH stack, the things every KeeneticOS router of that build ships with. On first principles they should fingerprint the device model, and we would expect them on uncompromised units too, not only on this operation. (The published analysis did not scan a clean-device control group to confirm that directly, so treat it as a strong inference, not a measured fact.) The same is likely true of the exposed surface itself: a SOHO router's reachable HTTP/SSH/FTP, and its stock cipher and key choices, are plausibly default, firmware-borne configuration rather than something the operator opened. That default exposure, together with whatever unpatched firmware flaws it carried, is the most probable thing that enabled the mass compromise in the first place (which fits the source's unpatched-vulnerability hypothesis). On their own these signals isolate a router class, not a proxy network. The source pins the operator-specific layer narrowly: the consistent SSH fingerprint "suggests a standardized deployment toolkit, likely automating the configuration of proxy services post-compromise." That is, the operator's signature is the automated proxy-service setup applied after compromise, plus the regional-ISP spread, riding on top of the firmware sameness. The durable anchor for the operation is the firmware composite and that operator overlay together; the firmware hashes alone would sweep up harmless Keenetic devices. This is Principle 4 in miniature: the lone fingerprint is a device tell, but the conjunction with the proxy posture and the org footprint is the finding. Read this way, the exhibit is also the invitation: do not stop at the matching hash and call it a botnet. Read what the hash is actually telling you, separate the firmware from the operator's overlay, and you have a real lead instead of a swept-up pile of innocent routers.

The article also teaches the durability gradient in practice. The published hunting query stacks 8+ parameters, then says plainly: "the original profile may no longer be effective so try to remove and change some values, since infrastructure changes," and hands over a loosened variant that drops HASSH, ssh.type, and port 22. That is the lesson put to work: which composite features survive churn, and which to drop first. (See When Your Router Becomes Someone Else's Weapon: Uncovering a 800+ Proxy Network via KeeneticOS Router, Chawkr. The attribution there is openly a guess — breach vs supply-chain vs unpatched vuln are listed as alternatives — so do not read the botnet/coordination claim as confirmed C2 observation.)

OVERCAST is the co-anchor that puts a number on the gradient. It is a fleet of ~1,900 RDP-only Windows VPS nodes, ~85% on a hosting provider that has been reported before in connection with C2 abuse, where hundreds of IPs rotate out every two weeks while the fleet holds steady within a ~1,400–1,900 band. The IPs are throwaway. The deployment template is baked into provisioning. The self-signed certificate CN follows a windows-{City} template (NetBIOS 15-char encoded: Frankfurt → windows-Frankfu, Dallas → windows-Dallas0, with suffixes 2g/4g/8g/1H encoding the VPS RAM/core tier), and the article states the gradient outright: "IPs rotate... Certificates get reissued. But the hostname stays because it's baked into the VPS provisioning template... certificate CN monitoring is the most durable detection anchor." A static blocklist of OVERCAST IPs goes stale within days; the cert-CN template lives on. (See the published OVERCAST article, Chawkr. Note that its published headline names a specific hosting company and asserts a nation-state framing. The doctrine treats both the operator attribution and the provider's role as unconfirmed — the article itself lays out five hypotheses and cannot confirm the single-APT label — so we present the fleet's purpose as open and do not read the headline's assertion as the doctrine's position. The Sources entry below reproduces that headline word for word, provider name and APT framing included, as citation practice requires; we endorse neither here.)

The churn, measured

Do not take our word for it. The "IPs churn, fingerprints persist" claim does not rest on faith. Chawkr publishes auto-updated IOC tracking feeds with full commit history, and two of them are the same two operations profiled above: OVERCAST (overcast.txt) and Nightfall (nightfall.txt, the KeeneticOS residential-proxy network). The git history is the receipt: pull the repo, diff the commits, and watch the IP layer recycle under a fingerprint that never moves. These are opposite churn signatures of the same law. In both, a static IP blocklist would be wrong inside two weeks, while the durable fingerprint kept tracking the operation straight through.

OVERCAST — a stable-sized fleet under violent rotation. The feed auto-updates roughly every two weeks. The fleet holds a live population of ~1,400–1,900 IPs, yet maintaining that population has cost ~8,784 total line-changes (adds plus deletes) across the feed's life. The clearest single data point: the 2026-05-05 update churned +1,642 / −1,745. The IP layer almost fully recycled in one fortnight while the fleet size barely moved (1,912 → 1,809).

Through every one of those rotations, the durable tracking anchor was the same one documented above: the windows-{City} self-signed cert naming convention plus the JARM/JA3S set. A blocklist of OVERCAST IPs is stale within days. The cert-CN template is not.

Nightfall — a network that decayed, then twitched back. The KeeneticOS proxy network's feed tells the more dramatic arc. It peaked at 786 live IPs in early February 2026, then collapsed roughly 98% to 12 by June (the population began cratering Feb–Mar 2026; the commit history shows the decline plainly, but the cause is not observable from the feed and we do not speculate on it). The point the trajectory makes: even a near-dead network keeps twitching. The latest update, 2026-06-01, still added +7 fresh IPs into a population of barely two dozen. The standing fingerprint caught infrastructure re-activating or moving even as the count cratered.

The anchor that survived Nightfall's collapse is the one documented above — the title / favicon / DOM / robots / headers-hash composite plus the org/ISP footprint — not any individual residential IP.

The teaching point. OVERCAST is rotation as continuous operation — a stable fleet whose IP layer almost fully recycles every fortnight. Nightfall is rotation as decline and resurrection — a network decaying toward death that still emits fresh-IP twitches. Different shapes, same law: the IP is perishable, the configuration posture endures. And unlike most of this doctrine's claims, this one is auditable — the public commit history at the URLs in the Sources section can be diffed by anyone.

Two cautions on weaker P2 candidates. The ICS exposure study shows extreme template homogeneity (JA3S 6c2811f7ba8e88604ea41a2bf9fa5ad7 shared by 95.99% / 958 hosts across 14 providers, identical SSH host-key, batch certificates issued in the same second), but the article concludes that sameness is "likely honeypot artifact," dropping to under 2% after filtering. This is the lesson flipped: here a durable fingerprint flagged fakes, not adversary tradecraft. And the exposed-AI cluster's durable configuration (one JA3S, one JARM, one domain wo2u.com) recurs across one operator's own IP blocks, not across many unrelated providers, a weaker durability-across-providers story.

To round out the spine: in EvilTokens the IPs churn while a shared Cloudflare configuration template stays put — the HTTP-headers config hash 144737606 recurs across the CDN fleet ("same Cloudflare configuration template, deployed across all frontend assets"), and the article states the gradient directly: "The 95 IPs in this analysis will rotate. Some already have," while the mixed service stack (Apache/nginx + Pure-FTPd + OpenSSH 8.9p1 + Exim across 15 providers) "doesn't switch to IIS on AWS overnight."

The IPs are the doormat. The configuration posture is the house. We were handed the house, and we keep wiping our feet on the mat and leaving.

The operational guidance follows straight from the measured churn in the tables above: treat any scrape older than about two weeks as largely stale, and re-seed on fresh data you serve yourself before you trust a result. By that mark a meaningful share of the IP layer has already turned over, while the fingerprint that identifies the operation has not.

This is the heart of the method, the hardest move, and the one we are most honest about. It is also where the field gives up earliest. The host shows you a residue and you log it as a stale banner; you never ask whether you caught the operation mid-attack. Stay with it. This is exactly the read that turns a closed ticket into a tracked operator.

Define both terms. An attack signature is infrastructure whose live attack mechanism is still observably present. An after-attack signature is the durable residue that infrastructure takes once that mechanism is gone or hidden. The same operator's host can present either, depending on when you scrape it relative to the attack. Figure 1 draws the contrast: panel A is the after-attack residue you usually inherit; panel B is the attack signature you capture when a scrape happens to fall inside the attack's live window.

The artifacts that raise the prior that you are looking at an attack mechanism still in place:

• A self-signed certificate where a legitimate service would have a CA-issued one.
• A remote-access service exposed — SSH, RDP, a remote management panel.
• Services that make no sense for the host's purported role.
• A reverse proxy that blocks rather than correctly redirects (covered as its own tell below).

Read this carefully, because here is where the field goes wrong in both directions. These are priors, not state-discriminators. Self-signed certs, exposed remote access, and out-of-place services show up in huge numbers on benign, misconfigured, dev/lab, red-team, and honeypot infrastructure alike. A Shodan banner is itself stale: it cannot tell you whether a host is live right now or just leftover residue. These artifacts tell you "this is operator infrastructure" far more confidently than they tell you "this is live right now." When the artifacts are missing but the host persists, that is a weaker, muddier signal. The host may have always been staging, may be benign, or the scrape may simply have missed the service. Hold both edges. The field treats the cert as proof and treats its absence as the all-clear, and both reads are wrong.

We do not claim a tested true/false rate for this distinction. What we claim is a disciplined, repeatable way to rank guesses and bring the most likely operator infrastructure forward for a human decision. The trust does not come from one analyst's read of one host. It comes from persistence across time and convergence across independent methods, which is exactly why the next principles exist. Do not stop at one host on one day. That single read is a lead, not a finding; make it earn its place across time and across methods.

EvilTokens is the one case that puts both states on observable assets side by side. Two live mechanisms are actively running: the Cloudflare wall that returns "Direct IP access not allowed" (an operator actively enforcing CDN-only access; see the reverse-proxy tell below), and Exim SMTP on port 465 actively sending phishing mail. Beside them sits a clean residue tell: a self-signed certificate with CN=www.example.com, the default left in place, sitting right next to the Let's Encrypt certificates used for the actual phishing pages. The default cert is the not-fully-configured leftover; the active Exim and the enforced CDN wall are the live mechanism. One operation, both states, on observable infrastructure. (See EvilTokens, Chawkr. The tier roles are inferred from clustering, not operator-confirmed.)

Even this exhibit is not the perfect case. The live tells and the residue tell sit on different assets inside the operation. They are not one and the same host watched first mid-attack and then later as pure residue. No published dataset captures that strict same-host, two-state change; the framing stays, for now, shown by example rather than literally measured. Several other cases offer no live-vs-residue contrast at all. OVERCAST observed "no payloads, no tooling artifacts, no domains," and the ICS, exposed-AI, and explorative studies are purely passive snapshots. This principle leans on EvilTokens out of need, not preference.

The deciding part is taught here as reasoning: the exact set of features, and the weighting that tips a host from "after-attack residue" to "live mechanism present." The tuned trigger is not. But the kind of durable signature this method finds is already there in our published work. OVERCAST's windows-{City} self-signed cert-CN convention (above) is the shape of the answer: a signature the operator's own tooling emits, baked into provisioning, surviving IP rotation while the addresses underneath it churn.

The Reverse-Proxy-Wall Tell

Do not stop at "nginx reverse proxy detected." That label is where the field closes the ticket. Ask the next question: what is this proxy built to do?

A real public reverse proxy serves or routes to a genuine backend for an audience. A proxy that meets every request it does not recognize with a blanket block, a reset, or a generic landing page, all while hiding the backend it fronts, is doing something else. It is splitting a front from a hidden origin. That split is the same design as attacker redirectors (RedGuard / RedWarden-class, malleable-C2 fronting), and it is exactly what defeats a pivot that leans on a single indicator. This is the layer your pivot can never reach, so reach it by asking what the proxy does, not just what it is.

EvilTokens carries the only concrete fronting mechanics in the casework, so it is the positive illustration. Across the CDN cluster, the dominant HTTP title is "Direct IP access not allowed | Cloudflare." The article reads this exactly as a configured wall: "the operator explicitly configured Cloudflare to reject requests that bypass the CDN. That's active management... We see this title because Shodan scans IPs directly — it doesn't go through Cloudflare's reverse proxy." The wall is visible only because the scanner hits the IP, not the proxy: the decoupling made observable.

The fronting is not only defensive. The published EvilTokens report observes a Cloudflare anycast IP, 172.67.191.79, associated with Cobalt Strike, and reads it as C2 traffic routed through Cloudflare's CDN to blend with legitimate HTTPS. Hedge this exactly like every other tier inference: it is a reported observation on a shared CDN anycast address, not a confirmed fact about a dedicated host. The term matters too. This is CDN-fronted C2 (or "domain hiding"), not classic domain fronting. Domain fronting requires an SNI-versus-Host mismatch (a benign domain in the TLS SNI, the real C2 host in the encrypted HTTP Host header), Cloudflare disabled it around 2015, and no such mismatch is shown here; so "domain fronting" is the wrong label for what was observed. cPanel/WHM proxy ports (2052–2096) are likewise reported fronted through Cloudflare alongside the phishing frontend. Read it as the live reverse-proxy-and-CDN-hiding tell, with that hedge attached. (See EvilTokens, Chawkr — the Cloudflare IP and CDN-cluster detail are reported in that published article.)

Say it plainly: this is a strong prior, never a verdict, because the benign baseline is enormous:

• CDN-locked origins that answer only via Cloudflare/Akamai/Fastly ("Direct IP access not allowed" is the textbook case — and most instances of it are entirely benign).
• mTLS / allowlisted admin panels, staging, ZTNA-gated corporate apps.
• Geofenced or WAF-blocked business applications in block mode.
• Default nginx landing pages, maintenance pages, and honeypots.

Note that "no correct redirect" is not one single thing: a harmless default or maintenance landing page is not the same as active Host-header/SNI refusal. Only the second one is the wall. The skilled-operator flip matters too. A good redirector often redirects in a believable way (a 302 to google.com, a convincing 404). A bare block is a mid-tier operator tell, not proof of a top-tier one, and its absence clears nothing.

Distinguish the genuine wall from the lookalikes the casework warns about. The KeeneticOS network's "proxy" is residential-IP laundering with directly reachable web panels on port 80 — not a fronting wall. Botnet traffic-laundering, where compromised nodes relay traffic to disguise it as ordinary user activity, is likewise not reverse-proxy fronting. The exposed-AI hosts answer port 11434 directly with no auth — the opposite of a wall. None of those is the tell; only EvilTokens' enforced CDN refusal is.

The contrast that teaches it is the correctly-redirecting proxy: an nginx reverse-proxy cluster that answers with a clean HTTP 301 to a real backend looks like a business and, on its own, draws less suspicion. That is the counter-example to the wall. Now picture those same hosts answering every scanner with a bare block and no onward redirect while sitting inside a credential-harvesting cohort. Then that wall, not any single hash, is the finding. This is the move the field skips: the hash gets dropped in a blocklist and the wall, the thing that actually names the operation, walks. The same axis can show up inside a single operation: one cluster exposes a live admin panel directly, while another sits behind a load-balancer-fronted residue with no panel reachable. EvilTokens gives us the real wall; the correctly-redirecting proxy and the same-operation live-vs-fronted pairing are the general contrast.

The qualitative tells are taught above (a bare block, no onward redirect, a hidden backend, inside a behavioral cohort); the precise status-code-and-behavior threshold that promotes "non-redirecting proxy" to "operator wall" is the tuned part.

The Anti-Analysis Wall: Geo/ASN Evasion as Infrastructure Tradecraft

The wall above is mostly blanket — it turns away everyone who bypasses the CDN. But a more careful operator builds a selective wall, and it is the infrastructure version of malware sandbox evasion. Just as a sample fingerprints the analysis VM and goes quiet, a server can fingerprint the visitor and decide what to show. It serves the live phishing kit or payload to a target geography, and it returns a harmless page, a generic block, a timeout, or nothing at all to everyone else. The "everyone else" the operator most wants to shut out is exactly the population that scans the internet — Shodan's and Censys's published scanner ranges, hyperscaler/cloud ASNs, Tor exits, and known security-research netblocks — plus any geography outside the victim set. In other words: it is built to lock you out.

Treat this as a first-class anti-analysis technique, because it has two consequences that pull in opposite directions:

• When you can catch it, it is a strong operator tell. The signature is asymmetry: the host's response depends on who is asking. A scan from a cloud ASN draws a wall or an empty 200, while the same host, reached from a residential IP in the target country, serves a live credential-harvesting page. Geo/ASN-conditional responses, target-country allowlisting, and per-visitor content are not how benign infrastructure behaves at scale. SideWinder is the casework anchor: Trellix documents geofenced, time-locked, per-victim second-stage URLs and hashes in a PDF→ClickOnce chain, where the payload is simply not there unless you are the intended victim at the intended moment. That is detection-evasion built straight into the delivery infrastructure, and where our own pipeline meets it, the right read is "evasion-aware design," not "quiet host."
• When you cannot catch it, it is the method's honest floor. Passive scan-metadata analysis reads only what is exposed to the scanner. An operator who blocks the scanner's ASN or geography at the edge may show up in the corpus as a dull host, a single benign banner, or, worst of all, not at all. This is a built-in blind spot, not random noise: the most evasion-disciplined operators are the ones least likely to be sampled. Any passive census under-counts exactly the tier that does this best, and that is the floor we have to say out loud. The doctrine's Data Sparsity reading applies here as a discipline: missing or sparse features can be deliberate hardening or evasion, not merely absence of data. But reading sparsity as evasion is a hypothesis to corroborate, never a conclusion: most empty hosts are simply empty.

When you suspect a selective wall, do the thing: do not just file the bland banner and move on. Vary the vantage point. Compare what the scanner saw against a fetch from a residential or in-region egress, and treat any difference as the finding. The detail of which vantage shifts, and how the asymmetry is scored, is operational. What we can teach is the principle: a response that changes with who is asking is itself the signature. (See SideWinder, Trellix, for the geofenced/time-locked delivery; the evasion-aware-infrastructure reading also appears in the SystemBC casework.)

Before / After: Two States

The attack-signature column above is drawn from EvilTokens' live tells (active Exim on 465, the enforced Cloudflare wall, the www.example.com default-cert residue, Cobalt Strike fronted on a Cloudflare IP). The after-attack column is the durable hosting shape the same architecture goes stale into. The same axis shows up again inside a single credential-harvesting cohort: one end shows the live mechanism (exposed admin panels, self-signed tooling certs, a non-standard admin port), the other shows durable residue (load-balancer-fronted landing pages, no panel, no SSH).

The Impersonation Discriminator: Base Domain and Homoglyph, Not Issuer Class

A certificate that names a real organization in its subject proves nothing on its own. Pivot on the bare organization name and you get the real organization's own infrastructure just as easily as any impersonator's. The name on the certificate is not the tell. Just as important, neither is the certificate's issuer class.

That last point throws out a piece of older tradecraft: by 2026, the issuer class of a certificate is at best a weak prior for impersonation. Extended Validation has carried no browser trust signal since 2019, when Chrome 77 and Firefox 70 removed the EV UI; the green-bar era is over. Most legitimate organizations now serve domain-validated certificates (Let's Encrypt / ACME, Google Trust Services, Amazon ACM) on their own apex domains. A DV cert is not evidence of impersonation, and "EV/commercial = real, DV/Let's Encrypt = fake" is simply wrong for today's web. Our own casework proves it. EvilTokens' phishing pages used Let's Encrypt certificates, while Google Trust Services certificates showed up on the operation's bridge tier: a free, automated CA on one tier and a reputable CA on another, neither of them EV. An issuer-class test would have waved both through. That is why issuer class fails as the discriminator, and why we cannot keep reaching for it.

The signals that actually carry weight are structural, not issuer-based:

• A real-organization name embedded as a left-hand subdomain label of an attacker-controlled base domain — realorg.realtld.attacker.tld — rather than living on the organization's own apex. The base domain is the tell, not the leftmost label.
• A homoglyph or punycode (xn--) lookalike of the real name — a visually-confusable Unicode spoof of the genuine string.

Two weaker hints, still better than issuer class, can help back this up: a self-signed certificate where a public-facing portal would normally carry any CA-issued cert at all, and an odd wildcard or multi-SAN structure that bundles a target's name in with unrelated attacker domains. Both are softer than the base-domain and homoglyph checks.

Same name, wrong base domain; or same name, homoglyph spoof. That is the check that tells a real organization's own portal apart from the panel built to impersonate it. A CN match is a lead; the base-domain or homoglyph mismatch is the finding. Issuer class is a weak prior you may note, never the verdict.

Is the Vulnerability a Fingerprint of the Service or of the Operator?

One last read inside this principle. When a CVE is present, ask whether it fingerprints the product (just along for the ride, since everyone running that version has it) or the operator's configuration choice that amounts to a signature.

EvilTokens' IoT proxy layer is the vuln-as-operator-signature case. The eight compromised cameras — Hikvision (16 of the re-clustered banners), GoAhead (8), Dahua (6), running VxWorks 6.9, ~50% on CHINANET — carry CVE-2021-36260 and CVE-2017-7921, both CVSS 9.8 and on the CISA Known Exploited Vulnerabilities catalog. Here the specific vuln set is the recruitment signature for that proxy tier: the operator picked exactly the camera models those CVEs open. The vulnerability points at the operator's chosen infrastructure, not at plain exposure. (See EvilTokens, Chawkr. The cameras' precise role, whether proxy relay, C2 relay, or credential exfil, is explicitly three hypotheses, so read the vuln set as a recruitment signature, not a confirmed function.)

The same logic shows up in the patching dimension. When a known CVE, say an HTTP/2 or TLS-stack flaw, clusters tightly across a credential-harvesting cohort, and end-of-life server builds run well above the normal rate of slow patching, that is not random neglect. It is a maintenance posture: a steady choice to deploy the same stale stack and never patch it. Maintenance posture is part of the operator's signature, just as the chosen camera models were in EvilTokens.

One thing we must not flip around: the explorative study's CVEs (CVE-2012-4360, CVE-2022-28330) are named there as sources of false clustering signals, features that created fake similarity across unrelated families, not operator fingerprints. Do not read them as vuln-as-signature; that would turn the article's own warning on its head. The ICS study's CVEs, likewise, are exposure/EPSS scores, not operator choices ("EPSS scores don't confirm exploitation"). The tuned patterns that tip the product-vs-posture call are held back.

Do not let one feature decide the case, as a rule. Base the call on the cohort plus the context around it: what shows up together, how alike the members are, where they are hosted, which vulnerabilities are present and whether those fingerprint the service or the operator's config. Weak signals add up into a read. On its own, almost any signal is a lead, not a conclusion. We forget this constantly. We get one matching port, one matching hash, and we call it.

The clearest statement of this principle lives in the ICS exposure study. Its thesis is the doctrine itself: "No single data point tells the story. But when multiple weak signals align, they reveal something important." It then takes each lone signal and shows it harmless on its own ("Shared certificates? Maybe the same CA. Same TLS fingerprint? Same product. Same CVEs? Common vulnerabilities. Same services? Standard stack.") before landing the point: "But all four together reveal how ICS infrastructure actually gets deployed." The finding is the combination, not any single tag. It backs this with real multi-parameter queries (hash:334888494 port:502; hash:-499029242 org:"Metro Ethernet Access Services" port:21; and a four-parameter anomaly query — a DOM hash, a headers hash, an org: and a port together — narrowing to two hosts worldwide). (See Internet-Exposed Modbus/ICS Infrastructure, Chawkr. Its homogeneity caveat — "likely honeypot artifact" — and its "not a single operator... industry-wide pattern" thesis both apply: use it for the principle statement, not for attribution.)

EvilTokens supplies the working half — the compound query built by hand. Its rule is blunt: "Each query combines 5-8 parameters. A single parameter match is noise. The full compound query describes one operational tier and very little else." The backend JA3S 574866101f64002c6421cc329e4d5458 carries the note "generic TLSv1.3 response, useful only in compound queries," and the detection rules require all hashes to match — "individual hash matches are not sufficient." Five full compound Shodan queries are published, one per tier. The ICS study states the rule. EvilTokens shows you how to build the query.

Here is what the single-feature habit actually costs you, and why it should sting. The exposed-AI study takes its Amazon database clusters and strips them to one feature. They "reduce to something like port:3306, matching millions of MySQL instances globally (the largest cluster maps to ~3.15 million Shodan results). The databases hide in the noise while the web infrastructure stands out." The same host, placed inside a ±15 parameter compound profile, can be attributed. On its own, it is one of three million. You had the operator in your hand and the lone port threw him back into the crowd. The study's alerting guidance says the same thing — "alert on any combination of 3+ matching fingerprints," and clusters with too few features get no query at all "because there are no compound feature combinations to describe."

OVERCAST shows the same trade-off between being precise and casting wide. Its generic Windows-RDP JARM and JA3S are, in its own words, "useful only in combination with the certificate pattern and hosting provider, not from the hashes alone." When the full multi-parameter fingerprint was queried, six clusters returned zero external overlap. The query was "too specific to surface overlap, but... precise enough for high-confidence detection." The explorative study backs this from the other side: "universal features (HTTP responses, SSL patterns) appeared across all clusters, creating artificial similarity," and real structure showed up only when families "shared 1-5 key features" together.

The exception proves the rule. Now and then a single indicator is specific enough to stand almost alone: a reused leaked private key, a distinct self-signed cert serial copied across nodes, a JARM that maps to a known C2 framework build, or an out-of-place outlier that the noise re-analysis picks out. Even then we confirm it with something else before we commit. The discipline is matching confidence to how specific the signal is, not pretending every lone signal is worthless. (The field is migrating JA3 → JA4 precisely because fingerprint families drift. That is the temporal-churn point again, and the reason the method anchors on convergence and persistence rather than any one scheme.)

One discipline rides with every signal in this principle: check the ground truth before you trust a label from an automated tool. A framework-detection label, a product-classification string, a "this is Cobalt Strike / this is GoPhish" verdict from any scanner or enrichment service — these are leads to confirm, not facts to report. Before a label turns into a finding, check it against the host's own evidence: its banner, its certificate, the response it actually serves. Carry the tool's label forward only after the host itself agrees with it.

There is a quieter way this fails, one analysts least expect: a good signature can still misfire when you match it against the wrong field or the wrong input. A real, high-quality string or hash that truly does mark a given tool will still throw false positives if you run it over inputs it was never meant to see: a numeric malware indicator that happens to collide with an unrelated structural ratio, or a substring that lands in a field holding the same characters for innocent reasons. The signature is not the problem. Its input scope is. Checking the ground truth tells you which one broke, a bad signature or a good one fed the wrong features, and the two fixes are opposite: retire the signature, or fix what you feed it. Skip the check and you hit the worst case: you label a real, harmless service as the thing the panel was built to impersonate. That is exactly the mistake the impersonation discriminator above is built to catch.

Watch how weak signals accumulate into a read on a generic credential-harvesting cohort:

• Signal 1 — Certificate pattern. A self-signed cert with a tooling-default issuer org on a non-standard admin port. Alone: a tooling default present on thousands of unrelated hosts. Noise.
• Signal 2 — Port layout. That same admin port carrying a proxy service, with JARM absent on 443. Alone: an unusual but explicable config.
• Signal 3 — Hosting posture + co-occurrence. A specific favicon hash recurring with the above across dozens of assets spanning 20+ countries and 30+ providers.

What this reveals: the combination — non-standard admin port + proxy service + the specific favicon hash + tooling-default cert + absent JARM on 443 — returns near-zero matches when you run it as a validation query against live counts. Not because any one piece is rare, but because the combination describes one operational tier. That is a high-precision tracking signature. The single favicon hash on its own would have been one of millions.

Look at the same evidence more than one way, and trust the structure that holds across all of them more than the structure that shows up under only one. Every method puts its own shape on the evidence: a clustering run, a hand-drawn link chart, a statistical model, a second analyst working the same data cold. Some of what any one method "finds" belongs to the evidence. Some of it is just an artifact of the method. The way to tell them apart is to look again, a different way, and keep what does not move. This is a robustness check, necessary but not sufficient, not a machine that tells you the truth.

When several methods are run over the same evidence and the same starting population, they are not independent witnesses. Their agreement rules out one specific failure, structure that is only an artifact of how a single method draws its boundaries, and that is its whole job. It does not clear the biases the methods share. If the underlying features were the wrong features, or the starting population was already dirty, every method carries that flaw forward and they will agree on the error. Those failures are cleared only by an independent source: different data, not a different method (passive DNS, victimology, vendor reporting; a second scan provider, Censys against Shodan). Read multi-method agreement as robustness against method artifacts, structure that stays stable across how you looked. It is never proof the structure means something, and never attribution.

Keep the "the methods disagree on the details" point honest. Each method has its own settings and its own sensitivities, so a difference in their outputs mixes two separate things: a real difference in what the methods see, and plain sensitivity to how each one was tuned. Check for agreement on the conclusions, not on every number along the way. Do not treat every difference as a meaningful finding.

This is the analytic-confidence idea that grown-up intelligence work and scientific practice already enforce: a result reproduced by an independent method is stronger than a result produced once. The doctrine puts it where it is rarely made routine, the metadata left behind after an incident. The discipline is the re-analysis you can run yourself and get the same result every time, not any one engine.

A worked instance: one phishing-tooling cohort, examined three independent ways. The example uses ClusterHawk's three analytical passes — call them core, deep, and advanced — and each one resolves the same cohort by a different method. But the lesson does not depend on the method, so read "three passes" as a stand-in for any three honest attempts to find the structure. We describe it here anonymously, with no codename, IP, or case-identifying counts, because the teaching is in the shape of the agreement, not the case. Every other named exhibit in this article was examined only one way and, by its nature, cannot illustrate this principle; this cohort was the one taken through all three passes in full.

The first thing to expect is that the surface details will differ across the three, and that they are allowed to. That is not a contradiction; it is the point. They are three different methods, not one method run three times: each draws the boundaries its own way, so one may split the cohort into many more groups than another. How finely the data gets split is a property of the method. The reliability signals are what you check for agreement.

And the reliability signals did converge:

• The same anomaly rate — the same low-single-digit-percent fraction of the cohort surfaced as most-critical under all three passes, not three different rates.
• The same multi-operator verdict — the hypothesis scoring put a coordinated-campaign explanation and a red-team / authorized-simulation explanation within a few points of each other, then refused to choose, applying an honest non-discrimination cap (a self-imposed ceiling on confidence when the available evidence genuinely cannot separate two competing explanations) because the dataset carried no victimology, payload, or temporal evidence to break the tie. The cap held identically across all three passes.
• The same surfaced outlier — the single most structurally unique asset in the dataset was isolated not by the main grouping but by the re-analysis of what the main grouping had set aside as noise (Structural Anomaly Detection / Noise Intelligence Mining), as an outlier even among outliers — and the same asset surfaced under every pass.

One pass alone could show none of that, because a single method can invent apparent structure out of its own shape. Agreement across three is structure that stays stable no matter which method you choose. The honesty caveat from the top of this section still holds: the three passes share the same features and the same starting cohort, so they back each other up. They are not independent witnesses. Their agreement rules out method artifacts. It does not rule out feature-selection or cohort bias, and it is not attribution. An independent source (passive DNS, registration data, victim telemetry, vendor reporting) would still be needed to say who operated anything.

A secondary touchpoint: the exposed-AI study was examined two ways rather than three, and the article treats their agreement as the proof point, "both converged on the same findings... that convergence is the validation." Two methods is a partial demonstration of the same principle, weaker than three but identical in idea, so it serves as the published honorable-mention cross-reference. (See Profiling the Largest Identifiable Exposed AI Infrastructure on the Internet, Chawkr.)

The Higher Rung: Survive a Change of Source, Not Just a Change of Method

Surviving a change of method is the first half of this principle. The second half is older and stronger, the oldest discipline in intelligence work: surviving a change of source. A human intelligence service does not act on what one agent reports. A single source, however well-placed, is a lead. It becomes intelligence only when an independent source confirms it, and big decisions wait for two or more. The field even grades the source and the claim apart from each other (how reliable is the source, how believable is the specific report), and a shiny, decisive report from one uncorroborated source is treated as exactly that: uncorroborated. The romantic picture of the lone operative whose word sets things in motion is fiction. In real work, that word would be run down through other channels before anyone moved on it. This is all-source intelligence, and it is the same principle as multi-method convergence, taken one step further: there, you change the method over one body of evidence; here, you change the evidence itself.

The word that carries the weight is independent. Two reports that trace back to the same origin are not two sources. They are one source counted twice, and treating that as corroboration is how analysts talk themselves into false confidence. This is exactly why the multi-method agreement above is honest about its own limit: several methods run over the same evidence and the same starting population are not independent witnesses. They guard against one failure mode, the artifact of how a single method draws its boundaries, and they say nothing about the biases they share. Agreement across methods that share an input is real corroboration of one thing (robustness to how you looked) and no corroboration at all of another (whether the evidence or the population was right in the first place).

So read the doctrine's whole verification stack as a corroboration ladder, weakest to strongest, in exactly the intelligence sense:

• Within one method, the conjunction corroborates — Principle 4's compound signature is many weak features agreeing, which beats any single feature but is still one analytic source.
• Across methods, convergence corroborates against method artifacts — Principle 5, necessary but not sufficient, because methods over a shared input are dependent.
• Across independent data sources, validation corroborates the substance — passive DNS, registration records, victim telemetry, a second scan provider (Censys against Shodan), and published vendor reporting are the genuinely independent witnesses. Agreement here is what lets a hypothesis graduate from "structurally robust" to "actually true," and attribution lives only at this rung.

The rule that falls out is simple and travels well: match your action to the number of independent sources, and never let a single source, however vivid, become a verdict on its own. The tempting finding, the one clean indicator that seems to crack the case, is the one to distrust most until something independent confirms it. This is the same instinct the ground-truth discipline enforced earlier, where a tool's label is a source to confirm, not a fact to report, turned into a standing habit: one source is where the work starts, never where it ends. Do not stop at the indicator. That is where the investigation begins.

A doctrine shown on one dataset reads as one lucky case. Shown on many, it reads as a method. Here is the whole body of evidence at a glance. Each principle sits on the published case that shows it best, and the spine operation (EvilTokens) keeps coming back so you can follow one operation looked at again from every angle.

Now the longer threads. We already walked EvilTokens from every angle in the principle sections, so the table above is just an index back into those, not a re-walk.

The Convergence Thread: One Cohort, Three Methods, End to End

The convergence principle is best walked through one anonymized cohort taken through all four moves: an internal phishing-tooling cohort examined three independent ways. No codename, no IPs, no counts that would name the case. The value is in the sequence, so follow the order.

Move 1 — Cohort seed. A tooling cohort seeded on a GoPhish/Evilginx-style profile: the whole population running the toolkit, not one favicon.

Move 2 — Persistent fingerprints. Read the durable setup, not the throwaway IPs: a tooling-default self-signed cert issuer on a non-standard admin port, the same title / DOM / favicon hashes again and again, and a proxy service on that port. All of it held across dozens of hosts and all three methods while the IPs churned across 30+ providers. The IPs move; the setup stays, and that is what we are supposed to be reading.

Move 3 — Attack vs after-attack. The cluster context split the live end from the residue end. The live end: exposed admin panels, self-signed tooling certs, the non-standard admin port. The residue end: load-balancer-fronted landing pages, no panel, no SSH. The EOL maintenance posture on the vulnerable-server clusters read as operator config, not as a product just lagging behind on its own.

Move 4 — Convergence. The surface details changed from method to method, as expected. The signals that matter agreed across all three: the same low-single-digit-percent anomaly rate, the same capped multi-operator verdict, and the same single surfaced outlier (an asset the main grouping missed entirely, which the noise re-analysis then picked out as the most structurally unique host in the dataset). The ceiling on all of it: three methods over one input is robustness, not independent corroboration. Confirming who operates this would still take an independent source.

The verdict. The clustering did not point to a single operator. It pointed to an industry-wide GoPhish deployment pattern, a template shared across what may be many independent operators and authorized red teams alike. The hypothesis engine capped the coordinated-campaign and red-team hypotheses within a few points of each other, because passive data cannot tell malicious phishing apart from authorized simulation without victimology it does not contain. Passive analysis can pin down the infrastructure's shape with confidence; it cannot prove who walked the chain. The structure is real; the attribution is not ours to assert from metadata alone.

The Anomaly Payoff: What Re-Mining Noise Reaches

The single most under-used move in the whole casework is going back to what the main clustering threw away as noise. We have everything we need to do it, and we still close the alert instead. EvilTokens is the payoff for doing it. Eight IPs the main clustering had labeled noise, re-analyzed on their own, "grouped into a coherent cluster of compromised surveillance cameras": a whole IoT proxy layer the article says "doesn't appear in any existing EvilTokens research" and "was invisible in primary clustering, emerging only when outlier IPs were re-clustered independently." A pivot never reaches a layer that, by definition, shares nothing with the seed. Drop the indicator in a blocklist and you never see this layer at all.

The exposed-AI study is the number-rich backup. Re-clustering its 142-IP outlier group gave "33 of 142 IPs (23%) re-clustered into identifiable XRUI sub-patterns" (Similarity Group 5: 34 IPs, score 0.849), and the standout anomaly 117.72.118.118 reportedly "shares XRUI features across multiple similarity groups but operates from a different ASN." The study reads this as the operator's footprint reaching beyond the core range. An org: pivot would miss exactly that different-ASN reach. (See the exposed-AI study, Chawkr.)

Two cautions, and keep them. OVERCAST's and the ICS study's noise work only re-ranked unstable mid-rotation IPs. It surfaced no hidden layer, so they cannot carry this principle. The anomaly scores quoted above (the 0.849 similarity-group score, and the score outputs in general) are reported as results; how the scoring works inside stays out.

Here is the whole ask: stop shipping out-of-the-box rules and build from the threats your own environment actually faces. We were handed the data and a method that works, and we keep reaching for the default rule pack. Here is how the four moves turn into detection.

A compound hunting query is built from a cohort, not a single feature. The shape matters more than any one value:

# Cohort-derived compound signature (template — fill load-bearing values from your own fresh data)
ssl.cert.issuer.org:<persistent_cert_issuer_org>
port:<admin_port>
http.favicon.hash:<favicon_hash>
http.title_hash:<title_hash>
-ssl.jarm:<value_absent_on_443>          # the structurally telling absence is part of the signature
# Validate against live counts before trusting. Near-zero global matches = high-precision tier signature.
# A single parameter match is noise. The conjunction is the finding.

One Sigma-style rule, compound over single-feature, illustrating the shape of a credential-harvesting management tier (fill the load-bearing values from your own fresh data):

title: GoPhish-Tier Campaign-Management Host (Compound)
description: >
  Detect a credential-harvesting management tier via a multi-parameter conjunction, not a single hash. The shape is the
  signature: a tooling-default admin service on a non-standard port, a recurring favicon, and a structurally telling
  absence on 443.
detection:
  selection:
    destination.port: <non_standard_admin_port>
    http.product: "<admin_or_proxy_product_string>"
    http.favicon.hash: <cohort_derived_favicon_hash>
  filter_jarm_present:
    ssl.jarm|exists: true
    destination.port: 443
  condition: selection and not filter_jarm_present
fields:
  - destination.ip
  - http.host
note: >
  Compound fingerprint — all of selection must match; the absent JARM on 443 is part of the signature. Re-seed on fresh
  data as infrastructure rotates; the favicon hash alone is a tooling default and is not actionable in isolation.
confidence: HIGH

The relaxation discipline comes from the KeeneticOS case: "the original profile may no longer be effective so try to remove and change some values, since infrastructure changes." A signature is a snapshot, not a standing truth. Re-seed on fresh, self-served data, and drop the features that have churned: shed the most rotation-prone first (a port, then a fingerprint hash), and keep the most durable layer for last, following the durability gradient.

Map the four moves onto the frameworks your team already runs, so you can hook this onto work you already do:

A careful analyst could, in principle, do every move in this doctrine by hand. What turns it from an art into a repeatable discipline is that a pipeline runs it the same way every time. In every case here the input was a population: a published IOC list, a same-window cohort, a raw mixed corpus, a tooling seed. ClusterHawk took that population, not a single pivot, and ran it end to end. First it filters honeypot and decoy infrastructure out before analysis. In the ICS study that step dropped an apparent 95.99% homogeneity to under 2% once the decoy artifact was removed. Then it sorts each cohort into operational tiers through ensemble clustering across several complementary views. It scores each cluster's stability and separation in plain Good/OK ratings, so weak structure is flagged rather than dressed up. Finally it re-mines what the main clustering threw out as noise. That last step, Structural Anomaly Detection and Noise Intelligence Mining, is where the layers a pivot can never reach come to the surface, and it is the engine behind the anomaly payoff. On top of the clusters it adds SHAP/LIME explainability (model-agnostic methods that tie a result back to the specific input features that drove it) on each cluster's medoid (the most central real member of a cluster, its stand-in host) and its borderline members, the compound multi-parameter hunting queries the detection section is built on, and a hypothesis engine that scores competing readings and caps its own confidence when the evidence cannot tell them apart.

Two honesty points hold the section up. The results are repeatable, but only under set conditions. For a fixed input dataset and a fixed pipeline version, the clustering, the anomaly set, and the outputs stay the same from run to run. That comes from pinned seeds and version-locked transforms, not from any claim that the methods are repeatable on their own. Across different scrapes the results are expected to differ, and that difference is the time-based core of the whole doctrine. The second point: the machine and its domain engineering do the analysis; the language model only writes the prose around the result. The cluster counts, the anomaly rate, the surfaced-outlier finding, and the tier structures throughout this article are outputs of the pipeline, identical on re-run, not written by a model. ClusterHawk does not invent structure. It shows the structure that is really there, and it tells you, just as readily, when that structure is an industry-wide pattern and not one operator. The pipelines, the key processing steps, and the noise mining are documented in the open; the tuned feature weights that turn this method into a product are not.

ClusterHawk is Chawkr's infrastructure clustering platform. The method is documented at https://clusterhawk.chawkr.com/docs/analysis/pipelines-overview and https://clusterhawk.chawkr.com/docs/analysis/noise-intelligence-mining; platform overview at https://clusterhawk.chawkr.com.

Seed from behavior. Mine for what lasts. Read the residue. Trust what survives every lens — and act only on what an independent source confirms.

The doctrine finds what a single-indicator pivot cannot: the configuration posture that lasts, the shape the operator leaves after the attack, the layer set deliberately apart from the cohort. EvilTokens' camera proxy tier hid in the noise. The most structurally unique outlier of a phishing-tooling cohort came up only in the noise re-analysis, never from the main clustering. The KeeneticOS network's recurring fingerprint — the same firmware everywhere plus the operator's proxy overlay — outlived every IP it ever ran on. A pivot reaches none of them.

Most of this doctrine asks you to take something on trust — the convergence cohort is internal, the tier roles are analytic reads, the thresholds are held back. So rest the doctrine's credibility on the one claim you do not have to take on faith. The central thesis — IPs churn, the configuration posture endures — is auditable, and the receipts are public. The OVERCAST and Nightfall IOC feeds carry full commit history at the URLs in the Sources section, and the numbers behind it are laid out in The churn, measured above: OVERCAST holds a near-constant live fleet while its IP layer recycles every two weeks under a windows-{City} certificate convention that never moves; Nightfall fades toward death while the same title/favicon/DOM composite still catches its twitches of reactivation. Two opposite churn signatures, one law. Don't take our word for it — pull the repository and diff the commits. That is the proof the rest of the method stands on.

Tiered operators are the norm now, not the exception. The access tier and the control tier are built not to share a single thread, and the live attack has usually moved on by the time you get there. So here is the invitation, and the whole point of the piece: do not just close the alert and drop the indicator in a blocklist. The threat actor is still out there, and the data they left behind is already exposed — on Shodan, in the certificate, in the noise the clustering set aside. Read that residue — the fingerprint that persists, the configuration posture, the outlier that sits out of place — track the operator, and bring the threat down. This is a discipline you can teach and repeat, not a knack. We were handed the house and we keep wiping our feet on the doormat. Think, don't just google.

Track the configuration posture, not the address. Read the residue, check the ground truth against an independent source, and trust what survives every lens. The IP is the doormat; the operator's configuration posture is the house. Pivoting finds the doormat — doctrine finds the house. We were handed the house. Stop wiping your feet on the doormat and walk in.

Chawkr / ClusterHawk casework cited

All Chawkr casework below is published at https://chawkr.com/threat-intel/all

• Chawkr — EvilTokens: Device Code Phishing Goes Industrial — spine exhibit: tier-death, attack-vs-after-attack, reverse-proxy wall, vuln-as-signature, compound queries, anomaly payoff https://chawkr.com/threat-intel/eviltokens-device-code-phishing

• Chawkr — Explorative Clustering of Malicious Infrastructure with ClusterHawk — P1 cohort-seed: 2,714 IPs / 44 families into 60 clusters with no prior training https://chawkr.com/threat-intel/explorative-malicious-infrastructure

• Chawkr — When Your Router Becomes Someone Else's Weapon: Uncovering a 800+ Proxy Network via KeeneticOS Router — P2 persistence: one rigid firmware fingerprint plus operator proxy overlay across disposable IPs; composite-relaxation guidance https://chawkr.com/threat-intel/keenetic-proxy-botnet-analysis

• Chawkr — OVERCAST: Tracking 1,900 Nation-State RDP Nodes Across Cloudzy's C2P Ecosystem — P2 co-anchor: ~800 IPs / 2-week churn vs durable windows-{City} cert template; P4 zero-overlap clusters https://chawkr.com/threat-intel/overcast

• Chawkr — The Pattern in the Noise: What 1,602 Exposed Modbus Systems Reveal About Industrial Security's Systemic Failures — P4 principle statement: "all four together reveal how ICS gets deployed" https://chawkr.com/threat-intel/exposed-industrial-control-modbus-clustering

• Chawkr — Profiling the Largest Identifiable Exposed AI Infrastructure on the Internet — P4 lone-feature-is-noise; anomaly-payoff backup; two-tier convergence https://chawkr.com/threat-intel/bizarre

• Chawkr — ClickFix to NetSupport: Validating ClusterHawk, Cluster Profiles, and What's New — validation-seeding: reproduced eSentire's ClickFix→NetSupport chain, added a predictive WinRM admin signature https://chawkr.com/threat-intel/esentire-clickfix-to-netsupport-validation

• Chawkr — SystemBC Infrastructure Investigation — validation-seeding: confirmed Black Lotus Labs' SystemBC proxy botnet, added role-based tiers + anomaly scores https://chawkr.com/threat-intel/systembc-infrastructure-investigation-automated-insights

• Chawkr — SideWinder's Click Once campaign — independent validation with ClusterHawk — validation-seeding: confirmed Trellix's SideWinder campaign; separated ~85% CDN baseline from ~15% nginx lead cluster https://chawkr.com/threat-intel/trellix-sidewinder-validation

Principle 5 (multi-method convergence) is demonstrated on an internal, unpublished phishing-tooling cohort, described anonymously; there is no Chawkr writeup to cite.

Public IOC tracking feeds (auditable churn evidence for P2)

Auto-updated feeds with full commit history — the living proof that IPs churn while fingerprints persist. Diff the commits to verify the rotation, decline, and reactivation figures cited in "The churn, measured."

• Chawkr — OVERCAST IOC tracking feed (auto-updated) — P2 churn evidence: stable ~1,400–1,900-IP fleet whose IP layer almost fully recycles per fortnight https://github.com/chawkr/iocs/commits/main/overcast.txt

• Chawkr — Nightfall IOC tracking feed (auto-updated) — P2 churn evidence: KeeneticOS network peaked 786, collapsed ~98% to 12, still emitting fresh-IP twitches https://github.com/chawkr/iocs/commits/main/nightfall.txt

Methodology and field references

• Shodan — Internet-wide scan-data platform — the metadata source for all analysis in this doctrine https://www.shodan.io

• David J. Bianco — The Pyramid of Pain (2013, updated 2014) https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html

• Sergio Caltagirone, Andrew Pendergast, Christopher Betz — The Diamond Model of Intrusion Analysis (2013) https://www.activeresponse.org/wp-content/uploads/2013/07/diamond.pdf

• Joe Slowik (DomainTools) — Formulating a Robust Pivoting Methodology (white paper) https://www.domaintools.com/white-papers/formulating-a-robust-pivoting-methodology

• Censys — Advanced Persistent Infrastructure Tracking (2020) https://censys.com/blog/advanced-persistent-infrastructure-tracking/

• Silent Push — What are Indicators of Future Attack? https://www.silentpush.com/blog/indicators-of-future-attack/

• FoxIO — JA4+ Network Fingerprinting Suite (2023) https://github.com/FoxIO-LLC/ja4

• John Althouse (Salesforce Engineering) — TLS Fingerprinting with JA3 and JA3S — the primary source for the JA3/JA3S limits this doctrine relies on (a lone JA3 collides across hosts sharing a TLS library) https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/

• John Althouse (Salesforce Engineering) — Easily Identify Malicious Servers on the Internet with JARM (2020) — the source for the JARM points here https://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a/

• HITB — JARM Randomizer: Evading JARM Fingerprinting (HITBSecConf 2021) https://conference.hitb.org/hitbsecconf2021ams/materials/D2%20COMMSEC%20-%20JARM%20Randomizer%20Evading%20JARM%20Fingerprinting%20-%20Dagmawi%20Mulugeta.pdf

• Intel 471 — How initial access offers power intrusions and ransomware — IAB → affiliate → operator tiering in the ransomware economy https://www.intel471.com/blog/how-initial-access-offers-power-intrusions-and-ransomware

• Hunt.io — A Hunt How-To: Detecting RedGuard C2 Redirector (2024) https://hunt.io/blog/detecting-redguard-c2-redirector

• MITRE — ATT&CK: Acquire Infrastructure (T1583), Compromise Infrastructure (T1584), Proxy (T1090), Stage Capabilities (T1608) https://attack.mitre.org

• CISA — Known Exploited Vulnerabilities Catalog (CVE-2021-36260, CVE-2017-7921) https://www.cisa.gov/known-exploited-vulnerabilities-catalog

• Rapid7 — Ransomware-as-a-Service Cheat Sheet (2023) — the layered IAB → affiliate → operator division of labor in the RaaS economy https://www.rapid7.com/blog/post/2023/08/22/ransomware-as-a-service-cheat-sheet/

• Cyberint — A Deep-Dive Into Initial Access Brokers: Trends, Statistics, Tactics and more — the IAB tier feeding RaaS operations https://cyberint.com/blog/research/a-deep-dive-into-initial-access-brokers-trends-statistics-tactics-and-more/

• Vectra AI (Joshua St. Hilaire) — C2 Evasion Techniques: Understanding JA3/S Randomization and Cipher Stunting — randomized ClientHello / cipher stunting defeating client-side TLS fingerprinting https://www.vectra.ai/blog/c2-evasion-techniques

• Stamus Networks — Adapting to Change: JA3 Fingerprints Fade as Browsers Embrace TLS Extension Randomization https://www.stamus-networks.com/blog/ja3-fingerprints-fade-browsers-embrace-tls-extension-randomization

• Conti leaks (2022) — leaked internal chats/playbooks exposing the group's shared infrastructure and tooling across operational roles (analysis: Infosec Institute) https://www.infosecinstitute.com/resources/malware-analysis/behind-the-stage-conti-leaks-before-and-after/