Intrusion Okta via le support tiers par Lapsus$

Le 22 mars 2022, le groupe d'extorsion Lapsus$ a diffusé des captures d'écran des systèmes internes d'Okta sur son canal Telegram. Okta — fournisseur de gestion des identités et des accès dont la plateforme d'authentification unique protège les connexions de plus de 15 000 organisations — a été contraint de confirmer un incident de sécurité survenu en réalité deux mois plus tôt, en janvier, et resté non divulgué.

Ce qui s'est passé

L'intrusion ne visait pas directement l'infrastructure propre d'Okta. Lapsus$ a plutôt compromis le réseau de Sitel (anciennement Sykes), un sous-traitant tiers de support client utilisé par Okta. Le groupe a obtenu l'accès au poste de travail d'un ingénieur de support de Sitel et, le 21 janvier 2022, l'a contrôlé via le protocole RDP (Remote Desktop Protocol) pendant 25 minutes consécutives, alors qu'il était connecté aux outils de support d'Okta.

Le premier signal d'alerte d'Okta est survenu le 20 janvier 2022, lorsque son équipe de sécurité a reçu une alerte indiquant qu'un nouveau facteur d'authentification multifacteur avait été ajouté au compte Okta d'un employé de Sitel depuis un nouvel emplacement. Okta a suspendu le compte et lancé une enquête, mais l'ampleur réelle n'est devenue claire qu'une fois que Lapsus$ a rendu l'affaire publique.

Portée et limites

Les ingénieurs de support opèrent avec des privilèges délibérément restreints. Ils ne peuvent ni créer ni supprimer d'utilisateurs, ne peuvent pas télécharger de bases de données clients et ne peuvent pas obtenir de mots de passe en clair. Ils peuvent consulter des données limitées telles que des tickets Jira et des listes d'utilisateurs, et faciliter des réinitialisations de mot de passe et de MFA.

La communication d'Okta a évolué au fil de l'enquête :

• Initialement, Okta a indiqué que l'impact potentiel maximal était de 366 clients — environ 2,5 % de sa base de clients — correspondant à tous ceux dont les données auraient théoriquement pu être touchées par le compte de l'ingénieur Sitel durant une fenêtre de cinq jours (16-21 janvier).
• Son enquête conclusive d'avril a confirmé que seuls deux locataires clients ont réellement été consultés, et que l'attaquant n'a effectué aucune modification de configuration, réinitialisation de MFA/mot de passe ni action d'« usurpation » du support client.

La controverse sur la divulgation

L'aspect le plus dommageable pour Okta n'a pas été la portée technique — étroite — mais le délai de deux mois entre la détection et la divulgation. Clients et régulateurs ont reproché à Okta de ne pas les avoir notifiés lorsque l'incident a été détecté en janvier, ne l'apprenant que lorsque Lapsus$ a choisi de le publier. Okta a elle-même reconnu qu'elle aurait dû agir plus vite et avec plus de transparence, et qu'elle s'était trop fiée à la chronologie médico-légale de Sitel au lieu d'exiger plus tôt des preuves directes.

Pourquoi c'est important

L'intrusion d'Okta est un cas emblématique du risque d'identité lié aux tiers et à la chaîne d'approvisionnement. Okta se situe au cœur du réseau de confiance de milliers d'organisations ; une compromission de ses outils de support — même étroite, de 25 minutes, via un sous-traitant — a eu un impact psychologique et réputationnel démesuré précisément en raison de cette position. L'incident a renforcé plusieurs leçons difficiles : les sous-traitants héritent du rayon d'impact du donneur d'ordre, la détection sans divulgation rapide érode la confiance plus vite que l'intrusion elle-même, et même un accès de support étroitement délimité doit être surveillé comme un chemin privilégié. Il s'inscrivait aussi dans la série de 2022 de Lapsus$ — aux côtés de Microsoft, Nvidia, Samsung et Uber — qui a montré comment un groupe peu structuré de jeunes acteurs pouvait déjouer à répétition les défenses des entreprises par l'ingénierie sociale plutôt que par la sophistication technique.