Installazione

pipx

pip

Esempi

Opzioni

Rate limiting

Un jitter casuale viene aggiunto sopra --delay tra ogni richiesta. Un back-off esponenziale (fino a --retries tentativi) viene applicato sulle risposte 429 e sugli errori di rete. Il ritardo predefinito è di 2 secondi; aumentalo a 4-6 secondi per batch di grandi dimensioni. Lo User-Agent viene ruotato da un pool di 16 agent comuni (Windows, macOS, iOS, Android) a ogni richiesta.

Precisione e limitazioni

TL;DR

• L'enumerazione dei metodi SSPR è un proxy ragionevole per la postura MFA sulla maggior parte dei tenant Entra ID moderni grazie alla registrazione combinata
• Non rileverà chiavi FIDO2, autenticazione basata su certificati o metodi su account guest/federati
• Gli account per cui SSPR è disabilitato sono confermati esistenti ma i loro metodi sono sconosciuti
• Questo non è un audit MFA definitivo — comprendi cosa vede e cosa non vede prima di fare affidamento sull'output

Perché i risultati SSPR sono un proxy ragionevole per l'MFA

L'esperienza di registrazione combinata delle informazioni di sicurezza di Microsoft, abilitata per impostazione predefinita dal 2020, registra i metodi di autenticazione sia per SSPR che per MFA in un unico flusso. In pratica questo significa che sulla maggior parte dei tenant Entra ID moderni, i metodi visibili tramite SSPR sono gli stessi metodi che proteggono l'accesso. Un account senza un metodo SSPR forte registrato è molto probabilmente un account senza un metodo MFA forte registrato.

Riferimenti:

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

Limitazioni note

SSPR e MFA sono registri separati. La registrazione combinata li fa sovrapporre nella maggior parte dei casi ma non sono la stessa cosa. Un metodo può esistere per l'MFA senza essere visibile qui se è stato registrato prima che la registrazione combinata fosse abilitata, o se l'amministratore lo ha escluso dalla policy SSPR.

Le chiavi di sicurezza FIDO2 e l'autenticazione basata su certificati non sono supportate da SSPR. Microsoft non ha mai aggiunto questi metodi al flusso SSPR. Un utente il cui unico fattore registrato è una chiave FIDO2 o una smart card apparirà qui come privo di metodi — un falso negativo. In pratica questo è raro per gli utenti standard ma più comune in ambienti ad alta sicurezza o passwordless.

Riferimenti:

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

Disallineamenti delle policy per metodo. Gli amministratori possono consentire un metodo per l'accesso MFA ma escluderlo dalla policy SSPR, o viceversa. Ad esempio un' organizzazione potrebbe consentire il push dell'autenticatore per l'accesso ma non per il reset della password. Lo strumento vede solo ciò che SSPR è disposto a offrire.

SSPR completamente disabilitato (SSPR_0011). Se SSPR non è concesso in licenza o non è abilitato per un utente, l'endpoint restituisce ViewSsprNotEnabledInUserPolicy e nessuna informazione sui metodi è disponibile. L'account esiste e probabilmente ha MFA configurato, ma questo strumento non può determinare cosa.

Account guest e federati. Gli utenti esterni e i guest B2B si autenticano tramite il loro tenant di origine. L'endpoint SSPR del tenant della risorsa non ha visibilità sulla registrazione MFA del loro tenant di origine e restituisce ViewFeatureNotAvailable. La loro postura MFA è invisibile da questo endpoint.

Restrizioni sui metodi a livello di tenant. Se un amministratore ha disabilitato una classe di metodi nella policy SSPR, questa non verrà offerta a nessun utente indipendentemente dalla registrazione individuale, rendendo impossibile distinguere "metodo non registrato" da "metodo disabilitato".

Gli account amministratore sono sempre abilitati a SSPR. Le impostazioni della policy SSPR di Microsoft si applicano solo agli utenti finali standard. Gli account amministratore sono sempre abilitati al reset della password self-service indipendentemente dalla policy SSPR del tenant, e Microsoft richiede che abbiano due metodi di autenticazione registrati. Questo è imposto a livello di piattaforma e non può essere disabilitato dagli amministratori del tenant.

Riferimento: SSPR policy documentation

[!IMPORTANT] Questo ha un'implicazione utile per la ricognizione. Se SSPR è disabilitato per gli utenti standard in un tenant (restituendo ViewSsprNotEnabledInUserPolicy), qualsiasi account che raggiunge con successo la schermata di selezione del metodo è probabilmente un membro di un ruolo privilegiato. Gli account che si enumerano correttamente tramite SSPR quando la policy più ampia del tenant è disabilitata si distinguono come probabili account amministratore, e i loro metodi registrati sono visibili anche quando i metodi degli utenti standard non lo sono. Questo consente l'identificazione di target di alto valore e account privilegiati che possono essere individuati per ulteriori attacchi mirati.

Riepilogo di ciò che lo strumento fornisce e non fornisce

Come funziona

TL;DR

• Due richieste per target: una GET per ottenere i token di sessione, poi una POST che replica l'invio asincrono del form da parte del browser
• Il campo CurrentViewName nella risposta del server viene usato come verità di base per il risultato — non il matching del body HTML
• Lo User-Agent viene ruotato a ogni richiesta da un pool di 16 stringhe di browser realistiche
• Jitter e back-off esponenziale vengono applicati automaticamente per evitare il rate limiting

Panoramica

Il portale SSPR di Microsoft (passwordreset.microsoftonline.com) mostra una schermata di selezione del metodo di contatto (MultigateAuthenticationControl) dopo aver accettato un username valido. L'HTML restituito elenca ogni metodo di verifica registrato come radio button in MultigateAuthenticationControl_RadioTable. I metodi la cui riga <tr> è display:none non sono registrati per quell'utente e vengono saltati.

Per ogni target, lo strumento esegue due richieste. Prima, una GET alla landing page per stabilire una sessione ed estrarre i token del form ASP.NET (__VIEWSTATE, __EVENTVALIDATION, WorkflowConsistencyCheck) necessari affinché il server accetti una POST. Questi token sono crittograficamente legati al cookie di sessione e non possono essere previsti o riutilizzati tra sessioni. Seconda, una POST che invia l'indirizzo email insieme a quei token, replicando il postback asincrono dell'UpdatePanel che il browser esegue quando l'utente clicca Avanti.

Il campo nascosto CurrentViewName nella risposta wire ASP.NET viene usato come segnale autorevole per ciò che il server ha deciso, piuttosto che il matching di sottostringhe sul body HTML.

Classificazione dei metodi

L'email alternativa e le domande di sicurezza sono contrassegnate come deboli in quanto sono phishable e non soddisfano l'intento di un secondo fattore. Gli account con soli metodi deboli, o nessun metodo, vengono segnalati.

[!NOTE] Microsoft supporta sia token OATH software che token OATH hardware (anteprima) per SSPR. I token OATH software inseriti tramite l'app authenticator molto probabilmente emergono attraverso lo stesso pulsante AppCodeRadio del TOTP — entrambi si presentano come inserimento di un codice a sei cifre — quindi sono probabilmente già coperti senza un radio ID separato. I token OATH hardware (un portachiavi fisico) sono una classe di dispositivo distinta ma producono anch'essi un codice basato sul tempo; potrebbero essere renderizzati attraverso lo stesso pulsante o uno diverso che non è ancora stato osservato durante i test di questo processo.

Risultati

Ringraziamenti

• RedByte1337/CredSpy
• Il nostro piccolo Claude