ResetSpy

Sonda l'endpoint Self-Service Password Reset (SSPR) di Microsoft per enumerare i metodi di verifica registrati e segnalare quelli che mancano di un secondo fattore forte. Fornisce l'enumerazione degli utenti e un'approssimazione della postura MFA sugli account Entra.

[!NOTE] Ad agosto 2026, Microsoft ha rimosso il CAPTCHA legacy dal flusso SSPR e lo ha sostituito con throttling lato backend e rilevamento degli abusi basato sul comportamento (vedi MC1400824). La posizione di Microsoft è che i controlli lato backend sono sufficienti per rilevare e bloccare gli abusi automatizzati.

Indice

• Installazione
  • pipx
  • pip
• Utilizzo
  • Esempi
  • Opzioni
  • Rate Limiting
• Precisione e limitazioni
  • TL;DR
  • Perché i risultati SSPR sono un proxy ragionevole per l'MFA
  • Limitazioni note
  • Riepilogo delle capacità
• Come funziona
  • TL;DR
  • Classificazione dei metodi
  • Risultati
• Ringraziamenti

Installazione

pipx

# Install pipx if needed
apt install pipx && pipx ensurepath

# From a local clone
git clone https://github.com/mlcsec/ResetSpy.git
cd ResetSpy
pipx install .

pip

python3 -m venv .venv
pip install -r requirements.txt

Esempi

# Single acc
resetspy [email protected]

# Email file (one per line)
resetspy emails.txt

# Proxy
resetspy emails.txt --proxy http://127.0.0.1:8080

# Export to CSV with increased delay
resetspy emails.txt --csv results.csv --delay 4

# Full HTTP debug — request/response headers and bodies printed to stderr
resetspy [email protected] -v

Opzioni

Flag	Default	Descrizione
--delay SECONDS	2.0	Ritardo base tra le richieste; il jitter viene aggiunto automaticamente
--retries N	1	Numero massimo di tentativi per account in caso di errori transitori
--proxy URL		Proxy; disabilita automaticamente la verifica SSL
--csv FILE		Esporta tutti i risultati in CSV
-v / --verbose		Stampa gli header e i body completi di richiesta/risposta su stderr

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