How to Read and Validate ClusterHawk Reports

• 1.1 Executive Summary: BLUF, Infrastructure Overview Table, Key Findings, Risk Assessment.
• The standing signature qualifier lives here, stated once for the whole report: every query, pivot and detection signature in the document is a candidate pattern. Matches identify hosts sharing that pattern, they require per-host verification, and they are not a confirmed-indicator list. That qualifier holds for everything downstream and is deliberately not repeated under each rule.
• 1.2 Priority Actions Reference: the top actions, drawn from Section 5.
• 1.3 Attribution Summary: the primary hypothesis with its Section 4 assessment. If no hypothesis that needs a single operator beats the null hypothesis, the summary says the data does not establish coordinated operation, and you should treat attribution as undetermined.

• Clusters grouped only when they share something distinctive: the same configuration, fingerprint composite or service stack, not merely the same provider or a common default. A cluster that shares nothing distinctive stands alone.
• What each group is, its role, which side it reads from, and its hunt priority.
• MITRE ATT&CK tactics per group, each carrying a side: whether the tactic describes something the hosts are equipped to do, or something an attacker would do against them.
• The Infrastructure Inventory Summary (asset counts and primary providers per cluster).

The three most significant clusters are profiled in full. Selection is deterministic rather than a matter of taste: a detection signature that names malicious tooling or an actor first, then anomaly concentration, then whether the cluster yields a candidate anchor, then confirmed known-exploited vulnerabilities, then size.

Each portrait runs as four numbered subsections, then a hosting and trackability block, finally the verdict.

1. Threat Intelligence & Technology Stack

• Detection Signatures, with the share each matching rule holds on a host, for example CobaltStrike:50%/GoPhish:50%. That split is a share between the rules that matched, not a confidence: a host matched by a single rule always reads 100%. Read what the signature names. The detection rules are the ones you set up for the job, so they can name malicious tooling, an actor, a device class, a service role or a legitimate application, and a match may be saying "this is a Cobalt Strike server" or "this is a mail server" or "this is a Plex box." Those are different findings and the report treats them differently: only a signature naming tooling or an actor carries threat weight. A match is also a lead to confirm rather than a fact to report: the report checks it against the host's own banner, certificate and service surface, and says whether that evidence backs it up.
• Product and technology families, and whether the version spread indicates maintenance or its absence.
• Vulnerability Intelligence: whether a CVE fingerprints the product (incidental, every host on that version carries it) or the operator's configuration posture (a signature). The identifiers, counts and KEV status live in 11.3.

2. Infrastructure & Network Profile

• Network services: the exposures that carry meaning, including a service the host's role does not need, a critical exposure, or a surface whose absence is itself the finding.
• Reverse-proxy and fronting posture: whether anything refuses direct requests without an onward redirect.
• Certificate and cryptography: issuer conventions read through durability and residue, not restated as statistics. Issuer class on its own says little now that most legitimate sites use free, automatically issued certificates. Where a certificate or hostname carries a recognisable organisation's name, whose base domain it sits under and whether the spelling is a lookalike say far more.
• Industrial protocols (ICS): BACnet, Modbus, Siemens S7 and similar, when the assets expose OT services. A high-signal finding that usually sits outside standard IT detection tooling.
• Exposed databases: MongoDB, Redis, Elasticsearch, MySQL, and whether authentication is enabled.

3. Cluster Validation & Uniqueness

• The compound query that projects the cluster's profile, with its real-world match count.
• Alongside it, the reduced pivot: a three to five term subset, durable and selective enough to actually return a population. The full conjunction is precise and usually unrunnable. The pivot is what you run first; you narrow to the full conjunction once you have hosts to narrow. Pivot terms may be positive or negated, and a negation counts as a full term. The hosts a pivot returns are a new cohort worth running through an analysis of their own, and an anchor that keeps holding as that population is refreshed is one worth following.
• A commodity match count (millions) flags a generic cluster. Baseline it, do not track it as an actor.
• Where the emitted query understates the profile because the provider cannot express the cluster's strongest features, the report says so in a clause. Read that clause. It is the difference between "we cannot find these hosts" and "Provider has no filter for the thing that identifies them."

Read a zero-match result against the query's specificity, not as a uniqueness score. This is the single most common misreading of the report. A conjunction stacking fifteen or more exact terms, including content hashes and certificate fingerprints, returns zero for almost any host group, benign ones included. Zero there is the expected outcome and tells you nothing about whether the infrastructure is unusual, purpose-built or targeted.

Zero on a low-specificity query is different: port plus product plus organization, no stacked hashes, no matches means something. That is a real uniqueness signal.

What a zero-match compound query does give you either way is a precise re-identification signature: a future host matching the whole conjunction is a strong candidate for the same cohort. Candidate, not confirmed. Verify per host before you act, and never publish these as an IOC feed or wire them to automatic blocking.

• If a cluster's profile contains no term the analysis can argue is non-base-rate, the report says so and emits no reduced pivot for it. That absence is deliberate and it is information: a pivot built from a default SSH algorithm list or a common-stack TLS fingerprint returns the base rate, which is worse than nothing because it looks like a result.

4. Statistical Analysis & Overlap

• Shared components and fingerprints with other clusters, and whether the overlap is a genuine relationship or a base-rate coincidence. The report lists some overlaps specifically in order to dismiss them.
• The adversary-versus-victim verdict, which is one of the two load-bearing judgements in the portrait. Everything downstream inherits it: the tactics cell in 2.A, the technique readings in Section 3, the role classification in 7.2, and how any Section 9 rule scoped to that cluster is framed.
• The medoid (most representative member) and borderline IP: what defines the cluster's identity and where it blurs.

Hosting, Identity and Trackability (closes each portrait)

• Hosting strategy: provider spread, geography, and what the procurement shape implies. The percentages themselves are in 2.A and 11.3.
• Cluster identity: the highest-importance differentiating features, including defining absences, which are part of the identity rather than a separate list of things not observed. For each one the portrait says whether the cluster shares a value or only the field sets it apart. A content hash that differs on every host can separate a cluster perfectly while no two members share it, and that hash is not the cluster's fingerprint.
• Instance validation: the medoid's defining traits and how the borderline asset diverges. When an explanation rests on things the host lacks that almost every other host lacks too, it confirms nothing, and the portrait says so.
• Quality, but only where it changes the verdict. A cluster whose members the methods grouped confidently while the hosts themselves disagree about what they are cannot be tracked as one thing, and the portrait says so. Where quality has no bearing on trackability, the portrait skips it and the numbers stay in Section 12 and 11.3.

Tracking verdict (the last line of every portrait)

One line, and it is the line to read if you read nothing else in the portrait:

Tracking verdict: Track / Track with verification / Do not track, with the anchor's name, its layer, and what would falsify it.

• Layer answers whether the anchor identifies the operator's own configuration, the vendor's product, or neither. A composite that fingerprints a camera model will match cleanly on thousands of unrelated units of the same model. It is an inventory finding, not a campaign anchor, and the report will say so rather than letting a clean match flatter you.
• Falsified by is the result that should make you drop the anchor. Read it before you commit a day to a lead. If it says "none stated," the anchor is not ready to track.
• Do not track is a real verdict, not a failure. Most clusters in most jobs earn it. When a cluster earns it, the portrait still carries the full evidence, because the profile is what justifies the negative call.

Where the numbers live. The portraits carry the argument. The reference tables (ports, products, CVEs, certificate statistics, provider percentages) live once, in Section 11.3. If you want the figures, go to the appendix; if you want to know what they mean, stay in the portrait.

Why this section enables actor tracking:

• Fingerprints and deployment templates persist across IP rotation, so you can follow infrastructure whose addresses churn.
• Compound profiles become predictive alerts. The compound, not any single parameter, is what makes the alert high-precision.
• High Metric Amber differentiators identify signature behaviors: the more a feature is over-represented against the dataset, the more distinctive it is, provided a real share of the cluster carries it. A feature on a quarter of the cluster or less is reported as a subgroup marker held by a named number of hosts, however high its lift, because a large lift on two hosts out of two hundred says something about those two hosts, not the cluster.

Pro tip: extract the fingerprints and the reduced pivot from each portrait, put the pivot into continuous monitoring, and pull exact values from Section 11 for platform integration. Never deploy a single-parameter match as a detection. It will be noise.

The section opens with the modelling basis and its limits, and that paragraph is worth more than the table under it. The analysis models observable configuration: what a host is equipped to do, and what its setup implies about who assembled it. It cannot model traffic, payload, victim, authentication or sequence. That rules out kill-chain reconstruction, dwell time, intent, and any claim that an observed capability was ever exercised. A technique mapped here says the capability is present. It never says it was used.

Every row declares which side it is read from. A technique is either an adversary capability the host is equipped to exercise, or a victim exposure that makes the host a target. The same open port supports both readings, and a table that does not say which is quietly asserting the more alarming one. The reading also has to match that cluster's adversary-versus-victim verdict in its portrait, so a cluster called victim-side exposure cannot carry an adversary-capability row.

That constraint exists because the failure it prevents is a real one: mapping Command and Control onto clusters the analysis has just concluded are ordinary exposed web servers tells anyone skimming the table that the job found C2 infrastructure, when it found the opposite.

Progression narratives across clusters (staging to relay to C2) appear only when a coordination signal supports them. Absent that, the report says so rather than assembling a story out of host typology.

• The competing hypotheses, typically a null (H0: unrelated or typological), and two to three alternatives (multi-operator collection, coordinated service, red team versus malicious, IAB or APT staging).
• For each: an assessment of strong, moderate, weak or not supported, the evidence behind it with cluster references, and the disconfirming indicators in prose, which is where the analytical value sits.
• The assessment says how well the evidence supports a hypothesis, not how likely it is to be true, and the report does not attach a percentage to it. Passive metadata does not support that kind of precision.

Agreement between the report's own methods is not corroboration. Feature importance, instance-level explanation and cross-cluster consistency are three ways of looking at one input. When they line up, that means the finding is not an artefact of a single method. It does not mean three sources confirmed it. The report states this once and caps the confidence accordingly. Independent corroboration means something from outside the dataset: registration or passive-resolution history, a different scan provider, published reporting.

Cluster quality caps the assessment. A hypothesis whose central clusters all sit in the weak stability band cannot be assessed strong, and a Bad or Very Bad grade or poor separation on a central cluster lowers it one step further. The report says when a cap binds.

Two hypotheses with the same assessment is a finding, not a tie to break. When two readings describe the same observable pattern (malicious C2 and a commercial red team on identical fingerprints, say) and nothing in the data separates them, the report gives them the same assessment and says so. Do not pick a winner; the evidence that would separate them (victimology, payload, temporal batching) is not in passive metadata. Keep both hypotheses active and drive targeted collection.

All actionable recommendations in the report live here, and they are hunting actions rather than remediation advice. You do not own these assets and the report does not pretend otherwise.

• Priority Actions, ordered CRITICAL / HIGH / MEDIUM, each naming the cluster it applies to.
• Hunt Procedures, ordered by expected yield: what to enumerate, on which assets, and what result would change the reading. Anomaly investigation targets and pivot queries are here, referencing Section 9 by name.
• Pivot Indicator List: the addresses whose signature names malicious tooling or a malware, C2, botnet, stealer or RAT family. Device classes, service roles, security tools and legitimate applications are excluded by design. On a job with no tooling detections there is no list at all, and the report says so rather than handing you a list of your own mail servers.
• Collection Priorities: ordered actions matching the Section 10.2 ranking.

The pivot list is not a blocklist. These are starting points for investigation, not confirmed indicators, and the report will not issue a blocklist even when it could. Submitted datasets routinely contain live business web properties, payment service domains and commercial marketplaces. Blocking on cluster membership blocks those too.

Read all of it: the most interesting asset in a dataset usually lives in 6.B, not 6.A.

Read every anomaly against the dataset you submitted. The detector finds hosts that deviate from this dataset's structural center; it does not score against a fixed model of "malicious." That makes interpretation entirely dependent on what you seeded:

• On a confirmed-bad or C2 seed, the anomalies are the hosts that break the malicious bulk, which can mean benign contaminants, a misrouted host, or an operator who is structurally different from the rest. "Flagged" here does not mean "the worst one"; it means "the one least like the others."
• On a mixed or broad seed, the anomalies are the genuine structural oddities: the bespoke host in a sea of commodity tooling, the standalone node deliberately separated from the fleet.

Same host, different dataset, different verdict. That is correct behavior, not instability. The detector tells you what is structurally different; you decide whether different is interesting. This is also why the verify-ground-truth step matters: confirm a flagged host against its own banner and certificate before deciding what its difference means.

An even spread of anomalies is a valid finding. Every job flags its most unstable 5%, so the question is never whether anomalies exist. If they spread evenly across the clusters, the dataset is structurally uniform: a tight, templated population where nothing meaningfully stands out. That is a real, honest answer (often a strong signal of single-template infrastructure), not an empty report.

6.A Main Clustering Anomaly Analysis

• IPs with unstable cluster membership across the clustering runs (assigned to many distinct clusters, low neighbor consistency, high neighbor turnover), each with a severity of CRITICAL, HIGH or MEDIUM that ranks it within the flagged list.
• The Top-N most anomalous IPs with their distinct-cluster counts and key instability pattern.
• Common anomaly patterns and which clusters the instability concentrates in. Where the anomaly load clusters into one or two groups rather than spreading, that concentration is itself a finding about where the cluster boundaries are weakest. Small clusters are the exception: a cluster too small to expect even one flagged host fragments from run to run by nature, so the report calls its instability expected rather than concentrated.

6.B Noise/Outlier Re-Analysis: the high-value move

• The noise partition (Cluster -1) is re-analyzed on its own, producing noise sub-clusters plus residual outliers.
• The outlier hosts come in a review order. A host that breaks what its own siblings agree on (a cluster deviation) comes first, because that is measured against the host's own neighbours. Novelty, flagged by Method Vela, comes after: it says a host is unusual among the other outliers, which on scan data usually means unusual or misconfigured rather than malicious. Each host also carries a pointer to the main cluster it sits closest to.
• This is where deliberately-separated infrastructure surfaces, for example a pure single-tool detection sitting outside every main cluster. A same-indicator pivot never reaches these; the re-analysis does.
• Cross-system signal: an IP flagged in both 6.A and 6.B is the highest-priority target in the dataset.

6.C Anomaly Intelligence Categorization Matrix: for each kind of anomaly, its detection source, what it establishes and what it does not.

6.D Anomaly Cluster Profiles: per-IP narrative, what defines its assigned cluster and exactly how it diverges.

6.E Tool-Detected Outlier Profiles: assets carrying offensive-tooling labels that landed in noise, with their similarity-group and reverse-similarity-group memberships (low-importance features shared with other noise IPs, an infrastructure-reuse signal).

7.1 Attribution Indicators Analysis

• Infrastructure behavioral patterns and the attribution challenges they raise.
• Technical Tradecraft Assessment: default versus custom configurations, OPSEC sophistication, fronting, naming discipline.
• Procurement and selection patterns: provider strategy, regional alignment, certificate procurement.

Tracked Infrastructure Families. A family is a pattern that recurs across two or more independent contexts, where a context can be a cluster, a provider, a platform or a device family, on an indicator that survives base-rate discipline and sits outside the device-model layer. That last condition does the real work. Without it a vendor certificate convention spanning two device clusters and two carriers would qualify while an operator's build standard recurring across bastions, print controllers and database hosts inside one cluster would not, which is exactly backwards. Commodity provider overlap, common-stack TLS fingerprints and default algorithm lists never qualify.

An empty families table is a finding, not a gap. When nothing clears the gate the report says so and names what came closest and what it lacked. That tells you where to collect next.

The Anchor Register. Every anchor the report names anywhere, whether in a portrait verdict, a family, a detection signature or a collection target, is defined once here: name, parameters, the evidence classes those parameters span, layer, verdict, reduced pivot, and what would falsify it. Everything else in the report refers to it by name and carries none of the detail.

Names are derived from what the anchor is, not from the cluster number it landed in, because cluster ids are assigned per job and mean nothing outside it. Use the register name when you record an anchor in your own tooling.

7.2 Infrastructure Role and Vulnerability Analysis

Roles are assigned by model, not by pattern match. For each role the report states what the role predicts a host would present, what was actually observed, and what is missing or what competing role explains the same observables equally well. That third part is what makes the classification falsifiable, and where the prediction fails the honest output is Undetermined with the failure named. "Port 443 is open, therefore C2" fits most of the internet, and the report will not write it.

Operator roles (Command and Control, Data Staging, Proxy/Relay) cannot be assigned to a cluster the portrait verdicted victim-side. For those the report describes what the host is in its own right, and where relevant what it would be useful for if someone recruited it.

Where the report can tie clusters together through a shared, distinctive configuration, it says which clusters share it and what role split that implies. It does not infer command hierarchies or communication paths, because scan data cannot show them.

Gaps here are hunting gaps, not remediation gaps.

A gap is a detection objective this dataset cannot support a rule for. The report names the objective, why the artefacts do not reach it, and the specific observable that would close it. "Cluster 2's content hashes are fully fragmented, so the objective of re-identifying the cohort by content cannot be met; a stable certificate or service-stack composite would be needed" is a gap. "Cluster 2 has poor coverage" is not, and you should push back if you see it.

The section carries the job's single ranked list of visibility gaps, covering detection blind spots, fingerprint fragmentation that defeats transport-layer detection, certificate conventions outside any CA trust chain, and asset classes that produce no usable telemetry at all.

Every rule opens with a detection objective. A rule without one is a query, not a detection, and the objective is where most of the usable information sits:

• Objective: what the rule is meant to surface, in behavioural or structural terms rather than a restatement of its own syntax.
• Layer: whether a match identifies operator configuration, a device model or vendor firmware, or is undetermined. This matches the layer recorded in the Anchor Register.
• Expected match population: who else legitimately matches. Every rule here has a false-positive population, and naming it is what lets you triage. If the report cannot describe who else matches, it says so rather than pretending the rule is clean.
• Defeated by: the cheapest change that makes the rule stop working. A content hash dies when the page changes, a certificate convention dies when the operator regenerates, an absence-based rule dies the moment the cohort exposes the service. This is what tells you how long the detection is good for.

Where a cluster warrants no rule, the report states the objective anyway and explains why the data cannot serve it. That is the honest form of a coverage gap and it is more useful than silence.

Each rule also ships with its reduced pivot and its falsification condition, the latter by reference to the Anchor Register rather than repeated in full.

How rule confidence is counted. Confidence tracks the number of independent evidence classes a rule conjoins, not the number of values it stacks. The classes are service surface, product identity, certificate convention, transport fingerprint, naming, content hashing, and absence. Six hashes are one class. Three parameters drawn from three classes beat six drawn from one. Three or more classes is High, two is Medium, one is an investigation starting point however many values it lists.

This is why a short rule can outrank a long one. The strongest anchor in a report is often a three-term composite spanning an SSH configuration hash, a port and a private naming convention, while a nine-term conjunction of content hashes is one class wearing a lot of numbers. An exclusion clause is a full term and its class counts, so a rule combining a service surface, a product identity and a well-founded absence spans three classes and earns High Confidence on that basis.

Rules may draw on the whole profile, including features no scan provider exposes as a filter, because rule syntax is not bound to one provider's vocabulary. Pivots may not, because a pivot has to run.

10.1 Operational Security Assessment: sophistication reads per cluster, deployment template consistency, infrastructure persistence, and whether the population looks provisioned or accumulated. Watch for the firmware-versus-operator check: a rigid template riding on a single device family is the vendor's image, not a provisioning toolkit.

10.2 Risk Assessment Framework: operational risk per cluster (severity against exposure), then the report's single ranked list of tracking targets.

Intelligence Collection Value is where you decide what to do first. Every anchor in the Register appears here, ranked best first, with two columns worth reading carefully:

• Confirming source and access cost. What you need in order to confirm the anchor, and roughly what it costs you. "Obtain registration history" is a five-minute job if you already have the access and a procurement conversation if you don't. The report says which.
• Trivially discoverable. Whether the anchor would fall out of one obvious public query anyway. A wildcard certificate convention usually would. A configuration uniformity spanning heterogeneous platforms usually would not. An anchor that is both durable and non-obvious is worth more of your day than one that is merely durable, and this column is the only place the report tells you so.

The subsection closes with the negative verdict: every "do not track" collected into one statement of what is not worth pursuing in this submission, and why. Read it. A negative result you can point at is worth more than a hedge, and it is what stops the same submission being re-analysed next quarter on the assumption there was something in it.

• 11.1 Infrastructure Asset Lists: a census. Every cluster in the job gets one row (id, label, asset count, classification), ordered by size, with the reserved partitions last. Clusters that were profiled, that hold a concentration of anomalies, or that are reserved partitions also get a short note underneath. Everything else is the row alone, which is what keeps this readable on jobs with a hundred clusters.
• 11.2 Cross-Cluster Correlation Matrix: the top shared-indicator overlaps with confidence.
• 11.3 Infrastructure Profiles: detailed profiles for the three profiled clusters plus any cluster with an anomaly concentration not already among them. Exact fingerprint values live here, along with the reference tables the portraits do not repeat: ports, products, CVEs, certificate statistics, provider percentages. This is the source for platform integration.
• The Detection Query row carries two queries: the full profile conjunction with its match-count band, and the reduced pivot beneath it. Copy the pivot when you want hosts back and the full conjunction when you want to narrow a population you already have. Exclusion terms appear exactly as generated.
• The Tracking verdict row carries the verdict word and the anchor's register name, and nothing else. The layer, the falsification clause and the reasoning are in the portrait and the Register. If you want the full verdict, that is where it lives.

• 12.1 Dataset Composition: total IPs, clustered assets, noise and outliers (Cluster -1), honeypots (Cluster -2), NIL (Cluster -3). These counts are derived once, here, and every other section cites them unchanged. If two sections disagree on a count, that is a defect worth reporting.
• 12.2 Quality Metrics: per-cluster ratings for Metric Quartz (stability), Metric Obsidian (distinctness) and Metric Topaz (distribution), rolled into a grade (Very Good / Good / OK / Bad / Very Bad). "Unmeasurable" means the cluster is a single host and no metric could be computed, which is not the same as a low grade. Treat "OK" clusters as hypotheses.
• Content agreement sits beside those as a second and independent axis, measured on the hosts' own observed data rather than on the numeric matrix. The two routinely disagree, and the disagreement is the interesting part: a cluster the methods held firmly while its members agree least about what they are cannot be followed as one thing.
• Detection signature status for the job: how many hosts carry a signature naming tooling or an actor, and how many carry only signatures describing what the host is, stated once. If none names tooling or an actor, every attribution downstream rests on infrastructure pattern analysis alone.
• Query-specificity reading: each emitted profile classified as high or low specificity, with what its match count therefore does and does not license. This is the only place that calibration argument is made in full.
• Anomaly concentration: which clusters hold more flagged hosts than their size predicts. The flagged count and severity split are fixed by design, so the report does not present them as findings.

Read the quality rating honestly. A high "Very Good" share means clean typological separation, not proof of a single operator. Separation is about how distinct the groups are, not who runs them.