Instalación

pipx

pip

Ejemplos

Opciones

Limitación de velocidad

Se añade un jitter aleatorio sobre --delay entre cada solicitud. Se aplica retroceso exponencial (hasta --retries intentos) en respuestas 429 y errores de red. El retardo predeterminado es de 2 segundos; auméntalo a 4-6 segundos para lotes grandes. El User-Agent se rota desde un grupo de 16 agentes comunes (Windows, macOS, iOS, Android) en cada solicitud.

Precisión y limitaciones

TL;DR

• La enumeración de métodos de SSPR es un proxy razonable de la postura de MFA en la mayoría de los inquilinos modernos de Entra ID debido al registro combinado
• No detectará claves FIDO2, autenticación basada en certificados ni métodos en cuentas de invitado/federadas
• Las cuentas en las que SSPR está deshabilitado se confirman como existentes, pero sus métodos son desconocidos
• Esto no es una auditoría definitiva de MFA — comprende qué ve y qué no ve antes de confiar en la salida

Por qué los resultados de SSPR son un proxy razonable de MFA

La experiencia de registro combinado de información de seguridad de Microsoft, habilitada de forma predeterminada desde 2020, registra métodos de autenticación tanto para SSPR como para MFA en un único flujo. En la práctica, esto significa que en la mayoría de los inquilinos modernos de Entra ID, los métodos visibles a través de SSPR son los mismos métodos que protegen el inicio de sesión. Una cuenta sin ningún método fuerte de SSPR registrado es muy probablemente una cuenta sin ningún método fuerte de MFA registrado.

Referencias:

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

Limitaciones conocidas

SSPR y MFA son registros separados. El registro combinado hace que se superpongan en la mayoría de los casos, pero no son lo mismo. Un método puede existir para MFA sin ser visible aquí si se registró antes de que se habilitara el registro combinado, o si el administrador lo excluyó de la política de SSPR.

Las claves de seguridad FIDO2 y la autenticación basada en certificados no son compatibles con SSPR. Microsoft nunca ha añadido estos métodos al flujo de SSPR. Un usuario cuyo único factor registrado sea una clave FIDO2 o una tarjeta inteligente aparecerá aquí como sin métodos — un falso negativo. En la práctica esto es raro para usuarios estándar, pero más común en entornos de alta seguridad o sin contraseña.

Referencias:

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

Discrepancias de política por método. Los administradores pueden permitir un método para el inicio de sesión con MFA pero excluirlo de la política de SSPR, o viceversa. Por ejemplo, una organización podría permitir la notificación push del autenticador para el inicio de sesión pero no para el restablecimiento de contraseña. La herramienta solo ve lo que SSPR está dispuesto a ofrecer.

SSPR deshabilitado por completo (SSPR_0011). Si SSPR no está licenciado o no está habilitado para un usuario, el endpoint devuelve ViewSsprNotEnabledInUserPolicy y no hay información de métodos disponible. La cuenta existe y probablemente tiene MFA configurado, pero esta herramienta no puede determinar qué.

Cuentas de invitado y federadas. Los usuarios externos y los invitados B2B se autentican a través de su inquilino de origen. El endpoint de SSPR del inquilino de recursos no tiene visibilidad sobre el registro de MFA de su inquilino de origen y devuelve ViewFeatureNotAvailable. Su postura de MFA es invisible desde este endpoint.

Restricciones de métodos a nivel de inquilino. Si un administrador ha deshabilitado una clase de método en la política de SSPR, no se ofrecerá a ningún usuario independientemente del registro individual, lo que hace imposible distinguir "método no registrado" de "método deshabilitado".

Las cuentas de administrador siempre tienen SSPR habilitado. La configuración de la política de SSPR de Microsoft se aplica solo a usuarios finales estándar. Las cuentas de administrador siempre están habilitadas para el restablecimiento de contraseña de autoservicio independientemente de la política de SSPR del inquilino, y Microsoft requiere que tengan dos métodos de autenticación registrados. Esto se aplica a nivel de plataforma y los administradores del inquilino no pueden deshabilitarlo.

Referencia: SSPR policy documentation

[!IMPORTANT] Esto tiene una implicación útil para el reconocimiento. Si SSPR está deshabilitado para usuarios estándar en un inquilino (devolviendo ViewSsprNotEnabledInUserPolicy), cualquier cuenta que llegue con éxito a la pantalla de selección de métodos es probablemente un miembro de un rol privilegiado. Las cuentas que se enumeran limpiamente vía SSPR cuando la política más amplia del inquilino está deshabilitada destacan como probables cuentas de administrador, y sus métodos registrados son visibles incluso cuando los métodos de usuarios estándar no lo son. Esto permite la identificación de objetivos de alto valor y cuentas privilegiadas que pueden ser señaladas para ataques dirigidos adicionales.

Resumen de lo que la herramienta proporciona y no proporciona

Cómo funciona

TL;DR

• Dos solicitudes por objetivo: un GET para obtener tokens de sesión, luego un POST que replica el envío de formulario asíncrono del navegador
• El campo de respuesta CurrentViewName del servidor se usa como la verdad fundamental para el resultado — no la coincidencia del cuerpo HTML
• El User-Agent se rota por solicitud desde un grupo de 16 cadenas de navegador realistas
• El jitter y el retroceso exponencial se aplican automáticamente para evitar la limitación de velocidad

Descripción general

El portal de SSPR de Microsoft (passwordreset.microsoftonline.com) muestra una pantalla de selección de método de contacto (MultigateAuthenticationControl) después de aceptar un nombre de usuario válido. El HTML devuelto lista cada método de verificación registrado como un botón de opción en MultigateAuthenticationControl_RadioTable. Los métodos cuya fila <tr> es display:none no están registrados para ese usuario y se omiten.

Para cada objetivo, la herramienta realiza dos solicitudes. Primero, un GET a la página de destino para establecer una sesión y extraer los tokens de formulario ASP.NET (__VIEWSTATE, __EVENTVALIDATION, WorkflowConsistencyCheck) que son necesarios para que el servidor acepte un POST. Estos tokens están criptográficamente vinculados a la cookie de sesión y no pueden predecirse ni reutilizarse entre sesiones. Segundo, un POST que envía la dirección de correo electrónico junto con esos tokens, replicando el postback asíncrono de UpdatePanel que realiza el navegador cuando el usuario hace clic en Siguiente.

El campo oculto CurrentViewName en la respuesta de red de ASP.NET se usa como la señal autoritativa de lo que decidió el servidor, en lugar de la coincidencia de subcadenas en el cuerpo HTML.

Clasificación de métodos

El correo electrónico alternativo y las preguntas de seguridad se marcan como débiles ya que son susceptibles de phishing y no satisfacen la intención de un segundo factor. Las cuentas con solo métodos débiles, o sin ningún método, se señalan.

[!NOTE] Microsoft admite tanto tokens OATH de software como tokens OATH de hardware (versión preliminar) para SSPR. Los tokens OATH de software introducidos a través de la aplicación de autenticación probablemente aparecen a través del mismo botón AppCodeRadio que TOTP — ambos se presentan como una entrada de código de seis dígitos — por lo que probablemente ya están cubiertos sin un ID de radio separado. Los tokens OATH de hardware (un llavero físico) son una clase de dispositivo distinta pero también producen un código basado en tiempo; pueden renderizarse a través del mismo botón u otro diferente que aún no se ha observado durante las pruebas de este proceso.

Resultados

Agradecimientos

• RedByte1337/CredSpy
• Nuestro hijo Claude