ReliaQuest : l'attaque confirmée qui n'est pas allée plus loin
Le 22 août 2026, l'entreprise de cybersécurité ReliaQuest confirme
avoir été la cible d'une attaque d'ingénierie sociale : vishing, fausse page de
connexion, un employé piégé. Contrairement à la plupart des dossiers de ce
Laboratoire, celui-ci documente une attaque qui a fonctionné jusqu'à un
certain point, puis a été stoppée — et explique précisément pourquoi.
✅ Confirmé par l'entreprise elle-même, sur
l'essentiel. ReliaQuest a publiquement reconnu l'attaque et son
mécanisme. Le désaccord porte uniquement sur l'ampleur : ShinyHunters revendique
un piratage, ReliaQuest confirme une exposition temporaire et limitée, sans
preuve d'accès à des données clients à ce jour.
Les chiffres, et leur statut réel
22 août
Date de la tentative d'attaque par ingénierie sociale,
confirmée par ReliaQuest.
Communiqué ReliaQuest.
1
Employé ayant saisi ses identifiants et approuvé une
notification MFA sur la fausse page — un seul suffit à ouvrir une session.
ReliaQuest, via The Register.
Lecture seule
Étendue de l'accès obtenu : la seule vue d'un tableau de
bord d'identité interne, selon ReliaQuest.
Citation officielle ReliaQuest.
0
Application ou système interne atteint ; donnée cliente
consultée, selon ReliaQuest.
Citation officielle ReliaQuest.
Chronologie
CONFIRMÉ
22 août 2026
Des attaquants appellent plusieurs employés de
ReliaQuest en usurpant l'identité d'un membre nommé de l'équipe sécurité, les
dirigeant vers une fausse page de connexion unique (SSO) clonée, hébergée sur
un domaine ressemblant à celui de l'entreprise.
CONFIRMÉ
22 août 2026
Un employé saisit son mot de passe sur la fausse page et
approuve une notification MFA sur son téléphone. Les attaquants obtiennent
une session valide sur le tableau de bord d'identité de l'entreprise.
CONFIRMÉ
22 août 2026
Les attaquants tentent de rebondir depuis ce tableau de
bord vers les applications internes de ReliaQuest. Le rebond échoue : les
contrôles d'accès exigent un appareil géré et reconnu par l'entreprise, que
les attaquants ne possèdent pas. L'équipe sécurité met fin à la session,
expire le mot de passe et réinitialise les facteurs d'authentification.
REVENDIQUÉ
23 août 2026
ShinyHunters publie une revendication sur son site de
fuite, avec des captures d'écran du tableau de bord Okta consulté. Aucune
donnée cliente, aucun échantillon validé, aucune demande de rançon
documentée n'accompagnent la publication.
🔐Ce qui a arrêté l'attaque, précisément
Le mot de passe était compromis. Le MFA était contourné — l'employé a
lui-même approuvé la notification. Dans beaucoup d'entreprises, ça aurait
suffi. Ici, un contrôle supplémentaire a tenu : l'accès aux applications
internes exige non seulement une identité valide, mais aussi un
appareil reconnu et géré par l'entreprise. Une session volée
depuis l'appareil personnel d'un attaquant, même avec les bons identifiants,
ne passe pas ce second filtre. C'est ce contrôle-là, pas le mot de passe ni le
MFA, qui a fait la différence.
Source : citation officielle ReliaQuest, via SecurityWeek.
Ce que ça change pour vous
Le mécanisme qui a piégé cet employé — un appel se présentant comme la
sécurité interne, une page de connexion qui ressemble exactement à la vraie,
une demande d'approbation MFA présentée comme routinière — est exactement le
type de manipulation qu'Egidio est conçu pour intercepter côté appel et
messagerie. Le réflexe qui protège reste le même, professionnel ou personnel :
aucune équipe sécurité légitime ne demande d'approuver une notification MFA par
téléphone. Voir Nouvelles
techniques de phishing.
🔒 Si un appel vous demande d'approuver une
notification d'authentification pendant que vous êtes en ligne avec
l'interlocuteur, raccrochez et vérifiez par un canal indépendant — même si le nom
affiché semble légitime.
Questions fréquentes
Des données clients de ReliaQuest ont-elles été volées ?
Non, selon ReliaQuest : aucune application ni donnée cliente n'a été
atteinte, l'accès s'est limité à la vue d'un tableau de bord interne.
Pourquoi l'attaque n'est-elle pas allée plus loin malgré un mot de passe et un MFA compromis ?
Un contrôle de confiance d'appareil a bloqué le rebond vers les applications
internes — c'est ce filtre, pas le MFA seul, qui a arrêté l'attaque.
ShinyHunters a-t-il fourni des preuves de son piratage ?
Des captures d'écran d'un tableau de bord, mais aucune donnée cliente ni
échantillon validé à ce jour.
📌 Dernière vérification : 25 août 2026.
Élément vérifiable à signaler : contact@egidio.app.
Citer cette pageEgidio — Laboratoire des menaces, « ReliaQuest : l'attaque confirmée qui n'est pas allée plus loin », egidio.app/laboratoire/reliaquest-attaque-bloquee-shinyhunters/. Licence CC BY 4.0.