Die meisten Unternehmen mit SIEM-System gehen davon aus, dass sie Angriffe erkennen. Die wenigsten können sagen, welche. Detection Coverage — die systematische Messung dessen, was ein SIEM tatsächlich erkennt und was nicht — ist eine der am stärksten vernachlässigten Disziplinen in der Cybersicherheit.

Das Problem: Gefühlte Sicherheit statt messbare Erkennung

Ein SIEM sammelt Logs, korreliert Events und generiert Alerts. Aber die entscheidende Frage lautet nicht, ob es Alerts generiert — sondern ob es die richtigen Angriffstechniken erkennt. Ein SIEM mit 500 aktiven Regeln kann trotzdem blind sein für die Techniken, die Angreifer tatsächlich einsetzen.

Der Mandiant M-Trends Report 2025 zeigt: Die durchschnittliche Dwell Time — die Zeit zwischen Erstinfektion und Entdeckung — liegt global bei 10 Tagen. Bei Unternehmen ohne externes Monitoring sind es oft Wochen oder Monate. Das bedeutet: Viele SIEM-Systeme erkennen Angriffe entweder gar nicht oder zu spät, um den Schaden zu begrenzen.

Das Problem ist nicht die Technologie. Das Problem ist, dass niemand systematisch misst, was erkannt wird — und was nicht.

MITRE ATT&CK als Messrahmen

Das MITRE ATT&CK Framework katalogisiert über 200 Angriffstechniken in 14 Taktiken — von Initial Access über Lateral Movement bis Exfiltration. Es bietet damit einen standardisierten Rahmen, um Detection Coverage zu messen: Für jede Technik kann dokumentiert werden, ob eine Erkennungsregel existiert, ob sie getestet wurde und ob sie in der Praxis funktioniert.

Die Realität in den meisten Organisationen: Die Coverage-Map zeigt mehr Lücken als Abdeckung. Typische Schwachstellen:

• Initial Access (TA0001): Oft gut abgedeckt durch E-Mail-Security und Endpoint-Detection
• Execution (TA0002): PowerShell- und Script-Monitoring ist verbreitet, aber oft nicht granular genug
• Persistence (TA0003): Häufig blind — Registry-Modifikationen, Scheduled Tasks und DLL-Hijacking werden in vielen SIEM-Konfigurationen nicht überwacht
• Lateral Movement (TA0008): Eine der größten Lücken. Pass-the-Hash, RDP-Hijacking und WMI-basierte Bewegung erzeugen in Standard-SIEM-Konfigurationen oft keine Alerts
• Exfiltration (TA0010): Datenabfluss über HTTPS, DNS-Tunneling oder Cloud-Storage wird selten erkannt

Detection Engineering: Von Regeln zu messbarer Qualität

Detection Engineering behandelt SIEM-Regeln wie Software: Sie werden entwickelt, getestet, versioniert und kontinuierlich verbessert. Der Ansatz geht über das bloße Schreiben von Korrelationsregeln hinaus und umfasst einen vollständigen Lifecycle:

1. Threat Intelligence: Welche Techniken nutzen die Angreifer, die für unsere Branche und Infrastruktur relevant sind?
2. Data Source Mapping: Welche Logs brauchen wir, um diese Techniken zu erkennen? Werden diese Logs tatsächlich gesammelt?
3. Rule Development: Erkennungslogik entwickeln — nicht nur Signaturen, sondern verhaltensbasierte Regeln
4. Testing: Regeln gegen reale Angriffssimulationen (Atomic Red Team, MITRE Caldera) validieren
5. Tuning: False Positives reduzieren, ohne die Erkennungsrate zu opfern
6. Measurement: Coverage gegen ATT&CK-Matrix messen und Lücken dokumentieren

MTTD: Die Metrik, die zählt

Die wichtigste Kennzahl für Detection-Qualität ist Mean Time to Detect (MTTD) — die durchschnittliche Zeit zwischen dem Beginn eines Angriffs und seiner Erkennung. MTTD wird pro Angriffstechnik gemessen, nicht pauschal für das gesamte SIEM.

Warum das wichtig ist: Ein SIEM kann Brute-Force-Angriffe in Sekunden erkennen (niedriger MTTD) und gleichzeitig blind sein für Lateral Movement via WMI (MTTD: unendlich). Der Durchschnittswert verschleiert die tatsächlichen Lücken.

Um MTTD sinnvoll zu messen, brauchen Organisationen regelmäßige Purple-Team-Übungen: Das Red Team führt definierte ATT&CK-Techniken aus, das Blue Team misst, wie schnell — und ob — sie erkannt werden. Die Ergebnisse fließen direkt in die Detection-Engineering-Roadmap.

Die häufigsten Coverage Gaps

Basierend auf Branchenberichten und Erfahrungswerten sind folgende Bereiche in den meisten SIEM-Implementierungen unterabgedeckt:

• Cloud-native Angriffe: Azure AD/Entra-ID-Manipulation, AWS-IAM-Eskalation, GCP-Service-Account-Missbrauch — die meisten SIEMs sammeln On-Premise-Logs zuverlässig, aber Cloud-Telemetrie nur lückenhaft
• Identity-basierte Angriffe: Token Theft, Session Hijacking, OAuth-App-Registrierung — Angriffe, die keine Malware hinterlassen
• Nicht-menschliche Identitäten: Service-Accounts, API-Keys und Bot-Accounts werden selten mit derselben Aufmerksamkeit überwacht wie menschliche Benutzer
• Datenexfiltration: Outbound-Traffic-Analyse, DLP-Integration und DNS-Monitoring fehlen in vielen SIEM-Konfigurationen
• Living-off-the-Land: Angriffe, die ausschließlich legitime System-Tools nutzen (PowerShell, WMI, PsExec), sind ohne Baseline-Monitoring kaum erkennbar

Von der Lückenanalyse zur Roadmap

Detection Coverage zu messen ist kein Selbstzweck. Die Ergebnisse müssen in eine priorisierte Roadmap münden:

1. Bestandsaufnahme: Aktuelle Regeln gegen MITRE ATT&CK mappen — was ist abgedeckt, was nicht?
2. Priorisierung: Welche Techniken nutzen die relevantesten Threat Actors für unsere Branche? Diese zuerst abdecken
3. Data Source Gaps schließen: Oft fehlt nicht die Regel, sondern die Datenquelle. Ohne Cloud-Logs keine Cloud-Detection
4. Testen und validieren: Jede neue Regel muss gegen reale Angriffssimulationen getestet werden — nicht nur syntaktisch korrekt sein
5. Kontinuierlich messen: Coverage ist kein Zustand, sondern ein Prozess. Neue Techniken erfordern neue Regeln

Handlungsempfehlungen

• ATT&CK Coverage Assessment durchführen: Bestehende SIEM-Regeln gegen die MITRE-ATT&CK-Matrix mappen. Tools wie DeTT&CT automatisieren diesen Prozess
• Data Source Inventory erstellen: Dokumentieren, welche Logs tatsächlich gesammelt werden — und welche fehlen. Ohne Daten keine Detection
• Purple-Team-Übungen etablieren: Regelmäßig (mindestens quartalsweise) Angriffstechniken simulieren und MTTD messen
• Detection-as-Code: SIEM-Regeln in Git versionieren, in CI/CD-Pipelines testen und automatisiert deployen
• Coverage-Dashboard aufbauen: Eine ATT&CK-Heatmap, die auf einen Blick zeigt, wo die Erkennung stark ist — und wo die blinden Flecken liegen

KI-Tooling als Einfallstor: Langflow im Fadenkreuz

Die US-amerikanische Cybersecurity-Behörde CISA hat die Schwachstelle CVE-2026-33017 in ihren Known Exploited Vulnerabilities (KEV) Catalog aufgenommen und eine Patch-Frist bis zum 8. April 2026 gesetzt. Betroffen ist Langflow, eine weit verbreitete Open-Source-Plattform zur visuellen Erstellung von KI-Workflows und LLM-Agenten — mit über 60.000 GitHub-Stars und wachsender Verbreitung in Unternehmen.

Die Schwachstelle hat einen CVSS-Score von 9.3 (kritisch) und ermöglicht es Angreifern, ohne Authentifizierung beliebigen Python-Code auf dem Server auszuführen. Das Bemerkenswerte: Die Ausnutzung begann innerhalb von 20 Stunden nach Bekanntwerden — ohne dass ein öffentlicher Exploit-Code existierte.

---

Was ist Langflow — und warum wird es angegriffen?

Langflow ist ein Open-Source-Framework, das es ermöglicht, LLM-Anwendungen (Large Language Models) visuell per Drag-and-Drop zu erstellen. Typische Einsatzgebiete sind RAG-Pipelines (Retrieval-Augmented Generation), KI-Agenten und Workflow-Automatisierungen.

Die Plattform wird von Entwicklungsteams eingesetzt, die schnell KI-Prototypen und Produktionsworkflows aufbauen wollen. Viele Instanzen laufen auf Cloud-Servern — teilweise ohne ausreichende Absicherung oder hinter öffentlich erreichbaren Endpoints. Genau das macht sie zu einem attraktiven Ziel für automatisierte Angriffe.

---

Technische Details: CVE-2026-33017

Die Schwachstelle liegt im Endpoint build_public_tmp, der für öffentliche Flows konzipiert ist und absichtlich ohne Authentifizierung arbeitet. Das Problem: Der Endpoint akzeptiert vom Angreifer übermittelte Flow-Daten, die eingebetteten Python-Code enthalten können. Dieser Code wird ohne Sandboxing direkt auf dem Server ausgeführt.

Laut der NVD-Beschreibung ist dies eine eigenständige Schwachstelle, die sich von CVE-2025-3248 unterscheidet. Letztere betraf den Endpoint /api/v1/validate/code und wurde durch das Hinzufügen einer Authentifizierung behoben. CVE-2026-33017 nutzt einen anderen Angriffsvektor über einen bewusst öffentlich zugänglichen Endpoint.

Betroffen sind alle Langflow-Versionen bis 1.8.2. Das Update auf Version 1.9.0 behebt die Schwachstelle.

---

20 Stunden vom Advisory zum Angriff

Laut einem Bericht von Sysdig begannen Angreifer innerhalb von 20 Stunden nach Veröffentlichung des Advisories, verwundbare Langflow-Instanzen zu attackieren. Sysdig hatte Honeypot-Nodes mit verwundbaren Instanzen über mehrere Cloud-Provider verteilt und beobachtete vier Angriffsversuche innerhalb weniger Stunden nach Deployment.

Ein Angreifer ging dabei über das initiale Scanning hinaus und exfiltrierte Umgebungsvariablen — einschließlich Zugangsdaten und API-Keys.

Besonders alarmierend: Es existierte zum Zeitpunkt der ersten Angriffe kein öffentlicher Exploit-Code auf GitHub. Das Advisory selbst enthielt genügend Details — den verwundbaren Endpoint-Pfad und den Mechanismus zur Code-Injection über Flow-Node-Definitionen — um einen funktionierenden Exploit zu konstruieren.

---

Einheitliches Angriffsmuster: os.popen() + HTTP-Exfiltration

Sysdig identifizierte ein konsistentes Post-Exploitation-Playbook über alle beobachteten Angriffe hinweg:

• Shell-Befehl über Pythons os.popen() ausführen
• Output über HTTP an externe C2-Infrastruktur exfiltrieren
• Umgebungsvariablen (Credentials, API-Keys) abgreifen

Sysdig veröffentlichte zudem eine Liste von Indicators of Compromise (IOCs), darunter Angreifer-IPs, C2-Infrastruktur, Dropper-URLs und Interactsh-Callback-Domains.

---

Warum Runtime Detection entscheidend ist

Sysdig betont, dass bei derart schneller Ausnutzung klassische Patch-Zyklen nicht mehr ausreichen. Runtime Detection bleibt die primäre Verteidigungslinie. Die eingesetzten Erkennungsregeln benötigen keine spezifische Signatur für CVE-2026-33017, weil sie das Exploitation-Verhalten erkennen, nicht die Schwachstelle selbst. Dieselben Regeln greifen unabhängig davon, ob der initiale Zugang über CVE-2026-33017, CVE-2025-3248 oder eine andere RCE erfolgt.

Das heißt: Verhaltensbasierte Erkennung erkennt den Angriff unabhängig von der spezifischen Schwachstelle — ob bekannt oder unbekannt.

---

Was Unternehmen jetzt tun müssen

• Sofort patchen: Update auf Langflow v1.9.0 oder höher
• Exponierte Instanzen prüfen: Jede öffentlich erreichbare Langflow-Instanz als potenziell kompromittiert behandeln
• Zugang einschränken: Langflow niemals ohne Authentifizierung und Netzwerksegmentierung betreiben
• Umgebungsvariablen rotieren: Alle Credentials, API-Keys und Datenbankzugänge auf kompromittierten Systemen sofort wechseln
• Runtime Monitoring: Verhaltensbasierte Erkennung implementieren, die Shell-Ausführung und HTTP-Exfiltration erkennt
• IOCs prüfen: Sysdig-IOCs gegen eigene Logs abgleichen

Die Front hat sich verschoben

„Wir haben früher über Defense-in-Depth und Endpoint Protection gesprochen. Dann kam Identity. Jetzt ist die API das neue Perimeter.“ So beschreibt Sean Murphy, CISO bei BECU, einem der größten US-Kreditinstitute, die aktuelle Lage. Und er steht mit dieser Einschätzung nicht allein.

In einer aktuellen Erhebung von CSO Online berichten mehrere CISOs übereinstimmend: APIs haben Endpoints als primäre Angriffsfläche abgelöst. Sie sind die Eingangstür zu Backend-Systemen, Partnerschnittstellen und Kundendaten — und in vielen Unternehmen weder inventarisiert noch ausreichend geschützt.

---

Die Zahlen: Jede dritte Organisation betroffen

Ein Salt Security Report von 2025 zeigt:

• Jede dritte Organisation wurde in den letzten 12 Monaten über eine API kompromittiert
• 95 % der API-Angriffe kommen von authentifizierten Quellen — über gestohlene API-Keys oder Credentials

Laut einer Studie von Enterprise Management Associates haben rund 70 % der Unternehmen nur 30 % ihrer APIs dokumentiert. Der Rest? Shadow-APIs, die außerhalb jeder Sicherheits-Governance existieren.

Konservative Schätzungen gehen davon aus, dass ein Großunternehmen zwischen 250 und 500 APIs betreibt. In der Realität sind es oft Tausende.

---

Warum EDR und WAF versagen

Das Kernproblem: Traditionelle Sicherheitswerkzeuge wie EDR, XDR und WAF sind für API-Angriffe schlicht nicht gebaut. Sie erkennen Malware auf Endpoints und einfache Web-Exploits — aber API-Missbrauch sieht für diese Systeme wie normaler, valider Traffic aus.

Elliott Franklin, CISO bei Fortitude Re, bringt es auf den Punkt: EDR und WAFs wurden für die Probleme von gestern gebaut. Ohne ein tiefes Verständnis von Business Logic und Identity Context übersehen traditionelle Tools Credential Stuffing, Token-Diebstahl oder Data Scraping.

API-Angriffe nutzen keine Payload-Patterns, die eine WAF erkennen würde. Sie missbrauchen Business Logic: gebrochene Authentifizierung, übermäßig permissive Autorisierung, exzessive Datenexposition. Einzeln betrachtet sind die Requests valide — erst in der Sequenz entsteht der Angriff.

James Faxon, Principal Advisor bei der Risk & Insight Group, erklärt: Ein Angreifer braucht keinen Laptop zu kompromittieren und keine Malware zu deployen. Mit einem gestohlenen Token und einer fehlerhaften Autorisierungslogik kann er sich lateral bewegen und Daten extrahieren, ohne traditionelle Endpoint-Controls auszulösen.

---

KI verschärft das Problem — auf beiden Seiten

Chaim Mazal, Chief AI and Security Officer bei Gigamon, warnt: KI hat die Demokratisierung offensiver Tools ermöglicht. Jeder kann jetzt API-Schwachstellen ausnutzen, unabhängig vom Skill-Level — ohne eine einzige Zeile Code zu schreiben.

Gleichzeitig vergrößert KI die Angriffsfläche von innen: Agentic AI, die autonom über APIs mit Systemen interagiert — einschließlich Model Context Protocol (MCP), Agent-to-Agent-Workflows und automatisierter Integrationen — schafft neue, schwer kontrollierbare Zugriffspfade.

Eine Studie von Software Finder (2025) zeigt: 56 % der IT-Entscheider erwarten, dass ihr Software-Stack bis 2030 KI-gesteuert sein wird. Mehr KI bedeutet mehr API-Aufrufe, mehr nicht-menschliche Identitäten, mehr Angriffsfläche.

---

Die Lieferkette als API-Risiko

Laut Gartner nutzen 71 % der Unternehmen APIs von Drittanbietern — SaaS-Plattformen, Cloud-Dienste, Partner-Integrationen. Jede dieser Verbindungen ist ein potenzieller Angriffsvektor.

Patrick Opet, CISO von JPMorganChase, veröffentlichte 2025 einen offenen Brief, in dem er warnte, dass das SaaS-Modell „stillschweigend Cyber-Angreifer ermöglicht“ und eine „substanzielle Schwachstelle schafft, die das globale Wirtschaftssystem schwächt“.

In der Praxis heißt das: API-Keys und Tokens landen in Repositories, werden nicht rotiert, haben übermäßige Berechtigungen und sind teilweise offen im Web auffindbar. Escape entdeckte 2024 über 18.000 API-Secrets und Tokens im offenen Internet.

---

Was CISOs empfehlen

1. API-Inventar aufbauen

„Was man nicht sieht, kann man nicht schützen“, sagt Andreas Gaetje, CISO bei Körber. Der erste Schritt ist ein vollständiges Inventar aller APIs — intern, extern, und von Drittanbietern. Jede API braucht einen Owner, eine Dokumentation und eine Threat-Model-Bewertung.

2. API Governance einführen

BECU implementierte eine einheitliche API-Policy für alle Entwickler — noch bevor die Technologie ausgerollt wurde. Jeder API-Builder unterliegt derselben internen Richtlinie. Das reduziert Fehlkonfigurationen, die laut OWASP Top 10 das größte API-Risiko darstellen.

3. Identity-basierte Absicherung

APIs als „nicht-menschliche Identitäten“ behandeln: Least-Privilege-Prinzip, zeitgebundene RBAC, regelmäßige Token-Rotation. Fortitude Re integriert API-Sicherheit direkt in die IAM-Strategie und trackt aktiv nicht-menschliche Identitäten.

4. Security in die CI/CD-Pipeline

API-Spezifikationen müssen automatisierte Sicherheitsvalidierung durchlaufen, bevor sie deployed werden. Infinite Computer Solutions hat Security-Checks direkt in die CI/CD-Pipeline eingebettet.

5. Verhaltensbasiertes Runtime-Monitoring

Wenn ein API-Consumer außerhalb seines erwarteten Musters agiert, ist das ein Security Event, keine technische Anomalie. Runtime-Erkennung ist die einzige Verteidigung, die bei Zero-Day-Exploitation funktioniert.

6. Third-Party-APIs wie Risiken behandeln

Credentials von Drittanbietern zentralisieren und verschlüsseln. Niemals rohe API-Keys an Entwicklungsteams verteilen. Regelmäßig rotieren und auf Behavioral Drift überwachen.

Es gibt Cyberangriffe, die einen innehalten lassen. CVE-2026-20131 ist so einer. Denn diesmal sitzt die Schwachstelle nicht in einer veralteten Anwendung, nicht in einem vergessenen System im Keller des Rechenzentrums — sondern direkt im Herz der Netzwerksicherheit: im Management-Interface von Cisco Secure Firewall.

Die amerikanische Bundesbehörde für Cybersicherheit CISA hat in dieser Woche einen dringenden Warnhinweis herausgegeben. Die Lücke wird aktiv ausgenutzt. Nicht theoretisch. Nicht in Proof-of-Concept-Demos. Sondern in echten Ransomware-Angriffen gegen echte Unternehmen — jetzt, gerade, während Sie diese Zeilen lesen.

Was passiert technisch — und warum es so gefährlich ist

Das Cisco Secure Firewall Management Center ist das Werkzeug, mit dem IT-Teams ihre Firewall-Infrastruktur zentral steuern und überwachen. Genau dieses Interface hat eine Schwachstelle in der Art, wie es eingehende Datenpakete verarbeitet.

Die Lücke erlaubt es einem Angreifer, über das öffentlich erreichbare Management-Interface eigenen Code einzuschleusen und auszuführen — mit vollen Systemrechten. Das Fatale: Es wird dafür kein gültiges Passwort, keine Zugangsdaten, keine vorherige Authentifizierung benötigt. Wer das Management-Interface aus dem Internet erreichen kann, kann angreifen.

Mit vollen Administratorrechten auf dem Firewall-Management kann ein Angreifer Sicherheitsregeln deaktivieren oder gezielt umschreiben, Protokollierung und Alarmierung abstellen — der Einbruch bleibt unsichtbar —, den eigentlichen Ransomware-Angriff auf das dahinterliegende Netzwerk vorbereiten und sich dauerhaft im System festsetzen, bevor irgendjemand Alarm schlägt.

Wer Kontrolle über das Firewall-Management hat, hat im Wesentlichen Kontrolle über die gesamte Netzwerksicherheit des Unternehmens.

Betroffen: Cisco Secure Firewall Management Center und Security Cloud Control

Konkret betroffen sind Unternehmen, die Cisco Secure Firewall Management Center (FMC) in verschiedenen Versionen sowie Cisco Security Cloud Control einsetzen. Cisco ist eines der weltweit meistgenutzten Netzwerk- und Sicherheitsunternehmen — entsprechend groß ist die Angriffsfläche.

Die eigentliche Botschaft: Prävention versagt — Detektion ist alles

Viele Sicherheitsstrategien bauen auf dem Prinzip auf: Wenn wir die Firewall richtig konfigurieren, sind wir sicher. CVE-2026-20131 zeigt einmal mehr, dass dieses Prinzip allein nicht ausreicht.

Eine Zero-Day-Lücke ist per Definition eine Schwachstelle, für die es zum Zeitpunkt der Angriffe noch keinen Patch gibt oder die so neu ist, dass viele Systeme noch ungepacht sind. Auch nach Bekanntwerden dauert das vollständige Einspielen von Patches in verteilten Unternehmensinfrastrukturen oft Tage bis Wochen.

Die entscheidende Frage lautet deshalb nicht: „Haben wir eine Firewall?” — sondern: „Merken wir, wenn jemand unsere Firewall bereits kompromittiert hat?”

Hier kommen API-Sicherheitslösungen wie Neosec eine zentrale Rolle zu. Moderne Angriffe — inklusive solcher, die über Management-Interfaces laufen — hinterlassen Spuren im API-Traffic. Ungewöhnliche Anfragen. Zugriffsmuster, die von normalen Administrationsmustern abweichen. Befehle, die zu ungewöhnlichen Zeiten ausgeführt werden. Wer diese Anomalien in Echtzeit erkennt, kann handeln, bevor der eigentliche Schaden entsteht.

Was jetzt zu tun ist

Sind wir betroffen? Setzen wir Cisco Secure Firewall Management Center oder Cisco Security Cloud Control ein? Wenn ja, ist sofortiges Handeln angezeigt. Cisco hat Sicherheitshinweise und — sofern verfügbar — Patches herausgegeben.

Ist das Management-Interface aus dem Internet erreichbar? Jedes Firewall-Management-Interface, das direkt aus dem öffentlichen Internet erreichbar ist, vergrößert die Angriffsfläche massiv. Die Best Practice: Management-Zugang ausschließlich über VPN oder isolierte Management-Netzwerke.

Haben wir Monitoring auf ungewöhnliches Verhalten? Nicht jede Attacke lässt sich verhindern. Aber jede Attacke hinterlässt Spuren — wenn man hinsieht. Stellen Sie sicher, dass Ihre Sicherheitsinfrastruktur Anomalien im API- und Management-Traffic aktiv überwacht und alarmiert.

Was ist unser Incident-Response-Plan? Wenn ein Angriff über diesen Vektor stattgefunden hat — wer wird informiert? Wer entscheidet über Gegenmaßnahmen? Diese Fragen sollten nicht erst im Ernstfall beantwortet werden.

Fazit

CVE-2026-20131 ist kein Einzelfall. Es ist ein weiteres Kapitel in einer langen Geschichte von Schwachstellen in genau den Systemen, denen wir am meisten vertrauen. Perimeter-Sicherheit allein ist seit Jahren nicht mehr ausreichend.

Unternehmen, die heute resilient gegenüber solchen Angriffen sind, haben eines gemeinsam: Sie gehen davon aus, dass Angreifer möglicherweise bereits im Netzwerk sind. Sie investieren in Detektion, Sichtbarkeit und die Fähigkeit, schnell zu reagieren — nicht nur darin, den Einbruch zu verhindern.

Neosec hilft dabei, genau diese Sichtbarkeit herzustellen — besonders dort, wo moderne Angriffe ansetzen: in den APIs und Management-Interfaces, über die heute Infrastruktur gesteuert wird.

Sprechen Sie uns an. Sicherheit beginnt damit, zu wissen, was gerade in Ihrem Netzwerk passiert.

---

Quellen: CISA Advisory zu CVE-2026-20131, Cisco Security Advisory (März 2026)

Das aktuelle SANS Whitepaper von Joshua Wright — „Authorization Sprawl: The Vulnerability Reshaping Modern Attacks” (Oktober 2025) — dokumentiert, wie sich die unkontrollierte Ausbreitung von Zugriffsrechten zum größten Risiko moderner IT-Landschaften entwickelt hat.

Was Authorization Sprawl bedeutet

Unter Authorization Sprawl versteht man die unkontrollierte Ausbreitung von Zugriffsrechten über Systeme, Cloud-Dienste, SaaS-Anwendungen und Identitätsplattformen hinweg. Durch die zunehmende Integration von SSO, API-Tokens und föderierten Identitäten entstehen unzählige Seitentüren ins Unternehmensnetz.

Während Authentifizierung (Login, MFA, EDR) in den letzten Jahren stark verbessert wurde, hinkt die Kontrolle der Autorisierung weit hinterher. Angreifer nutzen diese Asymmetrie gezielt aus: Ein kompromittierter Account, ein offener Token, ein vergessenes Servicekonto — und der Weg ist frei für Datenexfiltration, Lateral Movement und Privilegienausweitung.

Wer diese Schwäche ausnutzt

Bekannte Gruppen wie Scattered Spider, LAPSUS$ und ShinyHunters setzen Authorization Sprawl inzwischen systematisch ein. Ihre Methode: Social Engineering, gestohlene OAuth-Tokens und API-Schlüssel mit SaaS-Schwachstellen kombinieren — und dabei klassische Schutzsysteme vollständig umgehen.

Der Angriffsvektor ist besonders tückisch, weil er innerhalb legitimer Prozesse stattfindet. Es gibt keine Malware, kein verdächtiges Binary, keinen fehlgeschlagenen Login. Der Angreifer nutzt die Berechtigungen, die das System ihm gewährt — nur eben nicht in der Art, wie es vorgesehen war.

Der blinde Fleck: Fokus auf Technik statt auf Autorisierung

Die Untersuchung von SANS identifiziert drei kritische Schwachpunkte in der Verteidigung:

• EDR erkennt diese Angriffe nicht: Die Aktivitäten finden innerhalb legitimer Prozesse statt — Browser, AWS-Sessions, Microsoft-365-Anwendungen. Kein Endpoint-Agent schlägt Alarm, wenn ein Nutzer über die Teams-API auf SharePoint-Daten zugreift — auch wenn er das normalerweise nie tut
• VPNs und Residential Proxies umgehen Geo-Detection: Impossible-Travel-Erkennung versagt, wenn Angreifer lokale Proxy-Dienste nutzen, die IPs im Zielland bereitstellen
• SaaS-Logging ist unzureichend: Viele SaaS-Anbieter bieten nur rudimentäres oder kostenpflichtiges Logging. Ohne vollständige Audit-Logs ist Incident Response nach einem Authorization-Sprawl-Angriff praktisch unmöglich

Wright bringt es auf den Punkt: Wir haben gelernt, wer sich anmeldet — aber nicht, was er danach tut.

Warum Autorisierung das nächste große Schlachtfeld ist

Die Verschiebung von Authentifizierung zu Autorisierung als primärem Angriffsvektor hat strukturelle Ursachen:

• Cloud und SaaS: Jede neue SaaS-Anwendung bringt eigene Berechtigungsmodelle mit. Die Summe aller Berechtigungen über alle Dienste hinweg ist für niemanden mehr überschaubar
• Nicht-menschliche Identitäten: Service-Accounts, API-Keys, OAuth-Tokens und Bot-Accounts wachsen schneller als menschliche Identitäten — und werden seltener überprüft
• Föderierte Identitäten: Ein kompromittierter Identity Provider (Okta, Azure AD, Google Workspace) kompromittiert alle angeschlossenen Dienste gleichzeitig

Handlungsempfehlungen

• Least Privilege konsequent durchsetzen: Regelmäßige Access Reviews für alle Benutzer, Service-Accounts und API-Tokens. Berechtigungen, die länger als 90 Tage nicht genutzt wurden, automatisch entziehen
• SaaS-Audit-Logging aktivieren und zentralisieren: Alle SaaS-Dienste müssen vollständige Audit-Logs liefern — und diese müssen in ein zentrales SIEM fließen
• Post-Authentication-Monitoring: Nicht nur überwachen, wer sich anmeldet, sondern was nach der Anmeldung passiert. Ungewöhnliche API-Aufrufe, Massenzugriffe auf Dateien und neue OAuth-App-Registrierungen sind starke Indikatoren
• Non-Human Identity Management: Service-Accounts und API-Keys inventarisieren, mit Ablaufdaten versehen und regelmäßig rotieren
• Conditional Access für SaaS: Zugriff auf kritische SaaS-Dienste nur von verwalteten Geräten und aus genehmigten Netzwerken erlauben

Am 15. Oktober 2025 veröffentlichte Microsoft Patches für 183 Sicherheitslücken — darunter zwei aktiv ausgenutzte Zero-Days, die grundlegende Fragen über den Zustand von Windows-Altcode aufwerfen.

Die beiden Zero-Days

CVE-2025-24990: Ein Treiber aus dem Jahr 2000

Die erste Schwachstelle betrifft den Agere Modem Driver — eine Komponente, die auf jeder Windows-Version seit Windows 2000 installiert ist. Der Treiber ist auch auf Systemen vorhanden, die keine Modem-Hardware besitzen. Er wurde nie entfernt, weil er als inaktiv galt.

Die Schwachstelle ermöglicht eine Privilegienerweiterung bis zu Systemrechten. Ein Angreifer, der bereits Code auf einem System ausführen kann (etwa nach einem erfolgreichen Phishing-Angriff), kann über den verwundbaren Treiber vollständige Kontrolle über das System erlangen.

Microsoft kündigte an, den Treiber in zukünftigen Windows-Versionen vollständig zu entfernen — ein seltenes Eingeständnis, dass über zwei Jahrzehnte alte Komponenten ein Sicherheitsrisiko darstellen, das nicht durch Patches allein gelöst werden kann.

CVE-2025-59230: Remote Access Connection Manager

Die zweite Schwachstelle betrifft den Remote Access Connection Manager (RasMan) — einen Windows-Dienst, der VPN- und Einwahlverbindungen verwaltet. Auch hier ermöglicht die Lücke eine Privilegienerweiterung. RasMan läuft auf vielen Systemen als Dienst, auch wenn keine VPN-Funktionalität aktiv genutzt wird.

Das eigentliche Problem: Legacy-Code als Angriffsfläche

Beide Zero-Days illustrieren ein systemisches Problem: Windows trägt Altlasten aus über 25 Jahren Entwicklungsgeschichte. Treiber, Dienste und Subsysteme, die für Technologien aus den frühen 2000er Jahren entwickelt wurden, laufen auf modernen Systemen weiter — oft unbemerkt, ungepflegt und mit Privilegien, die sie längst nicht mehr haben sollten.

Für Angreifer sind solche Legacy-Komponenten attraktiv:

• Geringe Aufmerksamkeit: Veraltete Treiber werden selten im Security-Review berücksichtigt
• Hohe Privilegien: Kernel-Mode-Treiber operieren mit maximalen Systemrechten
• Universelle Präsenz: Wenn ein Treiber auf jeder Windows-Installation seit 2000 vorhanden ist, ist die Angriffsfläche global

Das SANS Institute warnt seit Jahren, dass Privilege Escalation über Legacy-Treiber ein zunehmend genutzter Angriffsvektor ist. Die Technik ist unter der MITRE ATT&CK-ID T1068 (Exploitation for Privilege Escalation) dokumentiert.

Was der Patch Tuesday enthielt

Die 183 gepatchten Schwachstellen im Oktober-Update umfassten neben den beiden Zero-Days auch kritische Lücken in:

• Microsoft Exchange Server
• Windows Hyper-V
• Microsoft Office
• .NET Framework

Die schiere Menge an Patches pro Monat — Microsoft hat 2025 durchschnittlich über 100 Schwachstellen pro Patch Tuesday behoben — verdeutlicht die Herausforderung für IT-Teams: Jeder Patch muss bewertet, getestet und deployed werden. Ohne automatisiertes Patch-Management und Priorisierung nach CISA-KEV und CVSS ist das nicht leistbar.

Handlungsempfehlungen

• Sofort patchen: Die beiden Zero-Days werden aktiv ausgenutzt. Priorisieren Sie CVE-2025-24990 und CVE-2025-59230 vor allen anderen Oktober-Patches
• Legacy-Treiber auditieren: Identifizieren Sie veraltete Treiber und Dienste auf Ihren Systemen. Tools wie DriverView oder Autoruns von Sysinternals helfen bei der Bestandsaufnahme
• Attack Surface Reduction (ASR) Rules: Microsoft Defender ASR-Regeln können die Ausnutzung verwundbarer Treiber erschweren
• Privilege Escalation im SIEM überwachen: Alerts auf ungewöhnliche Prozesshierarchien einrichten — wenn ein Standardprozess plötzlich mit SYSTEM-Rechten läuft, ist das ein Alarm
• Patch-Management automatisieren: Bei 100+ Patches pro Monat ist manuelles Patch-Management nicht skalierbar