Entra ID Risk Protection: Durchgesickerte Anmeldedaten, Risikobehaftete Benutzer nicht behoben

Entra ID Risk Protection: Durchgesickerte Anmeldedaten, Risikobehaftete Benutzer nicht behoben

Entra ID Risk Protection hat kein Problem damit, kompromittierte Konten zu finden. Das Problem ist, was danach passiert. In einer großen Zahl von Tenants zeigt sich dasselbe Muster — durchgesickerte Anmeldedaten und risikobehaftete Benutzer bleiben wochen- oder monatelang unbehoben — weil die Erkennung auslöst, in einem Bericht landet und dort liegen bleibt. Dieser Artikel handelt von genau dieser Lücke: nicht von der Erkennungslogik, die Microsoft bereits für Sie übernimmt, sondern von dem Reaktions-Workflow, den fast niemand operationalisiert.

Jeder risikobehaftete Benutzer in Entra ID trägt einen Risikostatus. Microsoft Graph dokumentiert die möglichen Werte als none, confirmedSafe, remediated, dismissed, atRisk und confirmedCompromised (plus den Sentinel-Wert unknownFutureValue). Nur drei davon schließen ein markiertes Konto aus der Warteschlange — remediated, dismissed und confirmedSafe — passend zu den manuellen Aktionen, die Microsoft anbietet: verwerfen, als sicher bestätigen, als kompromittiert bestätigen. Sowohl atRisk als auch confirmedCompromised lassen den Benutzer im Bericht der risikobehafteten Benutzer stehen. atRisk bedeutet, dass das Konto weiterhin markiert ist und nichts unternommen wurde. confirmedCompromised ist der Status, der viele überrascht: Ein Administrator hat sich das Konto angesehen, die Kompromittierung bestätigt — und allein dieser Status bedeutet noch nicht, dass jemand das Konto abgesichert hat.

Eine Kompromittierung zu bestätigen ist eine Kennzeichnungsaktion, keine Eindämmungsaktion. Das Gleiche gilt für das Verwerfen.

Auch der Backlog löst sich nicht von selbst auf. Erkennungen und Benutzer mit niedrigem Risiko „bleiben sechs Monate lang im Produkt bestehen, bevor sie automatisch entfernt werden" — aber mittlere und hohe Risikostufen bleiben bestehen, bis sie behoben oder verworfen werden. Eine vor zwei Jahren ausgelöste Hochrisiko-Erkennung durchgesickerter Anmeldedaten steht heute noch im Bericht der risikobehafteten Benutzer, wenn nicht ein Mensch oder eine Richtlinie sie geschlossen hat.

Wie die Erkennung durchgesickerter Anmeldedaten funktioniert

Durchgesickerte Anmeldedaten ist eine der wenigen Risikoerkennungen, die keinerlei Unschärfe zulässt.

Microsoft beschreibt die dahinterliegende Pipeline: ein groß angelegter Credential-Scanning-Dienst, der kontinuierlich Dark-Web-Foren, Breach-Dump-Repositories, Paste-Sites, von Strafverfolgungsbehörden beschlagnahmte Daten und weitere Quellen über das Microsoft Threat Intelligence Center (MSTIC), die Microsoft Digital Crimes Unit (DCU) und Industriepartner überwacht. Werden Anmeldedaten entdeckt, gleicht der Dienst das tatsächliche Credential-Material mit den aktuell gültigen Kennworthashes des Tenants ab, und eine Erkennung wird nur ausgelöst, wenn eine bestätigte Übereinstimmung gefunden wird. In Microsofts eigenen Worten ist die Erkennung „immer hochriskant, weil sie eine verifizierte Offenlegung von Anmeldedaten darstellt, kein heuristisches Signal".

Daraus ergeben sich zwei operative Konsequenzen.

Erstens: Das ist kein Wahrscheinlichkeitswert. Atypische Reiseaktivität kann ein Benutzer im Urlaub sein. Eine Erkennung durchgesickerter Anmeldedaten bedeutet, dass ein Passwort, das in Ihrem Tenant aktuell funktioniert, sich in fremder Hand befindet. Das verdient einen Incident, keine Triage-Warteschlange.

Zweitens: Sie erfahren es spät. Durchgesickerte Anmeldedaten wird offline berechnet, und Microsoft dokumentiert, dass „in Echtzeit ausgelöste Erkennungen 5–10 Minuten benötigen, bis Details in den Berichten erscheinen. Offline-Erkennungen benötigen bis zu 48 Stunden, bis sie in den Berichten erscheinen." Das Zeitfenster zwischen der Offenlegung und Ihrer ersten Gelegenheit zu reagieren wird in Tagen gemessen — genau deshalb muss die Reaktion schnell erfolgen, sobald das Signal eintrifft.

Kennworthashsynchronisierung spielt hier eine größere Rolle, als den meisten Teams bewusst ist. Ein cloudbasiertes Zurücksetzen des Passworts über Microsoft Entra behebt das Benutzerrisiko für diese Erkennung sowohl für Cloud- als auch für lokale Passwörter — aber nur, „solange die Kennworthashsynchronisierung (PHS) für lokale Kennwörter aktiviert ist".

Warum der Backlog risikobehafteter Benutzer nie leerer wird

Die Tenants mit den schlimmsten Backlogs sind selten die, die das Produkt ignoriert haben. Es sind die, bei denen sich mehrere kleine Lücken summieren.

Die Benachrichtigungen erreichen niemanden. Die E-Mail „Users at risk detected" nutzt standardmäßig einen Schwellenwert von hohem Benutzerrisiko. Standardmäßig werden Benutzer, denen aktiv die Rolle Globaler Administrator, Sicherheitsadministrator oder Sicherheitsleser zugewiesen ist, zur Empfängerliste hinzugefügt, und sie müssen eine E-Mail- oder Alternative-E-Mail-Adresse konfiguriert haben. Zwei dokumentierte Fallstricke unterlaufen das leise: Ein Benutzer, der über Privileged Identity Management in eine dieser Rollen wechselt, „erhält E-Mails nur, wenn er zum Zeitpunkt des E-Mail-Versands aktiviert ist", und „das Versenden von E-Mails an Benutzer in gruppenzugewiesenen Rollen wird nicht unterstützt". Ein Tenant, der Sicherheitsleser über eine Gruppe vergibt und Administratoren bedarfsgesteuert über PIM aktiviert, kann genau null Benachrichtigungen erhalten, während sich das Dashboard füllt.

Richtlinienschwellenwerte liegen über dem Großteil der Warteschlange. Microsofts empfohlene Konfiguration ist eine Benutzerrisikorichtlinie bei Hoch und eine Anmelderisikorichtlinie bei Mittel und Hoch. Das ist solide Empfehlung, bedeutet aber, dass jede Erkennung mit mittlerem Benutzerrisiko und jede mit niedrigem Risiko einem Menschen überlassen bleibt — und mittlere Risiken bestehen bleiben, bis sie jemand schließt.

Selbstbehebung steht praktisch nicht zur Verfügung. Microsoft warnt: „Benutzer müssen sich für Microsoft Entra Multi-Faktor-Authentifizierung registrieren, bevor eine Situation eintritt, die eine Behebung erfordert. Für Hybridbenutzer, die aus der lokalen Umgebung synchronisiert werden, muss Kennwortrückschreibung aktiviert sein. Nicht registrierte Benutzer werden blockiert und benötigen administratives Eingreifen." Hybridbenutzer benötigen zusätzlich PHS sowie die Opt-in-Einstellung Lokale Kennwortänderung zum Zurücksetzen des Benutzerrisikos zulassen, bevor eine lokale Kennwortänderung ihr Risiko löscht. Fehlen diese Voraussetzungen, leert die Richtlinie die Warteschlange nicht — sie verwandelt risikobehaftete Benutzer in blockierte Benutzer und verlagert die Arbeit zum Helpdesk.

Manche Erkennungen werden nicht mehr automatisch behoben. Microsoft behebt Sitzungen mit MFA-Ansprüchen nicht mehr automatisch, wenn eine Erkennung im Zusammenhang mit Token-Diebstahl oder die Erkennung Verifizierte Bedrohungsakteur-IP auslöst. Betroffen sind Microsoft Entra Threat Intelligence, Anomales Token, Angreifer in der Mitte (Attacker in the Middle), Verifizierte Bedrohungsakteur-IP und Token-Aussteller-Anomalie. Trifft eine davon einen Benutzer, erfordert das Löschen des Risikos eine sichere Kennwortänderung und eine erneute Authentifizierung mit MFA. Wer noch dem Denkmodell „MFA löst alles" folgt, sieht diese Fälle sich anhäufen.

Gelöschte Benutzer bleiben für immer hängen. „Wenn ein Benutzer aus dem Verzeichnis gelöscht wurde, der ein Risiko aufwies, erscheint dieser Benutzer weiterhin im Risikobericht, obwohl das Konto gelöscht wurde. Administratoren können das Risiko für aus dem Verzeichnis gelöschte Benutzer nicht verwerfen." Das Bereinigen erfordert einen Microsoft-Supportfall. Jeder ausgeschiedene risikobehaftete Benutzer bläht die Zahl dauerhaft auf — und trainiert das Team darauf, der Zahl nicht mehr zu vertrauen.

Die Legacy-Automatisierung hat ein Ablaufdatum. Microsofts Vorgabe ist eindeutig: „Die in Microsoft Entra ID Protection konfigurierten Legacy-Risikorichtlinien werden am 1. Oktober 2026 eingestellt." Tenants, deren einzige automatisierte Reaktion eine Legacy-Risikorichtlinie in ID Protection ist — statt einer Conditional-Access-Richtlinie —, verlieren sie, und ein Backlog, der bislang automatisch abgebaut wurde, beginnt erneut zu wachsen.

Erkennung: Messen Sie Ihren eigenen Behebungs-Backlog

Die Portalberichte zeigen Ihnen, wer risikobehaftet ist. Sie zeigen Ihnen nicht, wie lange jemand risikobehaftet bleibt — und genau das ist die Zahl, die zählt. Dafür brauchen Sie die Risikodaten in Log Analytics.

Konfigurieren Sie Diagnoseeinstellungen unter Entra ID > Überwachung und Integrität > Diagnoseeinstellungen und exportieren Sie die Kategorien RiskyUsers und UserRiskEvents (Microsoft stellt außerdem RiskyServicePrincipals, ServicePrincipalRiskEvents, RiskyAgents und AgentRiskEvents bereit). Sie landen in den Tabellen AADRiskyUsers und AADUserRiskEvents.

Worauf Sie achten sollten

Offene Erkennungen durchgesickerter Anmeldedaten

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskEventType == "leakedCredentials"
| where RiskState == "atRisk"
| project DetectedDateTime, UserPrincipalName, RiskLevel, RiskState, RiskDetail, DetectionTimingType
| order by DetectedDateTime asc

Jede Zeile ist ein Konto, dessen Passwort nachweislich offengelegt ist und das niemand angefasst hat. Nach Alter sortiert steht Ihre schlimmste Exposition ganz oben in dieser Liste.

Wie alt ist der At-Risk-Backlog

AADRiskyUsers
| summarize arg_max(TimeGenerated, RiskState, RiskLevel, RiskDetail, RiskLastUpdatedDateTime)
    by UserPrincipalName
| where RiskState == "atRisk"
| where RiskLevel in ("high", "medium")
| extend DaysAtRisk = datetime_diff('day', now(), RiskLastUpdatedDateTime)
| project UserPrincipalName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime, DaysAtRisk
| order by DaysAtRisk desc

AADRiskyUsers erhält bei jeder Änderung des Risikostatus eines Benutzers einen neuen Datensatz, daher fasst arg_max den Stream auf den zuletzt bekannten Status pro Benutzer zusammen, bevor das Alter berechnet wird.

Den Verwerfen-Button prüfen

AADRiskyUsers
| where TimeGenerated > ago(90d)
| where RiskState == "dismissed" and RiskDetail == "adminDismissedAllRiskForUser"
| project TimeGenerated, UserPrincipalName, RiskLevel, RiskDetail
| order by TimeGenerated desc

Verwerfen ist nach einer Untersuchung ein legitimes Ergebnis. Es ist aber auch der schnellste Weg, ein Dashboard gesund aussehen zu lassen. Gleichen Sie diese Liste mit Ihrem Ticketsystem ab: Ein Verwerfen ohne passenden Untersuchungsdatensatz ist eine Entscheidung, die später niemand verteidigen kann.

Zeit bis zum Schließen, nach Erkennungstyp

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskLevel == "high"
| where RiskState in ("remediated", "dismissed", "confirmedCompromised")
| extend HoursToClose = datetime_diff('hour', LastUpdatedDateTime, DetectedDateTime)
| summarize Detections = count(),
            MedianHours = percentile(HoursToClose, 50),
            P90Hours = percentile(HoursToClose, 90)
    by RiskEventType
| order by Detections desc

Das ist die Kennzahl, die vor die Führungsebene gehört. „Wir haben 40 risikobehaftete Benutzer" löst ein Schulterzucken aus; „unsere mediane Zeit bis zum Schließen einer bestätigten durchgesickerten Anmeldedaten-Erkennung beträgt 26 Tage" nicht.

Dieselben Daten über Microsoft Graph abfragen

Die riskyUsers-API erfordert eine Microsoft Entra ID P2-Lizenz (oder Microsoft Entra Suite). Zum Lesen wird die Berechtigung IdentityRiskyUser.Read.All benötigt, und für delegierten Zugriff muss der angemeldete Benutzer die Rolle Globaler Leser, Sicherheitsoperator, Sicherheitsleser oder Sicherheitsadministrator innehaben.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskState eq 'atRisk' and riskLevel eq 'high'

Der Endpunkt unterstützt $filter und $select, mit einer maximalen Seitengröße von 500 Objekten über $top. Dieselbe Abfrage über das Graph PowerShell SDK:

Import-Module Microsoft.Graph.Identity.SignIns

Get-MgRiskyUser -Filter "riskState eq 'atRisk' and riskLevel eq 'high'" -All |
    Select-Object UserPrincipalName, RiskLevel, RiskState, RiskDetail, RiskLastUpdatedDateTime

Führen Sie sie nach Zeitplan aus und alarmieren Sie bei der Anzahl, nicht bei einzelnen Ereignissen. Ein Backlog, der Woche für Woche wächst, ist der eigentliche Befund.

Behebung: Die Warteschlange leeren und leer halten

1. Wissen, was jede Aktion tatsächlich bewirkt

Bevor Sie irgendetwas automatisieren, stellen Sie sicher, dass das Team sich einig ist, was jede Schaltfläche bedeutet. Microsoft dokumentiert den resultierenden Status und das Detail für jeden Pfad:

Die Benennung ist tatsächlich verwirrend, und Microsoft weist selbst darauf hin: Das Risikodetail „User performed secured password reset" ist eine systemseitig gemeldete Bezeichnung, die anzeigt, dass der Benutzer eine sichere Kennwortänderung abgeschlossen hat (MFA gefolgt von einer Kennwortänderung) — kein Self-Service-Kennwort-Reset-Vorgang.

Beachten Sie auch die Rollenaufteilung — Sicherheitsoperator ist die Rolle mit den geringsten Rechten, um Benutzerrisiko zu verwerfen, während Benutzeradministrator für das Zurücksetzen von Kennwörtern erforderlich ist. Ein Kennwort-Reset innerhalb von ID Protection benötigt beides.

2. Den Backlog durchgesickerter Anmeldedaten einmalig manuell abarbeiten

Microsofts Untersuchungsschritte für diese Erkennung sind konkret und das richtige Runbook, um die bestehende Warteschlange zu leeren:

1. Umfang der Offenlegung einschätzen — Risikoverlauf und Anmeldeprotokolle des Benutzers auf korreliertes Anmelderisiko prüfen (unbekannte Standorte, anonyme IP-Adressen, atypische Reiseaktivität).
2. Prüfen, ob das Kennwort bereits geändert wurde, nachdem das Leck erkannt wurde; falls ja, ist das Risiko möglicherweise bereits selbst behoben.
3. Zugriff blockieren, falls ein Angreifer aktiv ist — Benutzer blockieren, Kennwort zurücksetzen und alle Refresh-Token widerrufen, wenn die Protokolle unautorisierten Zugriff zeigen.
4. Auf laterale Bewegung prüfen — Rechteausweitung, neue App-Registrierungen, Änderungen an Postfachregeln, Zugriff auf sensible Ressourcen.
5. Verknüpfte Konten überprüfen — verwendet der Benutzer Kennwörter mehrfach, gilt das Anmeldedatum als über Ihren Tenant hinaus kompromittiert.

3. „Kompromittierung bestätigen" zum Auslöser für Eindämmung machen

Die Bestätigung der Kompromittierung setzt die Risikostufe auf Hoch und fließt in Microsofts Modelle ein, aber Microsoft listet die Eindämmungsmaßnahmen separat auf: eine Kennwortänderung anfordern, den Benutzer blockieren, falls der Angreifer das Kennwort zurücksetzen oder MFA durchführen kann, Refresh-Token widerrufen, als kompromittiert eingestufte Geräte deaktivieren und, bei Verwendung von Continuous Access Evaluation, alle Zugriffstoken widerrufen.

Automatisieren Sie die Kennzeichnung, damit die menschliche Zeit in die Eindämmung fließt:

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/confirmCompromised
Content-Type: application/json

{
  "userIds": [
    "29f270bb-4d23-4f68-8a57-dc73dc0d4caf",
    "20f91ec9-d140-4d90-9cd9-f618587a1471"
  ]
}

Diese Aktion erfordert IdentityRiskyUser.ReadWrite.All, wobei Sicherheitsadministrator die Rolle mit den geringsten unterstützten Rechten ist, und liefert bei Erfolg 204 No Content.

4. Den Dauerzustand mit Conditional Access automatisieren

Manuelles Abarbeiten skaliert nicht. Zwei risikobasierte Conditional-Access-Richtlinien halten die Warteschlange nahe null, und Microsoft stellt ausdrücklich klar, dass sie getrennt sein müssen — „kombinieren Sie Anmelderisiko- und Benutzerrisikobedingungen nicht in derselben Conditional-Access-Richtlinie."

• Benutzerrisikorichtlinie: Wählen Sie Risikobehebung erforderlich, wenn das Benutzerrisiko Hoch ist. Diese Wahl wendet automatisch Authentifizierungsstärke erforderlich als Zugriffssteuerung und Anmeldehäufigkeit – Jedes Mal als Sitzungssteuerung an.
• Anmelderisikorichtlinie: Multi-Faktor-Authentifizierung erfordern, wenn das Anmelderisiko Mittel oder Hoch ist, mit Anmeldehäufigkeit auf jedes Mal gesetzt.

Schließen Sie Notfallzugriffskonten und Dienstprinzipale aus, starten Sie im Nur-Bericht-Modus und bestätigen Sie die Auswirkungen, bevor Sie auf Ein umschalten. Die vollständige Konfigurationsanleitung finden Sie in Azure Identity Protection: Reaktion auf kompromittierte Konten — und der Nur-Bericht-Modus ist eine Rollout-Stufe, keine Zielstellung, eine Falle, die in Conditional Access Nur-Bericht-Modus, veraltete Ausnahmen behandelt wird. Bringen Sie zuerst die Ausschlussliste in Ordnung, mit der Anleitung in Entra ID Break-Glass: Notfallzugangskonten, und prüfen Sie das Richtlinien-Set als Ganzes gegen Azure Bedingter Zugriff: MFA-Bypass mit gestohlenem Passwort.

5. Die Voraussetzungen beheben, die Selbstbehebung blockieren

• Bestätigen Sie, dass Benutzer für MFA registriert sind, bevor die Richtlinie live geht; nicht registrierte Benutzer werden blockiert statt behoben. Registrierungsabdeckung ist nur die halbe Geschichte — siehe Azure Identitätssicherheit: Warum MFA allein nicht ausreicht.
• Aktivieren Sie für Hybrididentitäten die Kennworthashsynchronisierung und schalten Sie Lokale Kennwortänderung zum Zurücksetzen des Benutzerrisikos zulassen unter Protection > Identity Protection > Settings ein. Microsoft weist darauf hin, dass dies nur per Opt-in möglich ist, und empfiehlt, den lokalen Kennwortänderungsprozess abzusichern — etwa indem vor einer lokalen Änderung MFA verlangt wird.

6. Benachrichtigungen an jemanden weiterleiten, der sie liest

Prüfen Sie, ob Empfänger der Warnung Users at risk detected eine gültige E-Mail- oder Alternative-E-Mail-Adresse haben, sich nicht auf gruppenzugewiesene Rollen verlassen, und berücksichtigen Sie das Timing der PIM-Aktivierung. Erwägen Sie, den Warnschwellenwert unter das Standard-Hoch zu senken, wenn Ihr Team die Kapazität dafür hat, und schalten Sie den wöchentlichen Digest für Trendsichtbarkeit ein.

7. Von den Legacy-Risikorichtlinien migrieren

Wenn die Risikodurchsetzung noch in den Legacy-ID-Protection-Richtlinien statt in Conditional Access liegt, migrieren Sie vor dem 1. Oktober 2026: Bauen Sie die entsprechenden Conditional-Access-Richtlinien im Nur-Bericht-Modus, validieren Sie sie, aktivieren Sie sie und deaktivieren Sie dann die alten Richtlinien unter ID Protection > Dashboard.

Wie EtcSec dies erkennt

EtcSec prüft den Reaktionspfad, nicht nur die Erkennungsebene.

Die Prüfungen Risk Protection kennzeichnen RISK_LEAKED_CREDENTIALS (Durchgesickerte Anmeldedaten nicht blockiert), wenn Konten mit bestätigt kompromittierten Anmeldedaten weiterhin aktiv und ungeblockt sind, und RISK_USERS_NOT_REMEDIATED (Risikobehaftete Benutzer nicht behoben), wenn als risikobehaftet markierte Konten nie behoben oder verworfen wurden. Beide sind als Kritisch eingestuft, weil beide ein Konto beschreiben, das ein Angreifer aktuell nutzen kann.

Daneben zeigt RISK_HIGH_RISK_USERS_ACTIVE Hochrisiko-Benutzer, deren Konten aktiviert bleiben, RISK_SIGNINS_NOT_INVESTIGATED erfasst risikobehaftete Anmeldungen ohne Nachverfolgung, und RISK_NO_AUTOMATED_RESPONSE identifiziert Tenants, in denen Risiko sichtbar ist, aber keine automatisierte Eindämmung existiert.

Für die umfassendere Tenant-Prüfung, in die diese Checks eingebettet sind, siehe Microsoft Entra ID Sicherheit auditieren: Leitfaden. Für die anmeldeseitigen Erkennungen, die in das Benutzerrisiko einfließen, siehe Entra ID AiTM-Token-Replay, Erkennung unmöglicher Reisen und MFA-Push-Fatigue und Password Spraying: Erkennung und Prävention.

Primärquellen

• What are risk detections? — Microsoft Entra ID Protection
• Risk detection types and levels
• Remediate risks and unblock users
• Investigate risk with Microsoft Entra ID Protection
• Risk policies — Microsoft Entra ID Protection
• Configure Microsoft Entra ID Protection notifications
• Export and use Microsoft Entra ID Protection data
• What is Microsoft Entra ID Protection?
• riskyUser resource type — Microsoft Graph v1.0
• riskyUser: confirmCompromised — Microsoft Graph v1.0
• List riskyUsers — Microsoft Graph v1.0
• Azure Monitor Logs reference — AADRiskyUsers
• Azure Monitor Logs reference — AADUserRiskEvents