Exemple de chronologie d'incident Okta (cas fictif)

TL;DR. Tout dans cet article est fictif : l'organisation, les personnes, les adresses IP (plages de documentation), les numéros d'AS (plage de documentation) et les domaines (.example). C'est l'exemple derrière le bouton Essayer un exemple de l'analyseur : 160 événements du System Log sur deux jours, pendant lesquels un attaquant convainc le helpdesk de réinitialiser le mot de passe et les facteurs d'un admin informatique, enrôle son propre Okta Verify depuis un VPS, attribue le rôle Super Administrator à un compte de service, ajoute un fournisseur d'identité entrant et s'en sert pour atteindre AWS. Le verdict de l'analyseur est Compromission probable, avec un constat critique et cinq constats élevés. Cette démonstration montre comment le lire.

Le décor fictif

« Northwind Logistics » (northwind.example) gère une petite organisation Okta : douze comptes, un réseau de bureau à Lyon, quelques télétravailleurs, et des applications comme Slack, Salesforce, Google Workspace, Jira et AWS IAM Identity Center. Trois comptes comptent :

Réseaux : le bureau (198.51.100.10, « Example Telecom », AS64496), le haut débit résidentiel (192.0.2.x, AS64497), et le VPS de l'attaquant (203.0.113.77, « Example VPS Hosting Ltd », AS64511, Amsterdam).

Le 14 septembre et la matinée du 15 sont des journées de travail ordinaires : connexions par mot de passe, push Okta Verify, SSO vers les applications, un mot de passe mal saisi de temps en temps.

L'intrusion, événement par événement (2026-09-15, UTC)

Lisez-le comme une histoire : à 14:03, le helpdesk réinitialise le mot de passe et les facteurs de Maya (un appelant s'est fait passer pour elle). Six minutes plus tard, « Maya » se connecte depuis un VPS néerlandais qu'elle n'a jamais utilisé, enrôle un nouvel Okta Verify et, moins de dix minutes après, se trouve dans l'Admin Console. Elle fait d'un compte de service un Super Administrator, crée et active un fournisseur d'identité entrant, puis se connecte en tant que compte de service grâce à lui. Les deux identités ouvrent AWS. À 15:41, la vraie Maya, de retour en ligne chez elle, ne peut plus se connecter : son mot de passe a été changé.

C'est le schéma décrit dans l'article sur l'ingénierie sociale du helpdesk et dans l'article sur la cross-tenant impersonation, condensé en 33 minutes.

Ce que signale l'analyseur

Verdict : Compromission probable. Statistiques : 160 événements, 12 utilisateurs, 5 adresses IP, 24 sessions, du 2026-09-14 07:56 au 2026-09-15 15:41 UTC.

Le constat critique suffirait à lui seul pour le verdict Compromission probable ; quatre règles élevées distinctes le rendent sans ambiguïté.

Deux détails à remarquer :

• La connexion via l'IdP n'est pas un constat distinct. user.authentication.auth_via_IDP est normal dans les organisations qui utilisent la fédération. Elle ressort ici via la règle sur les hébergeurs et via la règle de SSO après activité suspecte, parce que svc-sync était la cible de l'octroi Super Administrator. Dans un cas réel, listez à la main chaque auth_via_IDP passé par un nouvel IdP.
• Les échecs de connexion de la victime ne sont pas non plus un constat. Deux échecs, c'est du bruit normal. Ils figurent tout de même dans la chronologie et, dans un cas réel, c'est le moment où l'utilisatrice s'aperçoit du problème ; demandez-lui quand elle a appelé le helpdesk.

Le traiter dans l'interface

1. Onglet Constats. Ouvrez les preuves du constat critique : trois événements (réinitialisation du mot de passe, réinitialisation des facteurs, activation du facteur). L'acteur des deux premiers est h.lambert, celui du troisième m.okafor depuis 203.0.113.77.
2. Chronologie de l'incident. Les preuves de chaque constat moyen ou plus, plus les actions d'administration des comptes concernés, dans l'ordre : en substance le tableau ci-dessus, construit pour vous.
3. Entités → adresses IP. 203.0.113.77 (AS64511, Pays-Bas) a des événements pour deux utilisateurs, m.okafor et svc-sync. Cliquez sur Événements pour voir tout ce qu'a fait cette IP.
4. Entités → sessions. La session de l'attaquant pour m.okafor contient l'enrôlement, l'accès à l'Admin Console, l'octroi et la création de l'IdP : une session, toute l'attaque.
5. Remédiation. Préserver les journaux ; supprimer les sessions ; revoir les admins ; durcir la vérification au helpdesk ; réinitialiser facteurs et mot de passe ; enquêter sur AWS et y révoquer les sessions ; révoquer l'octroi Super Administrator ; supprimer l'IdP et revoir les règles de routage ; bloquer les hébergeurs à la connexion ; contacter l'utilisatrice ; escalader vers la réponse à incident.

Ce que ferait ensuite une équipe de réponse

• Confiner dans Okta : supprimer « Partner SSO », révoquer le rôle d'admin de svc-sync, supprimer les sessions des deux comptes, réenrôler Maya en personne.
• Suivre dans AWS : les deux identités ont atteint AWS IAM Identity Center à 14:35–14:36 depuis 203.0.113.77. CloudTrail devient la source principale ; AWS Forensics le lit de la même façon.
• Fermer le point d'entrée : établir comment le helpdesk a vérifié l'appelant à 14:03, et changer la procédure pour les réinitialisations d'administrateurs.

À vous d'essayer

Ouvrez l'analyseur, cliquez sur Essayer un exemple et suivez les étapes ci-dessus. Lisez ensuite le guide d'analyse pas à pas pour faire de même avec votre propre export, ou le guide d'investigation pour la méthode.

L'exemple est généré par un script du projet (scripts/make-samples.py) qui suit le schéma LogEvent du System Log décrit dans la documentation développeur d'Okta et utilise des eventTypes du catalogue des event types. Ses adresses IP proviennent des plages de documentation de la RFC 5737 et ses numéros d'AS de la plage de documentation de la RFC 5398 : rien n'y renvoie à un réseau réel.