Détournement de session Okta : repérer les cookies volés
Détecter un détournement de session Okta dans le System Log : un externalSessionId vu depuis plusieurs ASN ou navigateurs, itinérance, et bruit VPN ou mobile.
TL;DR. Un cookie de session Okta volé permet à l'attaquant de sauter entièrement le mot de passe et la MFA : il n'y a donc aucun échec de connexion à trouver. Ce que l'on peut trouver, c'est une session utilisée depuis deux endroits : le même authenticationContext.externalSessionId associé à deux valeurs différentes de securityContext.asNumber, ou à deux user agents différents, en quelques heures. Ajoutez les événements security.session.detect_client_roaming d'Okta, puis écartez les VPN d'entreprise et les téléphones qui passent du Wi-Fi aux données mobiles avant de conclure au vol.
Comment les sessions sont volées
Après une connexion réussie, le navigateur détient un cookie de session. Quiconque présente ce cookie est l'utilisateur jusqu'à la fin de la session. Okta Security décrit les deux façons courantes dont les cookies quittent la machine de la victime : des logiciels malveillants de type infostealer qui extraient les cookies du navigateur, et des sites d'hameçonnage adversary-in-the-middle qui relaient la vraie connexion et capturent la session obtenue (Okta Security : se défendre contre le détournement de session). MITRE ATT&CK répertorie le vol sous T1539, Steal Web Session Cookie et la réutilisation sous T1550.004, Web Session Cookie.
Les artefacts de session fuient aussi par des canaux moins évidents. Lors de l'incident d'octobre 2023 touchant le système de support d'Okta, un acteur malveillant a accédé à des fichiers joints à des tickets ; certains étaient des fichiers HAR contenant des jetons de session, utilisés pour détourner les sessions de cinq clients (Okta Security : cause racine et remédiation). Nettoyer les fichiers HAR avant de les partager est une leçon pour tous les processus de support, pas seulement celui d'Okta.
Les champs qui identifient une session
| Champ | Usage |
|---|---|
authenticationContext.externalSessionId | l'identifiant de session (externalSessionId) ; regroupez dessus |
authenticationContext.rootSessionId | la racine de la session interactive ; Okta Security note que externalSessionId peut être régénéré après des événements du cycle de vie des facteurs alors que la racine persiste (article rootSessionId) |
securityContext.asNumber, asOrg | le réseau (ASN) d'où vient la requête |
client.ipAddress | la source exacte |
client.userAgent.rawUserAgent | navigateur et système |
L'idée clé : les requêtes légitimes de la victime et les requêtes rejouées par l'attaquant partagent un identifiant de session, mais diffèrent par le réseau et, en général, par le navigateur.
Les signaux, du plus fort au plus faible
| Signal | Pourquoi c'est important | Règle de l'analyseur | Sévérité |
|---|---|---|---|
| Même session, 2 ASN ou plus en 12 h | le cookie est utilisé depuis un autre réseau | session.multi_asn | élevée |
| Même session, 2 user agents ou plus en 12 h | un autre navigateur détient le cookie | session.multi_user_agent | moyenne |
security.session.detect_client_roaming | Okta a lui-même signalé la session comme itinérante | session.roaming | moyenne |
| Activité de session depuis un hébergeur ou un anonymiseur | les attaquants rejouent depuis des VPS et des proxys | access.hosting_provider, access.anonymizer | moyenne |
| SSO vers des applications sensibles depuis le nouveau réseau | l'attaquant utilise ce qu'il a volé | app.sso_after_suspicious | élevée |
Sur les organisations Identity Engine, cherchez aussi user.session.context.change (le contexte de la session a assez changé pour justifier une réévaluation des politiques) et policy.auth_reevaluate.fail, tous deux listés dans le catalogue des event types d'Okta. L'analyseur ne les utilise pas encore comme détections ; le tableau des événements les affiche.
Dérouler une alerte
Supposons que l'analyseur signale « Session utilisée depuis plusieurs réseaux » pour a.user :
- Ouvrez les preuves et triez par date. Où la session a-t-elle commencé ? Le
user.session.start(et la MFA) devrait venir du réseau habituel de l'utilisateur. Les requêtes ultérieures depuis un second ASN sont le rejeu candidat. - Caractérisez le second réseau. Un
asOrgqui est un FAI résidentiel dans la ville de l'utilisateur, c'est probablement son propre téléphone ou son domicile. Un fournisseur cloud, un hébergeur de VPS, ou un pays où l'utilisateur n'est jamais allé, non. - Vérifiez le user agent. La même chaîne de navigateur sur les deux réseaux suggère un utilisateur qui se déplace ; un système ou un navigateur différent sur le second réseau suggère une copie du cookie.
- Listez ce qu'a fait le second réseau. Cibles SSO, actions d'administration, enrôlement de facteur. Un attaquant qui a détourné une session enrôle souvent un facteur ou crée un jeton pour persister au-delà de la durée de vie de la session.
- Vérifiez la machine de l'utilisateur. Un vol de cookie par infostealer signifie que le poste est compromis ; réinitialiser le mot de passe Okta ne le nettoie pas.
Les faux positifs que vous rencontrerez
- Des téléphones qui passent du Wi-Fi aux données mobiles. Deux ASN (le FAI du domicile et l'opérateur mobile) dans une session, même user agent. Très fréquent.
- Un VPN d'entreprise connecté en cours de session. La session démarre sur le FAI du domicile et continue depuis la sortie du VPN. Si votre VPN sort par un fournisseur cloud, cela déclenche aussi la règle sur les hébergeurs.
- Des proxys de sécurité et passerelles web qui sortent par leur propre ASN pour une partie du trafic seulement.
- Des mises à jour du navigateur pendant une longue session modifient la chaîne du user agent.
C'est pourquoi la règle multi-ASN produit un constat élevé, pas critique. L'article sur le réglage explique comment les traiter ; en bref, connaissez les ASN de sortie de votre VPN et vos opérateurs mobiles, et vérifiez-les en premier.
Confinement
- Supprimez les sessions de l'utilisateur et révoquez ses jetons : cela invalide le cookie volé dans Okta.
- Révoquez les sessions dans les applications en aval atteintes par l'attaquant. Elles sont indépendantes de celles d'Okta.
- Considérez le poste comme compromis si un infostealer est plausible : réinstallez-le, puis réinitialisez tous les identifiants utilisés dessus.
- Réinitialisez mot de passe et facteurs si l'attaquant a aussi enrôlé un facteur ou si vous ne pouvez pas exclure un vol d'identifiants.
Prévention
Les recommandations d'Okta Security contre le rejeu de cookies incluent la liaison des sessions d'administration au réseau (IP ou ASN), la réauthentification pour les ressources sensibles, des authentificateurs résistants au phishing (qui neutralisent l'hameçonnage adversary-in-the-middle), des exigences de gestion des appareils et des durées de session plus courtes là où les données sont sensibles (Okta Security). Après l'incident des fichiers HAR, Okta a aussi présenté une liaison des sessions d'administration à l'emplacement réseau comme amélioration du produit (article sur la cause racine).