🚨 La MFA ne protège pas ce qu'ils volent vraiment

Salut,

Vous avez un mot de passe long, une double authentification, un gestionnaire de secrets bien rangé. Et un groupe qu’on suit depuis 2020 vient de lire le Gmail professionnel de ses victimes sans toucher à aucun des trois. Kaspersky a documenté l’outil cette semaine sur Securelist. Le mécanisme mérite qu’on s’y arrête, parce qu’il vise l’angle mort que presque personne ne surveille : ce n’est pas votre connexion qu’on attaque, c’est votre session déjà ouverte.

STRD : le vol de session, décortiqué

Le groupe s’appelle ToddyCat, actif depuis environ 2020 sur des cibles en Europe et en Asie. Leur nouvel outil, baptisé Umbrij, a un objectif précis : accéder au Gmail d’entreprise des victimes via l’API Google. Et cette API, comme presque tout l’écosystème Google, s’appuie sur OAuth 2.0.

Autrement dit : une fois que vous vous êtes authentifié, ce n’est pas votre mot de passe qui circule à chaque requête, c’est un jeton OAuth qui prouve, à votre place, que la session est légitime. Umbrij vole ce jeton et s’en sert. Point.

Le plus élégant - et le plus inquiétant - c’est la façon dont il l’obtient. La technique est baptisée STRD, pour Shadow Token via Remote Debug. Sur une machine où la victime utilise un navigateur Chromium et ne s’est pas déconnectée de Gmail, l’outil ne casse rien du tout. Il relance le navigateur en mode headless - sans interface, invisible - puis se connecte au port de débogage à distance de Chromium. Ce port, c’est le canal que les développeurs utilisent pour piloter le navigateur, inspecter des pages, automatiser des tests. Détourné, il devient une télécommande : Umbrij prend le contrôle de la session ouverte et interroge Gmail comme si c’était vous, assis devant l’écran.

Regardez ce qui n’a servi à rien dans cette chaîne. Le mot de passe : jamais demandé, on n’en a pas besoin puisqu’on n’ouvre pas de connexion, on récupère une session qui l’est déjà. La MFA : elle protège le moment du login, or il n’y a pas de login ici. Le second facteur a été validé une fois, au début de la journée, par la vraie personne - et le jeton qui en découle, lui, ne redemande rien. C’est tout le sujet : on ne vous vole pas votre identité, on vous vole la preuve que vous l’avez déjà prouvée.

Reste à poser l’outil sur la machine. Là, ToddyCat n’invente rien de neuf, et c’est pédagogique : DLL sideloading sur Windows. Vous déposez une DLL malveillante à côté d’un binaire légitime, signé, de confiance. Le binaire démarre, cherche sa bibliothèque dans le répertoire courant, et charge la vôtre au lieu de la bonne. Un exécutable au-dessus de tout soupçon exécute votre code. La signature numérique rassure l’antivirus ; le mal est déjà chargé en mémoire.

La coulisse : l’authentification n’est qu’un début

Ce qui me reste de cette histoire, c’est un renversement de perspective que je vois trop peu appliqué. On a passé dix ans à blinder la porte : mots de passe complexes, MFA, passkeys, coffres- forts. Excellent travail, nécessaire. Mais une fois la porte franchie, ce qui traîne derrière - le jeton, le cookie de session, l’onglet Gmail resté ouvert - hérite de toute la confiance accordée à ce login, et personne ne le surveille avec la même intensité.

La session est l’actif. Pas le login. Un jeton OAuth qui vit trop longtemps, un navigateur qu’on ne déconnecte jamais, un port de débogage qui traîne : voilà les vrais coffres. Se déconnecter en fin de journée n’est pas une politesse de grand-père, c’est ce qui aurait cassé STRD net. Et côté défense, la question à se poser change : ne demandez pas seulement « qui s’est authentifié ? », demandez « ce jeton est-il encore utilisé depuis le bon endroit, le bon processus, la bonne machine ? ». Un jeton volé se trahit rarement au login. Il se trahit dans l’usage.

Pour cette semaine