Ein Kontoeinbruch scheitert selten an fehlender Automatisierung. Häufig reicht eine kleine Liste gebräuchlicher Passwörter, die gegen viele Benutzerkonten getestet wird, und genau hier setzt das sogenannte password spraying an. Für Sicherheitsverantwortliche ist das relevant, weil diese Methode Lockouts umgeht, schwache Passwörter ausnutzt und sich oft in normalen Anmeldefehlern versteckt. In diesem Artikel ordne ich die Technik ein, zeige typische Erkennungsmerkmale und gehe die Schutzmaßnahmen durch, die in der Praxis wirklich etwas bringen.
Die wichtigsten Punkte auf einen Blick
- Beim Spraying werden wenige gängige Passwörter gegen viele Konten getestet, nicht umgekehrt.
- Die Methode ist so wirksam, weil sie Lockout-Mechanismen umgeht und auf Passwort-Wiederverwendung setzt.
- Ein Angriff wird oft erst sichtbar, wenn man Anmeldefehler über mehrere Identitäten und Zeitfenster hinweg korreliert.
- Den größten Effekt liefern starke MFA, Passkeys, Passwortmanager, Rate-Limits und saubere Alarmregeln.
- Im Ernstfall reicht ein Passwortwechsel allein nicht aus, weil aktive Sitzungen und Tokens mit betrachtet werden müssen.
Wie ein Angriff über viele Konten funktioniert
Ich sehe diese Technik am ehesten als ein Identitätsproblem, nicht als ein reines Passwortproblem. Der Angreifer nimmt eine Liste gültiger Benutzernamen, ergänzt sie um ein paar sehr häufige Kennwörter und probiert diese Kombinationen kontrolliert gegen viele Konten aus. Der Trick liegt in der Disziplin: Statt ein einzelnes Konto mit tausenden Versuchen zu belasten, bleibt jede Zielidentität unter dem Radar und das Lockout greift oft nicht sofort.
In der Praxis kommen solche Versuche häufig über Anmeldeseiten von Cloud-Diensten, VPNs, Mailportalen oder zentralen Identitätsanbietern. Die Benutzerliste stammt meist aus Datenlecks, aus öffentlich erreichbaren Verzeichnissen oder aus einfachen Namensmustern. Der Angriff ist deshalb erfolgreich, weil er breit ansetzt und sich an schwache, wiederverwendete Passwörter anpasst.
Wichtig ist die zeitliche Steuerung: Die Versuche werden oft so verteilt, dass sie wie normales Fehlverhalten aussehen. Manche Kampagnen laufen über Stunden oder Tage, andere verteilen sich auf mehrere Quell-IP-Adressen. Genau diese gedrosselte, massenhafte Logik macht die Methode so unangenehm für klassische Erkennungsregeln. Der nächste Schritt ist deshalb die Abgrenzung zu ähnlichen Angriffsmustern.
Worin sich der Angriff von klassischem Brute Force und Credential Stuffing unterscheidet
Wer die Unterschiede kennt, trifft bessere Entscheidungen bei Detection und Hardening. Ich trenne diese drei Muster in Audits immer sofort, weil dieselbe Gegenmaßnahme nicht gegen alle Varianten gleich gut wirkt.
| Methode | Angriffslogik | Voraussetzung | Typisches Risiko |
|---|---|---|---|
| Spraying-Angriff | Wenige häufige Passwörter werden gegen viele Konten getestet. | Gültige Benutzernamen und schwache Passwortwahl. | Lockouts werden umgangen, schwache Konten fallen schnell. |
| Klassischer Brute Force | Viele Passwörter werden gegen ein Konto ausprobiert. | Hohe Fehlertoleranz oder Offline-Zugriff. | Wird schneller gesperrt und fällt oft deutlicher auf. |
| Credential Stuffing | Bereits geleakte Zugangsdaten werden als Paare wiederverwendet. | Vorheriger Datenabfluss bei einem anderen Dienst. | Besonders gefährlich bei Passwort-Wiederverwendung. |
Für die Verteidigung bedeutet das: Ich muss nicht nur auf die Zahl der Fehlversuche pro Konto schauen, sondern auf das Muster über mehrere Identitäten. So landet man schnell bei der eigentlichen Frage, warum diese Methode überhaupt so häufig funktioniert.
Warum diese Methode in echten Umgebungen so oft klappt
Die kurze Antwort lautet: weil Menschen Passwörter teilen, wiederverwenden oder zu nah an dem wählen, was sich leicht merken lässt. Der längere Grund ist technischer. Moderne Arbeitsumgebungen haben viele externe Eintrittspunkte, SSO, hybride Identitäten und Konten, die nicht gleich streng behandelt werden. Wenn dann noch ein Dienst ohne starke zweite Authentisierungsstufe läuft, wird aus einem kleinen Fehler ein echter Einbruch.
Ich sehe dabei immer wieder dieselben Verstärker:
- Wiederverwendete Kennwörter, die aus anderen Leaks schon bekannt sind.
- Standard- und Musterpasswörter, die in Unternehmen trotz Richtlinien auftauchen.
- Schwache Sonderkonten wie Service-, Admin- oder Übergangskonten.
- Zu wenig Telemetrie, sodass verteilte Fehlversuche nicht zusammengeführt werden.
- Legacy-Authentisierung, bei der MFA nicht überall durchgesetzt werden kann.
Ein weiterer Punkt wird oft unterschätzt: Nicht jeder Schutzmechanismus hilft dem Benutzer und dem Angreifer gleichermaßen. Eine harte Sperre kann legitime Nutzer frustrieren, eine zu weiche Sperre lädt zum Ausprobieren ein. Deshalb ist ein gutes Gleichgewicht aus Sperrlogik, Risikobewertung und zusätzlicher Absicherung entscheidend. Genau an dieser Stelle wird die Erkennung interessant.
Woran ich einen Angriff in Logs und Identitätsdaten erkenne
Ein einzelner Fehlversuch sagt wenig. Das Muster über mehrere Konten sagt viel. In der Analyse schaue ich deshalb zuerst auf Korrelation: Tauchen innerhalb eines kurzen Zeitraums Fehlanmeldungen bei vielen Benutzern auf, oft mit demselben Passwortmuster oder aus derselben Infrastruktur, ist das verdächtig. Noch stärker wird das Signal, wenn dieselben Quellen auch gegen Mail, VPN oder andere externe Anmeldestellen arbeiten.
Typische Warnzeichen sind:
- viele fehlgeschlagene Logins für verschiedene Konten statt für ein einzelnes Konto;
- ein wiederkehrendes Passwortmuster oder sehr ähnliche Varianten;
- Quell-IP-Adressen, die auf verteilte Infrastruktur oder wechselnde Netze hindeuten;
- Anmeldefehler zu ungewöhnlichen Uhrzeiten oder in kurzen Wellen;
- erfolgreiche Anmeldungen, denen plötzlich ein normaler Zugriff auf sensible Bereiche folgt.
Für die Praxis ist wichtig, dass die Logs sauber genug sind. Ich brauche nicht nur den einzelnen Fehlversuch, sondern auch Benutzername, Zeitstempel, Quelle, Dienst, Ergebnis und wenn möglich das Umfeld wie Gerät, Standort und Risikobewertung. Die Erkennung wird erst dann brauchbar, wenn man Authentifizierungsfehler als Beziehung zwischen Konten, nicht als isolierte Ereignisse behandelt. Auf dieser Analyse bauen die Schutzmaßnahmen auf.
Wie man Konten wirksam absichert
Wenn ich Verteidigung priorisiere, starte ich nicht bei exotischen Sonderfällen, sondern bei den Maßnahmen mit dem größten Verhältnis aus Aufwand und Wirkung. Passwortregeln, MFA und saubere Sperrmechanismen sind keine Konkurrenz, sondern ein Paket. Die gute Nachricht: Vieles davon lässt sich ohne tiefen Umbau einführen, wenn die Reihenfolge stimmt.
| Maßnahme | Was sie bringt | Wo ihre Grenze liegt |
|---|---|---|
| Passwortmanager | Ermöglicht lange, einzigartige Passwörter pro Dienst. | Hilft nicht gegen bereits gestohlene Sitzungen. |
| Phishing-resistente MFA oder Passkeys | Macht reines Passwort-Raten weitgehend wirkungslos. | Rollout, Registrierung und Recovery müssen sauber geplant werden. |
| Smart Lockout und Rate-Limits | Bremst automatisierte Versuche und trennt legitime Nutzer von Angreifern besser. | Verteilte Angriffe bleiben möglich und brauchen zusätzliche Korrelation. |
| Gesperrte schwache Passwörter | Blockiert triviale und häufig kompromittierte Kennwörter schon bei der Vergabe. | Ersetzt keine zweite Authentisierungsstufe. |
| Bedingter Zugriff | Erhöht die Hürde bei riskanten Standorten, Geräten oder Anmeldewegen. | Wirkt nur gut mit sauberen Signalen und klaren Policies. |
Besonders wichtig finde ich heute Passkeys und andere phishing-resistente Verfahren. Sie ersetzen das geteilte Geheimnis durch kryptographische Nachweise und reduzieren damit genau die Angriffsfläche, die ein Spraying-Angriff ausnutzt. Für viele Organisationen ist das der sauberste Weg, weil man sich nicht mehr darauf verlassen muss, dass Nutzer ein wirklich starkes und einzigartiges Passwort im Alltag fehlerfrei verwalten. Der nächste Schritt ist aber die Frage, was man tut, wenn ein Angriff bereits erfolgreich war.
Was im Ernstfall zuerst passieren sollte
Wenn ich auf einen bestätigten Vorfall schaue, ist die wichtigste Regel: Nicht nur das Passwort ändern und hoffen, dass es damit erledigt ist. Aktive Sitzungen, Refresh-Tokens und andere bestehende Zugriffe können weiterleben, obwohl das Passwort schon neu gesetzt wurde. Deshalb muss die Reaktion immer breiter ansetzen als die bloße Kontosperre.
- Ich identifiziere zuerst die betroffenen Konten und die kritischen Konten mit erhöhter Berechtigung.
- Danach entziehe ich aktive Sitzungen, Tokens und verbundene Anmeldungen, soweit das System das unterstützt.
- Anschließend setze ich Passwörter zurück und prüfe, ob neue Anmeldefaktoren unbemerkt hinzugefügt wurden.
- Ich sichere die Logs, damit der Zeitraum des Zugriffs, die Quelle und das Ausmaß sauber rekonstruiert werden können.
- Zum Schluss prüfe ich, ob Dienstkonten, Admin-Zugänge oder API-Keys betroffen sein könnten.
Bei Konten mit hoher Reichweite, etwa E-Mail, Identitätsverwaltung oder Cloud-Adminrechten, behandle ich den Fall immer als potenziell weiterreichend. Dort geht es nicht nur um Zugang, sondern um Vertrauen in die gesamte Umgebung. Sobald ein Angreifer dort ankommt, muss die Gegenmaßnahme schnell, dokumentiert und vollständig sein. Mit einer klaren Priorisierung lässt sich das Risiko anschließend dauerhaft deutlich senken.
Welche Maßnahmen ich 2026 zuerst priorisieren würde
Wenn ich ein begrenztes Budget oder nur ein kleines Projektfenster habe, setze ich die Reihenfolge bewusst hart. Nicht alles bringt denselben Nutzen, und genau das sollte man ehrlich sagen. Die höchste Priorität haben aus meiner Sicht Konten, die Zugriff auf Identität, Mail, VPN und Administration haben, denn dort endet ein Fehlzugang selten bei einem einzelnen Nutzer.
- Phishing-resistente MFA für Administratoren, Remote-Zugänge und alle Konten mit kritischem Zugriff.
- Passkeys und Passwortmanager, damit einzigartige Passwörter überhaupt praktikabel werden.
- Saubere Detection über viele Konten statt nur über einzelne Fehlversuche.
- Schwache und wiederverwendete Passwörter blockieren, statt sie nur zu messen.
- Service- und Legacy-Konten härten, weil sie oft die ruhigsten, aber riskantesten Ziele sind.
Wenn ich das auf einen Satz verdichten müsste: Nicht der einzelne Login ist das Problem, sondern die Summe aus schwachen Kennwörtern, zu großzügigen Zugriffswegen und zu wenig Korrelation. Wer diese drei Punkte konsequent angeht, nimmt dem Angriff seine Wirkung, ohne den Betrieb unnötig zu belasten.
