Password Spraying und Credential Stuffing in Logs erkennen

Password Spraying und Credential Stuffing zeigen sich beide als Haufen fehlgeschlagener Anmeldungen, doch die Form dieses Haufens unterscheidet sich, und damit auch die Gegenmaßnahme. Wenn Ihr einziger Alert "fünf Fehlversuche bei einem Konto" lautet, übersehen Sie beide Angriffe.

Drei Angriffe, drei Muster

Das OWASP Credential Stuffing Prevention Cheat Sheet grenzt sie wie folgt voneinander ab:

Laut OWASP sind die Abwehrmaßnahmen in vielen Fällen dieselben und wirken auch gegen Brute Force.

Worauf Sie in den Logs achten sollten

Die Detection-Strategie von MITRE für Password Spraying lautet: viele fehlgeschlagene Authentifizierungen mit einem Passwort oder einer kleinen Auswahl an Passwörtern über viele Benutzerkonten hinweg innerhalb eines Zeitfensters. Bei Credential Stuffing sind es mehrere Fehlversuche mit unterschiedlichen Kombinationen aus Benutzername und Passwort von einer einzelnen IP-Adresse oder Session in kurzer Zeit.

Angreifer passen sich an die naheliegenden Gegenmaßnahmen an:

• Gedrosseltes Spraying. MITRE beschreibt Tooling von APT28, das über Tage oder Wochen nur etwa vier Versuche pro Stunde und Zielkonto unternahm. Die Quad7-Aktivitäten nutzten lediglich einen einzigen Anmeldeversuch innerhalb von 24 Stunden und blieben so unter den Schwellenwerten der Brute-Force-Erkennung. Zähler pro Konto erfassen das nicht.
• Verteiltes Spraying. MITRE weist außerdem darauf hin, dass APT28 einen Kubernetes-Cluster für verteilte Sprays in großem Umfang einsetzte. Eine reine Zählung pro Quell-IP übersieht das, weil keine einzelne Adresse oft scheitert. Zählen Sie deshalb zusätzlich die unterschiedlichen Konten mit Fehlversuchen pro Zeitfenster über alle Quellen hinweg, und schlüsseln Sie dieselben Daten nach ASN und User Agent auf.
• Unauffälligere Protokolle. Angreifer können LDAP- und Kerberos-Versuche nutzen, die seltener auffällige Ereignisse wie die Windows-Event-ID 4625 ("Logon Failure") auslösen, die üblicherweise bei fehlgeschlagenen SMB-Verbindungen entsteht. Erfassen Sie neben 4625 daher auch LDAP- und Kerberos-Fehler.

Angreifer zielen meist auf Management-Dienste an gängigen Ports: SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP), LDAP (389/TCP), Kerberos (88/TCP) sowie Web-Management-Oberflächen auf 80 und 443. Ebenfalls im Visier stehen SSO, Cloud-Anwendungen mit föderierter Authentifizierung und extern erreichbare E-Mail-Dienste wie Office 365 und OWA.

Microsoft 365: Smart Lockout richtig einsetzen

Microsoft Entra Smart Lockout ist immer aktiv. Standardmäßig sperrt es ein Konto nach 10 fehlgeschlagenen Versuchen in Azure-Public-Tenants bzw. nach drei in Azure-US-Government-Tenants. Die erste Sperre dauert eine Minute und wird bei weiteren Fehlversuchen länger. Die Rate der Steigerung gibt Microsoft nicht bekannt.

• Es merkt sich die Hashes der letzten drei falschen Passwörter, sodass die Wiederholung desselben falschen Passworts den Zähler nicht erhöht. So führt der wiederholte Tippfehler eines Benutzers nicht zur Sperre. Gegen einen Spray hilft das kaum, da jedes Konto das Passwort nur einmal sieht.
• Bekannte und unbekannte Standorte haben getrennte Lockout-Zähler. Ein Angreifer von einem neuen Standort kann also gesperrt werden, während der echte Benutzer weiterarbeitet.
• Benutzerdefinierte Werte erfordern Microsoft Entra ID P1 oder höher. Melden Sie sich im Microsoft Entra admin center mindestens als Authentication Policy Administrator an und gehen Sie zu Entra ID > Authentication methods > Password protection. Dort legen Sie den Lockout threshold und die Lockout duration in Sekunden fest (Standard: 60).
• Entra blockiert standardmäßig zudem manche Anmeldungen anhand von IP-Verkehr und Verhaltenssignalen und gibt AADSTS50053 - IdsLocked zurück, unabhängig davon, ob das Passwort gültig war. Betrachten Sie Konten mit diesem Code als angegriffen, werten Sie ihn aber nicht als Beweis dafür, dass das Passwort falsch oder richtig war.

Smart Lockout garantiert nicht, dass ein legitimer Benutzer nie gesperrt wird. MITRE nennt die Kehrseite: Eine zu strenge Richtlinie kann einen Denial of Service verursachen, weil alle vom Angriff betroffenen Konten gesperrt werden.

Hybride Umgebungen

Bei Pass-through Authentication muss der Entra-Schwellenwert niedriger sein als der On-Premises-Schwellenwert von AD DS, und der AD-DS-Schwellenwert sollte mindestens zwei- bis dreimal so hoch liegen. Die Entra-Sperrdauer muss länger sein als die von AD DS. Microsofts Beispiel: ein Schwellenwert von 10 gegenüber 20 und 120 Sekunden gegenüber 60. Die Entra-Dauer wird in Sekunden angegeben, die von AD DS in Minuten, achten Sie also auf die Einheiten.

Das Hash-Tracking steht bei Pass-through Authentication nicht zur Verfügung. Um Ihre AD-DS-Werte auszulesen, öffnen Sie die Gruppenrichtlinienverwaltung, bearbeiten die Richtlinie mit Ihren Sperreinstellungen und navigieren zu Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.

Ihre eigene Login-Seite und exponierte Dienste

Lockout ist eine Kontrolle pro Konto. Unsere Einschätzung: Ein Stuffing-Lauf, der jedes Konto nur ein- oder zweimal probiert, erreicht den Schwellenwert oft nie. Verlassen Sie sich daher nicht darauf als Hauptverteidigung. MITRE warnt, dass Stuffing zahlreiche Fehlversuche und Sperren auslösen kann, was aber von Ihrer Richtlinie abhängt. Die Mitigations für beide Techniken ergänzen:

• Multi-Faktor-Authentifizierung, wo möglich auf extern erreichbaren Diensten aktiviert.
• Conditional-Access-Richtlinien, die Anmeldungen von nicht konformen Geräten oder von außerhalb definierter IP-Bereiche der Organisation blockieren.
• Das Blockieren riskanter Anfragen, etwa von Anonymisierungsdiensten oder Proxys.
• Passwortrichtlinien auf Basis der NIST-Empfehlungen.
• Bei Stuffing: das proaktive Zurücksetzen von Konten, die bekanntermaßen in kompromittierten Zugangsdaten auftauchen, entweder sofort oder nachdem Sie Brute-Force-Versuche erkannt haben.

Für eine eigene Anwendung enthält das OWASP Authentication Cheat Sheet Abschnitte zum Schutz vor automatisierten Angriffen, zu CAPTCHA sowie zu Logging und Monitoring.

Wo Sie anfangen sollten

1. Listen Sie jeden aus dem Internet erreichbaren Login auf: Microsoft 365 oder OWA, VPN, RDP, SSH, SSO und Ihre eigenen Web-Formulare. Schließen Sie jeden Management-Port, der nicht offen sein muss.
2. Prüfen Sie Schwellenwert und Dauer von Smart Lockout unter Entra ID > Authentication methods > Password protection. Bei Pass-through Authentication vergleichen Sie sie anhand der oben genannten Regeln mit Ihrer AD-DS-Sperrrichtlinie.
3. Erstellen Sie zwei Abfragen über Ihre Sign-in-Logs. Die erste zählt die unterschiedlichen Konten mit fehlgeschlagenen Anmeldungen pro Quell-IP und Stunde. Die zweite ignoriert die Quelle: Sie zählt die unterschiedlichen scheiternden Konten pro Zeitfenster insgesamt und gliedert sie dann nach ASN und User Agent auf. Richten Sie für beide einen Alert ein und führen Sie AADSTS50053 als separate Ansicht.
4. Aktivieren Sie MFA für jeden extern erreichbaren Dienst und ergänzen Sie dann Conditional-Access-Regeln für nicht verwaltete Geräte und Anonymisierungsdienste.
5. Gleichen Sie Mitarbeiterkonten mit bekannten Datenlecks ab, zum Beispiel mit unserem Check auf kompromittierte Passwörter, und setzen Sie Treffer zurück. Falls Ihnen die Kapazitäten fehlen, die Logs täglich zu überwachen, schließt unser Managed Monitoring diese Lücke.