Investigation d'une compromission Okta : le guide
Enquêter sur une compromission Okta depuis le System Log : périmètre, eventTypes utiles, chaîne d'attaque étape par étape et ce qu'il faut confiner en premier.
TL;DR. Une compromission Okta laisse presque toujours une trace lisible dans le System Log : une réinitialisation ou une avalanche de demandes MFA, une connexion depuis un réseau que l'utilisateur n'a jamais utilisé, un nouveau facteur, puis des actions d'administration (rôles, jetons d'API, fournisseurs d'identité) et du SSO vers les applications qui comptent. Exportez au minimum les 90 jours de rétention, lisez-les comme une séquence plutôt que comme des alertes isolées, confinez dans l'ordre sessions → facteurs → droits d'admin → jetons et IdP → applications en aval, et enquêtez sur chaque application ouverte par l'attaquant dans ses propres journaux. L'analyseur gratuit Okta Forensics fait la corrélation dans votre navigateur, sans rien téléverser.
J'ai lu beaucoup de chronologies d'incidents d'identité, et le schéma est d'une régularité presque ennuyeuse : l'attaquant n'exploite aucune faille du fournisseur d'identité. Il obtient d'une personne, ou d'un agent du support, qu'elle lui ouvre la porte, puis il utilise les fonctions d'administration exactement comme prévu. C'est une bonne nouvelle pour les équipes de réponse, car ce qui est prévu est journalisé. Ce guide décrit ma méthode ; le reste de la série « Enquêter sur un tenant Okta » détaille chaque étape.
Étape 0 : poser les questions
Écrivez-les avant d'ouvrir la moindre ligne de log. Une enquête de compromission doit répondre à cinq questions :
- Accès initial. Quel compte a été pris en premier, quand et comment (devinette de mot de passe, fatigue MFA, réinitialisation par le support, session volée) ?
- Privilèges. L'attaquant a-t-il atteint un administrateur, ou s'est-il attribué des droits d'admin ?
- Persistance. Qu'a-t-il laissé derrière lui : admins supplémentaires, jetons d'API, nouveau fournisseur d'identité, politiques affaiblies ?
- Portée. Quelles applications en aval a-t-il ouvertes en SSO ?
- État du confinement. L'un de ces éléments est-il encore actif en ce moment ?
Tout ce qui suit répond à l'une de ces questions.
Étape 1 : récupérer tout le journal, pas une vue filtrée
L'API System Log ne renvoie que 90 jours de données, comme l'indique le guide de requêtage du System Log d'Okta. Lancez l'export maintenant, avant que les preuves n'expirent, et prenez toute l'organisation plutôt qu'une recherche sur un utilisateur : la plupart des corrélations utiles (une réinitialisation faite par quelqu'un d'autre, un rôle d'admin accordé à un autre compte) se trouvent dans des événements où votre suspect est la cible, pas l'acteur.
Le guide d'export du System Log couvre l'API, le CSV de l'Admin Console, le Log Streaming et les exports SIEM, y compris le piège de pagination qui fait disparaître des événements sans bruit.
Étape 2 : connaître la chaîne d'attaque recherchée
Cette chaîne n'a rien de théorique. En août 2023, Okta Security a décrit des attaquants qui appelaient des services d'assistance informatique pour faire réinitialiser les facteurs d'utilisateurs privilégiés, utilisaient l'accès Super Administrator obtenu pour accorder des privilèges à d'autres comptes, et configuraient un second fournisseur d'identité pour se connecter en tant que d'autres utilisateurs (Okta Security, cross-tenant impersonation). L'avis conjoint CISA/FBI sur Scattered Spider décrit les mêmes familles de techniques, dont l'usurpation d'identité auprès du support et les demandes MFA répétées (CISA AA23-320A).
Chaque étape correspond à une courte liste d'eventTypes :
| Étape | Ce qui se passe | eventTypes clés | Approfondir |
|---|---|---|---|
| Accès initial | Rafale de push, réinitialisation par le support, spraying, cookie volé | system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push, user.mfa.factor.reset_all, user.session.start (FAILURE) | fatigue MFA, réinitialisations par le support, spraying, détournement de session |
| Tête de pont | L'attaquant enrôle son propre facteur | user.mfa.factor.activate | réinitialisations par le support |
| Accès admin | Ouverture de l'Admin Console | user.session.access_admin_app | abus d'admin |
| Privilèges et persistance | Rôles, jetons, politiques | user.account.privilege.grant, group.privilege.grant, system.api_token.create, policy.lifecycle.deactivate | abus d'admin |
| Porte dérobée de fédération | Nouvel IdP entrant, connexion via celui-ci | system.idp.lifecycle.create, user.authentication.auth_via_IDP | cross-tenant impersonation |
| Portée | SSO vers AWS, Microsoft 365, GitHub… | user.authentication.sso | ce guide, étape 6 |
La table complète se trouve dans les eventTypes réellement utiles en réponse à incident.
Étape 3 : trouver le patient zéro
Partez des signaux les plus forts :
- Réinitialisations faites par quelqu'un d'autre. Filtrez
user.mfa.factor.reset_all,user.mfa.factor.deactivateetuser.account.reset_passwordquand l'acteur diffère de la cible. Cherchez ensuite unuser.mfa.factor.activatede la cible peu après. Si cet enrôlement vient d'un réseau que l'utilisateur n'avait jamais utilisé, vous tenez probablement votre point d'entrée. - Rafales de push. Plusieurs demandes push ou refus pour un même utilisateur en quelques minutes, surtout si l'une finit par être acceptée.
- Des échecs de connexion sur de nombreux utilisateurs depuis une même IP, suivis d'un succès.
- Une session, plusieurs réseaux. Le même externalSessionId vu depuis deux ASN est la trace classique d'un cookie de session rejoué.
- L'origine de la connexion.
securityContext.asOrg,securityContext.isProxyetdebugContext.debugData.tunnelsindiquent si la source est un hébergeur, un proxy ou Tor. Les salariés se connectent rarement depuis un VPS.
Étape 4 : suivre la piste d'administration
Une fois le compte compromis identifié, pivotez sur lui en tant qu'acteur. Listez tout ce qu'il a fait en tant qu'administrateur entre sa première connexion suspecte et maintenant : octrois de rôles (debugContext.debugData.privilegeGranted indique lequel), jetons d'API, fournisseurs d'identité, règles de routage, modifications de politiques et d'authentificateurs, zones réseau, réglages ThreatInsight. Répétez ensuite le pivot pour chaque compte qu'il a touché : un admin fraîchement promu ou un compte de service qui se connecte via un nouvel IdP, c'est la seconde identité de l'attaquant qu'il ne faut pas manquer.
Étape 5 : construire la chronologie
Une chronologie défendable compte une ligne par événement, en UTC, avec acteur, cible, IP source et ASN, session et résultat. Conservez l'uuid brut de chaque événement pour que n'importe qui puisse confronter votre lecture au journal d'origine. La démonstration sur un incident fictif montre à quoi cela ressemble sur une intrusion complète, bien qu'inventée.
Étape 6 : suivre l'attaquant dans les applications
user.authentication.sso vous dit quelles applications ont été ouvertes, quand et d'où, mais rien de ce qui y a été fait. Le journal d'audit de l'application est l'étape suivante. Les sessions dans ces applications survivent aussi à la session Okta : tuer la session Okta ne déconnecte pas l'attaquant de celles-ci. Pour AWS, la source est CloudTrail ; l'outil frère AWS Forensics le lit comme ce site lit le System Log. Pour Microsoft 365 et Entra ID, M365 Forensics fait de même.
Étape 7 : confiner dans le bon ordre
L'ordre compte, car certaines positions de l'attaquant survivent à la suppression des autres :
- Préservez l'export avant de modifier quoi que ce soit.
- Supprimez les sessions des utilisateurs concernés et révoquez leurs jetons.
- Réinitialisez facteurs et mots de passe, en réenrôlant le vrai utilisateur par un canal vérifié.
- Retirez les rôles d'admin inattendus, en commençant par Super Administrator.
- Révoquez les jetons d'API créés pendant l'incident : un jeton d'API porte les permissions de son créateur et ne dépend pas de son mot de passe.
- Désactivez les fournisseurs d'identité inconnus et revoyez les règles de routage.
- Restaurez les politiques, les authentificateurs et les réglages de sécurité.
- Révoquez les sessions dans les applications en aval et enquêtez dessus.
Les recommandations d'Okta pour la campagne de 2023 ajoutent un durcissement à inscrire au plan post-incident : authentificateurs résistants au phishing, vérification plus stricte par le support, et réauthentification pour les actions d'administration sensibles (Okta Security).
Le faire avec l'analyseur
Tout ce qui précède peut se faire à la main dans un SIEM ou un tableur. L'analyseur Okta Forensics automatise la corrélation : déposez l'export, il applique 25 règles de détection (seuils, séquences et conditions de suivi) à chaque événement et produit un verdict (Aucun signe de compromission, Activité suspecte ou Compromission probable) avec ses raisons, une chronologie, un pivot par entité et une checklist de remédiation classée par urgence. Tout tourne localement en WebAssembly ; les journaux ne quittent jamais votre machine. Le guide pas à pas présente chaque écran.
FAQ
Jusqu'où peut-on remonter dans Okta ?
L'API System Log renvoie 90 jours d'événements. Au-delà, il ne reste que ce qui a été streamé ou exporté vers un SIEM ou un stockage avant expiration.
Quel compte regarder en premier ?
Les administrateurs, puis tout compte dont le mot de passe ou les facteurs ont été réinitialisés par quelqu'un d'autre, puis les comptes connectés depuis un hébergeur ou un anonymiseur. Cet ordre suit la progression des attaques d'identité récentes.
Un résultat propre prouve-t-il que le tenant est sain ?
Non. Il ne couvre que les événements présents dans l'export. Vérifiez la période, vérifiez que l'export n'était pas filtré, et confirmez auprès des personnes concernées. Le guide des limites et du réglage liste les angles morts.