Threat Actor Naming Hell: APT28, Fancy Bear, or STRONTIUM?

One group, eight names

A CTI report lands in your inbox warning about Forest Blizzard. Your SIEM watchlist says APT28. The MISP event you imported last week tags Sofacy. A colleague swears the relevant campaign was Fancy Bear. Congratulations: you have spent twenty minutes confirming that all four names describe the same GRU-linked intrusion set.

This is not an edge case. It is the default state of threat intelligence, and it costs analyst time every single day. Here is a partial alias list for that one group:

Nine names, one adversary. Multiply that by the hundreds of tracked groups and you understand why alias mapping is a discipline of its own.

Why vendors will never agree

The cynical explanation is marketing: a memorable name like Fancy Bear generates headlines, and no vendor wants to promote a competitor's brand in its flagship report. That is real, but it is not the whole story. There are legitimate technical reasons too.

Visibility differs. Each vendor sees the adversary through its own telemetry. Microsoft sees identity attacks and O365 abuse. CrowdStrike sees endpoint tradecraft. Proofpoint sees phishing waves. Each builds a cluster from a different slice of the same activity, and those clusters rarely have identical boundaries.

Clustering methodology differs. A vendor names an activity cluster, not a human organization. Mandiant may merge two clusters that CrowdStrike keeps separate, because their evidence thresholds differ. Saying "APT28 equals Fancy Bear" is shorthand for "these two clusters overlap heavily", not a mathematical identity. Sometimes the overlap is partial, and blindly merging aliases imports someone else's attribution errors into your database.

Renaming happens. Microsoft threw out its entire chemical-element taxonomy in April 2023 and moved to weather names. Overnight, STRONTIUM became Forest Blizzard and NOBELIUM became Midnight Blizzard. Every internal wiki that hardcoded the old names silently rotted.

The major taxonomies, decoded

Once you know each vendor's scheme, a name alone tells you who is talking and what they believe about the actor.

Mandiant: numbers and confidence tiers

• APT + number: state-sponsored espionage (APT1, APT28, APT29, APT41)
• FIN + number: financially motivated crime (FIN7, FIN8, FIN11)
• UNC + number: uncategorized clusters that have not yet earned a merge or a graduation (UNC2452 was the early name for the SolarWinds activity)

The UNC system is the interesting part: it makes uncertainty explicit. A UNC number is a promise that the cluster is real but the attribution work is unfinished.

CrowdStrike: animals by country

The animal encodes the assessed state sponsor or motivation:

So Fancy Bear tells you "Russia, state-linked" before you read a single sentence. Wizard Spider tells you "criminal". The adjective is the group identifier; the animal is the attribution claim.

Microsoft: weather families

Since 2023, Microsoft uses weather themes with the same logic:

• Blizzard: Russia (Forest Blizzard, Midnight Blizzard)
• Typhoon: China (Volt Typhoon, Salt Typhoon)
• Sandstorm: Iran (Peach Sandstorm)
• Sleet: North Korea (Emerald Sleet)
• Tempest: financially motivated
• **Storm-****: temporary designation for clusters in development, the equivalent of Mandiant's UNC

Everyone else

Secureworks uses metals (IRON for Russia, BRONZE for China, GOLD for crime). Proofpoint uses TA numbers with no attribution baked in. Unit 42 uses constellation names. Kaspersky and ESET tend to name groups after malware families or strings found in samples (Sofacy, Sednit), which is why their names often predate everyone else's.

Mapping aliases without losing your mind

You cannot stop the naming chaos, but you can contain it. The practice that works:

Pick one canonical name per actor. Internally, every group gets exactly one primary identifier. A common choice is the MITRE ATT&CK group ID (APT28 is G0007), because it is vendor-neutral and stable. Every ticket, detection, and report uses the canonical name; aliases live in a lookup table.

Treat aliases as claims, not facts. Record who asserts the equivalence and how strong the overlap is. "Microsoft maps Forest Blizzard to what Mandiant calls APT28" is verifiable. "They are the same" is a shortcut that will eventually bite you when two vendors split a cluster.

Use existing mappings before building your own. The MITRE ATT&CK group entries list associated names with references. The MISP Galaxy threat-actor cluster is community-maintained and machine-readable. Neither is perfect or fully current, but both beat a hand-rolled spreadsheet.

Automate the lookup. The alias table only pays off if analysts hit it reflexively. Wire it into your enrichment pipeline so that any actor name in a report resolves to the canonical ID before it reaches a ticket.

A minimal registry entry looks like this:

actor: G0007
canonical_name: APT28
attribution: Russia, GRU Unit 26165 (high confidence, multiple governments)
aliases:
  - name: Fancy Bear
    source: CrowdStrike
  - name: Forest Blizzard
    source: Microsoft
    note: formerly STRONTIUM (pre-2023)
  - name: Sofacy
    source: Kaspersky
  - name: TA422
    source: Proofpoint
last_reviewed: 2026-02-10

The last_reviewed field matters more than it looks: alias sets drift as vendors merge, split, and rename clusters, so schedule a periodic review of the actors you actually track.

Or let someone else maintain the table

Maintaining alias mappings for every group you might ever encounter is a poor use of analyst time. This is exactly why actors.mlab.sh exists: 500+ threat actor profiles where each group carries its full alias list across vendor taxonomies, alongside targeting, tooling, and the CVEs the group is known to exploit. Search for "Forest Blizzard", "Sofacy", or "TA422" and you land on the same APT28 profile. That single page replaces the twenty-minute cross-referencing ritual at the top of this article.

Whatever tooling you use, the principle stands: resolve names once, at ingestion, against a maintained reference, and never let raw vendor names propagate into detections or reports unmapped.

What a name is actually worth

A closing caution. Vendor names compress a lot of analytic judgment into one label, and it is tempting to treat them as ground truth. They are not. They are cluster labels with confidence attached, drawn from partial visibility. When two reports disagree about whether an intrusion was Midnight Blizzard or APT29, the interesting question is rarely the name; it is which observed behaviors overlap and what that means for your defenses.

Track the aliases so you can read everyone's reporting. Then spend your energy on the TTPs behind the name, because those are what will show up in your logs.

The name is a pointer, not the payload. Dereference it fast and move on to the tradecraft.