L’incident a commencé lorsque les équipes de sécurité de BeyondTrust ont détecté un attaquant tentant d’accéder à un compte administrateur interne d’Okta à l’aide d’un cookie de session valide volé dans le système de support d’Okta. Les contrôles de stratégie personnalisés ont bloqué l’activité initiale de l’attaquant. Cependant les limitations du modèle de sécurité d’Okta lui ont permis d’effectuer quelques actions. L’outil Identity Security Insights de BeyondTrust a alerté les équipes, qui ont pu bloquer tous les accès et vérifier que cet attaquant n’avait accès à aucun système.

La réponse initiale à l’incident a indiqué une possible compromission chez Okta, soit d’un membre de son équipe support, soit d’une personne en mesure d’accéder aux données liées au support client. Nous avons fait part de nos préoccupations concernant une brèche à Okta le 2 octobre. N’ayant reçu aucun accusé de réception de la part Okta concernant une éventuelle violation, nous avons continué d’escalader nos préoccupations au sein d’Okta jusqu’au 19 octobre, date à laquelle les responsables de la sécurité d’Okta nous ont informés qu’ils avaient effectivement subi une violation et que nous étions l’un de leurs clients concernés.

Okta a publié cette déclaration confirmant la brèche que nous avons détectée il y a près de trois semaines. Encore une fois, même si BeyondTrust ou nos clients n’ont pas été exposés, nous partageons les détails de l’attaque pour informer les autres utilisateurs d’Okta et les professionnels de la sécurité de l’information. Pour les clients BeyondTrust qui utilisent notre produit Identity Security Insights, nous avons également présenté les différentes détections qui nous ont alertés et des recommandations pour mieux contrôler votre surface d’attaque et limiter la possibilité et l’impact des attaques ciblées Okta.

Aperçu de la chronologie
2 octobre 2023 – Attaque centrée sur l’identité détectée et bloquée sur un compte administrateur Okta interne et alerte Okta
3 octobre 2023 : Demande au support Okta d’escalader vers l’équipe de sécurité Okta étant donné que les premiers éléments de preuve indiquent une compromission au sein de l’organisation de support Okta.
11 octobre 2023 et 13 octobre 2023 : organisation de sessions Zoom avec l’équipe de sécurité Okta pour expliquer pourquoi nous pensions qu’ils pourraient être compromis
19 octobre 2023 – Les responsables de la sécurité Okta ont confirmé avoir subi une violation interne et que BeyondTrust était l’un de leurs clients concernés.

Détails de l’attaque
Le 2 octobre 2023, un agent de support Okta a demandé à un administrateur Okta de BeyondTrust de générer un fichier HAR pour l’aider à résoudre un problème de support en cours sur lequel l’administrateur travaillait. Les fichiers HAR sont des archives HTTP qui peuvent être générées par un navigateur Web pour enregistrer les interactions avec un site Web, dans ce cas pour déboguer un problème avec le site. L’administrateur a répondu à la demande et a généré un fichier HAR contenant une requête API et un cookie de session qui a été téléchargé sur le portail support d’Okta.
Le compte de l’admin Okta était protégé par l’authentification FIDO2, et les politiques d’Okta de BeyondTrust autorisaient uniquement l’accès à la console d’administration à partir d’appareils gérés sur lesquels Okta Verify était installé.
Dans les 30 minutes qui ont suivi le téléchargement du fichier par l’administrateur sur le portail support d’Okta, un attaquant a utilisé le cookie de session de ce ticket de support pour tenter d’effectuer des actions dans l’environnement Okta de BeyondTrust. Les politiques personnalisées de BeyondTrust concernant l’accès à la console d’administration l’ont initialement bloqué, mais il a pivoté vers l’utilisation d’actions API d’administration authentifiées avec le cookie de session volé. Les actions API ne peuvent pas être protégées par des politiques de la même manière que l’accès réel à la console d’administration. À l’aide de l’API, il a créé un compte utilisateur lui servant de backdoor en utilisant une convention de nommage identique aux comptes de service existants.
Notre propre instance d’Identity Security Insights de BeyondTrust et les détections personnalisées de nos équipes de sécurité nous ont alertés sur plusieurs aspects de l’intrusion. Nous avons immédiatement désactivé le compte utilisateur servant de backdoor et révoqué l’accès de l’attaquant avant que le compte puisse être utilisé, empêchant ainsi toute autre action. Nous n’avons trouvé aucune preuve d’une autre activité irrégulière chez tous les autres utilisateurs privilégiés d’Okta dans Identity Security Insights, aucune preuve de la création d’autres comptes Okta suspects et aucune preuve d’une activité inhabituelle sur le compte de l’utilisateur ciblé avant cet incident.

Chronologie détaillée de l’attaque

2 octobre 2023
• Un administrateur Okta de BeyondTrust génère un enregistrement du navigateur (fichier HAR) à la demande du support Okta lié au support en cours suite à un incident non lié à la sécurité.
• Dans les 30 minutes qui ont suivi le téléchargement du fichier de support, une tentative d’accès à la console d’administration Okya de BeyondTrust a eu lieu en tant qu’administrateur Okta de BeyondTrust et utilisant une adresse IP en Malaisie liée à des services proxy/VPN anonymisés.
• Les événements Okta sont enregistrés à partir de cette adresse IP malaisienne. Cependant, il n’y a eu aucun événement ou activité d’authentification préalable de cet utilisateur à cet emplacement, comme on pourrait s’y attendre.
• L’attaquant a été authentifié, mais l’accès à la console Okta a été refusé en raison d’une configuration de politique de sécurité Okta autre que celle par défaut appliquée par les équipes de sécurité de BeyondTrust :
• Par défaut, l’accès est refusé et n’est autorisé que si des critères spécifiques sont remplis.
• L’attaquant se voit refuser l’accès à la console en raison de l’exigence de la politique d’Okta Verify sur un appareil géré.
• L’attaquant tente de générer un rapport sur l’état du mot de passe à l’aide de l’API sous-jacente de la console d’administration Okta.
• L’attaquant tente d’accéder au tableau de bord principal d’Okta, mais reçoit un message de contestation de politique.
• L’attaquant utilise l’API officielle d’Okta pour créer un faux compte de service nommé « svc_network_backup » dans le but de le faire ressembler à des comptes de service existants.
• L’attaquant a agi rapidement, mais nos détections et nos réponses ont été immédiates, désactivant le compte et atténuant toute exposition potentielle.
• BeyondTrust a lancé un processus de réponse aux incidents, isolant immédiatement et enquêtant de manière approfondie sur tous les systèmes et comptes associés à l’administrateur.
• L’enquête n’a révélé aucun signe de compromission, mais elle a permis de découvrir le fichier HAR qui avait été généré pour le ticket de support. Il s’agit d’un fait notable car ces derniers ne sont créés que dans des circonstances exceptionnelles, dans ce cas pour résoudre un problème de support.
• BeyondTrust a contacté le support Okta pour l’informer de nos préoccupations pendant que nous poursuivions notre enquête.

3 octobre 2023
• Une enquête plus approfondie a exclu la possibilité que la compromission provienne d’un système BeyondTrust, ce qui nous a conduit à conclure que le système de support Okta était probablement compromis.
• Nous avons demandé au support d’Okta de faire remonter l’information à leur équipe de sécurité, étant donné que nous craignions qu’Okta ait été compromis et que d’autres clients d’Okta puissent être exposés. Aucune compromission connue ou incident de sécurité en cours n’a été communiqué par Okta.

11 octobre 2023
• Réunion Zoom d’Okta Support avec un membre de leur équipe de sécurité au cours de laquelle nous avons partagé nos conclusions et demandé les logs à Okta concernant l’accès aux données des dossiers support.
• Okta s’engage à fournir les journaux demandés et à travailler avec nous. Aucune compromission connue ou incident de sécurité en cours n’a été communiqué par Okta.

13 octobre 2023
• Les journaux de support d’Okta ont été reçus mais contenaient plusieurs divergences. Nous avons demandé des journaux plus détaillés relatifs aux écarts et avons réitéré nos inquiétudes quant à la forte probabilité de compromission au sein du support d’Okta et au fait que nous n’étions probablement pas le seul client concerné. Aucune compromission connue ou incident de sécurité en cours n’a été communiqué par Okta.

19 octobre 2023
• Appel de la direction de la sécurité d’Okta qui nous a informés qu’il y avait eu une brèche chez Okta et que nous étions l’un des clients exposés lors de cette violation.

20 octobre 2023
• En même temps que l’annonce publique d’Okta, nous publions ce blog avec des informations détaillées, tels que des indicateurs de compromission, afin de fournir des informations à la communauté de la sécurité et de protéger les clients mutuels.

BeyondTrust souhaite remercier Okta d’avoir travaillé avec nous pour protéger nos clients communs. Nous apprécions leur transparence en signalant cette violation, en informant les clients concernés et en soulignant les étapes d’enquête ultérieures.

Identity Security Insights - Détections spécifiques à cette découverte
Les détections et recommandations disponibles dans la solution Identity Security Insights de BeyondTrust auraient été déclenchées pour les clients Insights s’ils avaient été ciblés par les techniques utilisées dans cette attaque Okta. Les détections et recommandations suivantes, disponibles dans la solution Identity Security Insights de BeyondTrust, auraient été déclenchées pour les clients ayant la solutions s’ils avaient été ciblés.
• Piratage de session Okta : les attaquants volent les cookies de session Okta et les utilisent pour accéder à Okta à partir de l’infrastructure qu’ils contrôlent, leur permettant ainsi de contourner la plupart des contrôles MFA et de sécurité liés à l’authentification. Cette détection recherche les sessions suspectes apparaissant sans événement d’authentification et compatibles avec un piratage de session.
• Un utilisateur Okta a effectué une action admin à l’aide d’un proxy : cet attaquant, ainsi que d’autres attaquants ciblant Okta, comme Scattered Spider, utilisent souvent des proxys pour se connecter en tant qu’utilisateurs privilégiés et effectuer des actions admins sensibles, mais les utilisateurs légitimes le font rarement.
• Des privilèges admin d’Okta ont été accordés à un utilisateur : les attaquants tentent souvent d’élever leurs privilèges ou d’accorder des privilèges à des comptes via backdoor. Cette détection au niveau des informations met en évidence toutes les affectations d’administrateur Okta. Ces missions sont généralement rares et se déroulent habituellement dans le cadre d’un processus établi.
• Un rapport généré sur l’état des mots de passe Okta : ce rapport est rarement généré dans la plupart des environnements que nous surveillons. Cette détection au niveau des informations met en évidence le moment où cela se produit au cas où l’activité serait suspecte.
• Un utilisateur Okta disposant d’un certain niveau d’accès admins utilise le MFA vulnérable à l’échange de carte SIM : notre processus de réponse aux incidents a été nettement plus rapide car l’utilisateur admin a utilisé FIDO2 comme MFA, ce qui nous a permis d’exclure le phishing d’un attaquant comme un mécanisme pour le jeton. vol. Les recommandations de posture destinées aux utilisateurs privilégiés permettent aux professionnels de la sécurité des identités de procéder à des modifications progressives qu’ils peuvent apporter pour mieux protéger ces comptes cruciaux.

Si vous utilisez actuellement Identity Security Insights, veuillez examiner vos résultats pour toute détection applicable sur les détails ci-dessous et n’hésitez pas à contacter le support BeyondTrust pour obtenir de l’aide dans l’examen de l’exposition potentielle de votre propre environnement à la suite de la violation d’Okta. Si vous n’êtes pas actuellement client d’Identity Security Insights mais que vous souhaitez profiter de notre essai gratuit pour évaluer votre environnement, veuillez nous contacter.

Indicateurs de compromis
• Accès aux fonctions d’administration d’Okta via un proxy (isproxy : true dans les événements du journal Okta)
• Accès à Okta depuis les IP 202[.]59.10.100 ou 23[.].105.182.19
• Accès à Okta, en particulier aux fonctions d’administration d’Okta, depuis les fournisseurs de VPS/d’hébergement. (Surtout : VPS Malaisie, LeaseWeb.)
• Accès à Okta avec cet agent utilisateur pour une version obsolète de Chrome pour MacOs : Mozilla/5.0 (Macintosh ; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, comme Gecko) Chrome/99.0.3538.77 Safari/537.36
• Compte Okta créé via l’API REST avec le nom svc_network_backup ou un autre nom imitant des comptes légitimes existants.
• Activité sur les points de terminaison tels que /reports/password-health/async_csv_download_schedule ?, qui sont généralement utilisés uniquement à partir de l’interface utilisateur de la console d’administration Okta, sans aucune connexion correspondante à la console d’administration.
• Activité Okta pour un utilisateur sans aucune indication claire que l’utilisateur s’est authentifié (par exemple, un événement user.session.start pour cet utilisateur d’une zone géographique similaire)
• Tentatives de connexion à la console d’administration refusées par la stratégie sans connexion ultérieure réussie à la console d’administration à partir du même utilisateur dans un délai d’une heure

Autres notes
• Okta a récemment mis à jour ses articles de sa base de données concernant la création et le contrôle des fichiers HAR. Nous vous recommandons de les consulter.
• Nous n’avons constaté aucune tentative infructueuse d’utilisation de la session volée après son expiration, mais cela peut être dû au fait que les actions tentées avec des sessions expirées n’apparaissent pas dans les journaux Okta.

Améliorations de posture recommandées
• Ajoutez des contrôles de stratégie dans Okta pour restreindre l’accès à la console d’administration.
• Envisagez d’ajuster la politique de session globale d’Okta pour émettre contrôle MFA à chaque connexion, ce qui empêchera les attaquants disposant d’un cookie volé d’accéder au tableau de bord principal.
• Limitez la durée des sessions Okta et prenez d’autres mesures pour réduire la fenêtre pendant laquelle un cookie volé peut être utilisé.
• Sachez que les actions de l’API d’administration authentifiées via le cookie de session ne sont couvertes que par la politique de session globale, qui est souvent moins restrictive que les autres politiques.
• Sachez que le piratage de session permet aux attaquants de contourner la MFA.
• Exigez une MFA matérielle solide pour tous les administrateurs Okta afin d’empêcher le piratage de jetons via le phishing d’un attaquant du milieu.

Pensées finales
Les attaques modernes basées sur l’identité peuvent être complexes et, comme le montre cette attaque, peuvent provenir d’environnements extérieurs au vôtre. De bonnes politiques spécifiques et des contrôles internes sont nécessaires pour limiter des éléments tels que la manière dont les fichiers HAR sont partagés. Une défense en profondeur est cependant importante. L’échec d’un seul contrôle ou processus ne devrait pas entraîner de brèche. Ici, plusieurs niveaux de contrôles (par exemple les contrôles de connexion Okta, la surveillance de la sécurité des identités, etc.) ont empêché une violation.