Installation

pipx

pip

Beispiele

Optionen

Rate Limiting

Zwischen jeder Anfrage wird zusätzlich zu --delay ein randomisierter Jitter hinzugefügt. Exponentielles Back-off (bis zu --retries Versuche) wird bei 429-Antworten und Netzwerkfehlern angewendet. Die Standardverzögerung beträgt 2 Sekunden; für große Stapel auf 4-6 Sekunden erhöhen. Der User-Agent wird bei jeder Anfrage aus einem Pool von 16 gängigen Agents (Windows, macOS, iOS, Android) rotiert.

Genauigkeit und Einschränkungen

TL;DR

• Die SSPR-Methoden-Enumeration ist aufgrund der kombinierten Registrierung ein sinnvoller Proxy für die MFA-Posture bei den meisten modernen Entra ID-Tenants
• Erkennt keine FIDO2-Schlüssel, zertifikatsbasierte Authentifizierung oder Methoden bei Gast-/föderierten Konten
• Konten, bei denen SSPR deaktiviert ist, werden als existierend bestätigt, aber ihre Methoden sind unbekannt
• Dies ist kein definitives MFA-Audit — verstehen Sie, was es sieht und was nicht, bevor Sie sich auf die Ausgabe verlassen

Warum SSPR-Ergebnisse ein sinnvoller MFA-Proxy sind

Microsofts kombinierte Registrierungserfahrung für Sicherheitsinformationen, standardmäßig aktiviert seit 2020, registriert Authentifizierungsmethoden sowohl für SSPR als auch für MFA in einem einzigen Flow. In der Praxis bedeutet dies, dass bei den meisten modernen Entra ID-Tenants die über SSPR sichtbaren Methoden dieselben Methoden sind, die die Anmeldung schützen. Ein Konto ohne registrierte starke SSPR-Methode ist sehr wahrscheinlich ein Konto ohne registrierte starke MFA-Methode.

Referenzen:

• Combined security information registration overview
• How it works: Azure AD self-service password reset

Bekannte Schwächen

SSPR und MFA sind separate Registrierungen. Die kombinierte Registrierung lässt sie in den meisten Fällen überlappen, aber sie sind nicht dasselbe. Eine Methode kann für MFA existieren, ohne hier sichtbar zu sein, wenn sie vor der Aktivierung der kombinierten Registrierung registriert wurde oder wenn der Administrator sie von der SSPR-Richtlinie ausgeschlossen hat.

FIDO2-Sicherheitsschlüssel und zertifikatsbasierte Authentifizierung werden von SSPR nicht unterstützt. Microsoft hat diese Methoden nie zum SSPR-Flow hinzugefügt. Ein Benutzer, dessen einziger registrierter Faktor ein FIDO2-Schlüssel oder eine Smartcard ist, erscheint hier als ohne Methoden — ein falsch-negatives Ergebnis. In der Praxis ist dies bei Standardbenutzern selten, aber in Umgebungen mit hoher Sicherheit oder Passwortlosigkeit häufiger.

Referenzen:

• Authentication methods available for SSPR
• FIDO2 security key sign-in

Richtlinienkonflikte pro Methode. Administratoren können eine Methode für die MFA-Anmeldung erlauben, sie aber von der SSPR-Richtlinie ausschließen, oder umgekehrt. Beispielsweise könnte eine Organisation Authenticator-Push für die Anmeldung erlauben, aber nicht für das Zurücksetzen des Passworts. Das Tool sieht nur, was SSPR bereit ist anzubieten.

SSPR vollständig deaktiviert (SSPR_0011). Wenn SSPR für einen Benutzer nicht lizenziert oder nicht aktiviert ist, gibt der Endpunkt ViewSsprNotEnabledInUserPolicy zurück und es sind keine Methodeninformationen verfügbar. Das Konto existiert und hat wahrscheinlich MFA konfiguriert, aber dieses Tool kann nicht feststellen, welche.

Gast- und föderierte Konten. Externe Benutzer und B2B-Gäste authentifizieren sich über ihren Heim-Tenant. Der SSPR-Endpunkt des Ressourcen-Tenants hat keine Sicht auf die MFA-Registrierung ihres Heim-Tenants und gibt ViewFeatureNotAvailable zurück. Ihre MFA-Posture ist von diesem Endpunkt aus unsichtbar.

Mandantenweite Methodenbeschränkungen. Wenn ein Administrator eine Methodenklasse in der SSPR-Richtlinie deaktiviert hat, wird sie keinem Benutzer angeboten, unabhängig von der individuellen Registrierung, was es unmöglich macht, zwischen „Methode nicht registriert" und „Methode deaktiviert" zu unterscheiden.

Administratorkonten sind immer SSPR-fähig. Microsofts SSPR-Richtlinieneinstellungen gelten nur für Standard-Endbenutzer. Administratorkonten sind immer für Self-Service Password Reset aktiviert, unabhängig von der SSPR-Richtlinie des Tenants, und Microsoft verlangt, dass sie zwei Authentifizierungsmethoden registriert haben. Dies wird auf Plattformebene erzwungen und kann von Tenant-Administratoren nicht deaktiviert werden.

Referenz: SSPR policy documentation

[!IMPORTANT] Dies hat eine nützliche Implikation für die Reconnaissance. Wenn SSPR für Standardbenutzer in einem Tenant deaktiviert ist (Rückgabe von ViewSsprNotEnabledInUserPolicy), ist jedes Konto, das erfolgreich den Methodenauswahlbildschirm erreicht, wahrscheinlich ein Mitglied einer privilegierten Rolle. Konten, die sauber über SSPR aufgelistet werden, wenn die übergreifende Tenant-Richtlinie deaktiviert ist, heben sich als wahrscheinliche Admin-Konten hervor, und ihre registrierten Methoden sind sichtbar, selbst wenn Standardbenutzermethoden es nicht sind. Dies ermöglicht die Identifizierung hochwertiger Ziele und privilegierter Konten, die für weitere gezielte Angriffe herausgegriffen werden können.

Übersicht darüber, was das Tool bietet und was nicht

Funktionsweise

TL;DR

• Zwei Anfragen pro Ziel: ein GET zum Erhalt von Session-Tokens, dann ein POST, der die asynchrone Formularübermittlung des Browsers nachbildet
• Das CurrentViewName-Antwortfeld des Servers wird als Ground Truth für das Ergebnis verwendet — nicht HTML-Body-Matching
• Der User-Agent wird pro Anfrage aus einem Pool von 16 realistischen Browser-Strings rotiert
• Jitter und exponentielles Back-off werden automatisch angewendet, um Rate Limiting zu vermeiden

Überblick

Microsofts SSPR-Portal (passwordreset.microsoftonline.com) zeigt einen Kontaktmethoden-Auswahlbildschirm (MultigateAuthenticationControl) nach Akzeptanz eines gültigen Benutzernamens. Das zurückgegebene HTML listet jede registrierte Verifizierungsmethode als Radio-Button in MultigateAuthenticationControl_RadioTable auf. Methoden, deren <tr>-Zeile display:none ist, sind für diesen Benutzer nicht registriert und werden übersprungen.

Für jedes Ziel führt das Tool zwei Anfragen durch. Zuerst ein GET auf die Landing- Page, um eine Session aufzubauen und die ASP.NET-Formular-Tokens (__VIEWSTATE, __EVENTVALIDATION, WorkflowConsistencyCheck) zu extrahieren, die erforderlich sind, damit der Server einen POST akzeptiert. Diese Tokens sind kryptografisch an das Session-Cookie gebunden und können nicht vorhergesagt oder über Sessions hinweg wiederverwendet werden. Zweitens ein POST, der die E-Mail-Adresse zusammen mit diesen Tokens übermittelt und den asynchronen UpdatePanel-Postback nachbildet, den der Browser ausführt, wenn der Benutzer auf Weiter klickt.

Das versteckte Feld CurrentViewName in der ASP.NET-Wire-Response wird als maßgebliches Signal dafür verwendet, was der Server entschieden hat, anstatt Substring- Matching im HTML-Body.

Methodenklassifizierung

Alternative E-Mail und Sicherheitsfragen werden als schwach markiert, da sie phishing-anfällig sind und nicht dem Zweck eines zweiten Faktors entsprechen. Konten mit nur schwachen Methoden oder gar keinen Methoden werden markiert.

[!NOTE] Microsoft unterstützt sowohl Software-OATH-Tokens als auch Hardware- OATH-Tokens (Vorschau) für SSPR. Software-OATH-Tokens, die über die Authenticator-App eingegeben werden, erscheinen höchstwahrscheinlich über denselben AppCodeRadio-Button wie TOTP — beide präsentieren sich als Eingabe eines sechsstelligen Codes —, sodass sie wahrscheinlich bereits ohne separate Radio-ID abgedeckt sind. Hardware-OATH-Tokens (ein physischer Keyfob) sind eine eigene Geräteklasse, erzeugen aber ebenfalls einen zeitbasierten Code; sie könnten über denselben Button oder einen anderen gerendert werden, der während des Tests dieses Prozesses noch nicht beobachtet wurde.

Ergebnisse

Danksagungen

• RedByte1337/CredSpy
• Unser Kind Claude