Password Spraying in AD und Entra ID: Erkennung

Was ist Password Spraying?

Password Spraying ist eine Brute-Force-Technik, bei der ein einzelnes Passwort oder eine sehr kleine Liste häufig genutzter Passwörter gegen viele unterschiedliche Konten getestet wird – anstatt, wie beim klassischen Vorgehen üblich, viele Passwörter nacheinander gegen ein einzelnes Konto auszuprobieren. In der MITRE-ATT&CK-Matrix wird die Technik unter der Kennung T1110.003 als Unterkategorie von Brute Force geführt.

Dieses Vorgehen ist bewusst gewählt, denn es soll gezielt die offensichtlichen Nebenwirkungen klassischer Brute-Force-Angriffe vermeiden, die üblicherweise schnell auffallen und Alarme auslösen. Statt ein einzelnes Konto durch viele wiederholte Fehlversuche zügig zu sperren, verteilt der Angreifer nur wenige Passwortkandidaten über eine Vielzahl verschiedener Identitäten und wartet geduldig ab, bis er auf die schwächste trifft.

Für diesen Artikel liegt der Fokus auf Hybrid Identity: Active Directory, Microsoft Entra ID sowie die Cloud- und Remotezugriffspfade, die weiterhin passwortbasierte Authentifizierung akzeptieren. Password Spraying ist keineswegs nur ein On-Premises-Thema. CISA und Microsoft beschreiben die Technik übereinstimmend als ein häufiges Initial-Access-Muster gegen föderierte, cloudbasierte und ins Internet exponierte Identitätsdienste.

Wie Password Spraying funktioniert

MITREs Definition ist dafür der richtige Ausgangspunkt: Angreifer verwenden ein einzelnes oder ein sehr kleines Set häufig genutzter Passwörter gegen viele verschiedene Konten, um genau jene Kontosperren zu vermeiden, die normalerweise eintreten würden, sobald ein einzelnes Konto wiederholt und in kurzer Folge bruteforced wird.

In der Praxis gehen Angreifer meist zweistufig vor: Zunächst bauen sie eine möglichst breite Zielliste auf, und erst in einem zweiten Schritt sprühen sie die schwächsten, am leichtesten zu erratenden Passwortkandidaten über diese Liste.

Typische Quellen für Zielkonten sind:

öffentlich sichtbare Benutzernamen oder E-Mail-Adressen
Namenskonventionen, abgeleitet aus LinkedIn, Unternehmenswebseiten oder kompromittierten Adressbüchern
Global Address Lists, nachdem ein erstes Cloud-Konto kompromittiert wurde
synchronisierte Hybrid-Identitäten, die sowohl in AD als auch in Microsoft Entra ID existieren

Typische Zielpfade sind:

Anmeldeendpunkte von Microsoft 365 und Entra
föderierte Authentifizierungsflüsse
VPN-Portale
Outlook Web oder andere nach außen exponierte Mail-Oberflächen
RDP oder andere veröffentlichte Remotezugriffs-Workflows
LDAP, Kerberos, SMB oder andere interne Protokolle, sobald der Angreifer bereits im Netzwerk aktiv ist

MITRE weist zusätzlich auf eine wichtige Detection-Nuance hin, die für Verteidiger relevant ist: Angreifer bevorzugen mitunter gezielt LDAP- und Kerberos-Authentifizierungsversuche, weil diese in vielen Umgebungen weniger sichtbar sein können als fehlgeschlagene SMB-Anmeldungen, die üblicherweise das Event 4625 auslösen und dadurch schneller auffallen.

Warum Password Spraying noch immer funktioniert

Password Spraying ist deshalb so wirksam, weil die Technik gleichzeitig Skalierung und Vorhersagbarkeit ausnutzt und sich nicht auf eine einzelne technische Schwachstelle verlässt.

Schwache Passwörter existieren weiterhin in großem Umfang

Die Dokumentation zu Microsoft Entra Password Protection ist hier eindeutig: Microsoft blockiert schwache Passwörter auf Basis realer Spray-Telemetrie, weil schwache Passwörter und ihre Varianten in der Praxis nach wie vor häufig genug vorkommen, um operativ relevant zu sein.

Passwort-only-Pfade bleiben exponiert

Sowohl CISAs Brute-Force-Warnungen als auch Microsofts aktuellere Berichte zu Cloud-Intrusionen verweisen übereinstimmend auf dieselbe grundlegende Schwachstelle: Solange ein Ziel weiterhin eine reine Passwort-Authentifizierung ohne zweiten Faktor exponiert, reicht bereits ein einziger erfolgreicher Anmeldeversuch aus, um Reconnaissance, Persistenz oder laterale Bewegung im Tenant oder Netzwerk zu starten.

Legacy- und föderierte Pfade vergrößern die Angriffsfläche

CISA warnt ausdrücklich davor, dass Password-Spray-Kampagnen häufig auf SSO- und Cloud-Anwendungen mit föderierter Authentifizierung abzielen. Auch Microsofts jüngere Berichte zeigen Password Spraying regelmäßig als ersten Schritt vor weiterführender Entra-Reconnaissance und Persistenzaktivität.

Low-and-slow-Vorgehen vermeidet auffällige Sperren

Bei Spraying geht es gerade nicht um Geschwindigkeit gegen ein einzelnes Konto, wie es bei einem klassischen Brute-Force-Angriff der Fall wäre. Es geht vielmehr um Zuverlässigkeit über eine große Zahl von Konten hinweg, ohne die jeweiligen Schwellenwerte pro Konto zu schnell zu überschreiten und dadurch Alarme auszulösen.

Voraussetzungen für einen erfolgreichen Password-Spraying-Angriff

Password Spraying gelingt in der Praxis in der Regel genau dann, wenn mehrere unterschiedliche Schwachstellen gleichzeitig zusammenkommen und sich gegenseitig begünstigen.

1. Der Angreifer kann gültige Benutzernamen enumerieren

Eine Spray-Kampagne fällt deutlich leichter, wenn Benutzernamen vorhersehbaren Mustern folgen oder von außen ermittelbar sind. Öffentliche E-Mail-Formate, vorhersehbare Admin-Aliase und wiederverwendete Cloud- oder On-Prem-Identitätsnamen erleichtern diesen Schritt zusätzlich.

2. Passwortbasierte Authentifizierung ist weiterhin exponiert

Wenn der Tenant oder die Umgebung wertvolle Pfade weiterhin über ein Passwort erreichbar macht, hat der Angreifer ein legitimes Ziel zum Besprühen. Dazu zählen Cloud-Sign-ins, VPN, Remote Access, Föderation sowie interne Authentifizierungsoberflächen.

3. Die Passwortbasis ist schwach genug, dass ein kleines Kandidaten-Set ausreicht

Genau das ist das Kontrollproblem, das AD-Passwortsicherheit: Fehlkonfigurationen die Angreifer Lieben behandelt. Ein Spray funktioniert, weil einzelne Benutzer weiterhin schwache, leicht erratbare oder organisationsbezogene Passwörter wählen.

4. Die MFA-Abdeckung ist unvollständig oder auf dem Zielpfad umgehbar

Selbst wenn Spraying nur ein gültiges Passwort liefert, wird das Konto deutlich weniger nützlich, sobald starke MFA oder phishing-resistente Folgekontrollen tatsächlich auf dem betroffenen Pfad durchgesetzt werden. CISA nennt fehlende MFA ausdrücklich als wiederkehrendes Merkmal kompromittierter Umgebungen.

5. Das Monitoring ist zu schwach, um das Muster zu erkennen

Ein paar Fehlversuche gegen ein einzelnes Konto lassen sich in der täglichen Alert-Flut leicht abtun oder übersehen. Das eigentliche Signal ist eine ungewöhnlich hohe Zahl von Fehlschlägen über viele Konten hinweg – aus derselben Quelle, derselben Infrastruktur-Familie oder mit einem wiederkehrenden Zeitmuster. Ohne eine solche Korrelation über mehrere Konten hinweg bleibt Password Spraying für viele Sicherheitsteams leicht zu übersehen.

Die Angriffskette

Eine typische Intrusionskette bei einem Password-Spraying-Angriff lässt sich in fünf aufeinanderfolgenden Schritten beschreiben.

Schritt 1 – Kontoliste aufbauen

Der Angreifer sammelt dazu Benutzernamen systematisch aus öffentlichen Quellen, früheren Datenlecks, Adressbüchern oder bereits kompromittierten Postfächern und konsolidiert sie zu einer möglichst vollständigen Zielliste.

Schritt 2 – Kleine Passwortliste auswählen

Die gewählten Passwörter sind meist saisonal geprägt, unternehmensbezogen oder anderweitig so generisch, dass sie die Komplexitätsregeln des Unternehmens erfüllen und trotzdem vorhersehbar bleiben.

Schritt 3 – Über viele Konten sprühen

Statt ein einzelnes Konto mit vielen aufeinanderfolgenden Versuchen zu belasten, testet der Angreifer ein kleines Passwort-Set über viele Benutzer hinweg und staffelt die einzelnen Versuche zeitlich so, dass die offensichtlichen Lockout-Schwellen jedes einzelnen Kontos nicht ausgelöst werden.

Schritt 4 – Das erste erfolgreiche Konto für Reconnaissance nutzen

Microsofts Bericht zu Peach Sandstorm zeigt das eigentliche Risiko: Schon ein einziges erfolgreich kompromittiertes Konto kann für Tenant Discovery, Persistenzversuche oder weiterführende Cloud-Reconnaissance ausreichen.

Schritt 5 – Zugriff ausweiten

Von diesem Punkt aus kann der Angreifer:

weitere Benutzernamen und Rollen sammeln
E-Mails oder die Global Address List herunterladen
als Nächstes gezielt privilegierte Benutzer angreifen
in Anwendungen, Subscriptions oder Infrastruktur vordringen, die an die kompromittierte Identität gebunden sind

Deshalb ist Password Spraying letztlich kein reines Problem fehlgeschlagener Anmeldungen, das sich mit einer einfachen Lockout-Regel erledigen ließe. Es ist vor allem ein Initial-Access-Problem, das sich in der Praxis sehr häufig zu einem ernsthaften Problem von Rechteausweitung und dauerhafter Persistenz weiterentwickelt.

Password Spraying vs. andere Brute-Force-Techniken

Diese Begriffe werden oft vermischt, bezeichnen aber unterschiedliche Vorgehensweisen.

Password Spraying = ein oder wenige Passwörter gegen viele Konten
Password Guessing = gezielte Versuche direkt gegen ein einzelnes Konto
Credential Stuffing = das Wiederverwenden bereits bekannter Benutzername-Passwort-Paare aus anderen Datenlecks
Klassischer Brute Force = sehr viele Versuche gegen eine Identität oder ein Geheimnis, bis dieses geknackt ist

Diese Unterscheidung ist in der Praxis operativ wichtig, weil sich die jeweils sinnvollen Detection- und Lockout-Strategien für jede dieser Techniken deutlich voneinander unterscheiden.

Detection

Es gibt keinen einzelnen universellen Indikator, der Password Spraying zuverlässig erkennt, weil die Technik Cloud-Pfade, föderierte Pfade und On-Premises-Pfade gleichermaßen betrifft und sich je nach Umgebung unterschiedlich äußert. Das entscheidende Modell bleibt deshalb auch hier die Korrelation einzelner, für sich genommen unauffälliger Ereignisse.

Cloud- und Entra-zentrierte Signale

Für Microsoft Entra ID sind vor allem folgende Signale relevant:

wiederholte fehlgeschlagene Anmeldungen gegen viele Benutzer von derselben IP-Adresse, demselben Infrastruktur-Cluster oder demselben User Agent
dasselbe Passwortkandidaten-Muster, das über die Zeit hinweg gegen viele Konten getestet wird
wiederholtes Smart-Lockout- oder Blocked-Sign-in-Verhalten über viele Konten aus derselben Quelle
mittleres oder hohes Sign-in-Risk zusammen mit wiederholten Passwortfehlern oder verdächtiger Infrastruktur
die Nutzung von Legacy Authentication auf ins Internet exponierten Identitätspfaden

Microsofts Dokumentation zu Smart Lockout ergänzt mehrere wichtige Fakten:

Smart Lockout ist bei Microsoft-Entra-Tenants standardmäßig immer aktiv und lässt sich nicht deaktivieren – nur Schwellenwerte und Dauer können angepasst werden, was Microsoft Entra ID P1 oder höher voraussetzt
der Standardschwellenwert liegt bei 10 Fehlversuchen für Azure-Public-Tenants und bei 3 für Azure-US-Government-Tenants
die Standard-Sperrdauer beginnt bei 60 Sekunden und steigt mit wiederholten Fehlversuchen weiter an
Smart Lockout merkt sich die letzten drei fehlerhaften Passwort-Hashes, sodass die wiederholte Eingabe desselben falschen Passworts den Zähler nicht immer weiter erhöht
diese Hash-Verfolgung steht bei Szenarien mit Pass-through Authentication nicht zur Verfügung, weil die eigentliche Authentifizierung On-Premises stattfindet

Diese Details sind wichtig, weil Verteidiger häufig überschätzen, was Lockout allein in einer Hybridumgebung tatsächlich leisten kann.

AD- und On-Premises-Signale

Für das Monitoring von On-Premises-Windows-Umgebungen sind vor allem folgende Signale relevant:

Häufungen von 4625-Fehlern aus derselben Quelle gegen viele Konten, wenn SMB oder ähnliche Pfade beteiligt sind
4771-Kerberos-Pre-Auth-Fehler über viele Benutzer hinweg innerhalb kurzer Zeit
LDAP- oder Kerberos-Fehler, die sich in ein Multi-Konten-Muster einfügen, auch wenn sie nicht wie eine klassische SMB-Brute-Force-Sequenz aussehen
dieselbe Quelle oder derselbe Relay-Pfad, der viele Identitäten in niedriger, aber wiederkehrender Kadenz berührt

MITRE weist ausdrücklich darauf hin, dass LDAP- und Kerberos-Versuche seltener die auffälligsten Windows-Fehlanmeldemuster erzeugen, auf die sich Verteidiger häufig verlassen. Genau deshalb ist AD-Sicherheitsüberwachung: Event IDs und SIEM an dieser Stelle direkt relevant.

Woran gute Korrelation zu erkennen ist

Eine belastbare Password-Spray-Detection lässt sich in der Regel so beschreiben:

eine IP-Adresse, ein ASN, ein User Agent oder ein kleines Infrastruktur-Set
viele unterschiedliche Ziel-Benutzernamen
sehr wenige Versuche pro Konto
ein wiederkehrendes Passwortkandidaten- oder Timing-Muster
ein oder zwei erfolgreiche Konten, gefolgt von Discovery- oder auf Rechteausweitung ausgerichteter Aktivität

Warum Smart Lockout und Logs allein nicht ausreichen

Smart Lockout reduziert das Risiko spürbar, aber Microsoft stellt klar, dass die Funktion nicht garantiert, dass legitime Benutzer niemals versehentlich ausgesperrt werden, und dass sie keinesfalls einen Ersatz für stärkere Authentifizierung und eine grundsätzlich bessere Passwortrichtlinie darstellt. Belastbare Detection hängt deshalb weiterhin von konsequentem Log-Review, funktionierendem Alerting und einem klaren, aktuellen Verständnis der tatsächlich exponierten Pfade ab.

Remediation

Die Abwehr von Password Spraying ist deutlich mehr als eine reine Passwort-Policy-Übung. Sie setzt sich aus stärkeren Passwörtern, weniger exponierten Passwort-only-Pfaden, wirksameren Kontrollen nach der eigentlichen Passworteingabe sowie einem besseren Schutz der hybriden Authentifizierungsgrenzen zwischen Cloud und On-Premises zusammen.

1. Starke MFA auf exponierten Identitätspfaden erzwingen

CISA und Microsoft empfehlen übereinstimmend MFA als zentrale Gegenmaßnahme gegen Password Spraying. Bei öffentlich erreichbaren Identitätssystemen – insbesondere Microsoft 365, Admin-Portalen, VPN und Remote Access – darf ein erfolgreich gesprühtes Passwort für sich genommen nicht ausreichen, um tatsächlich weiterzukommen.

Deshalb gehören auch Azure Identitätssicherheit: Warum MFA Allein Nicht Ausreicht und Azure Bedingter Zugriff: MFA-Bypass mit Gestohlenem Passwort direkt in diesen Themenkomplex. MFA muss auf den richtigen Pfaden vorhanden und korrekt durchgesetzt sein.

2. Smart Lockout in Entra korrekt einsetzen

Microsoft dokumentiert Smart Lockout als Standardschutz gegen Brute-Force- und Password-Spray-Aktivität, doch Hybrid-Teams sollten die Konfiguration bewusst abstimmen:

den Schwellenwert von Microsoft Entra niedriger halten als den der On-Prem-AD-DS
die Sperrdauer von Microsoft Entra länger halten als die der AD-DS
verstehen, dass Pass-through Authentication Teile des Smart-Lockout-Verhaltens verändert
prüfen, ob die eigene On-Premises-Kontosperrrichtlinie vor allem Verfügbarkeitsprobleme verursacht, ohne das Spray-Risiko wirklich zu senken

3. Microsoft Entra Password Protection einführen

Microsoft Entra Password Protection zählt zu den wirksamsten Anti-Spray-Kontrollen überhaupt, weil die Funktion auf realer Spray-Telemetrie basiert und bekannte schwache Passwörter samt ihren Varianten blockiert.

Wichtige Implementierungspunkte laut Microsoft-Dokumentation:

Cloud-Tenants erhalten standardmäßig die globale Liste gesperrter Passwörter
benutzerdefinierte gesperrte Passwörter lassen sich für tenant-spezifische schwache Begriffe ergänzen
On-Premises-AD-DS kann dieselbe Kontrollfamilie über Microsoft-Entra-Password-Protection-Agents nutzen
Microsoft empfiehlt, die On-Prem-Einführung zunächst im Audit-Modus zu starten, bevor auf den Enforced-Modus umgeschaltet wird

Das ist gerade in hybriden Umgebungen relevant, weil ein Angreifer On-Premises-Passwörter genauso gerne sprüht wie Cloud-Passwörter.

4. Legacy Authentication und exponierte Passwort-only-Flächen reduzieren

Legacy Authentication bleibt für Angreifer nach wie vor attraktiv, weil sie ältere, rein passwortbasierte Zugriffspfade offenhält und dabei einige der stärkeren Kontrollen moderner Anmeldeabläufe umgehen kann. Solange Legacy Authentication in der Umgebung aktiviert bleibt, überlassen Verteidiger Angreifern damit weiterhin unnötig günstige und leicht auszunutzende Angriffspfade.

Das hängt unmittelbar mit Azure Tenant-Härtung: Unsichere Defaults sowie mit Ihrer umfassenderen Conditional-Access-Prüfung zusammen.

5. Privilegierte Identitäten anders schützen als den Rest der Population

Ein erfolgreich gesprühtes Konto mit geringem Wert ist ärgerlich, aber meist begrenzt in seiner Auswirkung. Ein erfolgreich gesprühtes privilegiertes Konto dagegen ist in aller Regel bereits der eigentliche Sicherheitsvorfall. Das bedeutet konkret:

strengere MFA-Anforderungen für privilegierte Rollen
engere Sign-in-Beschränkungen für administrative Identitäten
eine aktive Überprüfung veralteter privilegierter Benutzer und Notfallkonten
ein zügiges Zurücksetzen und eine unmittelbare Untersuchung, sobald ein privilegiertes Konto Ziel eines Sprays wird oder gesperrt wird

Genau hier werden Azure Identity Protection: Reaktion auf Kompromittierte Konten und Veraltete und Überprivilegierte Konten in AD Teil derselben Mitigationsstrategie.

6. Erfolgreich gesprühte Konten als Kompromittierung behandeln, nicht nur als schwaches Passwort

Microsofts Threat-Reporting ist an dieser Stelle besonders aufschlussreich: Sobald ein einzelner Spray-Versuch erfolgreich war, pivotiert der Angreifer in der Praxis häufig sehr schnell in Richtung Reconnaissance, Persistenz und laterale Bewegung innerhalb der Umgebung. Setzen Sie deshalb nicht nur das Passwort zurück, sondern widerrufen Sie aktive Sessions, prüfen Sie MFA-Änderungen, untersuchen Sie mögliche Folgeaktivitäten und klären Sie, welche weiteren Daten oder Pfade über das kompromittierte Konto zugänglich waren.

Validierung nach der Härtung

Betrachten Sie die Password-Spraying-Remediation keinesfalls schon dann als abgeschlossen, wenn Smart Lockout aktiviert wurde oder eine neue Passwortrichtlinie intern angekündigt worden ist. Validieren Sie stattdessen die tatsächlich exponierten Pfade direkt und regelmäßig.

prüfen Sie, welche ins Internet exponierten Pfade weiterhin eine reine Passwort-Authentifizierung akzeptieren
bestätigen Sie, dass MFA auf diesen Pfaden durchgesetzt wird – besonders für Admin- und High-Value-Konten
testen Sie das tatsächliche Verhalten von Smart Lockout und vergleichen Sie es in hybriden Umgebungen mit den On-Prem-AD-Lockout-Einstellungen
prüfen Sie die Sign-in-Logs auf breite Multi-Benutzer-Fehlermuster statt nur auf einzelne Kontosperren
bestätigen Sie, dass Microsoft Entra Password Protection in der Cloud und, sofern vorgesehen, auch On-Premises aktiv ist
prüfen Sie, ob tenant-spezifische schwache Begriffe wie Firmenname, Produktname oder saisonale Muster in der benutzerdefinierten Sperrliste berücksichtigt sind

Das eigentliche Erfolgskriterium ist einfach formuliert: Eine kleine Liste häufiger Passwörter darf weder in der Cloud noch On-Premises noch einen brauchbaren Einstiegspunkt liefern.

Wie EtcSec verwandte Exposition erkennt

EtcSec benötigt an dieser Stelle kein künstliches password spraying-Taxonomie-Tag, um echten Mehrwert zu liefern. Der eigentliche Nutzen liegt in den umgebenden Kontrollen, die letztlich darüber entscheiden, ob ein Spray-Versuch erfolgreich verläuft oder folgenlos ins Leere läuft.

Die nächstliegenden zugrunde liegenden Findings sind genau jene, die eine Spray-Kampagne in der Praxis überhaupt erst praktikabel machen: eine schwache Passwortrichtlinie auf AD-Seite sowie fehlende MFA-Anforderungen auf den exponierten Entra-Anmeldepfaden. Das ist nicht dasselbe wie die Angriffstechnik selbst, aber genau diese Kontrolllücken machen aus einem breit angelegten Spray einen nutzbaren Einstiegspunkt.

Die wichtigsten verwandten Kontrollen sind:

Zusammengenommen zeigen diese Kontrollen, ob die Umgebung weiterhin eine leicht angreifbare Spray-Oberfläche bietet.

Password Spraying: Erkennung und Prävention für Active Directory und Entra ID