Google ersetzt 22 Jahre Bedrohungsakteur-Namen durch ein einheitliches Schema

Sechs Aliasse. So viele öffentliche Namen hat die russische Staatsgruppe APT44 seit 2004 angesammelt: Dark Basin, Frozenbarents, Greyenergy, Hades, Inedibleochotense und Quedagh – plus den Spitznamen „Sandworm", den die meisten Sicherheitsverantwortlichen tatsächlich verwenden. Ab dem 25. Juli 2026 hat die Google Threat Intelligence Group dieses Durcheinander auf zwei Wörter reduziert: SANDWORM RELIC. Die Umbenennung ist die sichtbare Spitze einer wesentlich umfangreicheren Schema-Überarbeitung, die jeder nachgelagerte Konsument von Google-Threat-Feeds nun mit seinem eigenen Tooling abgleichen muss.

Was geschehen ist

GTIG kündigte am 25. Juli 2026 ein einheitliches kryptonymbasiertes Benennungsschema an, das standardisieren soll, wie die fusionierte Organisation Bedrohungsakteure verfolgt. Wie Cyber Press berichtete, adressiert die Änderung direkt die Fragmentierung, die nach der Fusion von Mandiant mit Googles Threat Analysis Group (TAG) zurückgeblieben ist. Beide Teams hatten jahrelang separate, unabhängig voneinander weiterentwickelte Tracking-Systeme betrieben, und der Zusammenschluss, der GTIG entstehen ließ, legte das strukturelle Problem offen, zwei parallele Benennungskonventionen in einer Organisation zu pflegen.

Das neue Format ist bewusst einfach gehalten. Jeder Akteur erhält ein zweiteiliges Kryptonym. Das erste Wort ist ein eindeutiger Bezeichner, der idealerweise aus früheren öffentlichen Berichten stammt, wo ein etablierter Name bereits existiert. Wenn kein etablierter Begriff verfügbar ist, generiert GTIG ein zufälliges Wort und lässt es durch ein Analysten-Review laufen, um Verzerrungen oder versehentliche Beleidigungen zu erkennen. Das zweite Wort ist ein Kategorielabel, das Motivation, Attribution oder Aktivitätstyp signalisiert. Nach dieser Konvention wird APT44/Sandworm zu SANDWORM RELIC, wobei RELIC die russische staatliche Attribution signalisiert.

GTIG priorisiert zunächst die Umbenennung von mehreren Dutzend der aktivsten Bedrohungsgruppen und verarbeitet danach weitere Akteure fortlaufend. Legacy-Namen bleiben in der Google Threat Intelligence (GTI)-Plattform indiziert und durchsuchbar, zusammen mit bewahrten MITRE ATT&CK-Zuordnungen und Aliassen von Drittanbietern. GTIG hat auch einen ausdrücklichen Vorbehalt angemerkt: Keine zwei Organisationen haben identische Einblicke in die Bedrohungslandschaft, sodass herstellerübergreifende Vergleiche von Natur aus ungenau bleiben. Das Team hat das Schema als praktische Verbesserung eingestuft, nicht als endgültige Lösung für das Attributionsproblem selbst.

Technische Struktur

Das technische Problem hier ist ein klassisches Entity-Resolution-Problem, angewendet auf Threat Intelligence statt auf Kundendatensätze oder Ad-IDs. Vor der Fusion waren Mandiants APT-nummerierter Katalog und TAGs interne Bezeichner zwei unterschiedliche Primärschlüsselräume, die auf überlappende (aber nicht identische) Mengen realer Entitäten verwiesen. Ein Verteidiger, der beide Feeds einlas, musste manuelle Abgleiche vornehmen: Ist Mandiants APT44 derselbe operationelle Cluster wie das, was TAG intern nannte? Manchmal ja, manchmal teilweise, manchmal wichen die Cluster ab – je nachdem, welche Telemetrie jedes Team hatte.

Sequenzielle Nummerierung wie „APT1" trägt null semantische Information. Der Name sagt nichts über Attribution, Motivation oder Aktivitätstyp aus, sodass Analysten eine Lookup-Tabelle auswendig lernen oder jedes Mal die Dokumentation durchsuchen müssen, wenn ein neuer Alert ausgelöst wird. Das zweiteilige Kryptonym bettet ein Kategorielabel direkt in den Bezeichner ein. RELIC = russischer Staat. Wenn GTIG die vollständige Suffix-Taxonomie veröffentlicht (die Quelle legt das vollständige Kategorie-Wörterbuch nicht offen, was relevant ist, da nachgelagertes Tooling dieses Mapping hardcoden oder abrufen muss), können Analysten den Attributionskontext allein aus dem Namen ableiten, ohne die Plattform aufzurufen.

Das Backward-Compatibility-Design ist der Teil, der verhindert, dass Enterprise-Integrationen brechen. Legacy-Bezeichner bleiben in GTI indiziert. MITRE ATT&CK-Zuordnungen bleiben erhalten. Drittanbieter-Aliasse werden beibehalten. In der Praxis bedeutet dies, dass eine SIEM-Regel, die auf „APT44" keyed ist, beim Abfragen gegen GTI weiterhin auf denselben Akteur-Datensatz auflösen sollte, und die Korrelation mit CrowdStrike-, Microsoft- oder Recorded Future-Benennungen (jede mit eigenen Konventionen) weiterhin einen Auflösungspfad hat.

Was wir noch nicht wissen: ob das Kryptonym als zusätzliches Feld in STIX/TAXII-Exporten verfügbar gemacht wird oder ob es den primären Bezeichner in Feed-Payloads ersetzt. Diese Unterscheidung bestimmt, ob bestehende Detection-Pipelines stillschweigend weiterarbeiten oder anfangen, Datensätze zu verwerfen. Abschätzung der Auswirkungen: Wenn GTIG Kryptonyme als neues Feld behandelt und Legacy-IDs im selben Objekt erhält, sind die Integrationskosten nahezu null. Wenn Kryptonyme zum kanonischen Primärschlüssel werden, ist eine mehrquartalige Migration in jedem SOC zu erwarten, das GTI konsumiert.

Wer betroffen ist

Drei Gruppen spüren dies am unmittelbarsten. Erstens SOC-Teams, die Detection-Regeln oder SOAR-Playbooks betreiben, die Bedrohungsakteur-Namen als Strings referenzieren. Jede Regel, die in einem Anreicherungsfeld nach „APT44" oder „Sandworm" sucht, muss nun auch „SANDWORM RELIC" abgleichen – oder die Ingestion-Schicht muss on-the-fly normalisieren. Das ist eine Dokumentations- und Testaufgabe, kein schwieriges Engineering-Problem, aber es ist reale Arbeit über mehrere Dutzend Prioritätsgruppen in der ersten Welle.

Zweitens Threat-Intelligence-Anbieter und MSSPs, die Google-Intel weiterverkaufen oder neu verpacken. Ihre kundenseitigen Reports, Dashboards und API-Verträge referenzieren wahrscheinlich die alten Namen. Der fortlaufende Umbenennungsplan bedeutet, dass ihre Content-Pipeline für Monate – nicht Wochen – eine Übersetzungsschicht benötigt, während GTIG die lange Liste weniger aktiver Gruppen abarbeitet.

Drittens – und hier sollten TRAFFIC-nahe Teams aufmerksam sein – Betrugs- und Missbrauchsteams innerhalb von Ad-Plattformen, Affiliate-Netzwerken und iGaming-Betreibern, die staatlich verknüpfte oder finanziell motivierte Gruppen für Ad-Fraud-, Credential-Stuffing- und Account-Takeover-Attributionen verfolgen. Wenn Ihr Fraud-Analytics-Stack Bedrohungsakteur-Labels einliest, um Vorfälle zu bewerten, hat sich das Label-Vokabular gerade unter Ihnen verschoben. Wer Dashboards gebaut hat, die Vorfälle nach zugeschriebenem Akteur über rollende 12-Monats-Fenster gruppieren, wird scheinbare Diskontinuitäten sehen, die eigentlich nur Umbennungsartefakte sind.

Historische Berichte sind das Problem zweiter Ordnung. Jeder Threat-Brief, jedes Board-Deck und jede Post-Mortem-Analyse aus dem letzten Jahrzehnt referenziert Legacy-Namen. Neue Mitarbeiter, die alte Dokumentation lesen, müssen die Alias-Tabelle in einem anderen Tab offen haben. GTIGs Entscheidung, die Legacy-Indizierung in GTI zu erhalten, mildert dies – aber nur für Kunden mit aktiven GTI-Abonnements. Teams, die sich auf kostenlose öffentliche Berichte oder archivierte Anbieter-Blogs verlassen, erhalten keine solche Kompatibilitätsschicht.

Playbook für Performance Marketing

Performance- und Growth-Teams besitzen normalerweise kein Threat-Intel, aber Ad-Fraud, Affiliate-Missbrauch und Account-Sicherheit überschneiden sich. Konkrete Maßnahmen für diese Woche:

Prüfen Sie alle internen Dokumente, Runbooks oder Looker/Tableau-Dashboards, die Bedrohungsakteur-Namen als Literal-Strings referenzieren. Suchen Sie nach „APT" gefolgt von Ziffern. Überall dort, wo diese auftauchen, fügen Sie eine Notiz hinzu, die den Umbenennungsplan kennzeichnet, und legen Sie ein Überprüfungsdatum fest.

Wenn Ihr Fraud-Stack aus GTI zieht oder Threat-Intel weiterverkauft, das GTI-Akteure referenziert, öffnen Sie jetzt ein Ticket bei Ihrem Anbieter mit zwei Fragen: Werden Kryptonyme als zusätzliches Feld oder als Ersatz verfügbar gemacht, und wie lautet deren Übersetzungs-SLA? Die Quelle legt GTIGs Exportformat-Änderungen nicht offen, daher werden die Anbieterantworten variieren.

Für Teams, die Attribution-Reporting unter Privacy Sandbox oder ähnlichen Frameworks aufbauen, ist dies eine nützliche Erinnerung daran, dass die Bezeichner-Stabilität über Anbietersysteme hinweg niemals kostenlos ist. Dieselbe Abgleichdisziplin gilt für Akteur-Namen, Kampagnen-IDs und Nutzer-Kohorten-Labels.

Überprüfbare Vorhersage: Wenn der Rollout GTIGs angegebenen fortlaufenden Zeitplan befolgt, sollten wir die mehreren Dutzend Prioritätsgruppen innerhalb der nächsten zwei Quartale umbenannt sehen, und nachgelagerte SIEM-Anbieter sollten innerhalb von 60 bis 90 Tagen nach der Ankündigung Übersetzungs-Mappings veröffentlichen. Wenn Übersetzungs-Mappings bis Ende Q3 2026 nicht geliefert wurden, sind sichtbare Detection-Lücken in Kundenumgebungen zu erwarten, die aus mehreren Feeds beziehen.

Wichtigste Erkenntnisse

• GTIG hat die APT-Nummerierung am 25. Juli 2026 durch zweiteilige Kryptonyme ersetzt. APT44/Sandworm heißt jetzt SANDWORM RELIC, wobei RELIC die russische staatliche Attribution signalisiert.
• Legacy-Namen bleiben in GTI indiziert und durchsuchbar, zusammen mit MITRE ATT&CK-Zuordnungen und Drittanbieter-Aliassen – dies sichert die Backward-Compatibility für bestehende Integrationen.
• Mehrere Dutzend Prioritätsakteure werden zuerst umbenannt, der Rest folgt fortlaufend. Es sind Monate zu erwarten, nicht Wochen, bis die vollständige Abdeckung erreicht ist.
• Unbekannt und beobachtenswert: ob Kryptonyme als neues Feld in Feed-Exporten hinzugefügt werden oder den Primärbezeichner ersetzen. Diese eine Design-Entscheidung bestimmt, ob SIEM-Pipelines stillschweigend weiterarbeiten oder Migrationsarbeit benötigen.
• GTIG hat ausdrücklich anerkannt, dass herstellerübergreifende Benennungsvergleiche ungenau bleiben, weil keine zwei Organisationen identische Einblicke teilen. Das neue Schema ist eine Verbesserung der Benutzerfreundlichkeit, kein Durchbruch bei der Attribution.