Two Vendor Names, One Loader: Modelling Attribution Without Overclaiming
Meridian Threat Intelligence tracks a cluster of intrusions against logistics firms. Two feeds describe it: Vendor A calls it 'Silent Chollima' and publishes a report covering January to March 2024; CERT-B publishes 'Storm-0921' covering April to June 2024. The overlap is a command-and-control domain registered through the same registrar, one custom loader sharing the same two unusual imports, and identical technique sequences: T1566.001 Spearphishing Attachment, T1059.001 PowerShell, T1105 Ingress Tool Transfer and T1071.001 Web Protocols. Vendor A asserts the cluster is 'linked to APT29' because the loader's C2 domain was once used in a campaign attributed to that group. Your manager wants the whole thing encoded in the platform as a single intrusion set named APT29, and wants the old detection rules keyed on the vendor names retired and replaced with rules that reference the group name instead.
1. How should the two reporting periods and the loader be represented in the ATT&CK data model, and what should be done with the APT29 label?
Read the worked answer
Separate the three things that are currently fused into one name.
Activity over time - Campaign. Each reporting period is a bounded set of activity with a first-seen and last-seen date. Encode Vendor A's January-to-March activity as one campaign and CERT-B's April-to-June as another, or as one campaign if your analysts judge the activity continuous; the model supports either, and the dates make the judgement auditable. Campaign objects carry their own identifiers and their own procedure examples, which is exactly what you lose by collapsing everything into a group.
The loader - Software. ATT&CK's Software category covers both malware and legitimate tools, so a custom loader belongs there with its own identifier, its observed behaviours and any hashes you hold. If it has no public name yet, you can still track it locally; unnamed does not mean unmodelled.
The group - Intrusion Set. Encode an intrusion set only at the confidence your evidence supports. Shared infrastructure and a handful of identical techniques are the weakest form of linkage: tooling is bought, leaked and reused, and infrastructure is deliberately shared to mislead. Vendor A's claim rests on a domain that was once used by an attributed campaign - that is a lead, not a finding.
Practical answer: create the campaigns and the software now; create your own cluster label for the intrusion set and record APT29 as an assessed association with a confidence and a citation, rather than renaming the cluster APT29.
2. What evidence would justify linking this cluster to APT29, and how should the platform record the difference between a confirmed and a suspected link?
Read the worked answer
Weak evidence, on its own: shared C2 infrastructure, a domain registered at the same registrar, a common loader, matching ATT&CK technique sequences, targeting of the same sector. All of these are consistent with a single actor and equally consistent with shared tooling, a contractor reused by several actors, a false flag, or two unrelated clusters running the same commodity kit. Technique sequences in particular are the least discriminating evidence available - the four techniques here are among the most common in the entire matrix.
Stronger evidence: unique code artefacts (a distinctive encryption routine or build path), reuse of credentials or certificates, an operational slip that ties infrastructure to a persona, telemetry showing the same operator infrastructure being configured from the same host, or a government attribution that publishes its evidence rather than only its conclusion. Corroboration across independent sources matters more than volume of overlaps.
Recording it: keep the uses-style relationships but attach your own confidence and free-text rationale rather than letting the graph imply certainty. Where ATT&CK itself links a group to a campaign or a piece of software, note that this reflects MITRE's assessment with cited reporting, not a verified fact; the group page is a summary of public reporting, and much of it hedges with 'likely'. A one-line rationale on each edge means the next analyst can re-evaluate the judgement instead of inheriting it silently.
3. The manager wants detection rules rewritten to key on the group name. Explain the problem and what the rules should reference instead.
Read the worked answer
Keying detection on a group name couples your detection estate to an attribution that is provisional and to a string that is almost guaranteed to change. Vendor names churn constantly; clusters get merged, split and renamed, and the platform's own labels are a local convention. Every rename becomes a rule-maintenance task, and every rule whose only distinguishing feature is a name will match either too much or nothing.
Rules should reference observable behaviour and the ATT&CK identifiers that describe it:
- Technique and sub-technique IDs - T1566.001, T1059.001, T1105, T1071.001 - which are stable across renames and only change through documented deprecation with a
revoked-bytrail. - Concrete artefacts where you have them: the loader's hashes and imports, the C2 domain patterns, the parent-child process relationships seen in the reporting.
- The campaign or software identifier, which is narrower and better evidenced than the group label.
Use group names for context and reporting, never as a matching predicate. Two further points: keep the technique-level rules generic enough to catch the next cluster with the same behaviours, and note in the rule metadata which technique it covers so that the coverage map stays accurate when the intel picture is redrawn. The correct response to the manager is that group names belong in the briefing, not in the detection logic.