Contexte de l'attaque
Le groupe de cybercriminels ShinyHunters a mené une campagne de phishing en enregistrant des domaines de type company.claims. Ces domaines, visuellement similaires à des adresses internes, ont été utilisés pour envoyer des e‑mails de leurre aux employés de ReliaQuest. L’objectif était d’inciter les victimes à accéder à une page d’authentification SSO factice, présentée comme appartenant à l’infrastructure de l’entreprise.
Mécanisme d'exploitation du SSO
Après avoir cliqué sur le lien, la cible a été redirigée vers une interface SSO reproduite à l’identique. La page demandait le mot de passe de l’utilisateur puis déclenchait une notification push sur le dispositif d’authentification mobile enregistré. L’employé, croyant interagir avec le service légitime, a saisi son mot de passe et a approuvé la notification. Cette double validation a généré un jeton d’accès valide pour le tableau de bord d’identité, ouvrant une session de courte durée. Le jeton était limité à des droits de lecture seule, ce qui a empêché toute modification ou exfiltration directe de données. La session a été immédiatement détectée par les contrôles internes, entraînant le blocage de toute tentative supplémentaire.
Analyse des impacts et mesures d’atténuation
Le périmètre d’accès a été confiné à la visualisation du tableau de bord d’identité ; aucune autre identité, aucune application métier et aucun jeu de données client n’ont été atteints. Aucun ransomware n’a été déployé. Cette limitation provient de la configuration du SSO, où les jetons d’accès sont associés à des scopes précis. Cependant, la compromission montre que la chaîne d’authentification repose encore sur la confiance implicite accordée aux notifications push, qui peuvent être exploitées lorsqu’un utilisateur valide un défi sans vérifier la provenance du site.
Pour réduire la surface d’exposition, plusieurs mesures techniques sont recommandées. Premièrement, la mise en place de DMARC, SPF et DKIM renforcés sur les domaines d’envoi permet de diminuer la réussite des campagnes de phishing par falsification d’adresse. Deuxièmement, l’ajout d’un facteur d’authentification supplémentaire, tel que la vérification de l’URL via un certificat client ou un code d’accès à usage unique affiché sur le dispositif de l’utilisateur, rendrait plus difficile l’approbation d’une notification push frauduleuse. Troisièmement, la segmentation du tableau de bord d’identité en micro‑services avec des politiques d’accès basées sur le principe du moindre privilège limiterait l’impact d’un jeton compromis à un sous‑ensemble de ressources.
Enfin, la surveillance en temps réel des flux d’authentification, couplée à des alertes sur les tentatives de connexion depuis des domaines non autorisés, permet d’intercepter rapidement les sessions anormales. L’incident souligne la nécessité d’une approche « zero‑trust » où chaque composant, du domaine de phishing potentiel au jeton d’accès, est continuellement validé.
