Does a threat-intelligence match identify an offender?¶
Not by itself.
A match may show that your incident shares infrastructure, malware, tooling or techniques with activity seen elsewhere.
That can be genuinely useful. But technical similarity is not the same as identifying the person or group behind your incident.
Start with exactly what matched¶
Different matches have different weight.
| Match | What it may support |
|---|---|
| Exact malware hash | The same file appears in both incidents |
| Dedicated server | Shared infrastructure may exist |
| Certificate or unique identifier | Strong technical relationship may exist |
| Malware family | Similar tooling, but possibly widely available |
| Shared cloud IP | Often weak because infrastructure may be shared |
| Common technique | Usually too broad for offender identity by itself |
Do not let a broad match sound more specific than it is.
Separate technical association from actor attribution¶
A useful relationship might look like:
The first two can be strong without automatically resolving the third.
Keep the intelligence wording intact¶
If the source says:
“associated with Group X”
do not silently turn that into:
“Group X carried out this incident”.
Preserve:
- source;
- publication date;
- confidence;
- observation period;
- what the assessment actually covers.
Use the match to develop the enquiry¶
A threat-intelligence match may justify:
- preserving related infrastructure records;
- searching for linked domains or certificates;
- comparing other incidents;
- identifying known malware behaviour;
- prioritising provider requests.
Then build attribution from the local evidence.
The practical point is: report what the intelligence match genuinely connects. Treat offender identity as a separate conclusion that needs incident-specific support.
