Cyber Attribution: Confidence and Competing Hypotheses

Cyber attribution connects an activity to an entity through reasoning that another analyst can examine. A group name displayed beside an IOC is the output of an earlier judgment. Before repeating it in your report, understand what was attributed, when, from which evidence, and against which alternatives.

In a September 10, 2026 Reddit discussion, an author asks whether a proposed intelligence report is useful and includes severity, confidence, and associated actors in its structure. The question exposes an analytical writing problem: those fields describe different things. The thread is a starting point, not a technical validation of the method below.

This guide develops a judgment record that can be challenged and revised. It supports defensive decisions without turning infrastructure resemblance into an accusation.

Define exactly what you are trying to attribute

“The same actor” can conceal several propositions. Two files might belong to one malware family. Two websites might use the same kit. Multiple intrusions might form a campaign. A campaign might connect to an operational team and, with further evidence, to an organization directing or financing it.

Each proposition requires different evidence. A common code function helps establish a software relationship; it does not prove who executed the software. A campaign name can group observations without resolving the operator's identity. A commercial actor label can cover a different set of activities from another vendor's label.

Write the exact proposition first: “Sites A and B were administered by the same team during the period examined.” You can then determine whether the evidence answers that question. “Everything belongs to group X” combines too many claims into one conclusion.

The guide to infrastructure clustering with passive DNS and certificates provides investigative leads. Preserve each relationship's type: shared hosting, a common certificate, identical code, or observed administrative control. These relationships cannot substitute for one another.

The worked Diamond Model investigation helps organize the entities and relationships before you evaluate competing explanations for them.

Specify the time boundary as well. Evidence connecting two hosts during a past campaign may not describe their current owners. An attribution without a period encourages downstream readers to apply it indefinitely, even after the infrastructure changes hands.

Separate observations, assumptions, and judgments

An observation describes what a source allows you to establish. An assumption bridges a gap needed for the reasoning. A judgment is the conclusion reached from the evidence you accept. Mixing these categories makes the assessment harder to review.

The ODNI ICD 203 analytical standards call for distinctions between information, assumptions, and judgments, explanations of uncertainty, and analysis of alternatives. They govern the US intelligence community. Here they are a methodological reference, not a claim that the directive imposes duties on your company.

A working file might contain these three entries:

• Observation: pages collected from two domains contain the same form.
• Assumption: this version of the form is not publicly distributed.
• Judgment: the deployments could share an operational origin.

The assumption is decisive. If the form comes from a widely available kit, its ability to distinguish operators decreases. Show where that assumption was checked, or keep it explicitly unresolved. Omitting it invites the reader to treat resemblance as identity evidence.

Preserve the collection method too. A directly observed page capture, a description in a report, and a copy of that description in an aggregator have different evidential roles. The guide to evaluating CTI sources helps examine that chain.

An observation can itself be wrong. Keep the original artifact, collection time, and any processing steps so a reviewer can check whether a parser, timezone conversion, or incomplete capture changed its meaning.

Keep likelihood, confidence, and severity separate

Likelihood addresses how plausible the proposition is. Confidence concerns the strength and stability of its foundations. Severity describes the possible consequences for the affected scope. An attack with serious consequences can still have a low-confidence attribution.

The UK framework Explaining Uncertainty in Intelligence Assessment distinguishes probability language from confidence ratings. It also explains why precise percentages can imply a measurement that the available information does not justify.

Write the judgment and its basis separately. For example: “Common administration is the most plausible explanation. Confidence is low because the artifacts come from one collection and their exclusivity has not been established.” This gives the reader a usable limitation without manufacturing a number.

If your organization adopts probability terms, choose an explicit convention and use it consistently. Do not mix words from different scales while assuming that they cover identical intervals. The FIRST curriculum on uncertainty in CTI reporting provides another reference and recommends qualifying analytical judgments.

A high-confidence label needs reasons specific to the case. “Multiple sources” is insufficient if they all repeat one report. Explain the independent observations, their limitations, and the information that could change the assessment.

Confidence also belongs to a particular claim. You might have strong evidence that two sites share a kit but weak evidence that one team runs them. A single confidence badge covering the entire case conceals that difference.

Develop hypotheses that evidence can challenge

Analysis of competing hypotheses, or ACH, examines alternative explanations instead of accumulating support for the first one. The CIA Tradecraft Primer describes the technique and its attention to disconfirming evidence. It structures discussion; it does not mechanically turn a collection of clues into truth.

For a case involving two phishing sites, plausible hypotheses could be:

• H1: the same team administers both operations.
• H2: separate teams use a shared service supplying part of the infrastructure.
• H3: independent deployments reproduce components available in a common kit.

Clarify what distinguishes H2 from H3. Is the common service still operating during the campaigns, or was a component simply copied? Without that distinction, the explanations overlap and comparing them becomes confusing.

Retain an unresolved explanation category when the evidence does not allow you to describe alternatives adequately. It is better to acknowledge a gap than invent an implausible third hypothesis to favor the first. The exercise concerns credible explanations and allows the question itself to be reframed.

Invite a reviewer to propose an alternative before showing your preferred conclusion. That small organizational choice can reveal an assumption that would otherwise shape the entire review. It is not a guarantee against bias, but it gives disagreement somewhere to enter the process.

Worked example: two sites and three explanations

Every artifact in this example is synthetic. The domains alpha.example and beta.example represent pages collected in a training exercise. They are not infrastructure to visit or block.

First observation: the pages look the same. H1 explains this, but so do H2 and H3. The observation supports closer comparison while doing little to distinguish the scenarios. Do not count every shared image as an independent confirmation.

Second observation: the pages use the same collector identifier. The team checks whether it belongs to a customer's configuration or appears in a generic kit release. Until that question is answered, the identifier does not establish common control. Keep it in the restricted evidence file without publishing a value that could be sensitive.

Third observation: hosting periods overlap. The timeline weakens some explanations based on simple sequential reassignment of an address. It does not exclude shared hosting or a common service. The finding improves a temporal relationship, not the identification of its operator.

Fourth observation: a kit copy contains the same default configuration. This weakens the use of the identifier as specific attribution evidence. The assessment should change even if an earlier presentation already grouped both sites into one operation.

The case can now group the sites for a search for similar behavior while withholding a conclusion about the operating team. That is still useful: it defines investigative checks without exaggerating what the evidence establishes.

Record the change explicitly. A reader who saw the earlier version should not have to compare two large reports to discover that the supposedly distinctive configuration was actually a default.

Find evidence that can distinguish the scenarios

After the first observations, the next question is not merely which other indicator resembles the existing ones. Ask what information could make one explanation less plausible than the others.

In the fictional case, verified evidence of distinct administrative accounts might support H2 or H3. An independent observation linking both deployments to the same administrative operation could strengthen H1, within the scope of that observation. Evidence that the service was resold would give H2 more support. None of this information should be assumed available.

Define the collection that might illuminate each point and the limits of access. An enterprise team should work with authorized sources, its own telemetry, and evidence provided through appropriate partners. Lack of access to decisive evidence is a result to report, not a reason to fill the gap with stronger language.

For every missing observation, ask whether your sensors could have detected it. Logs that do not collect administrative events cannot exclude common administration. “Not observed” becomes meaningful only when visibility is explained.

The guide to investigating IOC alerts with IP, DNS, and process evidence covers local correlation. That correlation can establish activity in your environment without identifying the person or organization behind it.

Maintain a judgment record that can be revised

A judgment record connects the conclusion to decisive evidence rather than to the size of the case file. The following is an original working template:

Judgment:
Exact proposition and relevant period:
Preferred hypothesis:
Alternatives still plausible:
Decisive observations and references:
Evidence contradicting the conclusion:
Dependent sources and repeated reporting:
Unverified assumptions:
Confidence and reasons:
Information that would change the judgment:
Supported decision and limits on use:
Author, reviewer, date, and version:

Give source dependence its own field. If report A is repeated by B, C, and D, preserve a provenance chain instead of counting four confirmations. If B also has independent collection, separate that portion from its repetition of A.

The record should survive a change of analyst. “Obvious attribution after pivoting” does not help a successor. Describe the pivot, the observed relationship, and why it matters. Report history and evidence reuse can support this continuity through dated observations.

Keep the review proportional to the intended use. A temporary internal cluster label and a public allegation have different consequences. The latter requires an appropriate review of its wording and evidential scope before release.

Connect attribution to an actual defensive decision

A SOC can hunt a technique, isolate a compromised endpoint, or revoke a session based on established local facts. It does not have to wait for an organization name before taking those actions. External communication identifying an operator, however, needs review appropriate to its consequences.

State whether attribution changes the hunt scope, telemetry selection, or response priority. If it does not affect immediate action, keep it as context rather than allowing it to displace operational evidence.

Do not distribute an analytical relationship as a blanket blocking rule. Associating one domain with a cluster does not make every customer of its hosting provider malicious. The guide to IP reputation false positives explains why the scope of an observation must remain visible.

When an IsMalicious reputation result contributes to the investigation, preserve its verdict, date, and exact role in the file. That enrichment helps examine infrastructure. It does not replace the evidence connecting an activity with its operator.

Revise attribution without erasing the earlier reasoning

New evidence can change a judgment without making the original investigation worthless. Issue a corrected version explaining what changed: a withdrawn source, a now-public artifact, a chronology error, or an additional observation. Identify recipients whose decisions depended on the earlier conclusion.

Retain the previous version as historical evidence and clearly identify the current version. If the attribution fed rules, tickets, or supplier records, check those outputs too. Correcting only the report paragraph leaves the consequences of the mistake in circulation.

A final reviewer should be able to answer three questions: which proposition is supported, why it is supported, and what could overturn it. The actor's name can remain unknown. Traceable reasoning still allows the team to choose and revise its defensive actions.