Token replay et session hijacking : aller au-delà du MFA

Introduction

Tu as activé le MFA résistant au phishing pour protéger les identités dans ton organisation. Pourtant, un attaquant parvient à voler une session utilisateur. Pourquoi cela se produit-il, et comment Microsoft propose-t-il des solutions pour ce type de menace spécifique ? Cet article explore le modèle de menace du vol de jeton (token replay) et les outils de sécurité avancés intégrés à Microsoft Entra ID pour y faire face.

Modèle de menace : fonctionnement du token theft

Le vol de token implique la capture de jetons de session authentifiés, permettant à un attaquant de se connecter sans nécessiter de mots de passe ou d'autres informations d'identification.

Techniques courantes utilisées

• Phishing relay AiTM (Attacks in the Middle) : Les attaquants interceptent les tokens via des proxys actifs dans des scénarios de phishing sophistiqués.
• Malware : Des logiciels malveillants installés sur l'appareil utilisateur peuvent extraire les tokens de session.
• Extensions de navigateur malveillantes : Certains plugins collectent et exfiltrent des données sensibles.

Contrôles Microsoft pour sécuriser les sessions

Face à ces menaces, Microsoft Entra ID offre plusieurs solutions pour renforcer la sécurité des sessions utilisateurs. Voici un aperçu des principaux contrôles :

Token Protection

Cette fonctionnalité attache un jeton d'accès à un appareil spécifique. Cela empêche les attaquants de réutiliser un token volé depuis un environnement non autorisé.

Contrôle de fréquence de connexion (sign-in frequency)

Grâce aux règles Conditional Access (CA), il est possible de demander une nouvelle authentification régulière pour limiter la durée de vie d'une session compromise.

Liaison avec la conformité des appareils

En combinant l'état des appareils via Microsoft Intune, les jetons peuvent être liés uniquement aux terminaux conformes aux politiques de sécurité définies.

Évaluation continue des sessions

Bien que le Continuous Access Evaluation (CAE) ait été couvert précédemment, cette approche complète le modèle Zero Trust en permettant une surveillance constante des sessions actives.

Détection des attaques dans les logs Entra

Les administrateurs peuvent collecter des signaux clés apportant des preuves d'activités suspectes. Voici quelques exemples de requêtes KQL pour Microsoft Sentinel.

Requête KQL pour le token replay

1SigninLogs
2| where ResultType == "50074" or ResultType == "50077"
3| where DeviceDetail != PreviousDeviceDetail
4| summarize LogCount = count() by UserPrincipalName, ResultType

Anomalies de session inhabituelle

1SigninLogs
2| where ResultType == "50125"
3| sort by Timestamp desc
4| summarize Count = count() by UserPrincipalName, IPAddress

Apparitions d’un token sur plusieurs adresses IP

1SigninLogs
2| where DeviceDetail contains "Browser"
3| summarize IPCluster = count() by IPAddress
4| where IPCluster > 1

Plan d'implémentation

Voici une méthodologie de mise en œuvre des contrôles décrits :

Checklist opérationnelle

Pour renforcer votre stratégie de gestion des sessions :

• Faire un audit complet des sessions via les journaux Entra.
• Activer Token Protection pour les utilisateurs à haut risque.
• Configurer la liaison des tokens aux appareils conformes.
• Déployer la surveillance Sentinel avec les requêtes KQL fournies.
• Appliquer des contrôles de fréquence de connexion via Conditional Access.
• Tester les politiques sur un groupe restreint avant un déploiement global.
• Former les équipes IT aux nouvelles détections et procédures.
• Réviser les politiques régulièrement en fonction des nouveaux indicateurs.

Pièges fréquents

Met en garde contre :

• Verrouillages imprévus : Surveillez attentivement les impacts de vos nouvelles règles sur les utilisateurs.
• Faux positifs : Réglez précisément vos détections pour éviter de ralentir vos processus.
• Applications non compatibles : Certaines anciennes solutions ne supportent pas les nouveaux mécanismes.

Plan 30/60/90 jours

Premier mois (30 jours)

• Configurer les journaux Entra pour collecter les données de sessions.
• Identifier les utilisateurs et les appareils à haut risque.
• Tester les politiques dans un environnement restreint.

Deuxième mois (60 jours)

• Déployer Token Protection sur les segments critiques.
• Activer les contrôles de fréquence de connexion via Conditional Access.
• Utiliser Sentinel pour surveiller les indicateurs d'anomalie.

Troisième mois (90 jours)

• Étendre les politiques à l'ensemble de votre organisation.
• Réaliser un audit complet des incidents et des faux positifs.
• Former tous les utilisateurs sur les nouvelles processus de sécurité.

Lien utiles

• Azure Conditional Access Documentation
• Microsoft Sentinel Logs Guide
• Token Protection Overview
• Zero Trust Implementation

Glossaire

• Token replay : Recyclage d'un jeton de session pour travailler dans un environnement non autorisé.
• Conditional Access : Contrôles définis dans Azure pour gérer les règles d'accès au moment de la connexion.
• Token Protection : Solution liant les jetons à des appareils spécifiques afin de limiter leur réutilisation.
• Zero Trust : Modèle de sécurité où aucun accès n'est implicitement accordé, et tout est continuellement vérifié.