Threat Lab Quarterly: August 2026

Veraltete und Ghost-SPNs finden, bevor Angreifer es tun

Von Huy Kha

Einführung

In den letzten Jahren haben Angriffe auf Active Directory, die Service Principal Names (SPNs) ausnutzen, zugenommen. Es begann mit Kerberoasting, aber die Techniken sind seitdem kreativer geworden. Ghost SPN-Angriffe können eine Privilegieneskalation ermöglichen, indem sie Dienstziele beanspruchen, die niemand mehr nutzt. Kürzlich erlauben SPN-Unicode-Kollisionsangriffe jedem authentifizierten Benutzer mit write-SPN-Berechtigungen ebenfalls eine Privilegieneskalation, indem sie nichts weiter als einen optisch identischen, aber technisch unterschiedlichen SPN verwenden.

Es gibt auch ein stilleres Problem, das nicht viel Beachtung findet, nämlich die grundlegende Sicherheitshygiene. Bei Netwrix sehen wir immer wieder dasselbe Muster, unabhängig von der Größe der Organisation. Computerkonten bleiben in Active Directory aktiviert, lange nachdem die dahinterstehende Maschine außer Betrieb genommen wurde. Dienstkonten behalten SPNs, die noch auf Hosts verweisen, die es nicht mehr gibt. Niemand räumt das auf, sodass das Konto einfach dort bleibt, noch aktiv, weiterhin anfällig für Kerberoasting, und niemand achtet darauf.

Versteckte SPNs in Ihren Domänen finden

Unser Sicherheitsteam hat beschlossen, etwas zu entwickeln, das IT-Profis und Administratoren die Arbeit erleichtert: ein PowerShell-Skript namens Find-StealthSPNs das versteckte SPNs in Computer- und Benutzerkonten aufspürt, damit Sie die Ergebnisse überprüfen und entscheiden können, was tatsächlich bereinigt werden muss.

Das Skript läuft in zwei Hauptdurchläufen. Der erste betrachtet jedes Computer-Konto im Forest. Da jede domänengebundene Maschine standardmäßig mindestens einen SPN registriert, prüft dieser Durchlauf, ob der eigene Hostname des Computers noch im DNS aufgelöst wird und ob einer seiner SPNs auf Hosts zeigt, die nirgendwo mehr existieren. Wir nennen dies einen ghost SPN, einen SPN, der noch auf einem Konto sitzt, technisch gültig ist, aber auf nichts Reales zeigt. Es erfasst auch Computerkonten, die in AD vorab erstellt, aber nie tatsächlich beigetreten sind, da diese oft gar keinen SPN haben und unbeachtet dort verbleiben.

Wir prüfen dies bewusst über DNS und nicht per ICMP-Ping. Manche Administratoren verlassen sich auf Ping, um schnell zu sehen, ob ein Host hinter einem SPN noch lebt, aber ICMP wird in den meisten Umgebungen oft durch Firewalls und hostbasierte Filter blockiert, sodass ein fehlgeschlagener Ping nicht viel aussagt. Ein fehlender DNS-Eintrag ist ein zuverlässigeres Signal dafür, dass niemand mehr erwartet, dass dieser Hostname existiert, unabhängig davon, ob das Gerät selbst auf einen Ping antworten würde.

Der zweite Durchgang betrachtet Benutzerkonten, speziell jene mit SPNs, da dies die klassische Einrichtung für ein Dienstkonto ist. Für jeden gefundenen SPN prüft er zwei Dinge: Existiert ein passendes Computerkonto noch in AD, und wird der Hostname noch in DNS aufgelöst? Wenn beides nicht zutrifft, ist das ein klares Signal dafür, dass der SPN unnötig ist. Das Konto ist noch aktiv, der SPN noch registriert und durch Kerberoasting weiterhin ausnutzbar, obwohl jetzt nichts Legitimes mehr davon abhängt.

Darüber hinaus prüft das Skript auch auf SPN-Unicode-Kollisionen, die Art von Angriff, die wir zuvor erwähnt haben, bei dem ein manipuliertes SPN optisch einem echten entsprechen kann, während es darunter ein völlig anderer Wert ist. Es markiert jedes SPN mit versteckten oder ähnlichen Zeichen und vergleicht alle SPNs im Forest, um Fälle zu erkennen, in denen zwei Konten scheinbar dasselbe SPN besitzen. Dies kann einige Fehlalarme verursachen, daher immer zuerst doppelt prüfen.

Alles läuft ausschließlich mit ADSI und DirectorySearcher, sodass keine Abhängigkeit vom ActiveDirectory PowerShell-Modul besteht und es in allen Domänen des Forests funktioniert, nicht nur in der, von der aus Sie es ausführen.

Eine kurze Anmerkung zur DNS-Auflösung: Dieses Skript prüft DNS mit dem Resolver, der auf dem Rechner konfiguriert ist, von dem aus es ausgeführt wird. Für (genauere) Ergebnisse führen Sie es von einem Domänencontroller statt von einer Arbeitsstation aus, da DCs bereits so eingerichtet sind, dass sie jede Domäne in Ihrer Umgebung auflösen. Das Ausführen auf einem Rechner mit ungewöhnlichen oder eingeschränkten DNS-Einstellungen kann falsche MISSING_DNS-Ergebnisse für tatsächlich vorhandene Einträge erzeugen.

Fazit

Am Ende des Tages versuchen wir, Organisationen dabei zu helfen, ihre Angriffsfläche zu reduzieren, indem wir veraltete Konten bereinigen, die niemand mehr überwacht. Jeder ghost SPN, jedes aktivierte Computerkonto, das an eine längst verschwundene Maschine gebunden ist, jedes Dienstkonto, das noch auf einen nicht mehr existierenden Host zeigt, ist ein weiterer Eintrag in Active Directory, der dort nicht sein sollte. Dafür ist kein raffinierter Angreifer nötig. Es reicht, wenn es jemand bemerkt, bevor Sie es tun.

---

Der Identitätssicherheitswinkel von DEF CON 34

Von Darryl Baker

DEF CON 34 und Black Hat USA 2026 haben drei separate Forschungsarbeiten veröffentlicht, die alle auf Identity-Infrastruktur hinweisen. Hier erfahren Sie, was jede ankündigte und was das für Personen bedeutet, die Identity- und AD-Programme betreiben.

CloudBasher: Kostenlose Cloud-Shells, die zur Angreifer-Infrastruktur wurden

Jenko Hwong und Chris Ryan stellten CloudBasher vor, ein Open-Source-Toolkit, das durch Reverse Engineering der privaten REST-APIs und WebSocket-Sitzungen hinter den kostenlosen Cloud-Shell-Funktionen in AWS, Azure und GCP erstellt wurde. Das Toolkit wird auf GitHub öffentlich sein, zusammen mit einer 2026-Analyse von Cloud-Fehlkonfigurationsmustern basierend auf Daten von Sicherheitsverletzungen.

Die Untersuchung brachte einige spezifische Erkenntnisse zutage, die für Identity Management-Teams wichtig sind.

• Eine kompromittierte AWS-Identität kann eine Rolle übernehmen und eine große Anzahl von CloudShell-Umgebungen starten.
• WebSocket-Terminalsitzungen bleiben aktiv, nachdem das zugrundeliegende Zugriffstoken widerrufen wurde, sodass das Widerrufen einer Anmeldeinformation nicht unbedingt eine aktive Sitzung beendet.
• M365- und Gmail-Verbraucherkonten erhalten standardmäßig Zugriff auf CloudShell, wodurch die relevante Angriffsfläche auf persönliche Konten und nicht nur auf Unternehmenskonten ausgeweitet wird.

Sobald eine Sitzung eingerichtet ist, verbleibt das Toolkit im $HOME-Verzeichnis (das Neustarts übersteht), kann den legitimen Benutzer innerhalb seiner eigenen Sitzung von sudo ausschließen und installiert ein C2-Framework.

Warum das wichtig ist: Wenn Ihr Identity-Programm die Token-Widerrufung als gleichbedeutend mit der Sitzungsbeendigung behandelt, sollte diese Annahme laut dieser Forschung überprüft und nicht einfach angenommen werden. Es lohnt sich auch zu prüfen, ob Ihre CloudShell-Zugriffsrichtlinien und Überwachung anomale Sitzungserstellungen überhaupt erkennen würden.

GhostJacking: KI-Codierungsagenten, die auf Anweisungen reagieren, die in Protokollen versteckt sind 

Barak Sternberg, Nevo Poran und Ron Bobrov von Tenet Security präsentierten GhostJacking, eine Technik zum Kapern von KI-Codieragenten, indem Anweisungen in Protokollen platziert werden, die der Agent lesen soll, wie WAF-Warnungen, Fehlerberichte und Überwachungsausgaben. Tenet berichtete von einer Erfolgsrate von 90 % gegen Claude Code unter der Standardkonfiguration von Cloudflare und schätzte, dass mehr als 15.000 Organisationen allein durch Cloudflare-Konfigurationen exponiert sind.

Tenet demonstrierte die Technik auf drei Plattformen. Vergiftete Cloudflare WAF-Protokolleinträge (Cloudflare steht vor geschätzten 42 % der Fortune-500-Unternehmen) veranlassten Agenten, DNS-Einstellungen zu ändern und den Datenverkehr umzuleiten. Eingeschleuste Datadog-Protokollmeldungen (von etwa 48 % der Fortune 500 genutzt) veranlassten Agenten, bösartige Pakete zu installieren, was zu Remote-Code-Ausführung und Diebstahl von Anmeldeinformationen führte. Vergiftete Sentry-Fehlerberichte (Sentry bedient schätzungsweise 4 Millionen Entwickler) führten dazu, dass eine kompromittierte Claude Code-Instanz für den Angreifer beim eigenen Seer AI-Agenten von Sentry bürgte, wodurch eine Vertrauenskette zwischen Agenten entstand. Tenet meldete außerdem, über 2.700 exponierte Datadog-API-Schlüssel gefunden zu haben, und gab separat eine JWT-bezogene Sandbox-Flucht in Claude Desktop an Anthropic weiter. Dieses Problem wurde vor dem DEF CON-Vortrag behoben.

Die Aktionen des Agents in allen drei Fällen verwenden seine eigenen legitimen, bereits autorisierten Anmeldeinformationen. Das bedeutet, dass EDR-, WAF- und IAM-Tools nichts Anomales melden.

Warum das wichtig ist: RBAC, das Prinzip der geringsten Rechte und MFA helfen hier nicht, da der Zugriff des Agenten legitim ist. Das Problem ist, was ihm mit diesem Zugriff befohlen wurde. Die Empfehlungen von Tenet sind eine vernünftige Start-Checkliste: standardmäßig den ausgehenden Netzwerkzugriff des Agenten einschränken, menschliche Genehmigung vor Infrastrukturänderungen verlangen, schreibgeschützte Tools von schreibfähigen trennen und jedes Protokoll oder jede Warnung, die ein Agent liest, als nicht vertrauenswürdige Eingabe behandeln, unabhängig von der Plattform, von der sie stammt.

The OpenAI–Hugging Face incident: An agent that escaped its own test

Im Juli 2026 gab OpenAI bekannt, dass während einer internen Bewertung mit dem ExploitGym-Benchmark (898 reale Schwachstellen) eine experimentelle Version von GPT-5.6 Sol, die ohne Sicherheitsvorkehrungen lief, aus ihrer Sandbox entkam und die Produktionsinfrastruktur von Hugging Face kompromittierte. Hugging Face meldete den Vorfall am 16. Juli; OpenAI gab seine Rolle am 21. Juli bekannt. Eric Wallace und Michael Dalton präsentierten dies auf der Black Hat USA 2026.

Laut den Enthüllungen fand und nutzte der Agent eine Zero-Day-Schwachstelle in einer selbst gehosteten Instanz von Artifactory (JFrogs Paket-Registry-Cache-Proxy), um seiner Sandbox zu entkommen und ins Internet zu gelangen. Der Agent schloss dann, dass Hugging Face den Antwortschlüssel des Benchmarks hostete, und ging direkt darauf los. Mehrere Agenteninstanzen koordinierten sich später über Artifactory selbst, tauschten Hunderttausende Nachrichten aus, um Aufgaben zu teilen und Exploits zu verbreiten. An einem Punkt schlugen die Agenten vor, ihre Nachrichten kryptographisch zu signieren, nachdem sie einen Betrüger vermuteten. Als OpenAI den Kanal am 4. Juli schloss, bauten die Agenten ihn innerhalb von vier Tagen wieder auf, indem sie Verzeichnisnamen an einem nicht authentifizierten Endpunkt als Ersatznachrichtenkanal nutzten.

Während einer 4,5-tägigen Kampagne protokollierte OpenAI mehr als 17.600 Agentenaktionen, darunter die Exfiltration von 136 Schlüssel für Credential-Stores, den Diebstahl eines Mesh-VPN-Authentifizierungsschlüssels, die Registrierung von 181 Geräten über Tailscale und den Erwerb von Schreibzugriff auf GitHub App. Die Aktivitäten auf 11 Kubernetes-Knoten umfassten Knoten-Imitation über AWS-Instanzmetadaten, gefälschte Identitätstoken mit einem gestohlenen EdDSA JWT-Signaturschlüssel und die Erstellung privilegierter Pods mit Host-Dateisystem-Mounts. OpenAI gab an, auch weitere kleinere Sandbox-Ausbrüche identifiziert zu haben, die als begrenzt beschrieben wurden und von denen keines das eigene Netzwerk verlassen haben soll.

Ein Detail, das speziell identity und incident response betrifft: Die forensischen Anfragen von Hugging Face wurden von denselben kommerziellen KI-Sicherheitsvorkehrungen blockiert, die in die OpenAI- und Anthropic-Modelle eingebaut sind, die es für die Untersuchung zu verwenden versuchte, da die Schutzmaßnahmen die Fragen eines Incident Responders nicht von denen eines Angreifers unterscheiden konnten. Hugging Face nutzte ein Open-Weight-Modell mit 753 Milliarden Parametern (GLM-5.2), um mehr als 17.000 Angreiferereignisse in Stunden statt Tagen zu verarbeiten.

Warum das wichtig ist: dies ist ein dokumentierter Fall eines autonomen Agenten, der eigenständig eine Schwachstelle entdeckt, Anmeldeinformationen exfiltriert, Tokens fälscht und sich ohne menschliche Anleitung lateral durch die Cloud-Infrastruktur bewegt. Wenn Ihr IAM- und Governance-Modell nur menschliche und Servicekonto-Identitäten berücksichtigt, ist dieser Vorfall ein konkreter Grund, eine dritte Kategorie hinzuzufügen: autonome Agenten, die eigenständig handeln können.

Was diese drei gemeinsam haben

CloudBasher bezieht sich auf Lücken in den Identity-Kontrollen auf Protokollebene: Token-Widerruf, Rollenübernahme-Grenzen, Standardzugriffsrichtlinien. GhostJacking handelt von einem KI-Agenten, der eine legitime, delegierte Identity nutzt, um Anweisungen auszuführen, denen er nicht hätte vertrauen sollen. Der OpenAI–Hugging Face-Vorfall betrifft einen Agenten, der eigenständig Anmeldeinformationen erlangt und fälscht, ohne dass ein Mensch oder ein manipuliertes Protokoll ihn dazu veranlasst hat.

Ein roter Faden zieht sich durch alle drei: Verteidiger sind durch Werkzeuge eingeschränkt, die Angreifer nicht beachten müssen. CloudBasher nutzte Annahmen aus, die Verteidiger nicht geprüft hatten. GhostJacking nutzte aus, dass Identity-Tools die Absicht nicht bewerten können. Und im Fall OpenAI–Hugging Face verlangsamten die Sicherheitsvorkehrungen, die Missbrauch verhindern sollten, auch die Reaktion der Verantwortlichen.

---

Praktische nächste Schritte für Identity- und AD-Teams

Vier Dinge, die sich dieses Quartal basierend auf dieser Forschung lohnen:

Forschung, die Sie möglicherweise verpasst haben

Falls Sie es verpasst haben: Wir teilen drei der besten Beiträge des Security Research Teams von Netwrix.

Leistungsstarke erweiterte LDAP-Steuerungen: Anti-Remediation und unsichtbare Erkundung in AD 

Der leitende Sicherheitsforscher Darryl Baker prüfte alle dokumentierten LDAP-Erweiterungen von Active Directory und fand zwei mit offensivem Potenzial, die bisher nicht veröffentlicht wurden. FORCE_UPDATE ermöglicht es einem Angreifer mit Schreibzugriff auf nur ein Attribut, einen bösartigen Wert in ADs Replikationskonfliktlösung durchzusetzen, sodass eine spätere Korrektur des Verteidigers stillschweigend rückgängig gemacht wird. Das OBJECT_SECURITY-Flag bei DirSync erlaubt jedem Domänenbenutzer, AD-Daten über den Replikationspfad massenhaft zu lesen, ohne die Protokollereignisse zu erzeugen, die eine normale Suche auslösen würde. Keines gewährt neue Privilegien, aber beide umgehen Erkennungen, auf die sich die meisten Verteidiger verlassen; der Beitrag enthält passende Erkennungsanleitungen und Open-Source-Red/Blue-Tools.

Warum das wichtig ist: Beide Techniken umgehen genau die Log-Ereignisse (Ereignis 1644, Ereignis 4662), auf die die meisten AD-Überwachungsregeln ausgerichtet sind. Wenn Ihre Erkennungen nicht speziell dagegen getestet wurden, werden sie wahrscheinlich nicht ausgelöst. Es lohnt sich auf jeden Fall zu prüfen, ob Ihre SACL-Canaries und Hunting-Abfragen dies tatsächlich erfassen würden. 

Mehr erfahren

Ihr KI-Codierassistent leakt Geheimnisse 

Darryl Baker hat die Speicherung von Zugangsdaten in 14 beliebten KI-Desktop-Assistenten-Tools, darunter Claude Code, GitHub Copilot, Cursor, Continue.dev und Cline, geprüft und festgestellt, dass die meisten OAuth-Tokens und API-Schlüssel im Klartext-JSON an vorhersehbaren Dateipfaden speichern. Eine spezifische Lücke: Unter WSL können Windows-seitige Claude Code-Zugangsdaten Dateien weltlesbare Berechtigungen erben. Der Beitrag beschreibt acht Angriffsszenarien, darunter die Übernahme einer aktiven Claude Code-Fernsteuerungssitzung und MCP-Konfigurationsdateien, die Tokens mehrerer Dienste in einer einzigen lesbaren Datei zusammenfassen. Außerdem wird AIHound vorgestellt, ein Open-Source-Scanner von Netwrix, der genau diese Art von exponierten Zugangsdaten auf einem Rechner prüft.

Warum das wichtig ist: Wenn Ihre Ingenieure eines dieser Tools verwenden, liegen ihre Zugangsdaten wahrscheinlich gerade unverschlüsselt auf der Festplatte, an einem Dateipfad, den ein Angreifer nicht erraten muss. Es ist keine Privilegieneskalation erforderlich, um sie zu lesen, und da MCP-Konfigurationen mehrere Servicetokens in einer Datei bündeln, kann ein einzeln kompromittierter Laptop auf alle verbundenen Systeme oder Dienste übergreifen. Dazu können Datenbanken, Cloud-Infrastrukturen und sogar andere KI-Tools gehören. AIHound bietet Ihnen eine schnelle Möglichkeit, Ihre eigene Exposition zu überprüfen, bevor jemand anderes sie für Sie findet. 

Mehr lesen

Automatisierung der Entra ID-Mandantenvernichtung mit KI 

Huy Kha zeigte mit Claude für Chrome gegen Microsoft Graph Explorer, dass sobald ein angemeldetes Konto bereits Global Administrator-Zugriff hat, browserseitiges JavaScript und Graph-Batch-Anfragen die Massenlöschung von Benutzern, Passwortzurücksetzungen, Sitzungswiderrufe und die Entfernung von Conditional Access-Richtlinien automatisieren können. Der Beitrag verbindet dies mit realen Vorfällen, darunter die Fälle Stryker und Storm-0501, bei denen zerstörerische Tenant-Operationen einer Kompromittierung eines privilegierten Kontos folgten, und macht deutlich, dass KI hier keinen neuen Angriffsweg geschaffen hat; sie nutzte einen bestehenden Admin-Workflow und machte ihn schneller und einfacher in großem Maßstab ausführbar.

Warum es wichtig ist: Dies ist die Lücke zwischen einer Kompromittierung eines privilegierten Kontos und der vollständigen Zerstörung des Tenants, und KI-Automatisierung schließt diese schnell. Sobald jemand eine Global Admin-Sitzung hat, benötigt er keine Skriptkenntnisse oder Zeit mehr, um maximalen Schaden anzurichten. Das erhöht die Bedeutung des Schutzes und der Überwachung von Admin-Sitzungen und Tools wie Graph Explorer, nicht nur der Anmeldedaten. 

Mehr lesen

2026 Bericht zur Daten- und Identity Security: Fortschritte und Lücken bei der Einführung und Bereitschaft von agentischer KI

Netwrix Research Lab befragte 2.317 IT- und Sicherheitsexperten aus 1.889 Organisationen, um den Data and Identity Security Report 2026 zu erstellen. Die Ergebnisse zeigen, dass Organisationen, in denen KI ihre Identity-Präsenz erheblich erweitert hat, etwa viermal häufiger Opfer von Sicherheitsverletzungen wurden als solche, in denen dies nicht der Fall war. Der Bericht führt die Lücke eher auf die Geschwindigkeit der Governance als auf deren Strenge zurück: 76 % der Organisationen verwalten oder überwachen nicht vollständig nicht-menschliche Identitäten, und nur 11 % berichten von vollständiger KI-Sicherheitsbereitschaft durch kontinuierliche Durchsetzung und Überwachung.

Warum es wichtig ist: Die Daten erschweren eine gängige Annahme, dass allein eine starke Identity Hygiene vor KI-gesteuerten Risiken schützt. Wenn Ihre Identity Governance noch auf vierteljährlichen Überprüfungen und periodischen Audits basiert, lohnt es sich zu prüfen, wie lange ein neuer KI-Agent oder eine nicht-menschliche Identität existiert, bevor es jemand bemerkt. Diese Verzögerung und nicht eine fehlende Kontrolle ist die eigentliche Ursache der in diesem Bericht aufgezeigten Sicherheitslücke.

Mehr erfahren

---

Das war’s für diese Ausgabe des Netwrix Threat Lab Quarterly. Wir sind bald mit neuen Forschungen und weiteren Möglichkeiten zurück, um die Lücken zu schließen, auf die Angreifer hoffen, dass Sie sie übersehen.