Installation

pipx

pip

Exemples

Options

Limitation de débit

Un jitter aléatoire est ajouté par-dessus --delay entre chaque requête. Un back-off exponentiel (jusqu'à --retries tentatives) est appliqué sur les réponses 429 et les erreurs réseau. Le délai par défaut est de 2 secondes ; augmentez-le à 4-6 secondes pour les lots importants. Le User-Agent est alterné à partir d'un pool de 16 agents courants (Windows, macOS, iOS, Android) à chaque requête.

Précision et limites

TL;DR

• L'énumération des méthodes SSPR est un proxy raisonnable pour la posture MFA sur la plupart des locataires Entra ID modernes en raison de l'enregistrement combiné
• Ne détectera pas les clés FIDO2, l'authentification par certificat, ni les méthodes sur les comptes invités/fédérés
• Les comptes pour lesquels SSPR est désactivé sont confirmés comme existants mais leurs méthodes sont inconnues
• Ce n'est pas un audit MFA définitif — comprenez ce qu'il voit et ne voit pas avant de vous fier à la sortie

Pourquoi les résultats SSPR constituent un proxy MFA raisonnable

L'expérience d'enregistrement combiné des informations de sécurité de Microsoft, activée par défaut depuis 2020, enregistre les méthodes d'authentification pour SSPR et MFA dans un seul flux. En pratique, cela signifie que sur la plupart des locataires Entra ID modernes, les méthodes visibles via SSPR sont les mêmes méthodes qui protègent la connexion. Un compte sans méthode SSPR forte enregistrée est très probablement un compte sans méthode MFA forte enregistrée.

Références :

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

Lacunes connues

SSPR et MFA sont des registres distincts. L'enregistrement combiné les fait se chevaucher dans la plupart des cas, mais ce ne sont pas la même chose. Une méthode peut exister pour MFA sans être visible ici si elle a été enregistrée avant que l'enregistrement combiné ne soit activé, ou si l'administrateur l'a exclue de la politique SSPR.

Les clés de sécurité FIDO2 et l'authentification par certificat ne sont pas prises en charge par SSPR. Microsoft n'a jamais ajouté ces méthodes au flux SSPR. Un utilisateur dont le seul facteur enregistré est une clé FIDO2 ou une carte à puce apparaîtra ici comme n'ayant aucune méthode — un faux négatif. En pratique, c'est rare pour les utilisateurs standard mais plus courant dans les environnements à haute sécurité ou sans mot de passe.

Références :

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

Incohérences de politique par méthode. Les administrateurs peuvent autoriser une méthode pour la connexion MFA mais l'exclure de la politique SSPR, ou inversement. Par exemple, une organisation pourrait autoriser la notification push de l'authentificateur pour la connexion mais pas pour la réinitialisation du mot de passe. L'outil ne voit que ce que SSPR est prêt à proposer.

SSPR entièrement désactivé (SSPR_0011). Si SSPR n'est pas sous licence ou pas activé pour un utilisateur, le point de terminaison renvoie ViewSsprNotEnabledInUserPolicy et aucune information de méthode n'est disponible. Le compte existe et a probablement MFA configuré, mais cet outil ne peut pas déterminer quoi.

Comptes invités et fédérés. Les utilisateurs externes et les invités B2B s'authentifient via leur locataire d'origine. Le point de terminaison SSPR du locataire de ressource n'a aucune visibilité sur l'enregistrement MFA du locataire d'origine et renvoie ViewFeatureNotAvailable. Leur posture MFA est invisible depuis ce point de terminaison.

Restrictions de méthode à l'échelle du locataire. Si un administrateur a désactivé une classe de méthode dans la politique SSPR, elle ne sera proposée à aucun utilisateur, indépendamment de l'enregistrement individuel, ce qui rend impossible de distinguer « méthode non enregistrée » de « méthode désactivée ».

Les comptes administrateur sont toujours SSPR-activés. Les paramètres de politique SSPR de Microsoft ne s'appliquent qu'aux utilisateurs finaux standard. Les comptes administrateur sont toujours activés pour la réinitialisation de mot de passe en libre-service, indépendamment de la politique SSPR du locataire, et Microsoft exige qu'ils aient deux méthodes d'authentification enregistrées. Cela est appliqué au niveau de la plateforme et ne peut pas être désactivé par les administrateurs du locataire.

Référence : SSPR policy documentation

[!IMPORTANT] Cela a une implication utile pour la reconnaissance. Si SSPR est désactivé pour les utilisateurs standard dans un locataire (renvoyant ViewSsprNotEnabledInUserPolicy), tout compte qui atteint avec succès l'écran de sélection de méthode est probablement un membre d'un rôle privilégié. Les comptes qui s'énumèrent proprement via SSPR lorsque la politique plus large du locataire est désactivée ressortent comme des comptes administrateur probables, et leurs méthodes enregistrées sont visibles même lorsque les méthodes des utilisateurs standard ne le sont pas. Cela permet d'identifier des cibles de grande valeur et des comptes privilégiés pouvant être isolés pour d'autres attaques ciblées.

Résumé de ce que l'outil fournit et ne fournit pas

Fonctionnement

TL;DR

• Deux requêtes par cible : un GET pour obtenir les jetons de session, puis un POST répliquant la soumission de formulaire asynchrone du navigateur
• Le champ de réponse CurrentViewName du serveur est utilisé comme source de vérité pour le résultat — pas la correspondance sur le corps HTML
• Le User-Agent est alterné à chaque requête à partir d'un pool de 16 chaînes de navigateur réalistes
• Le jitter et le back-off exponentiel sont appliqués automatiquement pour éviter la limitation de débit

Vue d'ensemble

Le portail SSPR de Microsoft (passwordreset.microsoftonline.com) affiche un écran de sélection de méthode de contact (MultigateAuthenticationControl) après avoir accepté un nom d'utilisateur valide. Le HTML renvoyé liste chaque méthode de vérification enregistrée sous forme de bouton radio dans MultigateAuthenticationControl_RadioTable. Les méthodes dont la ligne <tr> est en display:none ne sont pas enregistrées pour cet utilisateur et sont ignorées.

Pour chaque cible, l'outil effectue deux requêtes. D'abord, un GET vers la page d'atterrissage pour établir une session et extraire les jetons de formulaire ASP.NET (__VIEWSTATE, __EVENTVALIDATION, WorkflowConsistencyCheck) qui sont requis pour que le serveur accepte un POST. Ces jetons sont cryptographiquement liés au cookie de session et ne peuvent pas être prédits ni réutilisés entre les sessions. Ensuite, un POST qui soumet l'adresse e-mail avec ces jetons, répliquant le postback asynchrone UpdatePanel que le navigateur effectue lorsque l'utilisateur clique sur Next.

Le champ caché CurrentViewName dans la réponse wire ASP.NET est utilisé comme signal faisant autorité pour ce que le serveur a décidé, plutôt que la correspondance de sous-chaînes sur le corps HTML.

Classification des méthodes

L'e-mail alternatif et les questions de sécurité sont signalés comme faibles car ils sont phishables et ne satisfont pas l'intention d'un second facteur. Les comptes avec uniquement des méthodes faibles, ou aucune méthode du tout, sont signalés.

[!NOTE] Microsoft prend en charge à la fois les jetons OATH logiciels et les jetons OATH matériels (aperçu) pour SSPR. Les jetons OATH logiciels saisis via l'application d'authentification apparaissent très probablement via le même bouton AppCodeRadio que le TOTP — les deux se présentent comme une saisie de code à six chiffres — ils sont donc probablement déjà couverts sans identifiant radio distinct. Les jetons OATH matériels (un porte-clés physique) sont une classe d'appareil distincte mais produisent aussi un code basé sur le temps ; ils peuvent s'afficher via le même bouton ou un autre qui n'a pas encore été observé lors des tests de ce processus.

Résultats

Remerciements

• RedByte1337/CredSpy
• Notre petit Claude