Passwort-Spraying erkennen – Konten gegen Massenlogins härten

Ein typisches Muster aus der Praxis: Der Helpdesk erhält mehrere Meldungen zu „ungewöhnlichen Anmeldeversuchen“, einzelne Nutzer:innen werden kurzfristig gesperrt, und im Hintergrund laufen hunderte fehlgeschlagene Logins über viele Konten verteilt. Häufig steckt dahinter kein gezielter Angriff auf eine Person, sondern Passwort-Spraying – eine Methode, bei der wenige verbreitete Passwörter gegen viele Benutzerkonten getestet werden. Der Trick: Durch geringe Versuchsrate pro Konto werden klassische Kontosperren umgangen, während die Erfolgswahrscheinlichkeit über die Menge steigt.

Was Passwort-Spraying von Brute Force unterscheidet

Warum „langsam und breit“ so effektiv ist

Bei klassischem Brute Force wird ein einzelnes Konto mit vielen Passwortversuchen bearbeitet, bis es gesperrt wird oder ein Treffer gelingt. Beim Spraying wird dagegen pro Konto nur selten getestet (z. B. ein Versuch pro Stunde oder pro Tag), dafür über sehr viele Konten. Das reduziert Alarmierung und vermeidet Lockout-Schwellen.

In Unternehmensumgebungen ist Spraying besonders attraktiv, weil Benutzernamen oft erratbar sind (vorname.nachname, Initialen, E-Mail-Adressen) und weil selbst gute Passwortregeln gelegentlich durch Altlasten, Servicekonten oder externe Identitäten unterlaufen werden.

Häufige Ziele und Einfallstore

• Cloud-Logins (z. B. Entra ID / Microsoft 365, Google Workspace, VPN-Portale)
• Web-Anwendungen mit Formular-Login (SSO, Portale, Ticketsysteme)
• Remote-Zugänge (VPN, SSH-Gateways, VDI) – meist dann, wenn Identitäten zentral sind

Wichtig: Spraying ist nicht „nur“ ein Passwortproblem. Es ist ein Identitäts- und Telemetrieproblem: Ohne saubere Signale in Logs und klare Reaktionspfade bleiben Angriffe lange unbemerkt.

Typische Indikatoren: So sieht Passwort-Spraying in der Realität aus

Muster in Anmeldeprotokollen

Mehrwert entsteht hier durch Mustererkennung, nicht durch Einzelereignisse. Typische Hinweise:

• Viele fehlgeschlagene Logins über einen Zeitraum, verteilt über viele Konten
• Gleiche oder ähnliche User-Agent-Strings, identische Parameter, ähnliche Zeitabstände
• Wiederkehrende Quellnetze/ASN oder auffällige Geolokationen im Vergleich zum Normalbetrieb
• Fehlschläge gefolgt von wenigen Erfolgen (ein Treffer reicht)

Besonders verdächtig ist die Kombination aus „viele Nutzer, wenig Versuche je Nutzer“ und „gleiches Quellmuster“. In Webserver- oder WAF-Logs zeigt sich das oft als identische POST-Requests auf /login, /auth, /session oder SSO-Endpunkte.

Kontosperren sind kein verlässliches Signal

Wer sich ausschließlich auf Lockouts verlässt, sieht Spraying oft zu spät. Angreifer passen die Frequenz an Policies an oder zielen auf Konten ohne Sperrmechanik (z. B. manche Legacy-Protokolle oder Fehlkonfigurationen). Deshalb sollte Erkennung immer auch ohne Lockout funktionieren: über Rate, Verteilung, Herkunft und Anomalien.

Warum Sperrregeln allein nicht reichen

Lockout-Policies können umgangen und missbraucht werden

Eine aggressive Sperrregel kann Spraying eindämmen, erzeugt aber neue Risiken: Denial-of-Service durch absichtliche Lockouts (gezielte Sperre wichtiger Konten) und hohe Helpdesk-Last. Zusätzlich können Lockouts bei Single-Sign-On Kaskaden auslösen, wenn viele Dienste daran hängen.

Der entscheidende Hebel: Zugriffskontrollen am Identitätsrand

Effektiver sind Kontrollen, die vor dem Passworttreffer greifen: risikobasierte Anmeldebedingungen, Blocken verdächtiger Quellen, starke Authentifizierung und saubere Protokollhygiene. In Microsoft-Umgebungen ist hier Conditional Access (kontextbasierte Zugriffskontrolle) ein zentraler Baustein, weil damit Regeln nach Gerät, Standort, Risiko, App und Authentifizierungstyp erzwingbar sind.

Konkrete Schutzmaßnahmen für Unternehmen und Teams

Passwortqualität real erhöhen statt nur „Komplexität“ fordern

Spraying gewinnt, wenn viele Nutzer dieselben Muster verwenden. In der Praxis hilft:

• Passphrasen statt kurzer komplexer Passwörter (länger, leichter merkbar)
• Verbot stark verbreiteter Passwörter (Blocklisten/Password-Filter)
• Keine Wiederverwendung zwischen Diensten; ein zentraler Passwortmanager reduziert Druck auf Nutzer:innen

Passwortpolitik sollte messbar sein: Wie viele Konten nutzen schwache oder wiederverwendete Passwörter? Ohne Transparenz werden Regeln zum Papiertiger. Passend dazu kann der Betrieb eines sicheren Passwortmanagers die Wiederverwendung deutlich senken.

MFA richtig einsetzen: Schutz ja, aber ohne Umgehungspfade

MFA (Mehrfaktor-Authentifizierung) stoppt viele Kontoübernahmen, aber nur, wenn sie konsequent durchgesetzt wird und nicht über Ausnahmen ausgehebelt wird. Praxisnahe Punkte:

• MFA für alle interaktiven Logins erzwingen, nicht nur für Admins
• Legacy-Authentifizierung und alte Protokolle abschalten, sofern möglich
• Starke Faktoren bevorzugen (z. B. FIDO2/Passkeys), schwächere Verfahren nur als Übergang
• „Break-Glass“-Konten separat absichern (starkes Passwort, restriktive Bedingungen, Monitoring)

Zur sauberen Einführung und für typische Fehlerbilder hilft eine klare MFA-Betriebspraxis, wie sie in MFA sicher nutzen – Schutz vor Kontoübernahmen beschrieben ist.

Rate-Limits und Schutzschichten vor dem Login-Endpunkt

Für Web- und Portal-Logins sind technische Bremsen wirksam, die nicht an einzelne Konten gebunden sind:

• IP- und ASN-basierte Rate-Limits auf Login-Endpunkten
• Progressive Delays (Verzögerung) nach Fehlschlägen je Quelle
• WAF/Reverse-Proxy-Regeln, die automatisierte Muster erkennen (Header/UA/Parameter)
• CAPTCHA nur gezielt einsetzen (nicht pauschal), um Usability nicht zu zerstören

Wichtig ist, diese Mechanismen zu testen: Zu strenge Limits treffen auch legitime Nutzer:innen (z. B. Carrier-NAT, Firmenproxies) und können Supportaufkommen erhöhen.

Admin- und Servicekonten isolieren und hart absichern

Spraying zielt gern auf privilegierte Konten oder Konten mit breiter Reichweite (Mailbox-Zugriff, Dateiablage, externe Freigaben). Maßnahmen:

• Administrationskonten getrennt von Nutzerkonten (kein Alltagslogin mit Adminrechten)
• Servicekonten minimieren, dokumentieren und Berechtigungen eng halten
• Wo möglich: keine Passwörter für Services, sondern Zertifikate/Managed Identities

Erkennung in der Praxis: Logs, Korrelation, Alarmierung

Welche Signale wirklich helfen

Eine robuste Erkennung korreliert mehrere Achsen:

• Zeitfenster: viele Fehlschläge in 10/30/60 Minuten
• Breite: Anzahl unterschiedlicher Benutzerkonten pro Quelle
• Herkunft: neue Länder/Netze/Datacenter-IP-Ranges
• Erfolg: ein erfolgreicher Login nach Serienfehlern ist ein Hochrisikoindikator

In Microsoft-Umgebungen kann zusätzlich das Zusammenspiel aus Anmeldeprotokollen und Risikoeinstufungen genutzt werden. In heterogenen Umgebungen lohnt sich zentrale Logsammlung und Korrelation (SIEM), um Muster über Dienste hinweg zu sehen; dazu passt SIEM im Mittelstand – Logs zentral auswerten.

Beispiel für eine sinnvolle Alarmregel (konzeptionell)

Eine praxistaugliche Regel ist meist besser als zehn perfekte, die niemand pflegt. Ein Beispielansatz:

• Wenn eine Quell-IP innerhalb von 30 Minuten bei > 20 unterschiedlichen Benutzern fehlschlägt, Alarm mit Priorität „hoch“
• Wenn innerhalb desselben Zeitfensters mindestens ein Login erfolgreich ist, Priorität „kritisch“ und automatische Containment-Aktion (z. B. Session-Revoke, Passwort-Reset-Workflow, Token invalidieren)
• Wenn die Quelle aus bekannten Hosting-/Datacenter-Netzen stammt, Schwellenwerte reduzieren

Wichtig ist die saubere Ausnahmebehandlung: Firmenproxies, SSO-Gateways oder Passwortmanager können Logins bündeln. Solche Quellen gehören in eine kontrollierte Allowlist mit zusätzlichem Monitoring.

Wenn ein Treffer gelingt: Response ohne Panik, aber zügig

Erste Maßnahmen bei Verdacht auf kompromittierte Identität

Ein erfolgreicher Spraying-Treffer ist oft nur der Einstieg in weitere Schritte (Postfachzugriff, Token-Diebstahl, Weiterleitungsregeln, Zugriff auf Teams/SharePoint, laterale Bewegung). Sinnvolle Sofortaktionen:

• Betroffenes Konto sperren oder Anmeldungen temporär blockieren
• Aktive Sessions/Tokens widerrufen, wo möglich
• Passwort zurücksetzen und erneute Registrierung von MFA/Authentikatoren prüfen
• Postfachregeln, delegierte Zugriffe und App-Zugriffe (Consent) kontrollieren
• Weitere Konten prüfen, die von derselben Quelle angegriffen wurden

Für strukturierte Abläufe hilft ein kompaktes Vorgehensmodell wie in Sicherheitsvorfall-Runbook – in 60 Minuten handlungsfähig, damit Sperren, Kommunikation und Forensik nicht durcheinanderlaufen.

Nacharbeit: Lücken schließen, sonst kommt die nächste Welle

Nach dem Incident sollte die Ursache nicht nur „schwaches Passwort“ heißen, sondern in Controls übersetzt werden:

• Wurde MFA flächendeckend erzwungen oder gab es Ausnahmen?
• Welche Login-Endpunkte hatten keine Rate-Limits?
• Gab es Konten ohne moderne Policies (Legacy/Hybrid/Alt-Apps)?
• Waren Alarme zu spät, zu laut oder zu leise?

In der Praxis reduziert eine Kombination aus starker Authentifizierung, kontextbasierten Regeln und guter Telemetrie die Angriffsfläche deutlich – und macht Spraying für Angreifer teuer, weil Treffer unwahrscheinlicher und Reaktionen schneller werden.

Kurze Umsetzungsschritte für den Alltag

• Anmeldeprotokolle zentral sammeln und mindestens nach Quelle + Anzahl betroffener Nutzer korrelieren.
• MFA für alle interaktiven Logins erzwingen und Ausnahmen dokumentieren; Legacy-Logins abschalten, wo möglich.
• Login-Endpunkte mit Rate-Limits und Verzögerungen gegen Automatisierung schützen.
• Passwort-Blocklisten und Passphrasen-Policy einführen; Wiederverwendung organisatorisch unterbinden (Passwortmanager).
• Alarme so bauen, dass „viele Nutzer je Quelle“ priorisiert wird – nicht nur Lockouts.

Häufige Stolperfallen bei der Härtung

Ausnahmen, die sich unbemerkt ausweiten

„Nur für diesen Dienst“ wird schnell zu „für zehn Dienste“. Jede Ausnahme (kein MFA, keine Conditional-Regel, keine Rate-Limits) sollte ein Ablaufdatum, einen Owner und Monitoring bekommen. Sonst wächst eine Schattenlandschaft, in der Spraying wieder Erfolg hat.

Zu viel Blocken ohne Betriebskonzept

IP-Blocking kann wirksam sein, aber auch legitime Nutzer treffen (Reisen, Carrier-NAT, externe Partner). Besser ist ein abgestuftes Modell: erst drosseln, dann zusätzliche Authentifizierung verlangen, erst danach hart blocken – und immer mit nachvollziehbarem Audit-Trail.

Fehlende Trennung von Admin- und Benutzer-Identitäten

Wenn Admin-Konten im Alltag genutzt werden, reicht ein einziger Spraying-Treffer für massiven Schaden. Separate Admin-Identitäten, restriktive Bedingungen und enges Monitoring sind ein Basisschutz, der sich schnell auszahlt.