81 Millionen Azure CLI Password-Spray-Angriffe. Die Angreifer versuchten nicht, die Multi-Faktor-Authentifizierung zu knacken. Sie umgingen sie.
Einundachtzig Millionen Password-Spray-Versuche. Achtundsiebzig kompromittierte Konten. Neununddreißig betroffene Unternehmen. Diese Zahlen veröffentlichte Huntress am 1. Juli 2026 aus einer laufenden Angriffskampagne, die auf Microsoft-Azure-Umgebungen abzielte – und die wichtigste Zahl ist keine davon. Die wichtigste Zahl ist null, nämlich wie viele MFA-Aufforderungen die Angreifer ausgelöst haben.
Diese Kampagne war nicht darauf ausgelegt, MFA zu umgehen, sondern sie komplett zu umgehen. Die Technik ist nicht neu – Sicherheitsexperten haben ROPC-basierte Authentifizierungsangriffe bereits dokumentiert – aber das Ausmaß dieser Kampagne und die gezielte Nutzung der Azure CLI machen sie zum klarsten aktuellen Beispiel dafür, was passiert, wenn veraltete Authentifizierungsverfahren parallel zu modernen Identitätskontrollen in derselben Unternehmensumgebung existieren.
Die Huntress-Analyse beschreibt, wie Angreifer den OAuth-2.0-Flow „Resource Owner Password Credentials“ nutzten, um sich direkt bei Azure AD zu authentifizieren – ohne Conditional Access Policies oder MFA-Anforderungen auszulösen. Um zu verstehen, warum das funktioniert, muss man wissen, was ROPC ist, wie es sich von modernen Authentifizierungsverfahren unterscheidet und warum es trotz der Abkündigung durch Microsoft in den meisten Azure-Mandanten weiterhin verfügbar ist.
Wichtige Erkenntnisse
1. Huntress dokumentierte 81 Millionen Azure CLI Password-Spray-Versuche, die 78 Konten in 39 Unternehmen kompromittierten.
Die Kampagne zielte auf einen veralteten OAuth-2.0-Flow namens Resource Owner Password Credentials (ROPC) ab, der Anmeldedaten direkt an Azure AD überträgt und moderne MFA- sowie Conditional Access Policy-Kontrollen vollständig umgeht.
2. ROPC ist von Microsoft abgekündigt, aber weiterhin weit verbreitet nutzbar.
Der OAuth-2.0-ROPC-Flow wurde für Altsysteme entwickelt, die keine Weiterleitung der Anwender in einen Browser zur Authentifizierung unterstützen. Microsoft hat ihn zugunsten moderner Flows abgekündigt, aber da er in den meisten Azure-Mandanten technisch weiterhin funktioniert, können Angreifer ihn nutzen, um sich zu authentifizieren, ohne MFA oder Conditional Access Policy-Kontrollen auszulösen.
3. Fehlkonfigurationen bei Conditional Access Policies sind der Hauptgrund.
Selbst Unternehmen mit Conditional Access Policies haben oft Lücken – bestimmte Anwendungen, Anwendergruppen oder standortbasierte Bedingungen, die ROPC-Datenverkehr ungeschützt lassen. Die Azure CLI ist eine häufige Ausnahme, sodass Entwickleranmeldedaten, die über ROPC authentifiziert werden, Produktionsressourcen erreichen können.
4. Das Angriffsmuster nutzt die Lücke zwischen Policy-Absicht und technischer Durchsetzung aus.
Unternehmen glauben, dass MFA ihre Azure-Umgebung schützt, weil es browserbasierte Authentifizierung absichert. ROPC-Authentifizierung läuft jedoch nicht über denselben Flow. Das ist keine Schwachstelle in MFA selbst – es handelt sich um eine Fehlkonfiguration, die einen veralteten Authentifizierungspfad neben dem modernen offenlässt.
5. Die Lösung erfordert mehr als Passworthygiene.
Um den ROPC-Angriffspfad zu blockieren, ist eine Kombination nötig: Sperrung veralteter Authentifizierungsprotokolle auf Mandantenebene, Prüfung der Conditional Access Policy auf Lücken, Rotation der Anmeldedaten für Konten mit Azure CLI-Zugriff und Implementierung von Identity and Access Management-Kontrollen, die ROPC-Authentifizierungen als Anomalien kennzeichnen.
Sie vertrauen auf die Sicherheit Ihres Unternehmens. Aber können Sie es auch nachweisen?
Jetzt lesen
Was ist ROPC und warum existiert es noch?
Das OAuth-2.0-Framework bietet verschiedene Authentifizierungsflüsse für unterschiedliche Anwendungsfälle. Der moderne Standard für interaktive Benutzeranmeldung ist der Authorization-Code-Flow mit PKCE – dabei werden Anwender zum Identity Provider weitergeleitet, geben dort ihre Anmeldedaten ein und erhalten einen Autorisierungscode für die Anwendung. Dieser Flow ist mit MFA und Conditional Access Policies kompatibel, da die Authentifizierung beim Identity Provider erfolgt, wo diese Kontrollen greifen.
ROPC wurde als Alternative für Altsysteme entwickelt, die keine browserbasierten Weiterleitungen unterstützen. Statt Anwender auf eine Login-Seite zu schicken, nimmt ROPC Anmeldedaten direkt von der Anwendung entgegen und sendet sie als POST-Request an den Identity Provider. Die Anwendung selbst übernimmt den Austausch der Zugangsdaten.
Microsoft hat ROPC abgekündigt, weil es architektonisch nicht mit modernen Sicherheitskontrollen vereinbar ist. Die Anmeldedaten fließen durch die Anwendung und nicht durch die Authentifizierungsoberfläche des Identity Providers, sodass MFA-Aufforderungen nicht in den Flow eingebunden werden können. Conditional Access Policies, die auf Anmeldeereignisse reagieren, werden nicht ausgelöst. Die Token-Ausgabe erfolgt, ohne dass die vollständige Conditional-Access-Prüfung des Identity Providers abgeschlossen ist.
Das Problem: Abkündigung bedeutet nicht Deaktivierung. ROPC ist in den meisten Azure-Mandanten weiterhin funktionsfähig. Microsoft bewegt Kunden zwar zu modernen Authentifizierungsflüssen, aber ROPC bleibt aus Gründen der Abwärtskompatibilität mit Altsystemen aktiv. In der von Huntress dokumentierten Kampagne nutzten Angreifer ROPC, um sich gegen die Azure CLI zu authentifizieren – ein gängiges Entwickler-Tool mit Zugriff auf Azure-Ressourcen –, weil die Azure CLI ROPC-Authentifizierung unterstützt und die meisten Unternehmen sie nicht explizit blockiert haben. Eine formale Risikoanalyse der Abdeckung von Authentifizierungsprotokollen – insbesondere die Zuordnung, welche Legacy-Flows in welchen Anwendungsszenarien noch aktiviert sind – ist der Ausgangspunkt, um diese Lücke zu schließen, bevor daraus ein Datenschutzvorfall wird.
Wie der Angriff in der Praxis abläuft
Die von Huntress dokumentierte Kampagne folgt einem bekannten Muster: Gültige Benutzernamen ermitteln, Credential Stuffing oder Password Spray gegen ROPC-fähige Endpunkte durchführen, Tokens aus erfolgreichen Authentifizierungen abgreifen und diese Tokens zum Zugriff auf Azure-Ressourcen verwenden.
Die Azure-CLI-Komponente ist entscheidend, weil CLI-Zugriff typischerweise weitreichende Berechtigungen umfasst. Entwicklerkonten mit Azure CLI-Zugriff haben oft Rechte auf Produktionsumgebungen, Ressourcengruppen, Speicherkonten und Compute-Ressourcen. Die CLI ist ein Verwaltungstool – sie soll breiten Zugriff ermöglichen. Kompromittieren Angreifer ein CLI-Konto über ROPC, erhalten sie nicht nur Zugriff auf E-Mails, sondern potenziell auf die gesamte Infrastruktur.
Brute-Force-Angriffe auf klassische Authentifizierungsendpunkte sind auffällig. Sie erzeugen fehlgeschlagene Anmeldeereignisse, die SIEM-Plattformen und Identitätsschutzsysteme erkennen und melden. ROPC-basierte Password-Sprays können unauffälliger sein: Sie erzeugen nicht dieselben browserbasierten Authentifizierungsereignisse, und viele Unternehmen protokollieren die ROPC-Token-Ausgabe nicht mit der gleichen Genauigkeit wie interaktive Anmeldungen.
Die Zahl von 81 Millionen Versuchen spiegelt den rechnerischen Aufwand für Credential Spraying im großen Stil wider – es ist eine große Zahl, aber die 78 erfolgreichen Kompromittierungen (0,000096 % Erfolgsquote) zeigen auch, wie viele Versuche nötig sind, um eine Übereinstimmung zu finden. Das eigentliche Risiko ist nicht die Anzahl der Versuche, sondern dass jede erfolgreiche ROPC-Authentifizierung ein Bearer-Token liefert, das Zugriff auf alles gewährt, was das kompromittierte Konto erreichen kann. Ein einziges kompromittiertes Entwicklerkonto mit Zugriff auf Produktionsspeicher, Compute-Ressourcen und CI/CD-Pipelines bedeutet gleichzeitig einen Datenschutzverstoß und einen Infrastrukturvorfall – die Kombination aus geistigem Eigentum in Code-Repositorys und regulierten Daten im Cloud-Speicher kann erhebliche Melde- und Behebungsverpflichtungen nach sich ziehen.
Phishing und Passwortwiederverwendung sind die häufigsten Quellen für die in Spray-Kampagnen genutzten Zugangsdaten. Sobald Anmeldedaten in Leak-Datenbanken auftauchen – und das tun sie meist früher oder später –, werden sie als Input für automatisierte Spray-Tools genutzt. ROPC-Authentifizierung im großen Stil hängt im Wesentlichen davon ab: (a) wie viele gültige Zugangsdaten Angreifer aus früheren Datenpannen besitzen und (b) wie viele Mandantenendpunkte über ROPC ohne CAP-Kontrolle erreichbar sind.
Das Problem der Conditional Access Policy Coverage
Conditional Access Policies sind die zentrale Defense-in-Depth-Sicherheitskontrolle für Azure-AD-Umgebungen. Sie ermöglichen Unternehmen, Bedingungen für erfolgreiche Authentifizierung zu definieren – etwa MFA-Anforderungen, Sperrung riskanter Anmeldeorte oder Zugriffsbeschränkungen auf konforme Geräte. Bei korrekter Konfiguration machen CAPs Password-Sprays weitgehend wirkungslos, da selbst gültige Zugangsdaten ohne erfüllte Policy-Bedingungen nicht authentifiziert werden.
Das Problem bei ROPC-Angriffen ist nicht, dass CAPs nicht funktionieren, sondern dass die Abdeckung selten vollständig ist. Unternehmen setzen CAPs schrittweise um, meist beginnend mit besonders kritischen Anwendungen und Anwendergruppen, und sammeln im Laufe der Zeit Ausnahmen an. Die Azure CLI ist eine typische Ausnahme: Entwickler benötigen CLI-Zugriff, CLI-basierte Tools laufen oft in automatisierten Pipelines, die keine MFA-Unterbrechungen verarbeiten können – das Ergebnis ist eine CAP-Ausnahme, die CLI-Authentifizierung zum Schwachpunkt macht.
Fehlkonfigurationen in der Identitätsschicht zählen durchgängig zu den effektivsten Angriffsvektoren. Eine einzige falsch konfigurierte Policy-Ausnahme kann Zugangsdaten für Legacy-Authentifizierungspfade freigeben, die ansonsten robuste MFA-Kontrollen umgehen. Die Huntress-Kampagne ist ein direktes Ergebnis dieses Musters: 78 kompromittierte Konten nicht, weil MFA schwach ist, sondern weil diese Konten eine CAP-Ausnahme hatten oder im Anwendungsscope lagen, der ROPC-Authentifizierung erlaubte.
Die Audit-Frage, die Unternehmen stellen sollten, lautet nicht „Haben wir Conditional Access Policies?“, sondern „Decken unsere Conditional Access Policies alle Authentifizierungspfade ab – einschließlich Legacy-Protokollendpunkte – für alle Benutzerkonten?“ Die meisten Unternehmen haben dies nicht auf Protokollebene geprüft. Die Erweiterung des Supply-Chain-Risikomanagements auf diese Fragestellung ist besonders für Unternehmen relevant, die Azure-CLI-Zugriff an Drittentwickler, Auftragnehmer oder Managed Service Provider vergeben haben – jede externe Anmeldeinformation mit CLI-Zugriff ist ein ROPC-Exposure-Point, den das CAP-Audit des Hauptunternehmens nicht direkt kontrollieren kann.
Identity Governance jenseits von MFA
Das ROPC-Angriffsmuster zeigt strukturell, dass MFA allein nicht ausreicht. MFA wirkt auf interaktiven Authentifizierungsflüssen. Legacy-Authentifizierungsprotokolle wurden bewusst außerhalb interaktiver Flows konzipiert. Sie sind per Design nicht MFA-kompatibel.
Die architektonische Antwort muss auf Protokollebene ansetzen, nicht nur auf Zugangsdatenebene. Legacy-Authentifizierung zu blockieren bedeutet, Azure AD so zu konfigurieren, dass ROPC-Token-Anfragen komplett abgelehnt werden – eine CAP kann erstellt werden, die Legacy-Authentifizierung für alle Anwender oder definierte Gruppen blockiert. Dies ist die wichtigste empfohlene Maßnahme laut Microsoft und Huntress.
Role-based access control und attribute-based access control Frameworks, die Entwickleranmeldedaten auf das notwendige Minimum beschränken, reduzieren das Schadenspotenzial eines ROPC-Komprimats. Ein Entwicklerkonto, das nur auf bestimmte Speichercontainer zugreifen und in bestimmte Ressourcengruppen deployen kann, ist weniger kritisch als ein Konto mit Contributor-Rechten für ein gesamtes Abonnement. Datenminimierung auf Zugangsdatenebene – also die Zuweisung von Entwicklerkonten mit minimalen Azure-Berechtigungen für die jeweilige Aufgabe, regelmäßig überprüft statt über Jahre hinweg angesammelt – macht Least-Privilege im laufenden Betrieb zur Realität statt zur bloßen Absicht bei der Bereitstellung.
Identity and Access Management-Programme, die Entwickleranmeldedaten als eigene Risikokategorie behandeln – mit Rotationsplänen, Zugriffsumfangsprüfungen und Anomalieerkennung bei ROPC-Token-Ausgaben – sind die unternehmensweite Antwort auf dieses Angriffsmuster. Die meisten IAM-Programme wurden für die Verwaltung menschlich vergebener Zugangsdaten in browserbasierten Workflows entwickelt. Entwickleranmeldedaten, die in CLI-Tools und Automatisierungspipelines genutzt werden, fallen oft außerhalb dieser Workflows.
Zero trust architecture für Cloud-Identitäten verlangt kontinuierliche Überprüfung auf Authentifizierungsereignisebene, nicht nur auf Anwendungsebene. Wird ein Token über ROPC ausgestellt, besagen zero trust-Prinzipien, dass dieses Token auf Risikosignale geprüft werden sollte – ungewöhnliche Quellregionen, Muster bei der Zugangsdatenwiederverwendung, Zugriffsfrequenz – bevor Ressourcen bereitgestellt werden. Diese kontinuierliche Bewertung bieten CAP-basierte Kontrollen, weshalb das CAP-Bypass-Potenzial von ROPC so gravierend ist.
Der Kiteworks Data Security and Compliance Risk: Annual Forecast Report 2026 zeigte, dass Lücken im Identity and Access Management weiterhin zu den häufigsten Ursachen für Datenpannen in Unternehmen zählen. Die von Huntress dokumentierte ROPC-Kampagne ist ein präzises Beispiel: kein raffinierter Zero-Day, sondern eine Legacy-Protokoll-Lücke, die viele Unternehmen in ihren Identity-Governance-Programmen nicht gezielt adressiert haben. Unternehmen, die sensible Inhalte über ein Private Data Network mit richtlinienbasierten Zugriffskontrollen und unveränderlicher Audit-Protokollierung auf Inhaltsebene leiten, verfügen über eine zusätzliche Schutzschicht: Selbst ein kompromittiertes Azure-Konto mit Produktionszugriff kann auf Inhalte, die durch Kiteworks-eigene ABAC-Richtlinien auf bestimmte autorisierte Identitäten beschränkt sind, nicht zugreifen.
Sofortige Maßnahmen zur Schadensbegrenzung
Die Huntress-Analyse gibt konkrete Empfehlungen, die Unternehmen sofort umsetzen können. Die wichtigsten Maßnahmen sind:
Legacy-Authentifizierung auf Mandantenebene blockieren. Azure AD Conditional Access Policies können veraltete Authentifizierungsprotokolle wie ROPC für alle Anwender oder gezielt für Gruppen und Anwendungen sperren. Microsoft stellt dafür eine Policy-Vorlage bereit. Unternehmen, die diesen Schritt wegen Abhängigkeiten von Altsystemen verzögert haben, sollten diese Abhängigkeiten prüfen und einen Migrationspfad erstellen.
Abdeckung der Conditional Access Policy prüfen. Alle Benutzerkonten und Anwendungen den jeweils geltenden CAPs zuordnen. Lücken identifizieren – Anwendungen ohne CAP, Benutzerkonten ohne MFA-Anforderung, Servicekonten mit CLI-Zugriff, die Conditional Access umgehen. Jede Lücke ist ein potenzieller ROPC-Exposure-Point.
Zugangsdaten für Konten mit Azure CLI-Zugriff rotieren. In der Huntress-Kampagne wurden 78 Konten erfolgreich über ROPC authentifiziert, bevor die Kampagne entdeckt wurde. Unternehmen, die eine Gefährdung nicht ausschließen können, sollten alle Entwicklerkonten mit CLI- oder programmatischem Azure-Zugriff rotieren.
Sign-in-Logging für ROPC-Ereignisse aktivieren. Die Anmeldeprotokolle von Azure AD erfassen Authentifizierungsereignisse, auch für Legacy-Authentifizierung. Die Konfiguration von SIEM-Alarmen für ROPC-Authentifizierungen bietet eine Frühwarnung für künftige Spray-Versuche – und schafft die Audit-Log-Basis für die Incident Response.
Anomalieerkennung bei Token-Ausgabe implementieren. ROPC-Token-Anfragen aus unerwarteten IP-Bereichen, Regionen oder zu ungewöhnlichen Zeiten sind erkennbare Signale. Identity-Protection-Tools, die Authentifizierungsrisiken bewerten, können ROPC-Sprays erkennen, bevor sich erfolgreiche Authentifizierungen häufen. Das CISO-Dashboard bietet Security-Verantwortlichen Echtzeit-Transparenz über Zugriffsaktivitäten auf Inhalte in allen überwachten Kanälen – sodass auffällige Aktivitäten nach einer Kompromittierung sichtbar werden, bevor sie zu einem meldepflichtigen Vorfall eskalieren.
Erfahren Sie mehr darüber, wie Kiteworks Identity Governance, Zugriffskontrollen und Cloud-Sicherheitskonfigurationen in regulierten Umgebungen adressiert – vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Der Resource Owner Password Credentials (ROPC) Flow ist ein veralteter OAuth-2.0-Authentifizierungsmechanismus, bei dem Benutzeranmeldedaten direkt von einer Anwendung als POST-Request an den Identity Provider gesendet werden – ohne browserbasierte Weiterleitung wie bei modernen Flows. Da die Anmeldedaten durch die Anwendung und nicht durch die Authentifizierungsoberfläche des Identity Providers fließen, können MFA-Aufforderungen nicht eingebunden werden und Conditional Access Policy-Prüfungen werden nicht ausgelöst. Microsoft hat ROPC wegen dieser Sicherheitsdefizite abgekündigt, aber das Protokoll ist in den meisten Azure-Mandanten weiterhin funktionsfähig, um die Kompatibilität mit Altsystemen zu gewährleisten. Huntress hat dokumentiert, wie Angreifer diesen Flow nutzten, um 81 Millionen Password-Spray-Versuche gegen Azure CLI-Endpunkte im Jahr 2026 durchzuführen und dabei 78 Konten kompromittierten – ohne eine einzige MFA-Aufforderung auszulösen. Die Fehlkonfiguration liegt nicht in MFA selbst, sondern in der fortbestehenden Verfügbarkeit eines Authentifizierungspfads, der sie umgeht. Unternehmen mit Compliance-Anforderungen – HIPAA, CMMC, DSGVO, FINRA – sollten die ROPC-Verfügbarkeit in ihrem Azure-Mandanten als Compliance-Lücke behandeln, da unüberwachte Legacy-Authentifizierungspfade die Zugriffskontroll-Dokumentation dieser Frameworks untergraben.
Ein Azure CLI Password-Spray-Angriff mit ROPC läuft wie folgt ab: Angreifer beschaffen oder erstellen eine Liste gültiger Azure AD-Benutzeranmeldedaten – meist aus früheren Datenpannen, Phishing-Kampagnen oder Credential-Stuffing-Ergebnissen. Diese Anmeldedaten werden dann über Azure CLI-Authentifizierungsanfragen gegen den ROPC-Token-Endpunkt von Azure AD eingereicht. Sind die Zugangsdaten gültig und blockiert keine Conditional Access Policy den ROPC-Flow für das Konto, stellt Azure AD ein Zugriffstoken aus – ohne MFA auszulösen. Der Angreifer nutzt dieses Token, um Azure CLI-Befehle gegen die Azure-Ressourcen des Opfers auszuführen. Der Angriff ist über SIEM-Monitoring von Legacy-Authentifizierungsereignissen in Azure AD-Protokollen erkennbar – aber nur, wenn Logging und Alarme konfiguriert sind. Zero trust architecture-Prinzipien, die kontinuierliche Überprüfung auf Token-Ausstellungsebene verlangen – inklusive Risikobewertung für Legacy-Authentifizierungsanfragen – bieten eine Erkennung, die MFA allein nicht leistet. Ein dokumentierter Incident-Response-Plan, der explizit ROPC-Kompromittierungsszenarien abdeckt – inklusive Azure-Aktivitätsprotokoll-Prüfung und Zugangsdatenrotation – gibt Sicherheitsteams einen klaren Ablauf von der Erkennung bis zur Eindämmung.
Eine Conditional Access Policy (CAP) in Azure AD definiert Bedingungen, unter denen Authentifizierung erfolgreich ist – etwa MFA-Anforderungen aus bestimmten Regionen, Sperrung riskanter Anmeldungen oder Zugriffsbeschränkungen auf konforme Geräte. Bei korrekter Konfiguration und Abdeckung machen CAPs Password-Spray-Angriffe weitgehend wirkungslos, da selbst gültige Zugangsdaten ohne erfüllte Policy-Bedingungen nicht authentifiziert werden. Der ROPC-Angriff umgeht CAPs, weil deren Durchsetzung bei interaktiven Anmeldeereignissen greift; ROPC-Token-Anfragen lösen diesen Flow nicht aus. Zudem haben viele Unternehmen CAP-Ausnahmen für Entwicklerwerkzeuge, Automatisierungspipelines und Altsysteme, die ROPC-kompatible Authentifizierung benötigen. Diese Ausnahmen schaffen die Lücken, die die von Huntress dokumentierte Kampagne ausnutzte. Identity and Access Management-Audits, die gezielt die Abdeckung von Authentifizierungsprotokollen – nicht nur von Anwendungen – prüfen, sind nötig, um diese Lücken zu identifizieren. Zugriffskontrollen auf Inhaltsebene – nicht nur auf Identitätsebene – bieten eine zusätzliche Schutzschicht, die selbst dann greift, wenn eine Authentifizierungslücke die Token-Ausgabe ermöglicht.
MFA-Anforderungen in Azure AD bedeuten, dass interaktive Authentifizierungsflüsse eine MFA-Prüfung auslösen, bevor Tokens ausgestellt werden. Das Blockieren von Legacy-Authentifizierung bedeutet, dass Azure AD Token-Anfragen, die veraltete Authentifizierungsprotokolle (inklusive ROPC) nutzen, unabhängig von der Gültigkeit der Zugangsdaten komplett ablehnt. Das sind zwei separate Kontrollen mit unterschiedlichen Effekten. MFA allein schützt nicht vor ROPC-Angriffen, da ROPC den interaktiven Authentifizierungsflow, in dem MFA greift, umgeht. Das Blockieren von Legacy-Authentifizierung stoppt ROPC-Token-Anfragen bereits vor der Zugangsdatenprüfung und verhindert den Angriff auf Protokollebene. Microsoft empfiehlt das Blockieren von Legacy-Authentifizierung als Baseline-Sicherheitskonfiguration, und Azure AD stellt dafür eine CAP-Vorlage bereit. Unternehmen sollten beide Maßnahmen umsetzen: MFA für alle interaktiven Authentifizierungen verlangen und Legacy-Authentifizierungsprotokolle für alle Benutzerkonten und Anwendungen, die auf moderne Flows umgestellt wurden, blockieren. Role-based access control mit Least-Privilege-Scope für Entwickleranmeldedaten reduziert den Schaden durch verbleibende Legacy-Lücken. Programme zum Management von Drittparteien sollten sicherstellen, dass Managed Service Provider und Auftragnehmer in der Azure-Umgebung bestätigt haben, dass sie Legacy-Authentifizierung in ihren eigenen Admin-Tools blockiert haben – ein MSP-Konto mit ROPC-fähigen CLI-Zugangsdaten schafft dasselbe Risiko wie ein internes Entwicklerkonto.
Unternehmen, die vermuten, Ziel einer Azure CLI ROPC Password-Spray-Kampagne gewesen zu sein, sollten fünf Sofortmaßnahmen ergreifen. Erstens: Azure AD-Anmeldeprotokolle ziehen und die letzten 90 Tage nach Legacy-Authentifizierungsereignissen filtern – ROPC-Token-Anfragen erscheinen als solche. Zweitens: Alle Konten identifizieren, die sich erfolgreich über Legacy-Authentifizierung angemeldet haben, und deren Azure-Aktivitätsprotokolle auf unbefugte Ressourcenzugriffe prüfen. Drittens: Zugangsdaten für alle Konten mit Azure CLI-Zugriff rotieren – unabhängig davon, ob ROPC-Authentifizierung bestätigt ist. Viertens: Eine Conditional Access Policy implementieren, die Legacy-Authentifizierung für alle Benutzerkonten oder mindestens für alle Konten mit Azure CLI- oder API-Zugriff blockiert. Fünftens: Alle CAP-Ausnahmen für Entwicklerwerkzeuge und Automatisierungskonten prüfen und schließen. Anschließend sollte eine vollständige Audit-Log-Basis geschaffen und SIEM-Alarme für künftige ROPC-Authentifizierungen konfiguriert werden. Der Incident-Response-Prozess sollte alle Erkenntnisse für etwaige regulatorische Compliance-Meldepflichten dokumentieren. Unternehmen, die regulierte Daten verwalten – PHI, CUI, personenbezogene Daten – sollten zudem prüfen, ob Speicher- oder Daten-Repositorys, auf die kompromittierte Azure-Zugangsdaten zugreifen konnten, Inhalte enthalten, die eine Meldepflicht nach geltenden Regelwerken auslösen.
Weitere Ressourcen
- Blogbeitrag
So gestalten Sie einen sicheren File-Transfer-Workflow für Drittanbieter und Auftragnehmer - Blogbeitrag
Die Bedeutung des Vendor Risk Managements für CISOs - Blogbeitrag
So schützen Sie geistiges Eigentum bei der Zusammenarbeit mit externen Partnern - Blogbeitrag
Bedrohungen bekämpfen mit Supply-Chain-Security und Risk Management - Blogbeitrag
Partner-Datenpannen: Ihre Sicherheit ist nur so stark wie Ihr schwächster Partner