APT_REPORT indexes eleven groups and ships fifty folders

The heading says country, and the content is somebody else's country list

The first structural heading on the page promises a taxonomy by country, and then does not deliver one. Its first line points the reader at another vendor's public page of threat-actor groups tracked by that vendor, which is a reasonable thing to do and a strange thing to do under your own heading.

What follows is a flat list of groups, and the selection tells you what the collection actually covers. Nearly every visible entry concerns groups attributed to North Korea or to a Russian-speaking actor: a group tracked under a numeric name, the intelligence-agency-linked group and a related campaign family, a group tracked under a codename, an organisation attributed to Lazarus, one attributed to Konni, a long-running group attributed to Oceanlotus, a state-attributed group numbered in the high twenties, one described only as a group that ran a PowerShell campaign, one with a single-letter codename, and one named after a chemical company that was hit by a destructive attack.

So the page is Korea and Russia heavy with a handful of others, and the heading does not describe that. For a reader who came looking for a country index, the page answers a different question than the one its own heading asks.

That matters because the two later headings are also loose: one is a bare region name, and one is a sector. Three different taxonomies, one file.

The readme indexes about eleven groups and the tree holds about fifty

The mismatch between the page and the repository is the most checkable thing about this project.

The visible readme covers roughly eleven groups across its sections. The repository root holds around fifty directories named after threat actors, covering state-attributed groups, commercial spyware vendors, an intrusion-set family, several numbered aliases, a ransomware crew, a supply-chain incident, an industrial control section, an exploit section, and a couple of thematic directories.

So most of what the repository contains is not reachable from the readme. Someone arriving for a group that has a directory will find nothing about it on the page, and someone following the page will not learn that the repository covers a much wider set.

The directory names are also inconsistent with each other. Some are numbered aliases, some are the vendor's own attribution, one is a press nickname rather than a research name, one combines a vendor name with a number, and a couple are generic words rather than actor names at all. There is also a misspelling in the list: a directory named after a well known commercial intrusion vendor has that vendor's name misspelled, which is the kind of error that breaks a search.

For an index whose whole purpose is findability, both problems are costly.

Three headings, three taxonomies, and a sector section with two entries

The heading levels are worth mapping because they are the only organising principle the page has.

The first promises groups by country. The second is a bare region name with no qualifier, and it holds two groups: one attributed to a Middle Eastern cluster and one numbered in the forties. The third promises groups for the finance sector, and it holds two as well: a banking trojan family and a group attributed to Nigeria.

Two entries under a sector heading is not a sector taxonomy. It is two links that happened to be filed together, and the heading was written to cover them.

What a reader gets, then, is a page where the level of a heading tells you how much precision to expect from the grouping beneath it, and the precision drops off sharply after the first section.

The entries themselves have a consistent shape, which helps more than the headings do. Each is a marker bullet carrying the report title, the link on the following line, and in most cases a date in parentheses after that. That pattern is the actual schema of this collection, and it is written by hand rather than generated from anything.

One vendor's blog is the backbone of the collection

The source distribution is uneven, and it is visible from the links alone.

A large share of the entries point at a single commercial security vendor's research blog. That one domain appears under the numeric group, under the agency-linked group, under the Konni attribution and under the Oceanlotus section, so a reader following several entries ends up trusting one organisation's analysis of several distinct actors.

Alongside it the collection cites other commercial research teams, including a large vendor's dedicated threat research arm, a second vendor's research arm, a third, a fourth, a fifth and a sixth. It also draws on two national response blogs, a security vendor's threat blog with its own numbered report series, and a check point research write-up.

Then the tail gets uneven in a different way. One item is sourced to two news outlets, a wire service and a national broadcaster, which is the only entry with more than one source. Two entries are reachable only through a link on a Chinese blogging platform, with no mirror and no archive. And one entry under a macOS-malware section has a link but no date.

So the collection's reliability varies by entry in a way the page does not flag.

Dates are present on most entries and missing on several

The most consistent thing about the page is the date convention, and even that has exceptions.

Most entries end with a date in parentheses, and reading them shows the collection's centre of gravity: the visible dates run from 2013 through mid-2019, with the densest cluster in 2018 and 2019. That is consistent with the repository containing a 2020 index document and a 2021 research report at its root.

Several entries have no date at all, and in at least one case the date line is missing while the link is present on its own line. A few headlines stop partway through a sentence, as though the entry was pasted and never finished. One of them reads like a mistranslation rather than a truncated title.

None of that makes the collection wrong. It makes it a pointer file whose entries need checking.

The practical rule that follows is simple: use this page to find the report, then go to the source for the date, the attribution and the indicators. The page is a table of contents maintained by one person, and it should be read as one.

One report is filed under a group it is not about

Inside the section for one long-running actor there is an entry about deobfuscating flow graphs for a different, numbered group, using two named reverse engineering tools.

That is a mis-file, and it is instructive because of how it happened. The report is a deobfuscation write-up about the tooling around a numbered group, it was clearly relevant enough to save, and it landed in the section for whichever actor the collector was working on that week.

In a folder-per-actor repository the same mistake is structural rather than clerical. Fifty directories invite fifty filing decisions, and nothing in the repository checks that a file is in the right one. A reader who trusts the directory name will confidently look in the wrong place.

The same applies to the readme's own sections, where a group described by its alias and a campaign family built around that alias are given separate headings, which is a reasonable distinction that a reader will not necessarily expect.

None of this is a reason to avoid the collection. It is a reason to treat the grouping as a hint rather than a classification.

The root mixes directories with spreadsheets and reports

The repository root is not a link file with a readme. It is a working directory, and it says so.

Alongside the readme and roughly fifty actor directories sit six documents. Two are spreadsheets, one with a name that has spaces around its underscore and one listing groups and operations together. Four are reports or reference documents: a threat actor encyclopedia, a national research report from 2021, and two generations of what is clearly the same set of printable group cards, one named for version two and one not.

The duplicate cards document is the interesting one. Two files, same content shape, different generations, both committed. That is what happens when a personal reference sheet is revised and the old revision is never deleted, and it tells you the collection has a maintenance rhythm that is not reflected in the readme.

The spreadsheets matter for a different reason. A markdown list of links and a spreadsheet of groups are two different artefacts with two different update habits, and a repository carrying both is telling you that the readme is a view onto the collection rather than the collection itself.

There is also no licence file, which for a repository full of other organisations' research is the detail to notice first.

No licence, no releases, and a social account as the homepage

Three closing facts describe the project's status rather than its content.

There is no licence file in the repository root and the repository's licence field is not asserted. For a link collection that is defensible, since the page contains other people's headlines and other people's links rather than their content. But it does mean the spreadsheets and the reference documents in the root have no stated terms either, and those are the artefacts most likely to be reused.

There are no published releases. For a collection that changes by adding lines to a markdown file, that is unremarkable, and the most recent commit is dated within the last week.

The homepage is a social media account belonging to the collector rather than a site, and the same account appears in the title line at the top of the readme. So the project's contact point is one person on one platform, and the title credits that person directly.

The subtitle, for what it is worth, misspells the last word of the collection's own description. It is a small thing, and it is the kind of thing that tells you this is a personal file maintained on an evening rather than a publication with an editorial process.

Editorial conclusion

APT_REPORT suits an analyst who wants a starting list of vendor research and is prepared to follow every link to the original. Three things to know before you treat it as an index. The group taxonomy is not consistent, so search the tree rather than the readme. The dates are incomplete and a few headlines are cut off mid-sentence, so verify publication dates at the source. And there is no licence file while the content belongs to other people's employers, which means the page is a set of pointers you should follow rather than a corpus you can republish.

Frequently asked questions

Official sources

1. blackorbird/APT_REPORT on GitHub
2. Issues
3. Project website
4. README