One Threat Actor, Five Names: How to Track APT Aliases Across Vendor Reports
Midnight Blizzard, Cozy Bear, APT29, NOBELIUM. Why the same threat actor has different names across vendors, what breaks when aliases aren't managed, and how to build an alias-aware actor knowledge base that stays accurate as reporting piles up.
Open five threat reports on the same intrusion campaign and you will often find five different names for the actor behind it. One vendor uses an animal, another a weather event, a third a numbered designation, and a government advisory something else entirely. Each name is "correct" inside its own vendor's reporting, and each one quietly fragments the picture for anyone trying to follow the actor over time.
For analysts, this is not a trivia problem. It decides whether a new report gets recognized as more evidence on a group you already track, or gets filed as a brand-new unknown. This guide explains why the naming problem exists, what it costs when it goes unmanaged, and a practical workflow for handling aliases without merging things you shouldn't.
Why One Actor Ends Up with So Many Names
Nobody coordinates a single global naming scheme, and the reasons go deeper than branding:
- Different telemetry, different views: Each vendor sees the world through its own customers, sensors, and incident response engagements. Two teams can cluster the same activity differently because they observed different slices of it.
- Different naming taxonomies: Vendors maintain their own conventions, and some have changed them. Microsoft, for example, moved to a weather-themed scheme in 2023, so older and newer reporting can use different names for the same activity.
- Clusters get promoted and renamed: Many teams start with a temporary designation for an unattributed cluster, then graduate it to a named group once enough evidence accumulates. Reports written before and after that change use different labels.
- Government and community names add layers: Advisories, ATT&CK group entries, and open-source research each bring their own labels and their own scoping.
A Quick Example: Same Activity, Different Labels
Names on the same row are widely treated as referring to the same or heavily overlapping activity, but the overlap is rarely a perfect 1:1 match, and that caveat matters:
| Commonly Cited Group | Names You May See Across Sources |
|---|---|
| APT29 | Cozy Bear, The Dukes, NOBELIUM, Midnight Blizzard |
| Sandworm | APT44, Voodoo Bear, IRIDIUM, Seashell Blizzard |
| Lazarus Group | HIDDEN COBRA, Labyrinth Chollima, ZINC, Diamond Sleet |
What Goes Wrong When Aliases Aren't Managed
Duplicate profiles split your evidence
Without alias tracking, "Cozy Bear" and "Midnight Blizzard" become two separate notes, two folders, or two rows in a spreadsheet. Each holds half the evidence, and neither tells the full story.
New reports get misread as new threats
If an analyst doesn't recognize a vendor's name for a group already on the radar, a relevant report gets triaged as "unknown actor" and the connection to existing intelligence is missed entirely.
Detection coverage has gaps
Detection engineers rely on a complete picture of an actor's techniques and tooling. When reporting is scattered across names, TTPs that appear under one alias never reach the team writing detection rules based on another.
Over-merging is just as dangerous
The opposite mistake is treating every alias as perfectly identical. Two vendors' clusters may overlap without being the same, and silently collapsing them can attribute one group's behavior to another. An alias is a claim, and claims need sources and confidence.
5-Step Workflow for Tracking Aliases That Holds Up
- 1. Pick One Canonical Entity per Actor: Choose a single anchor record to hold everything you know. Which name you use matters less than using one consistently, so evidence always accumulates in the same place.
- 2. Record Every Vendor Name as an Alias, with Its Source: Note who uses each name and where you saw it. "Midnight Blizzard (Microsoft reporting)" is far more useful six months later than a bare name in a list.
- 3. Capture Evidence at the Moment You Read It: Preserve the excerpt, source URL, and timestamp as you find them. Attribution claims are the first thing challenged, and the original page may not stay online.
- 4. Link Observables, Malware, and Tools to the Entity, Not a Name: Domains, IPs, file hashes, and tool families should attach to the actor entity itself, so intelligence from any vendor's naming ends up in one connected record.
- 5. Track Confidence and Revisit Merges: Note whether an alias mapping is well established or tentative. When new evidence shows two clusters diverging or converging, adjust the relationship instead of rewriting history.
For a deeper look at why attribution compounds over time, see Why Threat Actor Tracking Falls Apart . To make steps 3 and 4 fast, read How to Turn Unstructured Web Research into Mapped MITRE ATT&CK Intelligence.
Managing Aliases and Actor Profiles with HC IntelLab
HC IntelLab
RECOMMENDEDHC IntelLab is built for the workflow above. Instead of keeping actor names in scattered notes, analysts create a single entity per adversary and build everything else around it.
- Capture at the source: the browser extension records highlights from any report with the URL, page title, and timestamp, so every alias you encounter keeps its evidence trail.
- One entity, many sources: link evidence from different vendors' reports to the same threat actor entity, and attach analyst notes explaining which names map to it and why.
- Connect the surrounding picture: attach domains, IP addresses, file hashes, and email addresses, and link the actor to its malware and tools to keep related intelligence in one graph.
- Build on MITRE ATT&CK: map private findings against ATT&CK actors, adversary aliases, and tools, layering internal intelligence on top of community knowledge.
- Share with your team: shared workspaces let teammates see the same entities, notes, and comments, so nobody researches the same actor twice under a different name.
The Free plan includes 200 captured highlights and 50 entities, enough to start building an alias-aware actor library without a credit card.
Frequently Asked Questions
Why do different vendors use different names for the same threat actor?
Each vendor tracks activity using its own telemetry, naming scheme, and clustering methodology. The same campaign can therefore be grouped and labeled differently, and some vendors have also changed their naming conventions over time.
Does a shared alias mean two groups are definitely the same?
No. Aliases often reflect strong overlap, not perfect equivalence. Treat each mapping as a claim with a source and a confidence level, and revisit it as new evidence arrives.
How should I store aliases for a threat actor?
Keep one canonical actor entity and record each alias against it, noting which vendor or source uses the name. Link evidence, observables, malware, and tools to the entity itself rather than to individual names.
Can HC IntelLab track threat actors across multiple vendor reports?
Yes. You can capture evidence from any web report, link it to a custom threat actor entity, attach notes and observables, and map the actor to MITRE ATT&CK, all in one shared workspace.
One actor. One profile. Every report.
Capture evidence from any vendor report, link it to a single actor entity, and build intelligence your whole team can search and trust.
Try HC IntelLab Free