In vielen Security-Assessments schauen alle zuerst auf Active Directory, Entra ID, Domain Admins, privilegierte Gruppen, Kerberoasting, NTLM, Tiering und lokale Administratorrechte. Absolut richtig,  denn dort entstehen nach wie vor viele der kritischsten Angriffspfade. Aber die Realität in Unternehmen hat sich verändert. 

Eure Identitäten, Berechtigungen und Vertrauensbeziehungen leben heute nicht mehr nur in Active Directory oder Microsoft Entra ID. Sie stecken auch in GitHub, Okta, Cloud-Plattformen, SaaS-Anwendungen, CI/CD-Pipelines, Entwicklerkonten, Service Principals, API-Tokens und Drittanbieter-Integrationen. 

Und genau deshalb wird BloodHound mit OpenGraph deutlich spannender. 

SpecterOps positioniert BloodHound OpenGraph | Cross‑Platform Attack Path Analysis als Erweiterung der Attack-Path-Analyse über das Microsoft-Ökosystem hinaus: Identitätsbeziehungen und Angriffspfade sollen künftig aus beliebigen Plattformen, Repositories oder Anwendungen visualisiert werden können. Anders gesagt: BloodHound schaut nicht mehr nur dorthin, wo klassische AD-Security-Teams ohnehin hinschauen. Es wird zum Graphen für die moderne Unternehmensrealität. 

Und genau das kann unbequem werden. 

Das Problem: Eure Angriffspfade enden nicht am Domain Controller

Viele Unternehmen haben in den letzten Jahren gelernt, Active Directory besser zu härten. Tiering-Modelle wurden eingeführt, Domain Admins reduziert, MFA ausgerollt, NTLM überwacht, lokale Adminrechte eingeschränkt und Entra-Rollen stärker kontrolliert. Das ist wichtig… aber es reicht nicht mehr. 

Denn aus Sicht eines Angreifers ist es völlig egal, ob der Weg zum Ziel über einen klassischen Domain Admin läuft oder über eine schlecht geschützte Entwicklerplattform, ein falsch berechtigtes GitHub-Repository, eine Cloud-Integration oder ein SaaS-Konto mit zu vielen Rechten. 

Die entscheidende Frage lautet nicht: „Ist unser Active Directory sauber?“, sondern: 

„Welche Kette aus Identitäten, Berechtigungen und Vertrauensbeziehungen führt zu unseren kritischsten Systemen?“ Und diese Kette kann heute quer durch eure Umgebung laufen. 

Zum Beispiel über: 

• • ein Entwicklerkonto mit Zugriff auf ein Repos itory, 

• • ein Repository mit Secrets oder Deployment-Rechten, 

• • eine CI/CD-Pipeline mit Cloud-Berechtigungen, 

• • einen Service Principal mit Zugriff auf produktive Workloads, 

• • eine SaaS-Anwendung mit weitreichenden Admin-Rechten, 

• • oder eine externe Identität, die intern zu viel darf. 

Die eigentliche Gefahr liegt selten in einer einzelnen Fehlkonfiguration. Gefährlich wird es, wenn mehrere scheinbar kleine Berechtigungen zusammen einen vollständigen Angriffspfad ergeben. 

Genau diese Perspektive macht Attack Path Management so wertvoll, und gleichzeitig so unangenehm. 

Was OpenGraph verändert 

OpenGraph erweitert BloodHound um die Möglichkeit, zusätzliche Datenquellen und eigene Erweiterungen in den Sicherheitsgraphen einzubinden. Laut Manage Extensions – SpecterOps können Extensions strukturierte Graphen erzeugen, indem sie unter anderem Node-Typen, Edge-Typen, Traversierbarkeit und visuelle Konfigurationen definieren. Diese strukturierten Graphen ermöglichen in BloodHound erweiterte Funktionen wie Pathfinding, Findings und Metriken.  

Die Konsequenz ist aber sehr praktisch: Ihr könnt Beziehungen sichtbar machen, die klassische AD-Tools nie sehen würden.  

SpecterOps bietet unter anderem GitHub, Jamf und Okta als vorinstallierte Erweiterungen in BloodHound Enterprise ab Version 9.3.0. In der Community-Library finden sich außerdem zahlreiche Beispiele für OpenGraph-Erweiterungen, unter anderem für 1Password, Ansible, Atlassian, Duo, GitLab, Google Cloud Platform, Kubernetes, Microsoft Exchange, MSSQL, Okta, Salesforce, Snowflake und weitere Systeme.  

Ganz neu ist nun auch AWS dazu gekommen: AWS IAM Attack Paths in BloodHound | SpecterOps 

Damit wird BloodHound vom klassischen AD-/Azure-Blick zu einem deutlich breiteren Werkzeug für Identitäts- und Angriffspfad-Analyse. Oder einfacher gesagt: 

Wenn eure Angriffsfläche plattformübergreifend ist, muss eure Analyse auch plattformübergreifend werden. 

Warum der Streit zwischen Microsoft und Nightmare-Eclipse das Thema noch relevanter macht 

Spannend wird das Thema gerade auch durch den öffentlichen Streit zwischen Microsoft und dem Sicherheitsforscher Nightmare-Eclipse, auch Chaotic Eclipse genannt. 

Microsoft veröffentlichte im Mai 2026 einen Beitrag zur Coordinated Vulnerability Disclosure und erklärte, mehrere Zero-Day-Schwachstellen seien ohne vorherige Meldung an Microsoft öffentlich gemacht worden. Microsoft nannte dabei RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma und MiniPlasma und argumentierte, unkoordinierte Veröffentlichungen mit Proof-of-Concept-Code für ungepatchte Schwachstellen könnten Kunden unnötigen Risiken aussetzen.  

Medienberichte ordnen den Fall als eskalierenden Konflikt zwischen Microsoft und Nightmare-Eclipse ein. Security Boulevard berichtete, dass der Forscher Microsoft Fehlverhalten im Disclosure-Prozess vorwarf, während Microsoft auf die Risiken unkoordinierter Veröffentlichungen verwies. Spätere Berichte beschrieben zudem weitere Veröffentlichungen, darunter LegacyHive, einen Windows-Zero-Day rund um den Windows User Profile Service, der nach Berichten kurz nach dem Juli 2026 Patch Tuesday publik wurde.  

Warum ist das für OpenGraph relevant? 

Weil dieser Streit sehr gut zeigt, wie schnell sich Bedrohungslagen verändern können. Eine Schwachstelle, ein öffentlicher PoC, ein ungepatchtes System, ein überprivilegiertes Konto oder eine unerwartete Vertrauensbeziehung und plötzlich wird aus einer theoretischen Lücke ein realer Angriffspfad. 

Viele Unternehmen denken bei solchen Zero-Day-Debatten zuerst an Patchmanagement. Das ist richtig, aber nicht vollständig. Denn selbst wenn ein Patch noch nicht verfügbar ist, stellen sich die Fragen: 

• • Welche Systeme wären betroffen? 

• • Welche Konten könnten den Angriffsweg ausnutzen? 

• • Welche Privilegien wären danach erreichbar? 

• • Welche Folgepfade entstehen in AD, Entra, Cloud oder SaaS? 

• • Welche kritischen Assets wären am Ende gefährdet? 

Genau hier wird Attack Path Management so wichtig. Es hilft euch nicht nur zu wissen, dass es ein Risiko gibt. Es hilft euch zu verstehen, wohin dieses Risiko führen kann. 

Was das für eure Security-Roadmap bedeutet 

OpenGraph ist kein „nice to have“ für Tool-Fans. Es ist ein Signal dafür, wohin sich moderne Security entwickeln muss. Viele Security-Programme sind noch stark bereichsorientiert: 

• • IAM kümmert sich um Identitäten. 

• • Cloud-Teams kümmern sich um Cloud-Berechtigungen. 

• • Entwicklerteams kümmern sich um GitHub, GitLab oder CI/CD. 

• • IT-Betrieb kümmert sich um Server und Clients. 

• • Security schaut über Monitoring, SIEM und Assessments darauf. 

Das Problem: Angreifer halten sich nicht an eure Organisationsstruktur. Sie kombinieren alles, was funktioniert. 

Deshalb sollten Unternehmen ihre Security-Roadmap um drei Fragen erweitern: 

1. 1. 1. Welche Plattformen erzeugen bei uns kritische Identitätsbeziehungen?
         Also nicht nur AD und Entra ID, sondern auch GitHub, Okta, GitLab, Cloud-Provider, SaaS-Anwendungen und Automatisierungsplattformen.
      2. Welche Vertrauensbeziehungen verstehen wir wirklich?
         Besonders spannend sind Service Accounts, Service Principals, API-Tokens, Deployments, Synchronisationen, SSO-Verbindungen und externe Identitäten. 
      3. Welche Angriffspfade priorisieren wir zuerst?
         Sichtbarkeit allein löst kein Problem. Entscheidend ist, welche Pfade zu Tier-0-Systemen, produktiven Workloads, sensiblen Daten oder geschäftskritischen Anwendungen führen. 

Hier trennt sich dann Tool-Euphorie von echter Security-Arbeit. 

Denn ein größerer Graph bedeutet nicht automatisch mehr Sicherheit. Ein größerer Graph bedeutet erst einmal: mehr Erkenntnisse, mehr Komplexität und mehr Entscheidungen. 

Unsere Meinung: Sichtbarkeit ist gut, Priorisierung ist besser 

Aus unserer Sicht ist OpenGraph ein wichtiger Schritt, weil es die Realität vieler Unternehmen besser abbildet: Identität ist heute verteilt. Angriffspfade sind verteilt. Verantwortung ist verteilt. 

Genau deshalb sollten Unternehmen OpenGraph nicht nur als neue BloodHound-Funktion betrachten, sondern als Anlass, ihr gesamtes Bedrohungsmodell zu hinterfragen. 

Die wichtigste Frage lautet: „Welche Findings verändern wirklich unser Risiko?“ 

Denn wenn ihr plötzlich Angriffspfade über AWS, GitHub, Okta, SaaS, Cloud, AD und Entra ID hinwegseht, braucht ihr mehr als ein Dashboard. Ihr braucht ein Betriebsmodell. 

Dazu gehören: 

• • klare Verantwortlichkeiten zwischen Security, IAM, Cloud, Entwicklung und Betrieb, 

• • ein gemeinsames Verständnis von kritischen Assets, 

• • ein Priorisierungsmodell für Angriffspfade, 

• • technische Mitigationen statt reiner Dokumentation, 

• • regelmäßige Re-Analysen nach Änderungen, 

• • und eine Governance, die nicht an Tool-Grenzen endet. 

Oder kurz gesagt: OpenGraph macht sichtbar, was viele Unternehmen organisatorisch noch nicht sauber gelöst haben. 

„OpenGraph zeigt sehr deutlich, dass moderne Angriffspfade nicht mehr an klassischen Systemgrenzen haltmachen. Für Unternehmen wird es entscheidend, nicht nur einzelne Berechtigungen zu prüfen, sondern die Kombination aus Identitäten, Plattformen und Vertrauensbeziehungen zu verstehen. Genau dort entstehen heute die Risiken, die in klassischen Assessments oft unsichtbar bleiben.“ – Fabian Böhm, CEO und Security Architect bei TEAL 

Was ihr jetzt konkret tun solltet 

Wenn ihr euch mit OpenGraph, BloodHound und plattformübergreifendem Attack Path Management beschäftigen wollt, würden wir nicht direkt mit „alles einsammeln, was geht“ starten. 

Besser ist ein strukturierter Einstieg: 

Kritische Assets definieren: Was darf auf keinen Fall kompromittiert werden? 

Identitätsquellen priorisieren: AD, Entra ID, GitHub, Okta, Cloud, SaaS … was ist bei euch wirklich relevant? 

Privilegierte Pfade prüfen: Welche Wege führen zu Admin-Rechten, produktiven Workloads oder sensiblen Daten? 

Service Principals und technische Konten analysieren: Gerade dort entstehen oft unterschätzte Angriffspfade. 

Findings nach Risiko priorisieren: Nicht alles, was sichtbar wird, ist gleich wichtig. 

Mitigation planen: Verantwortliche, Maßnahmen, Fristen und technische Kontrollen festlegen. 

Regelmäßig wiederholen: Angriffspfade ändern sich mit jeder neuen Integration, Rolle, Pipeline und Anwendung. 

Wichtig: Attack Path Management ist kein einmaliges Projekt. Es ist ein kontinuierlicher Prozess. 

BloodHound OpenGraph ist mehr als eine technische Erweiterung. Es ist ein Hinweis darauf, dass sich die Sicherheitsrealität vieler Unternehmen grundlegend verändert hat. 

Ihr wollt wissen, welche Angriffspfade in eurer Umgebung wirklich kritisch sind, nicht nur in Active Directory, sondern über Identitäten, Cloud, SaaS und Entwicklerplattformen hinweg? 

Dann lasst uns gemeinsam draufschauen.