An IP address, malware hash, or shared hosting provider rarely identifies an operator by itself. Attribution is an assessment built from multiple evidence types, each with limitations. Bulk analysis can help organize indicators and find possible relationships, but it cannot turn a reputation label into proof of who conducted an intrusion.

Separate observations from hypotheses

Start by recording directly observed facts: which system saw an address, when it appeared, what process or account was involved, and which file hash was collected. Keep provider statements and analyst inferences in separate fields. For example, “two hosts resolved to this address on these dates” is an observation; “the same operator controlled both hosts” is a hypothesis requiring more support.

Assess each evidence type

• Infrastructure: compare DNS history, certificates, hosting, and timing where the data is available. Shared cloud or hosting infrastructure is common and weak on its own.
• Files: compare exact hashes, code similarities, signing information, and execution behavior. Similarity can indicate reuse or copying, not necessarily common authorship.
• Behavior: examine repeated tactics and sequences in local telemetry. Common tools or techniques may be used by unrelated actors.
• External reporting: preserve the publisher, publication date, cited evidence, and confidence language. Multiple reports may rely on the same underlying source.

Build a time-bounded relationship map

Normalize indicators and link them to observations with timestamps. Group candidates by evidence such as repeated contact patterns, passive DNS changes, certificate reuse, or file similarity. Record the basis for each edge and its time range. A shared ASN, country, malware family label, or reputation score should not be presented as a strong relationship without corroboration.

Test alternative explanations

Ask whether a shared service, a compromised third party, recycled infrastructure, copied tools, or unrelated activity could explain the same observations. Search for evidence that would weaken the hypothesis as well as evidence that supports it. If key alternatives cannot be excluded, state that limitation.

Communicate confidence and scope

Use the confidence terms and definitions adopted by your organization, and explain which evidence supports the assessment. Distinguish confidence in an infrastructure link from confidence in operator identity. Limit conclusions to the time period and activity actually examined; one campaign or tool match does not establish responsibility for other incidents.

In operational reports, a useful conclusion may be “activity is consistent with a previously reported cluster, but attribution is unconfirmed.” That communicates a lead without overstating what the evidence proves.

Keep the analysis reproducible

1. Preserve source records and query dates for each indicator.
2. Record collection gaps, provider limitations, and possible data reuse.
3. Keep observations, assessments, and confidence separate.
4. Revisit the hypothesis when new evidence or corrections appear.

Infrastructure analysis is most valuable as a way to prioritize investigation and form testable hypotheses. Restraint is part of good attribution: describe what the evidence supports, and leave unknowns visible.