Password Spraying stieg um das 155-Fache — weil MFA nie ausgelöst wurde

In der ersten Hälfte 2026 hat Huntress bei seinen Kunden einen 155-fachen Anstieg von Password-Spraying-Angriffen gemessen. Das war keine Rückkehr zur lauten Brute Force. Es war die ruhige Wiederverwendung alter Passwörter gegen einen Anmeldeweg, der nie nach einem zweiten Faktor fragte.

Ein großer Teil des Traffics galt Microsofts Azure CLI. In einem Zwei-Wochen-Fenster Mitte Juni zählte Huntress mehr als 81 Millionen Anmeldeversuche und 78 kompromittierte Konten in 64 Organisationen. Viele glaubten, MFA sei bereits aktiv. Für die vom Angreifer genutzte Methode feuerte sie nie.

Dieser Artikel erklärt, was Spraying ist, wie die LSHIY-Kampagne einen veralteten OAuth-Grant missbraucht hat, warum Conditional Access vollständig wirkte und unvollständig blieb – und was sich ändern muss, damit ein Passwort allein die Tür nicht öffnet.

Spraying ist nicht Brute Force

Ein Brute-Force-Angriff hämmert ein Konto mit vielen Passwortversuchen. Das löst Sperren, Ratenlimits und „Impossible Travel“-Alarme aus. Password Spraying kehrt die Reihenfolge um: Der Angreifer wählt ein wahrscheinliches Passwort, testet es gegen eine lange Benutzernamenliste, wartet und wechselt dann zum nächsten Passwort.

• Brute Force: viele Versuche gegen ein Konto. Schnell, laut, leicht zu sperren.
• Password Spraying: ein Versuch gegen viele Konten. Langsam genug, um unter Sperrschwellen zu bleiben.
• Credential Stuffing: bekannte E-Mail/Passwort-Paare aus früheren Leaks, erneut auf anderen Seiten getestet.

Diese Kampagne mischte Spray-Skala mit gestohlenen Paaren

Die LSHIY-Kampagne lag zwischen den letzten beiden Kategorien. Huntress berichtete, dass das Targeting der Häufigkeit von Passwörtern in kompromittierten Combo-Listen folgte, nicht Branche oder Unternehmensgröße. Angreifer nutzten Benutzername-Passwort-Paare, die bereits geleakt und nie rotiert worden waren. Deshalb zählt Einzigartigkeit auch dann, wenn MFA auf dem Papier existiert: Ein wiederverwendetes Passwort, das noch funktioniert, ist eine wartende Sitzung.

Ein typisches Spray beginnt weiter mit Aufklärung — gültige Benutzernamen über LinkedIn, Firmenwebseiten, Leak-Dumps oder Phishing — und einer kurzen Liste häufiger oder saisonaler Passwörter. Dieser Operator brauchte keine cleveren Ratespiele. Die Passwörter waren schon bekannt. Der Vorteil lag im Volumen, in schwer zu blockierender Infrastruktur und in einem Anmeldefluss, der die MFA-Seite übersprang.

Der Auth-Flow, den die Zeit vergessen hat

Azure CLI, das Kommandozeilenwerkzeug für Azure und Microsoft Entra, akzeptiert noch einen veralteten OAuth-Grant namens Resource Owner Password Credentials (ROPC). Microsofts Dokumentation warnt, ROPC sei mit Multifaktor-Authentifizierung unvereinbar. OAuth 2.1 hat den Grant vollständig deprecated.

Bei einer normalen Browser-Anmeldung landet der Nutzer auf einer Autorisierungsseite. Dort kann Conditional Access MFA verlangen, den Gerätezustand prüfen oder einen riskanten Standort ablehnen. ROPC besucht diese Seite nie. Der Client schickt Benutzername und Passwort direkt an den Token-Endpunkt des Mandanten. Ist das Passwort noch gültig, kann dort ein benutzerdelegiertes Token ohne interaktive Abfrage entstehen.

Huntress-Threat-Intelligence-Leiter Andrew „Spike“ Brandt sagte es klar: Auch wenn wir ROPC eine Autorisierungsmethode nennen, „ist es technisch eine Impersonationsmethode“. Für einen Angreifer mit einem wiederverwendeten Passwort ist das der ganze Gewinn — eine Sitzung, kein Ratespiel.

MFA war konfiguriert. Die Richtlinie war es nicht.

Das ist der Punkt, der jeden beunruhigen sollte, der ein MFA-Häkchen für das Ziel hält. Beim Peak am 22. Juni prüfte Huntress 23 betroffene Unternehmen. Acht hatten gar keine MFA-Richtlinie. Die übrigen 15 hatten MFA über Conditional Access erzwungen — und verloren trotzdem Konten — weil die Richtlinie den Angriffspfad nicht abdeckte.

• MFA galt nur für bestimmte Apps, etwa Microsoft-Adminportale, Azure CLI blieb außen vor.
• MFA galt nur für bestimmte Gruppen, oft „nur Admins“, während die kompromittierten Nutzer außerhalb lagen.
• MFA war nur von nicht vertrauenswürdigen Standorten nötig. Uneinheitliche IPv6-Geolokalisierung ließ Angreiferadressen vertrauenswürdig erscheinen.
• MFA blieb im Nur-Bericht-Modus: konfiguriert, beobachtet, nie durchgesetzt.

Eine spätere Zählung machte die Lücke klarer

In einem Follow-up schrieb Huntress, dass 55 der 78 kompromittierten Konten bereits Conditional-Access-Richtlinien mit MFA-Pflicht hatten. Eine Organisation nannte eine Richtlinie sogar „Block Azure CLI“. Sie blockierte Azure CLI nicht. MFA scheiterte nicht als Technik. Sie scheiterte als Geltungsbereich.

Huntress sah nach den erfolgreichen LSHIY-Logins keine Nachkompromittierungsaktivität. Product Manager Rich Mozeleski vermutet, der Operator habe Zugangsdaten zur Weiterverkaufsvalidierung geprüft statt in den Mandanten zu leben. Das tröstet wenig. Ein bestätigtes Passwort, das MFA umgeht, bleibt Ware auf einer Dark-Web-Liste – und der nächste Käufer bleibt vielleicht nicht bei der Validierung.

IP-Sperren wurden zum Wackelkontakt

Die erste Welle kam aus dem IPv6-Bereich 2a0a:d683::/32, angekündigt von LSHIY LLC (AS32167). Der Angreifer nutzte LSHIYs Bring-your-own-IP-Angebot (BYOIP) — ein legitimes Peering, mit dem Kunden Traffic über eigene Bereiche routen. Nach Meldungen sperrte LSHIY diesen Nutzer Anfang Juli.

Das Spray hörte nicht auf. Die Aktivität wechselte zu IPv6-Bereichen bei FranTech, dann zu 3xK Tech über IPv4, rotierte durch Tausende Adressen und hielt das Volumen pro IP niedrig. Huntress sah später wieder etwa 1,5 Millionen Versuche pro Tag. IPv6 liefert einen riesigen Adressraum. Anbieterwechsel liefert einen neuen, sobald einer geschlossen wird.

Verteidiger, die auf die Sperre des aktuellen ASN warten, bleiben immer einen Schritt hinterher. Die dauerhafte Kontrolle macht ein Passwort unzureichend – sie pflegt keine Denylist von gestriger Infrastruktur.

Was Organisationen ändern sollten

Conditional Access fein einzustellen, ohne echte Nutzer auszusperren, ist schwer. Genau das hält den Angriff am Leben. Huntress’ Leitfaden bleibt der kürzeste Weg hinaus:

• MFA verlangen — oder die Anmeldung blockieren — für alle Nutzer, alle Cloud-Apps und alle Client-App-Typen, ohne stille Ausnahmen.
• Eine starke Client-Einstellung wie userStrongAuthClientAuthNRequired nutzen, damit ROPC selbst bei korrektem Passwort scheitert.
• ROPC und andere Legacy-Grants deaktivieren, die MFA nicht erfüllen können. Microsoft rät Entwicklern bereits zur Migration.
• Azure CLI auf Personen beschränken, die sie wirklich brauchen. Die meisten Mitarbeitenden tun das nicht.
• Reaktion nach Gültigkeit der Zugangsdaten priorisieren, nicht nach Spray-Volumen. Die lautesten Mandanten sind oft am wenigsten kompromittiert.
• Passworthygiene als unvollendete MFA behandeln: einzigartige Geheimnisse, Rotation nach jedem Leak und Passkeys oder andere passwortlose Optionen für hochwertige Konten.
• Die Regeln aufschreiben. Unser Leitfaden für sichere Passwörter 2026 hilft, aus „wir haben MFA“ einen durchsetzbaren Standard für Wiederverwendung, Rotation und Fallbacks zu machen.

Was Einzelne tun sollten

Sie brauchen keinen Entra-Mandanten, um in diesem Radius zu liegen. Dieselben Combo-Listen, die Azure-CLI-Sprays speisten, werden täglich gegen private E-Mail-, Shopping- und Social-Konten getestet. Spraying und Stuffing leben von Wiederverwendung.

• Für jedes Konto ein eigenes Passwort nutzen. Erzeugen Sie eines mit unserem Passwort-Generator und speichern Sie es im Manager.
• Führen Sie einen Leak-Test für alles aus, das Sie wiederverwendet haben. Die LSHIY-Passwörter waren alt; sie funktionierten, weil niemand sie rotiert hatte.
• MFA überall aktivieren, dann Passkeys oder Sicherheitsschlüssel für E-Mail, Passwortmanager, Banking und Arbeit bevorzugen. Klassische MFA hilft weiter gegen Stuffing — aber wie unser AitM-Artikel zeigt, sind SMS und TOTP nicht das Ende der Geschichte.
• Wenn Sie Azure CLI oder einen anderen Legacy-Client nutzen, fragen Sie die IT, ob ROPC für Ihr Konto noch erlaubt ist. Ein Passwort, das Sie nie im Browser tippen, kann ein Werkzeug trotzdem wiederholen.