Instalação

pipx

pip

Exemplos

Opções

Limitação de taxa

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.

Precisão e Limitações

TL;DR

• A enumeração de métodos de SSPR é um proxy razoável para a postura de MFA na maioria dos tenants modernos do Entra ID devido ao registro combinado
• Não detectará chaves FIDO2, autenticação baseada em certificado ou métodos em contas convidadas/federadas
• Contas onde o SSPR está desabilitado são confirmadas como existentes, mas seus métodos são desconhecidos
• Esta não é uma auditoria definitiva de MFA — entenda o que ela vê e o que não vê antes de confiar na saída

Por que os resultados de SSPR são um proxy razoável de MFA

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:

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

Limitações conhecidas

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:

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

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.

Resumo do que a ferramenta fornece e não fornece

Como funciona

TL;DR

• Duas requisições por alvo: um GET para obter tokens de sessão, depois um POST replicando o envio assíncrono de formulário do navegador
• O campo de resposta CurrentViewName do servidor é usado como a verdade absoluta para o resultado — não a correspondência no corpo HTML
• O User-Agent é rotacionado por requisição a partir de um pool de 16 strings realistas de navegador
• Jitter e back-off exponencial são aplicados automaticamente para evitar limitação de taxa

Visão geral

O portal de SSPR da Microsoft (passwordreset.microsoftonline.com) mostra uma tela de seleção de método de contato (MultigateAuthenticationControl) após aceitar um nome de usuário válido. O HTML retornado lista cada método de verificação registrado como um botão de rádio em MultigateAuthenticationControl_RadioTable. Métodos cuja linha <tr> é display:none não estão registrados para aquele usuário e são ignorados.

Para cada alvo, a ferramenta realiza duas requisições. Primeiro, um GET para a página de destino para estabelecer uma sessão e extrair os tokens de formulário ASP.NET (__VIEWSTATE, __EVENTVALIDATION, WorkflowConsistencyCheck) que são necessários para que o servidor aceite um POST. Esses tokens são criptograficamente vinculados ao cookie de sessão e não podem ser previstos ou reutilizados entre sessões. Segundo, um POST que envia o endereço de e-mail junto com esses tokens, replicando o postback assíncrono do UpdatePanel que o navegador realiza quando o usuário clica em Avançar.

O campo oculto CurrentViewName na resposta de rede ASP.NET é usado como o sinal autoritativo para o que o servidor decidiu, em vez de correspondência de substring no corpo HTML.

Classificação de métodos

E-mail alternativo e perguntas de segurança são sinalizados como fracos, pois são suscetíveis a phishing e não satisfazem a intenção de um segundo fator. Contas com apenas métodos fracos, ou sem nenhum método, são sinalizadas.

[!NOTE] A Microsoft suporta tanto tokens OATH de software quanto tokens OATH de hardware (pré-visualização) para SSPR. Tokens OATH de software inseridos via aplicativo autenticador provavelmente aparecem através do mesmo botão AppCodeRadio que o TOTP — ambos se apresentam como entrada de código de seis dígitos — então provavelmente já estão cobertos sem um ID de rádio separado. Tokens OATH de hardware (um chaveiro físico) são uma classe de dispositivo distinta, mas também produzem um código baseado em tempo; eles podem ser renderizados através do mesmo botão ou de um diferente que ainda não foi observado durante os testes deste processo.

Resultados

Agradecimentos

• RedByte1337/CredSpy
• Nosso filho Claude