Der Hack bei CenterPoint Energy hat nichts mit deinem Tenant zu tun – und trotzdem betrifft er dich. Ein Angreifer hat sich über eine öffentliche API ohne Rate-Limiting Zugriff auf rund 7,49 Millionen Kundendatensätze verschafft, darunter Namen, Adressen, Kontonummern und teilweise Sozialversicherungsnummern. CenterPoint Energy hat den Vorfall gegenüber der SEC bestätigt, ohne genaue Zahlen zu nennen. Für Sysadmins in Deutschland ist der konkrete Fall zweitrangig. Relevant ist das Muster dahinter: Millionen Zugangsdaten landen regelmäßig in Leaks, und ein Teil davon gehört garantiert zu Mitarbeitern deines Unternehmens, die private und geschäftliche Zugangsdaten wiederverwenden.
Ausgangslage: Warum Drittanbieter-Leaks jeden Sysadmin betreffen
Der eigentliche Angriffspunkt bei CenterPoint war eine fehlende Absicherung der eigenen Infrastruktur. Für dich als Sysadmin im Microsoft-Umfeld ist allerdings nicht der Leak selbst das Problem, sondern das, was danach passiert. Sobald Zugangsdaten öffentlich oder im Darknet gehandelt werden, testen Angreifer diese automatisiert gegen andere Dienste – auch gegen deinen Entra-ID-Tenant. Diese Technik heißt Credential Stuffing und ist deshalb so erfolgreich, weil Passwort-Wiederverwendung nach wie vor die Regel statt die Ausnahme ist.
Das eigentliche Risiko: Credential Reuse im eigenen Tenant
Wenn ein Mitarbeiter dasselbe Passwort bei einem Energieversorger, einem Onlineshop und im Firmen-Account nutzt, reicht ein einziger Drittanbieter-Leak, um dein Unternehmen zu kompromittieren. Genau deshalb solltest du nicht abwarten, bis ein Angriff im eigenen Tenant sichtbar wird, sondern proaktiv gegensteuern. Microsoft bietet dafür zwei zusammenspielende Werkzeuge: Entra ID Password Protection verhindert schwache und bekannte Passwörter von vornherein, Entra ID Protection erkennt verdächtige Anmeldungen und kompromittierte Konten im laufenden Betrieb.
Entra ID Password Protection erklärt
Entra ID Password Protection prüft bei jeder Passwortänderung, ob das gewählte Passwort auf einer Sperrliste steht. Dabei gibt es zwei Ebenen, die zusammenarbeiten.
Globale Banned-Password-Liste
Microsoft pflegt eine global aktualisierte Liste bekannter, häufig verwendeter und in Leaks aufgetauchter Passwörter. Diese Liste ist automatisch aktiv, sobald du Cloud-Konten in Entra ID nutzt, und benötigt keine zusätzliche Konfiguration.
Benutzerdefinierte Banned-Password-Liste
Zusätzlich kannst du eine eigene Liste pflegen, die firmenspezifische Begriffe blockiert – etwa Produktnamen, Standorte oder Varianten des Firmennamens. Genau hier setzt du auch an, wenn ein aktueller Drittanbieter-Leak bekannt wird: Trage betroffene Begriffe oder bekannt gewordene Passwortmuster in die Custom-Liste ein, damit sie in deinem Tenant künftig nicht mehr verwendet werden können.
Schritt für Schritt: Custom Banned Password List einrichten
Die Konfiguration erfolgt entweder im Azure-Portal unter Entra ID > Security > Authentication methods > Password protection, oder automatisiert über Microsoft Graph PowerShell. Für die Automatisierung, etwa nach einem bekannt gewordenen Leak, eignet sich folgender Ablauf:
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Directory.ReadWrite.All"
$template = Get-MgDirectorySettingTemplate | Where-Object DisplayName -eq "Password Rule Settings"
$setting = New-MgDirectorySetting -TemplateId $template.Id
($setting.Values | Where-Object Name -eq "BannedPasswordList").Value = "Firmenname123;Standort2026;ProduktXYZ"
($setting.Values | Where-Object Name -eq "EnableBannedPasswordCheck").Value = "true"
Update-MgDirectorySetting -DirectorySettingId $setting.Id -BodyParameter $settingAchte darauf, die Liste regelmäßig zu pflegen, nicht nur einmalig nach einem Vorfall. Details zu Parametern und Grenzwerten findest du in der offiziellen Microsoft-Dokumentation zu Entra ID Password Protection.
Entra ID Protection: Risky Users und Risky Sign-ins erkennen
Password Protection verhindert schwache Passwörter, erkennt aber nicht, ob ein bereits gültiges Passwort aus einem Leak stammt. Genau dafür gibt es Entra ID Protection. Der Dienst bewertet Anmeldungen anhand von Signalen wie Leaked-Credentials-Feeds, unmöglichen Reisebewegungen, anonymisierten IP-Adressen oder ungewöhnlichem Anmeldeverhalten und stuft Nutzer sowie einzelne Sign-ins in Risikostufen ein. Ein „Risky User“ mit dem Risikofaktor „Leaked Credentials“ bedeutet konkret: Microsoft hat dieses Passwort in einem bekannten Datenleck gefunden. Das ist der direkte Bezug zu Fällen wie CenterPoint Energy – die entsprechenden Feeds werden kontinuierlich mit neuen Leaks abgeglichen.
Conditional-Access-Policies für kompromittierte Konten
Erkennung allein reicht nicht, du musst automatisiert reagieren. Dafür konfigurierst du risikobasierte Conditional-Access-Policies:
- Bei Risikostufe „Hoch“ (Sign-in-Risiko): Zugriff blockieren oder MFA zusätzlich erzwingen.
- Bei erkanntem Risky User: automatische Passwortänderung erzwingen, bevor der Nutzer sich weiter anmelden kann.
- Bei Leaked-Credentials-Signal: Kombination aus Passwort-Reset und MFA-Neuregistrierung.
Diese Policies richtest du unter Entra ID > Protection > Conditional Access ein. Wichtig: Ohne Entra ID P2 stehen dir nur eingeschränkte Signale zur Verfügung, die vollständige Risikobewertung ist an diese Lizenz gebunden.
SSPR und erzwungene Reset-Workflows bei bekannt gewordenen Leaks
Self-Service Password Reset entlastet dein Helpdesk-Team, wenn nach einem Leak viele Nutzer gleichzeitig ihr Passwort ändern müssen. Kombiniere SSPR mit einer erzwungenen Passwortänderung, sobald du weißt, dass Zugangsdaten deiner Mitarbeiter in einem Drittanbieter-Leak aufgetaucht sind. So verteilt sich die Last auf die Nutzer selbst, statt dass dein Team jeden Reset manuell durchführen muss.
Monitoring und Automatisierung
Die Sign-in-Logs in Entra ID und die Identity-Protection-Reports zeigen dir, welche Konten aktuell als riskant eingestuft sind. Für größere Umgebungen lohnt sich die Weiterleitung dieser Daten an Microsoft Sentinel oder eine Automatisierung über Logic Apps, die bei neuen Risky-User-Events automatisch ein Ticket erstellt oder direkt eine Conditional-Access-Aktion auslöst. So bist du nicht auf manuelles Prüfen angewiesen, sondern reagierst innerhalb von Minuten statt Stunden.
Ergänzender Schutz: Phishing-resistente MFA und Passkeys
Selbst die beste Passwort-Hygiene schützt nicht vor jedem Angriff. Deshalb solltest du parallel auf phishing-resistente MFA-Methoden wie FIDO2-Sicherheitsschlüssel oder Passkeys umstellen. Diese Methoden sind gegen klassisches Credential Stuffing und Phishing weitgehend immun, weil kein Passwort mehr übertragen wird, das gestohlen werden könnte. Mehr Grundlagen zu Phishing-Abwehr findest du in unserem Artikel zu Strategien gegen Phishing-Angriffe.
Praxis-Checkliste: Sofortmaßnahmen nach einem Drittanbieter-Leak
- Custom Banned Password List um relevante Begriffe aus dem Leak erweitern.
- Identity Protection Reports auf neue Risky Users mit Signal „Leaked Credentials“ prüfen.
- Conditional-Access-Policy für Passwort-Reset bei hohem Risiko aktivieren.
- Betroffene Nutzer per SSPR-Workflow zum Passwortwechsel zwingen.
- Sign-in-Logs für die betroffenen Konten für mindestens 30 Tage engmaschig beobachten.
- Prüfen, ob eine Meldepflicht besteht, falls eigene Kundendaten betroffen sein könnten – siehe dazu unseren Artikel zur DSGVO-Meldepflicht nach einem Datenleck.
- Vorfall gemäß eigenem Ablaufplan dokumentieren, wie im Incident Response Plan für Sysadmins beschrieben.
Der Hintergrund zum CenterPoint-Energy-Vorfall stammt aus der Berichterstattung von BleepingComputer, die auch weitere Details zur Angriffsmethode über die ungeschützte API liefert.
FAQ
Welche Lizenz brauche ich für Entra ID Password Protection?
Die globale Banned-Password-Liste ist mit jedem Entra-ID-Plan aktiv. Für benutzerdefinierte Listen, On-Premises-Integration und vollständige Identity-Protection-Signale benötigst du Entra ID P1 beziehungsweise für risikobasierte Conditional Access und detaillierte Risikoberichte Entra ID P2.
Funktioniert Entra ID Password Protection auch on-premises für Active Directory?
Ja, über den Password Protection Proxy und den Password Protection DC Agent lässt sich derselbe Bad-Password-Schutz auf lokale Active-Directory-Umgebungen ausweiten. Passwortänderungen im On-Prem-AD werden dann gegen dieselbe Sperrliste geprüft wie in der Cloud.
Wo finde ich die Logs von Entra ID Password Protection?
Die Auswertung erfolgt über die Audit-Logs in Entra ID sowie, im On-Premises-Szenario, über die Ereignisanzeige auf den Domänencontrollern beziehungsweise dem Proxy-Server. Dort siehst du, welche Passwortänderungen abgelehnt wurden und warum.
Was macht der Password Protection Agent beziehungsweise Proxy genau?
Der Proxy läuft in deiner Domäne und leitet Anfragen der Domänencontroller an den Entra-ID-Dienst weiter, um die aktuelle globale und benutzerdefinierte Sperrliste abzugleichen. Der DC Agent selbst wird auf jedem Domänencontroller installiert und setzt die Prüfung bei jeder lokalen Passwortänderung durch.