Okta a-t-il suffisamment audité son sous-traitant Sitel ?
Le scénario de l'attaque contre Okta se dessine, désormais qu'ont filtré des éléments relatifs à l'enquête chez le sous-traitant ciblé.
Attaqué par l'intermédiaire de son sous-traitant Sitel, Okta aurait-il dû communiquer avant d'avoir à reconnaître l'évidence ? On est en droit de se poser la question. À plus forte raison depuis qu'ont filtré des éléments relatifs à ladite attaque. Plus précisément, une chronologie des événements, telle que l'a établie l'enquête de Mandiant.
New documents for the Okta breach: I have obtained copies of the Mandiant report detailing the embarrassing Sitel/SYKES breach timeline and the methodology of the LAPSUS$ group. 1/N https://t.co/z05uQYclg9 pic.twitter.com/e0T4EdWPxT
- Bill Demirkapi (@BillDemirkapi) March 28, 2022
Constat : l'offensive a impliqué des outils populaires chez les cybercriminels. En l'occurrence, Mimikatz, Process Explorer et Process Hacker. Chacun d'entre eux a été installé depuis l'environnement compromis, après les avoir... recherchés sur Bing, puis téléchargés sur GitHub.
Du côté d'Okta, la chronologie communiquée au public commence le 20 janvier. L'entreprise affirme avoir reçu sa première alerte ce jour-là. Objet : une tentative - infructueuse - d'ajout d'un mot de passe sur le compte Okta d'un ingénieur support de Sitel.
D'après les observations de Mandiant, le premier événement (connexion à l'environnement cible) intervient le 16 janvier à 0 h 33 (UTC ; heure de Londres). Les « grands travaux » de LAPSUS$ commencent véritablement le 19, avec une connexion RDP suivie d'une élévation de privilèges grâce à l'outil UserProfileScvEoP.exe, destiné à exploiter la faille CVE-2021-34484.
Environ 24 heures plus tard surviennent les actions suivantes : création d'un compte, latéralisation par RDP, puis désactivation de l'agent EDR FireEye (après récupération et exécution successives de Process Explorer et de Process Hacker). Mimikatz entre ensuite en scène pour récupérer des identifiants et les exfiltrer vers Pastebin.
Des mots de passe admin à foison ?
Le 20 janvier, vers 23 heures, intervient la première connexion au compte Office 365 de l'ingénieur support. Rapidement, ce compte accède, via SecureLink, à un fichier sensible. En l'occurrence, un tableau Excel nommé DomAdmins-LastPass. Explicite comme nom de fichier ? En tout cas, quelques heures plus tard, le compte de l'ingénieur parvient à en créer un autre, et à l'ajouter au groupe TenantAdmins (admins du locataire). Rapidement, ce nouveau compte crée une règle : transférer, vers des adresses sur lesquelles les cybercriminels ont la main, tous les mails parvenant sur le locataire.
La dernière connexion à l'Office 365 de Sitel - plus précisément de Sykes, entreprise acquise en 2021 et qui assure le support Okta - se produit vers 14 heures le 21 janvier. Après quoi Sitel orchestre une réinitialisation globale des mots de passe.
Du côté d'Okta, on affirme ne pas avoir saisi l'étendue du problème une fois la première alerte reçue. « Nous aurions réagi différemment », assure l'entreprise. Sans expliquer pourquoi elle n'a pas ouvert la communication à partir du 22 mars, une fois que Sitel lui avait remonté le rapport complet de Mandiant.
Photo d'illustration © Okta
Sur le même thème
Voir tous les articles Cybersécurité