Abus du rôle Super Admin et des jetons d'API Okta
Repérer dans le System Log Okta les octrois de rôles d'admin, jetons d'API, politiques affaiblies et accès du support, puis retirer la persistance laissée.
TL;DR. Une fois qu'un attaquant tient un administrateur Okta, il s'assure de le garder : un second Super Administrator (user.account.privilege.grant avec debugData.privilegeGranted), un jeton d'API (system.api_token.create) qui survit aux réinitialisations de mot de passe et de MFA, et des défenses affaiblies (policy.*, security.authenticator.lifecycle.deactivate, zone.*). Listez chaque action d'administration du compte compromis depuis sa première connexion suspecte, puis celles de chaque compte qu'il a promu. Retirez jetons et rôles avant d'annoncer à qui que ce soit que l'incident est confiné.
Pourquoi la persistance admin compte plus que le point d'entrée
Le premier compte compromis est généralement repéré et réinitialisé. Ce que l'attaquant en a fait entre-temps, c'est ce qui lui permet de rester. Le compte rendu d'Okta Security sur la campagne de 2023 décrit des comptes Super Administrator compromis utilisés pour attribuer des privilèges plus élevés à d'autres comptes, réinitialiser les authentificateurs d'admins existants et, dans certains cas, retirer l'exigence de second facteur des politiques d'authentification (Okta Security). Chacune de ces actions est journalisée.
Techniques MITRE ATT&CK en jeu : T1098.003 Additional Cloud Roles, T1098.001 Additional Cloud Credentials, T1556.006 Multi-Factor Authentication (affaiblissement de la MFA).
Octrois de rôles d'admin
| eventType | Signification | Champ à lire |
|---|---|---|
user.account.privilege.grant | les privilèges d'admin d'un utilisateur ont changé | debugContext.debugData.privilegeGranted, target |
group.privilege.grant | un groupe a reçu des privilèges d'admin | puis vérifier qui est dans le groupe |
user.account.privilege.revoke | tous les privilèges d'admin d'un utilisateur retirés | qui a nettoyé, et quand |
user.session.access_admin_app | ouverture de l'Admin Console | premier accès admin depuis un nouveau réseau |
Le catalogue précise que user.account.privilege.grant contient la liste des privilèges actuels de l'utilisateur (event types). L'analyseur répartit les octrois en deux règles : Rôle Super administrateur attribué (élevée) quand privilegeGranted mentionne Super Administrator, et Rôle d'administration attribué (moyenne) pour tout autre rôle.
Ce qui rend un octroi suspect :
- le bénéficiaire est un compte de service ou un compte dormant avec lequel personne ne se connecte de façon interactive ;
- l'auteur s'est connecté quelques minutes plus tôt depuis un nouveau réseau ou après une réinitialisation de facteurs ;
- l'octroi a lieu hors de votre processus de changement (pas de ticket, heure inhabituelle pour cet admin) ;
- un groupe reçoit des droits d'admin, puis quelqu'un y est ajouté.
Jetons d'API
La documentation d'Okta est claire sur les propriétés qui rendent les jetons attrayants pour un attaquant : un jeton a les permissions de l'utilisateur qui l'a créé, reste valide 30 jours et se renouvelle à chaque utilisation, et n'est rejeté qu'une fois son créateur désactivé (Okta Help Center : jetons d'API). Réinitialiser le mot de passe ou les facteurs du créateur ne le révoque pas.
| eventType | Signification |
|---|---|
system.api_token.create | un nouveau jeton d'API a été créé |
system.api_token.revoke | un jeton a été révoqué |
system.api_token.request_outside_allowed_range | un jeton a été utilisé hors de sa zone réseau autorisée |
Pour savoir ce qu'a fait un jeton, Okta Security recommande de requêter sur transaction.detail.rootApiTokenId (Okta Security). Chaque jeton créé pendant la fenêtre de l'incident doit être révoqué, puis son activité examinée.
L'analyseur signale chaque création sous Jeton d'API créé (moyenne) : les jetons sont courants pour les intégrations, celui-ci demande donc du contexte, et devient décisif à côté d'un constat élevé sur le même acteur.
L'affaiblissement des défenses
| eventType | Règle de l'analyseur | Sévérité |
|---|---|---|
security.authenticator.lifecycle.deactivate, system.mfa.factor.deactivate | Authentificateur désactivé | élevée |
policy.lifecycle.deactivate, policy.lifecycle.delete, policy.rule.deactivate, policy.rule.delete | Politique ou règle désactivée | moyenne |
policy.lifecycle.update, policy.rule.update, policy.lifecycle.overwrite | Politique modifiée | faible |
security.threat.configuration.update, security.attack_protection.settings.update, security.session_protection.status.update, zone.update, zone.delete, zone.deactivate, zone.remove_blacklist | Paramètres de sécurité modifiés | moyenne |
Une modification de politique est informative à elle seule, car les admins changent les règles en permanence. Le System Log indique que la règle a changé ; ouvrez la politique dans l'Admin Console et comparez avec votre documentation pour voir ce qui a changé (par exemple, MFA plus exigée pour un groupe).
Usurpation par le support
user.session.impersonation.grant et user.session.impersonation.initiate enregistrent l'activation puis l'utilisation de l'accès du support. L'analyseur les signale sous Accès du support Okta / usurpation (moyenne). La question à se poser est simple : quelqu'un de votre équipe a-t-il ouvert un ticket de support qui le nécessitait ? Sinon, révoquez l'accès et cherchez qui l'a activé.
Déroulé de l'enquête
- Ancrez-vous sur l'admin compromis. À partir de son premier
user.session.startsuspect, listez chaque événement dont il est l'acteur. Le pivot par entité de l'analyseur le fait en un clic. - Dressez la liste de ce qu'il a touché : chaque utilisateur promu, chaque jeton créé, chaque groupe doté de droits, chaque IdP, politique, authentificateur et zone modifiés.
- Recommencez l'étape 1 pour chaque compte promu. Les attaquants enchaînent les identités.
- Comparez avec l'état actuel dans l'Admin Console (Security › Administrators, Security › API › Tokens). Ce qui a été créé il y a plus de 90 jours ne figure pas dans le journal.
Ordre de remédiation
- Révoquez les jetons d'API créés pendant l'incident (Security › API › Tokens).
- Révoquez les rôles d'admin accordés pendant l'incident, en commençant par Super Administrator ; puis passez en revue toutes les attributions d'admin.
- Supprimez les sessions des comptes concernés.
- Restaurez politiques, authentificateurs, zones réseau et réglages ThreatInsight.
- Supprimez les fournisseurs d'identité inconnus.
Pourquoi les jetons d'abord : un jeton permet à l'attaquant de réattribuer un rôle que vous venez de retirer, tant que son créateur est actif.
À long terme, les recommandations d'Okta pour cette famille d'attaques incluent moins de Super Administrators permanents (des rôles d'admin personnalisés, limités au besoin), la réauthentification des sessions d'administration et les Protected Actions sur les opérations sensibles (Okta Security). La page sur les rôles d'administration standard aide à décider qui a besoin de quoi.