L’entreprise de cybersécurité ReliaQuest a confirmé que l’un de ses employés avait été la cible d’une attaque d’ingénierie sociale au cours de laquelle les attaquants s’étaient fait passer pour un membre de l’équipe de sécurité, mais que leur tentative d’accéder aux systèmes et aux données de l’entreprise avait échoué. L’entreprise a expliqué que les attaquants avaient appelé plusieurs employés et tenté de les rediriger vers une fausse page de connexion au service d’authentification unique SSO hébergée derrière un réseau de distribution de contenu.
L’affaire a commencé après que l’unité de recherche sur les menaces de ReliaQuest a alerté sur une campagne qu’elle attribue au groupe d’extorsion ShinyHunters, reposant sur l’enregistrement de domaines sous l’extension .claims et la création d’adresses ressemblant aux domaines des services d’assistance et des équipes informatiques des organisations ciblées. L’entreprise a indiqué que les domaines suivaient un modèle comprenant le nom ou l’abréviation de l’organisation avant l’extension, tandis que des sources de BleepingComputer ont identifié le domaine utilisé lors de cet incident comme étant reliaquest.claims.
Un accès temporaire sans franchissement vers les applications
L’un des employés ciblés a réussi à saisir ses identifiants sur la fausse page SSO et a également approuvé une notification d’authentification multifacteur sur son téléphone. Cela a donné à l’attaquant un accès temporaire en lecture seule au tableau de bord d’identité de ReliaQuest. Il semble que l’attaquant ait utilisé le nom d’un véritable employé de l’équipe de sécurité lors des appels d’hameçonnage vocal.
Cependant, l’accès ne s’est pas transformé en compromission plus large. L’entreprise a déclaré que les contrôles de confiance des appareils avaient empêché les tentatives ultérieures d’accès aux applications via le tableau de bord d’identité et que l’attaquant continuait de recevoir des refus lorsqu’il tentait d’utiliser ces applications. Selon ReliaQuest, aucune de ses applications ou de ses systèmes n’a été consulté et les données des clients n’ont pas été touchées.
L’entreprise a mis fin aux sessions de l’attaquant, révoqué le mot de passe exposé et réinitialisé tous les jetons d’authentification. Elle a également vérifié l’application des contrôles d’accès, de la confiance des appareils et de l’accès depuis l’intérieur du réseau depuis le 21 août, et a déclaré que l’enquête n’avait trouvé aucun élément attestant d’un accès à d’autres comptes, applications ou données, ni de la création par l’attaquant d’un mécanisme de persistance au sein de ses systèmes.
Que montre concrètement cet incident ?
L’incident révèle que le succès d’un hameçonnage, le vol d’identifiants et l’approbation d’une demande MFA ne signifient pas automatiquement que l’attaquant est capable d’accéder aux ressources de l’organisation. Dans ce cas, une couche ultérieure de contrôles a bloqué les tentatives provenant d’un appareil ou d’un contexte ne satisfaisant pas aux exigences de confiance. Il s’agit d’une interprétation fondée sur la chronologie de l’incident telle que décrite par ReliaQuest, et non d’un élément prouvant que l’authentification multifacteur seule a empêché la compromission.
ShinyHunters a publié des captures d’écran qu’il présente comme la preuve du piratage d’un compte Okta SSO appartenant à un employé de ReliaQuest, puis a intégré ces captures à son site de divulgation de données. Dans une publication, le groupe a fait référence aux précédents rapports de ReliaQuest le concernant et a également déclaré à BleepingComputer que son accès était limité à la lecture et ne s’étendait pas aux applications, aux systèmes ou aux données des clients. Toutefois, ReliaQuest n’a pas confirmé davantage que l’entité ayant mené l’attaque était ShinyHunters ; l’attribution de l’incident au groupe reste donc une allégation non tranchée au vu des informations disponibles.