mlcsec/resetspyEnumerar contas de usuário e métodos de autenticação registrados por meio do portal de Redefinição de Senha por Autoatendimento (SSPR) da Microsoft
Sonda o endpoint de Redefinição de Senha por Autoatendimento (SSPR) da Microsoft para enumerar métodos de verificação registrados e sinalizar quaisquer que não possuam um segundo fator forte. Fornece enumeração de usuários e uma aproximação da postura de MFA em contas do Entra.
[!NOTE] Em agosto de 2026, a Microsoft removeu o CAPTCHA legado do fluxo de SSPR e o substituiu por limitação de taxa no backend e detecção de abuso baseada em comportamento (consulte MC1400824). A posição da Microsoft é de que os controles de backend são suficientes para detectar e bloquear abuso automatizado.
# 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 .
python3 -m venv .venv
pip install -r requirements.txt
# 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
| Flag | Padrão | Descrição |
|---|---|---|
--delay SECONDS | 2.0 | Atraso base entre requisições; jitter adicionado automaticamente |
--retries N | 1 | Máximo de tentativas por conta em erros transitórios |
--proxy URL | Proxy; desabilita a verificação SSL automaticamente | |
--csv FILE | Exporta todos os resultados para CSV | |
-v / --verbose | Imprime cabeçalhos e corpos completos de requisição/resposta em stderr |
Um jitter aleatório é adicionado sobre o --delay entre cada requisição.
Back-off exponencial (até --retries tentativas) é aplicado em respostas
429 e erros de rede. O atraso padrão é de 2 segundos; aumente para
4-6 segundos em lotes grandes. O User-Agent é rotacionado a partir de um pool de 16
agentes comuns (Windows, macOS, iOS, Android) a cada requisição.
A experiência de registro combinado de informações de segurança da Microsoft, habilitada por padrão desde 2020, registra métodos de autenticação para SSPR e MFA em um único fluxo. Na prática, isso significa que na maioria dos tenants modernos do Entra ID, os métodos visíveis através do SSPR são os mesmos métodos que protegem o login. Uma conta sem nenhum método forte de SSPR registrado é muito provavelmente uma conta sem nenhum método forte de MFA registrado.
Referências:
SSPR e MFA são registros separados. O registro combinado faz com que eles se sobreponham na maioria dos casos, mas não são a mesma coisa. Um método pode existir para MFA sem ser visível aqui se foi registrado antes do registro combinado ser habilitado, ou se o administrador o excluiu da política de SSPR.
Chaves de segurança FIDO2 e autenticação baseada em certificado não são suportadas pelo SSPR. A Microsoft nunca adicionou esses métodos ao fluxo de SSPR. Um usuário cujo único fator registrado é uma chave FIDO2 ou smart card aparecerá aqui como não tendo métodos — um falso negativo. Na prática, isso é raro para usuários padrão, mas mais comum em ambientes de alta segurança ou sem senha.
Referências:
Incompatibilidades de política por método. Administradores podem permitir um método para login com MFA, mas excluí-lo da política de SSPR, ou vice-versa. Por exemplo, uma organização pode permitir push do autenticador para login, mas não para redefinição de senha. A ferramenta só vê o que o SSPR está disposto a oferecer.
SSPR totalmente desabilitado (SSPR_0011). Se o SSPR não estiver licenciado ou não estiver
habilitado para um usuário, o endpoint retorna ViewSsprNotEnabledInUserPolicy
e nenhuma informação de método está disponível. A conta existe e provavelmente tem MFA
configurado, mas esta ferramenta não consegue determinar o quê.
Contas convidadas e federadas. Usuários externos e convidados B2B autenticam
através de seu tenant de origem. O endpoint de SSPR do tenant de recurso não tem
visibilidade sobre o registro de MFA do tenant de origem e retorna
ViewFeatureNotAvailable. A postura de MFA deles é invisível a partir deste endpoint.
Restrições de método em todo o tenant. Se um administrador desabilitou uma classe de método na política de SSPR, ela não será oferecida a nenhum usuário, independentemente do registro individual, tornando impossível distinguir "método não registrado" de "método desabilitado".
Contas de administrador estão sempre com SSPR habilitado. As configurações de política de SSPR da Microsoft aplicam-se apenas a usuários finais padrão. Contas de administrador estão sempre habilitadas para redefinição de senha por autoatendimento, independentemente da política de SSPR do tenant, e a Microsoft exige que elas tenham dois métodos de autenticação registrados. Isso é imposto no nível da plataforma e não pode ser desabilitado por administradores do tenant.
Referência: SSPR policy documentation
[!IMPORTANT] Isso tem uma implicação útil para reconhecimento. Se o SSPR estiver desabilitado para usuários padrão em um tenant (retornando
ViewSsprNotEnabledInUserPolicy), qualquer conta que alcance com sucesso a tela de seleção de método é provavelmente um membro de uma função privilegiada. Contas que enumeram de forma limpa via SSPR quando a política mais ampla do tenant está desabilitada destacam-se como prováveis contas de administrador, e seus métodos registrados são visíveis mesmo quando os métodos de usuários padrão não são. Isso permite a identificação de alvos de alto valor e contas privilegiadas que podem ser destacadas para ataques direcionados adicionais.