Zwei SOCs, zwei Ergebnisse: Das CISA-Red Team zerlegt die Verteidigung zweier kritischer Infrastrukturen

Am 25. August 2026 hat die Cybersecurity and Infrastructure Security Agency (CISA) einen Advisory veröffentlicht, der zwei parallel durchgeführte offensive Bewertungen vergleicht. Die Ergebnisse zeigen eine tiefe Kluft: Eine der beiden Organisationen hat keine bösartige Aktivität erkannt, während die andere die ersten Versuche identifiziert und isoliert hat, was das Red Team dazu zwang, im Assume-Breach-Modus zu arbeiten. In beiden Fällen haben die simulierten Angreifer jedoch vollständigen Zugriff auf die Domäne, auf sensible Unternehmenssysteme und auf Cloud-Ressourcen erlangt. Der Advisory enthält keine CVEs oder Kompromittierungsindikatoren: Es handelt sich um einen Bewertungsbericht, nicht um ein Bulletin zu einer einzelnen Schwachstelle.

Zwei Organisationen, kritische Sektoren, gleiches Ziel

Die CISA hat zwei gleichzeitige Red-Team-Bewertungen durchgeführt. Die erste betraf eine Organisation des Government Services and Facilities Sector (Organisation A), die zweite eine Organisation des Water and Wastewater Systems Sector (Organisation B). Ein Red Team simuliert das Tradecraft echter Bedrohungsakteure, um die Erkennungs-, Untersuchungs- und Reaktionsfähigkeiten einer Organisation zu bewerten. Das Ziel ist es, einen persistenten Zugriff auf das Unternehmensnetzwerk und die von der Organisation selbst ausgewählten sensiblen Unternehmenssysteme zu erlangen und aufrechtzuerhalten. Diese Systeme, als SBS bezeichnet, sind Anwendungen, Datenspeicher oder Infrastrukturkomponenten, deren Kompromittierung erhebliche Auswirkungen auf Betrieb, Finanzen oder Kundendaten hätte.

Die Unterstützung der CISA ist gemäß 6 U.S.C. §§ 652(c)(5) und 659(c)(6) autorisiert. Der Bericht verwendet das MITRE ATT&CK for Enterprise Framework, Version 19, um die beobachteten Taktiken und Techniken abzubilden. Die genauen Versionen der betroffenen Produkte wurden nicht bekannt gegeben: Die Analyse konzentriert sich auf verbreitete Konfigurationen und Technologien wie Active Directory, Active Directory Certificate Services (ADCS), System Center Configuration Manager (SCCM), AWS IAM und Tools zur Endpoint Detection and Response (EDR).

Organisation A: Vollständige Kompromittierung ohne jeden Alarm

Im Fall von Organisation A erlangte das Red Team eine vollständige Kompromittierung der Domäne sowie Zugriff auf mehrere SBS und Cloud-Ressourcen, ohne dass die Verteidiger die Aktivität erkannten oder eindämmten. Der Weg begann mit der Aufklärung: Es wurde eine Webanwendung mit Standardanmeldeinformationen für mehrere integrierte Konten identifiziert, die es ermöglichte, E-Mails von einer internen E-Mail-Adresse aus zu versenden. Diese Adresse wurde für gezielte Phishing-Kampagnen genutzt, was zu einem ersten Zugriff auf vier Workstations führte.

Von den kompromittierten Workstations aus führte das Red Team einen modifizierten BloodHound-Collector aus, der angepasst wurde, um statische Signaturen des EDR zu umgehen. Das Tool fragte Active Directory ab und sammelte Informationen über Benutzer, Computer, Gruppen, Zugriffssteuerungslisten, Organisationseinheiten und Gruppenrichtlinienobjekte (GPOs). Eine der Workstations hatte die standardmäßige Machine Account Quota (MAQ) von 10: Dieser Wert erlaubt es nicht privilegierten Benutzern, bis zu 10 Computerkonten zur Domäne hinzuzufügen. In Kombination mit fehlkonfigurierten ADCS-Vorlagen gemäß der als ESC1 bekannten Technik konnte das Team ein Computerkonto erstellen und Zertifikate für beliebige Benutzer- oder Computerkonten anfordern. Von dort aus wurde die laterale Bewegung systematisch.

Nachdem erhöhte Privilegien auf der Domäne erlangt wurden, bestand der Plan für den Zugriff auf die SBS darin, Active-Directory-Daten zu nutzen, um Benutzer und Gruppen zu identifizieren, die mit den sensiblen Systemen verbunden sind, SCCM-Server abzufragen, um Benutzer-Geräte-Beziehungen aufzuzählen, und die zugewiesenen Workstations zu ermitteln. Die laterale Bewegung vom SCCM-Server zu den Workstations der Zielbenutzer ermöglichte die Suche nach Anmeldeinformationen. Für das erste SBS, eine Datenbank, wurden auf der Workstation eines administrativen Benutzers Klartext-Anmeldeinformationen gefunden. Für die zweite Datenbank konzentrierte sich die Suche auf die Dateien connections.json und product-preferences.xml eines SQL-Developer-Tools: Nach der Entschlüsselung gaben sie das Klartext-Passwort der Datenbank preis. Für das dritte SBS, ein automatisiertes Verarbeitungssystem, wurden statische, langfristige AWS Identity and Access Management (IAM)-Benutzeranmeldeinformationen erlangt, die in Konfigurationsdateien in den Home-Verzeichnissen der Zielbenutzer gespeichert waren. Die Organisation hatte für diese Anmeldeinformationen kein Ablaufdatum oder keine Rotation konfiguriert.

Es wurde kein Alarm ausgelöst. Der Zugriff auf die SBS wurde auch auf virtuelle Desktops ausgeweitet, die den Zugriff auf aktive und interaktive Benutzersitzungen beschränken und Kontrollen wie die Segmentierung der Netzwerke sensibler Systeme hinzufügen. Auch dies hielt das Red Team nicht auf.

Organisation B: Frühzeitige Erkennung, aber Assume Breach gewährt dennoch Zugriff

Organisation B zeigte eine sehr unterschiedliche Verteidigungshaltung. Sie identifizierte die anfänglichen Kompromittierungsversuche schnell, stellte die betroffenen Systeme unter Quarantäne und zwang das Red Team, zu einem „Assume Breach“-Modell überzugehen. In diesem Modell gewährten die vertrauenswürdigen Agenten der Organisation (Trusted Agents, TA) Zugriff auf einen Host, der das Zugriffsniveau replizierte, das das Red Team gehabt hätte, wenn die Verteidiger die anfängliche Aktivität nicht erkannt hätten.

Von diesem Host aus eskalierte das Red Team die Privilegien, bewegte sich lateral zu den SBS, den Cloud-Ressourcen und einem Bastion-Host in der OT-DMZ. Hier erkannten die Verteidiger die Aktivität erneut und isolierten das System. Der Zugriff auf das OT-Netzwerk wurde ohne tatsächliche Ausführung auf OT-Systemen nachgewiesen. Trotz der doppelten Erkennung und Isolierung ermöglichte das Assume-Breach-Modell dennoch den Nachweis des Zugriffs auf SBS, Cloud und OT-DMZ. Die Resilienz von Organisation B verlangsamte den Angreifer, eliminierte das Risiko jedoch nicht.

Die Techniken hinter der Kompromittierung: ADCS, MAQ, SCCM und statische Anmeldeinformationen

Der Bericht ordnet die Aktivitäten verschiedenen Identifikatoren des MITRE ATT&CK v19-Frameworks zu, darunter T1589.001 (Opferidentifizierung), T1566 (Phishing), T1087.002 (Kontoerkennung), T1018 (Erkennung entfernter Systeme), T1069.002 (Erkennung von Berechtigungsgruppen), T1615 (Erkennung von Gruppenrichtlinien), T1136.002 (Erstellung von Domänenkonten), T1649 (Diebstahl oder Fälschung von Zertifikaten), T1033 (Erkennung des Systembesitzers), T1552 (ungeschützte Anmeldeinformationen) und T1552.001 (Anmeldeinformationen in Dateien).

Die Kombination aus standardmäßiger Machine Account Quota und für ESC1 anfälligen ADCS-Vorlagen ist besonders gefährlich. Die MAQ ermöglicht es einem normalen Benutzer, Computerkonten zu erstellen; ESC1 erlaubt es, Zertifikate für beliebige Konten anzufordern, einschließlich der gerade erstellten. Das Ergebnis ist ein schwer zu erkennender Weg zur Rechteausweitung, wenn das EDR nicht kalibriert ist. Der modifizierte BloodHound-Collector umging die statischen Signaturen und zeigte, dass der allein auf bekannten Signaturen basierende Schutz gegen angepasste Offensivwerkzeuge nicht ausreicht.

Statische, langfristige AWS-IAM-Anmeldeinformationen stellen eine weitere schwerwiegende Schwachstelle dar. Ohne Ablaufdatum oder Rotation bleiben sie nach einem Diebstahl unbegrenzt gültig. Die Dateien connections.json und product-preferences.xml des SQL-Developer-Tools enthalten Passwörter, die mit schwachen oder umkehrbaren Algorithmen verschlüsselt sind: Wer sie findet, kann sie entschlüsseln und direkten Zugriff auf die Datenbank erhalten.

Warum Verteidiger scheitern: Silos, Rauschen und unterschätzte Cloud

Der Vergleich zwischen den beiden Organisationen verdeutlicht wiederkehrende Probleme. Nicht kalibrierte Erkennungswerkzeuge führen zu unerkannten Bedrohungen. Ohne definierte Baselines und Alarmfilterung überlasten Fehlalarme und Routinebenachrichtigungen die Netzwerkverteidiger, die schließlich echte Signale ignorieren. In Organisation A ermöglichte dies dem Angreifer, sich stunden- oder tagelang ungestört zu bewegen.

Organisatorische Silos und bürokratische Hindernisse verhindern eine effektive Reaktion auf Vorfälle. Fragmentierte Kommunikation, unklare Verantwortlichkeiten und begrenzte Befugnisse der Verteidiger behindern die Incident Response selbst dann, wenn Alarme generiert werden. In Organisation B deutet die Notwendigkeit, zum Assume-Breach-Modell überzugehen, darauf hin, dass interne Prozesse die Reaktion auf einen echten Angriff hätten verlangsamen oder erschweren können, obwohl die anfängliche Reaktion schnell war.

Cloud-Umgebungen sind oft ein unterschätztes Risiko. Es fehlen spezifische Sicherheitskontrollen und Prozesse, um auf eine Cloud-Kompromittierung zu reagieren. Statische IAM-Anmeldeinformationen und nicht rotierte Zugriffstoken stellen einen zunehmend ausgenutzten Angriffsvektor dar, doch viele Organisationen haben keine Verfahren, um diese Elemente im Falle eines Vorfalls zu erkennen und zu widerrufen.

Die Empfehlungen der CISA zur Risikominderung

Der Advisory listet vier Schlüsselmaßnahmen auf. Erstens: Etablieren und kontinuierliches Pflegen einer Baseline sowie Reduzierung des Alarmrauschens durch Feintuning. Zweitens: Silos abbauen und Netzwerkverteidiger befähigen, indem klare Befugnisse und Kommunikationskanäle zugewiesen werden. Drittens: Implementierung von Conditional-Access-Richtlinien für Workload-Identitäten und Überwachung übermäßiger oder ungenutzter Berechtigungen. Viertens: Etablierung und regelmäßige Überprüfung umfassender Verfahren zur Erkennung, Behebung und zum Widerruf von Zugriffs- und Refresh-Token im Falle einer Cloud-Kompromittierung.

Zu den Adressaten gehören Behörden des Federal Civilian Executive Branch, staatliche, lokale, Stammes- und Territorialregierungen sowie kritische Infrastrukturen. Die betroffenen Rollen reichen von Systemadministratoren über Incident Responder, defensive Cybersicherheitsanalysten und Schwachstellenanalysten bis hin zu Netzwerkbetreibern und Verantwortlichen für Sicherheitssysteme. Die Botschaft ist klar: Fehlkonfigurationen und statische Anmeldeinformationen sind die bevorzugte Einstiegspforte für Angreifer, und ein SOC, der das Rauschen nicht filtern kann, sieht selbst erfolgreiche Angriffe nicht.