Methodology

The Registry

The registry merges actor records from MITRE ATT&CK®, the MISP galaxy, ETDA's Threat Group Cards and Malpedia into one actor per group and keeps the evidence for each merge.

Source records

2,971

Actors

1,096

Merges

1,875

Evidence links

4,440

Ambiguous aliases

133

Typed as software

5,253

Merges is the number of records folded into another record, which is source records minus actors. An evidence link is one shared name that joined two records. An ambiguous alias is a name that two ATT&CK groups both carry. Typed as software counts the names that belong to malware or a tool and to no actor.

How Records Are Merged

1. Names are normalized. The registry lowercases each name, folds full-width characters to plain ones, drops spaces and punctuation, and removes a trailing “Group” or “Team”. Digits stay, so APT28 and APT2 remain separate actors.
2. Shared names make candidates. Two records are candidates for a merge when they share a normalized name or alias. Each shared name is kept as an evidence link.
3. Some names are left alone. A shared name never merges two groups that ATT&CK lists under different IDs. The name is recorded as an ambiguity.
4. Software is not an actor. A name that matches a Malpedia malware family or an ATT&CK software entry, and no actor, is typed as malware or a tool and is not shown as an actor.

Match Against the Paper's Names

75.4% of the paper's names resolve to an actor

The CCS '25 dataset labels its reports with 443 actor names. The registry resolves 334 of them to an actor. Another 23 are typed as malware or a tool. The remaining 86 match neither.

• Resolved
• Typed as software
• Unmatched

Software names do not raise the match rate. It measures agreement with the paper's labels, not how many resolved names are correct, because a resolved name is only as reliable as the aliases behind it.

Ambiguous Aliases

Each alias below is carried by more than one ATT&CK group. The registry cannot tell which group another source meant by it, so it does not merge the groups and does not use the alias to link a report to either one.

Names That Did Not Resolve

These names appear in reports and resolve to no actor, most frequent first. A name typed as malware or a tool is software, not a missing actor. A name with no type may be an actor that none of the sources lists. The Name Guesses page gives a program's label for each one and the method's measured accuracy, with every label pending confirmation.

Report Dates

Each report has one date and a label for where the date came from. The first rule that gives a usable date wins.

1. The Malpedia library date recorded for the report's URL (malpedia-library).
2. The date at the start of the report's title (title-date). Some collections file a paper as "2014-11-14 - Title". The site uses that date when it is not later than the day ORKL added the report, and it removes the date from the title it shows.
3. The file creation date stored in the report itself (file-metadata).
4. The date ORKL added the report to its collection (orkl-ingest). This is when ORKL saw the report, not when it was published, so it can be later than the true date.

A date before 1990 or a placeholder such as 0001-01-01 counts as missing, and the next rule applies. A report that passes none of the rules is undated, and it is never in a timeline or a trend.

Report Links

A report can carry two addresses, and the site labels each one as the original publisher's page or as a copy. It decides from the address's host alone, never from the field the address was stored in, because a source can store a mirror where the publisher's link belongs. The About page lists every label.

1. Known copy hosts are copies. An address on vx-underground.org, archive.orkl.eu, app.box.com, web.archive.org, archive.org, archive.ph, archive.is or archive.today is labeled as a mirror, an archive or a snapshot, and is never labeled as the original. A GitHub address counts as a mirror only under the CyberMonitor account, because the same host also serves publishers' own repositories.
2. Hosts that serve other people's pages are not called the original. An address on a link shortener (t.co, bit.ly and similar), a reference site (Wikipedia, ETDA's Threat Group Cards or Malpedia), a file host (Google Drive, Dropbox, Mega, SlideShare, Scribd, Pastebin and similar) or a cache is labeled "Link, publisher not confirmed". The site cannot tell who wrote the page behind such an address.
3. Any other web address is labeled as the original. This is a rule, not a check: the site does not confirm that the host is the publisher, so a copy on a host in neither list above would be labeled as an original.
4. An unreadable address is dropped. A link that is not a web address cannot be followed, so the site does not show it.
5. A failed link check moves a link back. The check covers one address per report, the one stored as its main link. If it failed, the panel marks that link as unreachable and lists the working links first. The link stays, because the check can be wrong.
6. A missing original is stated, not filled in. When a report has only copies, the panel says no original publisher link is known and names the copies. With only an unconfirmed link, it says no original is confirmed.

Many ORKL records give a mirror address and no publisher address, and the pipeline does not yet look one up.

What Is Published

Each source has a publish value that limits what the site may show from it. The About page gives each source's value and license.

evidence-only

Nothing from the source appears in the published data. The source only adds evidence when the registry decides whether two actor names belong to the same actor, and the site reports that evidence as a count.

No source is evidence-only in this build.

ORKL tags its reports with actor names. While ORKL is link-only, the site never shows those tags and never links a report to an actor on the strength of a tag alone. A report is linked to an actor only through Malpedia, ATT&CK references or the paper's data.

The actors, CVEs and techniques listed for an ORKL report were added by this project, and the table can filter and search on them. Actors come from the sources named above, or from a title or text that names them, and CVE and technique IDs are matched in the report text. The link-only rule allows this because the project works out those identifiers itself.

Actors named in a title

The site keeps no post text from the Microsoft, Talos and ESET blogs, The DFIR Report or ORKL. It can still read the title it shows. When that title contains the name of an actor that has a page here, the report is linked to that actor, and the report panel lists it under "Named in the title", apart from the actors a source tags. The paper's own report titles are read the same way. ORKL's actor tags are still never shown or used for these links.

The match reads whole words and uses only the names this site already publishes. It skips a name that belongs to two actors, a name that is also an ordinary word, and the names of malware that a title can mention without being about the actor. A title is the publisher's own statement, but it is weaker than a tag, and it can name an actor in passing.

Actors named in the text

The pipeline reads ORKL's report text once, at fetch, and keeps only which actors with a page here it names, how often, and where the name first appears. The text is never stored or published. The panel lists these actors under "Named in the text", apart from tagged actors and those named in the title.

The match is stricter than for titles, since a report mentions actors in passing. A name must appear twice, or once in the opening 300 words if it has several words or a digit, such as Fancy Bear or APT29. The same names are skipped. Only actors published when a report was read can be found in it.

Names a vendor post states

A post titled with a vendor's own label, such as Storm-3168, can miss the report that uses the actor's usual name. The Microsoft, Talos and ESET blogs often say outright that two names are one actor, as in "JadePuffer, tracked by Microsoft as Storm-3168". The pipeline reads each post's text in memory for phrases that equate two names, such as "also known as", "tracked as" and "a.k.a.", then keeps the two names and drops the sentence. Phrases such as "overlaps with" and "similar to" are not read, because they say the two are different.

A stated pair is used in two cases. When one name is an actor this site already publishes, the other becomes an alias of that actor. When neither name is known, the pair adds a new actor only if one name is a vendor cluster label such as Storm-3168 or UNC2452 and the name guesser calls both names an actor. The guesser alone is not enough, because it calls almost any capitalized name an actor, malware families included. A pair is never used to join two actors the sources keep apart, or to turn a malware family into an actor. The rule is provisional, and every alias it adds carries the blog's source badge.

A cluster ID in a post title can also add an actor. When a Talos title carries a UAT- ID, or a Microsoft title carries a Storm- or DEV- ID, and no source lists that ID, it becomes an actor labeled "unconfirmed vendor cluster" with that post as its report. Only the vendor that issues the format counts, and other shapes such as UNC and TA are left out because they match unrelated labels. The label drops once a source or a stated pair names the cluster.

Known Limitations

• Sources update on different schedules. The home page shows the last good fetch for each one, and a source that fails keeps its last good data until it recovers.
• A report that no source connects to an actor appears on no profile, even when its text names one. Actor names found in report text are not extracted in this version.
• Two sources can disagree on a value such as origin. The profile shows every value with its source and does not pick one.