Google adopts two-word cryptonyms to name threat actors

Google’s Threat Intelligence Group will assign two-word cryptonyms — a memorable label plus a category term — to threat actor clusters in its GTI platform, replacing numeric tags.

Google’s Threat Intelligence Group has introduced a two-word cryptonym system for labeling threat actor clusters in its Google Threat Intelligence (GTI) platform. The change replaces numeric or disparate identifiers with a paired name and category.

The first word will be a unique, memorable label for the actor. If no commonly used name exists, Google will assign a randomly generated term. The second word will indicate origin, motivation or activity type. Google gave examples: “Castle” for China-linked actors, “Ion” for Iranian groups, “Neptune” for North Korean clusters, “Relic” for Russian actors and “Comet” for cybercrime gangs.

Several dozen of the most active threat actors have already been renamed. Google said updates will continue on a rolling basis as teams map existing clusters to the new schema.

Previous identifiers, vendor aliases and mappings to frameworks such as MITRE ATT&CK will remain indexed and searchable in GTI. Google will also keep the UNC label for clusters that have not been assigned to a categorized actor.

Google framed the change as a way to make actor names easier to remember and to reduce friction when analysts compare alerts, intelligence reports and telemetry across different naming systems. The company noted that uneven visibility across organizations has led to many inconsistent labels for the same actor.

As an example of the renaming, the group commonly tracked as APT44 will appear in GTI as Sandworm Relic. Google said legacy names and aliases will remain available so investigators can reconcile past reporting with the new cryptonyms.

The new schema will be applied gradually across GTI. Google wrote that keeping the convention simple should help operational teams map GTI names to other naming taxonomies while preserving historical context and detection mappings.

Articles by this author