Dans les recommandations Microsoft il est conseillé de bloquer le transfert d’authentification pour les comptes d’administration (Rôle) dans l’environnement ENTRAID. Avant de se lancer dans le blocage, essayons de comprendre tout d’abord la nature de l’attaque.

1        Le principe de base

Le “blocage du transfert d’authentification” implique le fait d’empêcher qu’une session d’authentification soit commencée sur un appareil et finalisée sur un autre.

Voici pour mieux comprendre un exemple typique :

• Un utilisateur (ou attaquant) lance une connexion sur un PC
• Le système lui demande de confirmer (MFA) sur un mobile
• La session est “transférée” entre appareils
•  

Le blocage consiste par conséquent à interdire ce mécanisme. Dans Entra ID, une authentification moderne est basée sur un flux OAuth (token) et sur contexte d’authentification (device, navigateur, session, IP…). Autrement dit Le “transfert d’authentification” consiste à décorréler le point de départ de la connexion et pour finir le point de validation

Description du principe de l’attaque dans le détail

1.1     Étape 1 – Initialisation par l’attaquant

L’attaquant Devil lance une authentification via une de ces interfaces

• Azure CLI (az login –use-device-code)
• Un script OAuth
• Une application

De ce fait Il appelle l’API Entra ID suivante : POST /devicecode

Entra ID retourne par conséquent les informations suivantes :

• device_code (secret côté attaquant) = identifiant de session caché
• user_code  (code visible utilisateur) = code de validation
• verification_uri  (URL Microsoft)

Ce qui est important de retenir ici c’est que la session est créée par l’attaquant et que protocole est concu permettre une authentification depuis un autre appareil. Par conséquent l’initialisation et la validation sont décorrélées

1.2     . Étape 2 – Social engineering

Passons maintenant à l’attaquant qui va envoyer un courriel, un teams voir un sms à notre utilisateur administrateur (joe) contenant le code user et l’URL Microsoft légitime (login.microsoftonline.com)

Notre utilisateur Administrateur joe constate une URL officielle (celle de Microsoft) et une page Microsoft. Pas d’erreur, pour Joe tout semble légitime. Pas de faux site et pas de vol de mot de passe

Joe valide donc le code et autorise la session en se rendant sur l’URL Microsoft , saisi le UserCode et s’authentifie (Connexion avec MFA)

D’un point de vue EntraID , un utilisateur légitime valide une demande d’accès et autorise la session

Joe pense qu’il valide une demande de connexion à son compte alors qu’il valide une connexion sur un autre périphérique. Le tour est joué

2        Bloquer le transfert d’authentification

Quand on interdit le transfert d’authentification , EntraID vérifie les trois données suivantes :

• La cohérence du périphérique
• La cohérence de la session
• L’ origine de la demande

Pour bloquer ce transfert, cela se fait directement depuis les règles d’accès conditionnels de ENTRAID

Concrètement il faut créer ou modifier une stratégie d’accès conditionnels qui s’applique à tout compte possédant un rôle dans l’environnement EntraID et activer la condition Authentication flows, puis choisir, Authentication transfer comme présenté ci dessous.

Puis bloquer l’accès