Fehlgeschlagene Anmeldungen Burst-Erkennung Entra ID: Warum Identity Protection ihn nicht erkennt

Fehlgeschlagene Anmeldungen Burst-Erkennung Entra ID: Was das ist

Die Abdeckung für die Burst-Erkennung fehlgeschlagener Anmeldungen in Entra ID ist von Haus aus dünn: Microsoft Entra ID Identity Protection liefert keine native Risikoerkennung, die einen Burst fehlgeschlagener Anmeldungen gegen ein einzelnes Konto erfassen soll — obwohl das Rohsignal dafür, Dutzende ungültiger Passwortversuche gegen ein Konto in einem kurzen Zeitfenster, direkt in Ihren Sign-in-Logs liegt. Dieser Artikel erklärt, warum Identity Protections eigene Erkennungen bei einer reinen Fehlversuchsserie nicht auslösen, und wie sich die Lücke mit einer KQL-Abfrage, Smart-Lockout-Tuning und einem Alert schließen lässt, der vor dem zehnten Versuch alarmiert — nicht erst nach dem ersten erfolgreichen.

Ein falsches Passwort gegen Entra ID landet in SigninLogs als Fehlercode AADSTS50126, und Microsofts eigene Referenz zu diesem Code macht unmissverständlich klar, warum ein einzelnes Auftreten nichts bedeutet: InvalidUserNameOrPassword — Fehler bei der Anmeldedatenprüfung wegen ungültigem Benutzernamen oder Passwort; der Nutzer hat nicht die richtigen Anmeldedaten eingegeben, und man muss mit einer gewissen Anzahl solcher Fehler in den Logs rechnen, weil sich Nutzer schlicht vertippen. Das ist nicht der einzige von Microsoft dokumentierte Anmeldedaten-Fehlercode — AADSTS50056 steht für ein ungültiges oder leeres Passwort, das für diesen Nutzer im Verzeichnis gar nicht existiert — und eine Erkennung, die nur einen der beiden im Blick hat, sieht nur einen Teil des Bursts. Ein Tippfehler ist Rauschen. Zwanzig davon gegen dasselbe Konto in fünf Minuten, oder dasselbe Passwort gegen fünfzig Konten in fünf Minuten geraten, sind es nicht — das ist im ersten Fall gezielte Brute-Force und im zweiten Password Spraying, und beide Muster erzeugen dasselbe Rohsignal: einen Burst von 50126.

Diese Unterscheidung ist wichtig dafür, worauf dieser Artikel verlinkt. Wer das Angreifer-Playbook sucht — Target-Enumeration, gängige Passwortlisten, warum Spraying kontobezogene Lockouts umgeht —, findet es unter Password Spraying: Erkennung und Prävention für Active Directory und Entra ID. Dieser Artikel ist die andere Hälfte: das Raw-Telemetry-Detection-Engineering, das existieren muss, weil Identity Protections eigene Risk Engine genau dieses Signal unmarkiert lässt.

Warum Identity Protection das nicht erkennt

Microsoft dokumentiert jede Sign-in- und Nutzerrisiko-Erkennung, die Identity Protection liefert, und keine davon heißt „wiederholte fehlgeschlagene Anmeldungen gegen ein Konto". Die nächstliegenden Kandidaten verfehlen dieses Signal alle aus einem konkreten, dokumentierten Grund:

Das praktische Ergebnis: Ein gezielter Brute-Force-Lauf oder eine erfolglose Spray-Welle kann komplett innerhalb von SigninLogs ablaufen — sichtbar, mit Zeitstempel, einer IP und einer Kontogruppe zuordenbar — ohne jemals RiskState, RiskLevelAggregated oder auch nur eine Zeile im Risky-Users-Report zu berühren. Endet Ihr Monitoring beim Identity-Protection-Dashboard, bleibt dieses Muster unsichtbar, bis es erfolgreich ist.

Erkennung: Die Abfrage selbst bauen

Da für dieses Muster kein riskEventType existiert, muss die Erkennung direkt gegen SigninLogs gebaut werden, die Log-Analytics-Tabelle, in die Entra-ID-Sign-in-Ereignisse fließen, sobald der Diagnose-Export aktiviert ist. Die relevanten Spalten:

Bevor Sie einen Schwellenwert festlegen, verschaffen Sie sich eine Baseline für Ihren eigenen Tenant. Microsofts veröffentlichte Beispielabfragen für SigninLogs enthalten dafür einen Ausgangspunkt — „Failed Signin reasons" —, hier angepasst, um die relevanten Anmeldedaten-Fehlercodes zu trennen:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50126", "50056", "50053")
| summarize Count = count() by ResultType, ResultDescription
| order by Count desc

Führen Sie das zuerst aus. Liegt gewöhnliches, tippfehlerbedingtes 50126-Rauschen bereits im Hunderterbereich pro Tag, alarmiert ein Burst-Schwellenwert im einstelligen Bereich bei gar nichts. Mit einer Baseline in der Hand decken zwei Abfragen die beiden Spielarten derselben Katalog-Lücke ab — gezielte Brute-Force gegen eine Identität und langsames, breites Spraying über viele:

Burst gegen ein einzelnes Konto:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            SourceIPs = dcount(IPAddress),
            LastFailure = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 15m)
| where FailureCount >= 10
| order by FailureCount desc

Burst über viele Konten aus einer Quelle:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            TargetedAccounts = dcount(UserPrincipalName),
            Accounts = make_set(UserPrincipalName, 20)
    by IPAddress, bin(TimeGenerated, 15m)
| where FailureCount >= 10 or TargetedAccounts >= 5
| order by FailureCount desc

Beide Abfragen verwenden ausschließlich dokumentierte SigninLogs-Spalten; die Schwellenwerte 10 und 5 sind illustrative Ausgangspunkte, keine Microsoft-Vorgaben — bemessen Sie sie an der Baseline-Abfrage oben und ziehen Sie sie an, sobald False Positives sinken. Verdrahten Sie eine der beiden Abfragen mit einer geplanten Microsoft-Sentinel-Analyseregel (oder einem einfachen Azure-Monitor-Log-Alert, falls Sie kein Sentinel betreiben), damit ein Burst einen Incident auslöst, statt bei der nächsten manuellen Log-Durchsicht zufällig gefunden zu werden.

Remediation

1. Smart Lockout verschärfen, statt sich auf die Standardwerte zu verlassen

Smart Lockout ist für jeden Tenant aktiv, aber seine Standardwerte sind auf breite Nutzbarkeit ausgelegt, nicht auf Erkennung:

• Die Standard-Lockout-Schwelle liegt bei 10 fehlgeschlagenen Versuchen (Azure-Public-Tenants; 3 für Azure US Government), danach wird das Konto für zunächst 60 Sekunden gesperrt, mit wachsender Dauer bei wiederholten Sperrungen.
• Smart Lockout unterscheidet zwischen bekanntem und unbekanntem Standort, um einen Angreifer vom echten Nutzer zu trennen, und sowohl bekannte als auch unbekannte Standorte führen eigene, getrennte Lockout-Zähler: Ein Angreifer, der sich von einem Standort aus anmeldet, den der echte Nutzer nie genutzt hat, verbraucht also einen eigenen Zähler, unabhängig von den Tippfehlern des echten Nutzers.
• Smart Lockout merkt sich außerdem die letzten drei falschen Passwort-Hashes, um den Lockout-Zähler beim wiederholten Raten desselben Passworts nicht hochzuzählen. Ein Spray, der ein gängiges Passwort gegen ein Konto wiederholt, treibt dieses Konto also nie in Richtung Lockout — genau der Fall, den Ihre eigene Abfrage abfangen muss. Microsoft merkt an, dass dieses Hash-Tracking für Kunden mit Pass-through-Authentication nicht verfügbar ist.
• Schwellenwert und Dauer unterhalb des Standards anzupassen erfordert Microsoft Entra ID P1 oder höher, konfigurierbar unter Entra ID > Authentication methods > Password protection.

Eine niedrigere Schwelle tauscht etwas Nutzerkomfort gegen die Möglichkeit, eine Brute-Force-Kampagne zu stoppen, lange bevor Ihr 15-Minuten-Erkennungsfenster überhaupt schließt. Stimmen Sie die Änderung mit einer hybriden AD-DS-Lockout-Policy ab. Für Pass-through Authentication ist Microsoft eindeutig: Die Entra-Lockout-Schwelle muss niedriger sein als die AD-DS-Kontosperrungsschwelle, so eingestellt, dass die AD-DS-Kontosperrungsschwelle mindestens zwei- bis dreimal so hoch ist wie die Microsoft-Entra-Lockout-Schwelle — der Cloud-Lockout fängt den Angriff dann ab, bevor er On-Premises ankommt.

2. Die KQL-Abfrage zu einem stehenden Alert machen

Eine Abfrage, die nur läuft, wenn sich jemand daran erinnert, sie in Log Analytics einzufügen, ist keine Erkennung. Speichern Sie sie als geplante Microsoft-Sentinel-Analyseregel (oder als Azure-Monitor-Log-Alert) im 15-Minuten-Takt passend zum bin()-Fenster, und leiten Sie sie an die Person weiter, die Identity-Incidents verantwortet. Das ist die Kontrolle, die die Katalog-Lücke tatsächlich schließt — Identity Protection bleibt bei einem reinen Fehlversuchs-Burst stumm, also alarmiert sonst niemand für Sie.

3. Eine sign-in-risikobasierte Conditional-Access-Policy für die Fälle ergänzen, die durchkommen

Nichts davon ersetzt risikobasiertes Conditional Access — es ergänzt es. Führt ein Burst irgendwann zu einem erfolgreichen Versuch, ist eine Sign-in-Risk-Policy das, was diese Session am Handeln hindert. Die vollständige Anleitung dazu finden Sie unter Azure Identity Protection: Geleakte Anmeldedaten blockieren; hat Ihre Conditional-Access-Baseline über risikobasierte Sign-ins hinaus weitere Lücken, prüfen Sie sie gegen Entra ID Conditional Access Lücken.

4. Den Sign-in-Log-Export aktivieren, bevor Sie ihn brauchen

SigninLogs füllt sich erst, sobald der Diagnose-Export nach Log Analytics aktiviert ist — wie jeder Azure-Monitor-Stream erfasst sie Ereignisse ab dem Zeitpunkt der Aktivierung, nicht rückwirkend. Aktivieren Sie den Export jetzt unter Entra ID > Monitoring & health > Diagnostic settings, damit die Historie beim nächsten Mal da ist, wenn Sie diese Abfragen gegen einen bereits eine Woche alten Incident laufen lassen müssen.

Wie EtcSec das erkennt

EtcSecs Risk-Protection-Checks umfassen genau diese Raw-Telemetry-Korrelation — intern geführt als RISK_FAILED_SIGNIN_BURST, als kritisch eingestuft und auf MITRE ATT&CK T1110.003 gemappt —, weil Identity Protections eigene Risk Engine, wie oben dokumentiert, keine Erkennung für Fehlervolumen gegen ein einzelnes Konto besitzt. Der Check läuft in denselben zwei Formen wie die Abfragen oben, über ein festes 10-Minuten-Fenster: mehr als 50 Anmeldedaten-Fehlschläge gegen einen Nutzer, oder mehr als 50 von einer IP über mehr als 10 verschiedene Nutzer verteilt. Das sind Audit-Schwellenwerte, hoch genug angesetzt, dass ein Fund ein Incident ist und kein Ausgangspunkt — genau deshalb startet die KQL oben niedriger und verlangt zuerst eine Baseline. Er steht neben den Checks, die prüfen, was passiert, sobald Identity Protection tatsächlich eine Flagge setzt: RISK_SIGNINS_NOT_INVESTIGATED (riskante Sign-ins ohne Follow-up) und RISK_NO_AUTOMATED_RESPONSE (Risiko sichtbar, aber keine automatisierte Eindämmung konfiguriert), und er bestimmt direkt mit, ob CA_NO_RISK_BASED_SIGNIN (keine sign-in-risikobasierte Conditional-Access-Policy) in Ihrer Umgebung überhaupt relevant ist.

Die Schwester-Detektoren aus derselben Raw-Telemetry-Familie finden Sie unter Entra Service Principal Sign-In Anomaly Detection und Entra ID AiTM-Token-Replay, Erkennung unmöglicher Reisen. Für die Response-seitige Lücke, sobald Identity Protection tatsächlich auslöst, siehe Entra ID Risk Protection: Geleakte Anmeldedaten, nicht behobene Risk Users.

Primärquellen

• What are risk detections? — Microsoft Entra ID Protection
• Prevent attacks using Smart Lockout — Microsoft Entra ID
• Microsoft Entra authentication & authorization error codes
• Azure Monitor Logs reference — SigninLogs
• Example log table queries for SigninLogs
• Learn about the monitoring and health activity log schemas — Microsoft Entra ID