Quand une vraie demande de connexion devient un piège de phishing

Le 20 août 2026, le Google Threat Intelligence Group (GTIG) a décrit trois campagnes présumées d’espionnage informatique russe visant des personnes liées à la recherche, à l’aéronautique, à la défense, aux administrations et aux groupes de réflexion en Europe et aux États-Unis. Leur particularité : les attaquants détournent des fonctions légitimes d’authentification et d’association d’appareils pour convaincre leurs victimes d’accorder elles-mêmes l’accès, plutôt que de miser principalement sur le cassage de mots de passe ou l’exploitation de vulnérabilités logicielles.

Une demande familière, mais une autorisation dangereuse

Les opérations reposent sur une ingénierie sociale persistante et ciblée. Les attaquants se font passer pour des responsables, des collègues ou d’autres contacts de confiance, puis construisent des invitations et des échanges suffisamment plausibles pour guider leurs cibles vers de véritables fonctions de sécurité.

Les techniques observées comprennent l’autorisation Google OAuth, les mots de passe spécifiques aux applications et l’association d’un nouvel appareil à un compte WhatsApp.

Cette méthode peut contourner la protection que les utilisateurs associent habituellement à l’authentification multifacteur. La victime ne transmet pas forcément son mot de passe : elle peut autoriser une application OAuth, générer un mot de passe d’application ou valider l’association d’un appareil. Dans chaque cas, son action donne à l’attaquant un accès qui paraît légitime.

Les méthodes attribuées aux trois groupes

UNC6293 : usurpation de contacts, mots de passe d’application et OAuth

UNC6293 aurait usurpé l’identité de responsables du département d’État américain et d’autres contacts considérés comme fiables. Les messages incitaient les cibles à créer puis à communiquer des mots de passe spécifiques aux applications, susceptibles de permettre un accès au compte sans passer par la demande habituelle de second facteur.

Le GTIG a également décrit des campagnes de phishing par consentement OAuth : au lieu de voler directement un mot de passe, les attaquants cherchent à obtenir des jetons d’accès autorisés par l’utilisateur.

Le groupe est considéré avec un niveau de confiance modéré comme un sous-cluster chargé de l’accès initial pour ICE RELIC, le nom employé par Google pour l’acteur auparavant connu sous celui d’APT29.

UNC7005, également suivi sous le nom STORM-2945 : WhatsApp et scénarios en plusieurs étapes

UNC7005 a employé un éventail plus large de techniques, notamment :

• Des escroqueries à l’association d’appareils WhatsApp : les victimes étaient amenées à relier à leur compte un appareil contrôlé par l’attaquant.
• De faux appels vocaux et des invitations à rejoindre des discussions chiffrées : ces échanges servaient à instaurer un climat de confiance avant l’envoi d’un lien ou d’un code malveillant.
• Des communications usurpant des organisations : certaines leurres faisaient référence au Finnish Operations Center et redirigeaient vers de faux portails de connexion Microsoft.
• Des flux Google OAuth et des logiciels malveillants : les attaquants cherchaient à obtenir des jetons ou un accès au compte, tout en déployant notamment les voleurs d’informations VIDAR et ATOMIC.

Ses techniques et son infrastructure diffèrent de ceux d’UNC6293. C’est pourquoi le GTIG suit les deux opérations séparément, malgré des cibles comparables et un recours commun à des mécanismes d’authentification légitimes.

UNC5976 : du phishing OAuth contre des cibles liées à la défense

UNC5976 aurait concentré ses efforts sur des personnels et des organisations militaires, aéronautiques et de défense, notamment parmi des cibles liées à l’Ukraine et à l’Arménie. Ses campagnes de phishing cherchaient à obtenir, via OAuth, l’autorisation d’accéder aux comptes ou aux données des victimes.

Ce que signifie le lien avec la Russie

Le GTIG estime avec un niveau de confiance élevé que l’ensemble de ces activités présente un lien avec la Russie. Il s’agit d’une évaluation d’attribution : cela ne signifie pas que chaque détail opérationnel ni que les relations entre les différents groupes soient établis avec le même degré de certitude.

Les informations disponibles évoquent également des liens possibles entre une partie de l’activité et ICE RELIC/APT29. Le rattachement d’UNC6293 à ICE RELIC est évalué avec un niveau de confiance modéré. Les trois clusters restent toutefois suivis séparément, car leurs méthodes et leurs infrastructures ne sont pas identiques.

Pourquoi l’authentification multifacteur ne suffit pas toujours

L’authentification multifacteur reste une protection importante, mais elle peut être contournée lorsqu’un attaquant pousse l’utilisateur à valider la mauvaise action. Un écran inattendu de consentement OAuth, une demande de création de mot de passe d’application ou un code d’association WhatsApp peut signaler une prise de contrôle imminente, même si aucun mot de passe n’a été dérobé.

La bonne approche consiste donc à considérer chaque demande d’authentification comme une opération à vérifier, et non comme une étape automatiquement sûre parce qu’elle apparaît dans un service connu.

Les réflexes recommandés par Google

Le GTIG recommande de ralentir les étapes que les attaquants cherchent à faire exécuter dans l’urgence :

• Vérifier l’adresse complète du site dans la barre du navigateur avant de se connecter ou d’autoriser un accès OAuth.
• Confirmer les invitations et les demandes par un autre canal, notamment celles liées à une conférence, à un appel, à une messagerie chiffrée ou à un contact prétendant représenter une administration ou une organisation.
• Ne jamais communiquer un mot de passe d’application, un code de vérification à usage unique, un QR code ou un code d’association d’appareil. Il ne faut pas non plus approuver une connexion ou une autorisation OAuth inattendue.
• Contrôler régulièrement les appareils associés à WhatsApp et aux autres applications de messagerie, puis supprimer ceux qui sont inconnus.
• Privilégier une authentification multifacteur résistante au phishing : les organisations devraient notamment déployer des clés de sécurité ou des passkeys et, lorsque c’est possible, limiter les applications OAuth à risque ainsi que l’usage des mots de passe spécifiques aux applications.

Pour les personnes travaillant dans des secteurs sensibles, la règle est simple : une marque familière, une véritable page de connexion ou une fonction d’authentification authentique ne suffit pas à prouver qu’une demande est légitime. Il faut aussi vérifier la demande elle-même et l’identité de la personne ou de l’organisation à son origine.