What a Threat Actor Name Buys You

Threat intelligence reporting is full of names. APT29, Lazarus Group, Sandworm, Mustang Panda. They arrive with a confidence that suggests a known organisation with a known payroll. They do real work, and they also carry less than most readers assume. That gap can be measured.

MITRE ATT&CK tracks the named-adversary layer publicly. We counted it.

What is actually being tracked

176 groups. 697 techniques. 825 distinct pieces of malware and tooling. That is the whole public named-adversary catalogue, and it is smaller than the discourse around it suggests.

The first useful number is how much of the technique catalogue any single group actually accounts for. The median tracked group has 19 recorded techniques — 2.7% of the catalogue.

A group name, then, doesn't describe an adversary's total capability. It describes a set of observed behaviours—in the median case, a tiny fraction of what is known to be possible. The busiest group in the catalogue, Kimsuky, has 130 techniques recorded. APT28 and Lazarus Group have 93 each. Those are the outliers, and they are outliers by a factor of five over the median.

The alias count is the attribution problem, made countable

Across those 176 groups there are 425 aliases — a mean of 2.4 alternative names each. The most-aliased are worth listing:

It is tempting to file this under industry untidiness: too many vendors inventing their own labels. That reading is too comfortable.

Those names were not assigned to a known entity by different people. Each one was created by a vendor who observed something — an intrusion set, a cluster of infrastructure, a pattern of tooling — and named what they had. The later claim that fifteen such observations are all the same actor is an analytical judgement, not an administrative merge.

Sometimes that judgement is well supported. In other cases, two clusters are merged based on thin overlap. A report on "APT28" might then be describing behaviour from an intrusion set the reader isn't thinking of. The alias count, then, is a rough proxy for how many separate observations have been analytically merged into a single identity.

69 of the 176 groups have no alias at all — a single vendor's naming, unreplicated by anyone else.

A third of catalogued behaviour belongs to nobody

Add up every technique used by every one of the 176 named groups and you get 498 of the 697 — 71.4%.

Which means 199 catalogued techniques are attributed to no named group at all. They are documented, real, and used — that is why they are in the catalogue — but they have not been tied to an actor anyone has named.

A detection strategy built only around known groups is therefore ignoring a third of the available data. That unattributed third isn't exotic; it's the ordinary work of uncatalogued criminal operators and one-off intrusions.

When a group name is the right tool

This doesn't make attribution useless, just narrow. A group name answers a more specific question than its confident use often implies.

A group name earns its place when you are anticipating what happens next. If an intrusion matches a group's documented pattern, their previously observed behaviour is a reasonable prior for what follows — because operators reuse what works, and changing habits is more expensive than changing infrastructure.

It is useful for sector targeting. Knowing that a group has historically gone after financial services in your region is a real input to how much you invest.

It is much weaker as a basis for public claims. The distance between "this matches the documented pattern of a group we call X" and "country Y attacked us" is enormous, and it is routinely collapsed in reporting. The evidence that supports the first almost never supports the second, and the people best placed to know this are usually the most careful about saying it.

How to read a report that names a group

When reading an intelligence product that leads with an actor name, ask three questions:

• Which name, and whose? If the report uses a vendor's own label, the underlying observations are that vendor's. That is not a flaw, but it bounds the claim.
• Is the behaviour or the infrastructure being matched? Infrastructure overlap is weak evidence — servers get resold, reused and shared. Behavioural overlap is stronger and harder to fake.
• What would this change? If the answer is nothing, the name was decoration.

The vulnerability half of the same problem is covered in from feed to decision. The harder question — what any of this demonstrably stops — is taken up in can you prove an attack was prevented.

What the catalogue cannot tell you

ATT&CK records observed and published behaviour. That has two consequences the numbers above must be read through.

A group with few recorded techniques may be quiet, or may simply be less studied. Four of the 176 have no recorded technique at all. Thin coverage tells you about publication rather than about attackers. It is a fact concerning researchers, and it should not be read as a measure of the adversary.

And the catalogue is shaped by who does the publishing. Groups that target well-resourced Western organisations get written about by well-resourced Western vendors. A group operating primarily against organisations in this region may be documented thinly or not at all, and its absence from a list of 176 says nothing about whether it is operating.

Counts are from the published MITRE ATT&CK Enterprise data on 19 August 2026, with revoked and deprecated objects excluded; the script is in our repository. We have written separately on how much of the AI threat matrix is ordinary security, which uses the same source from the other end.