Les chercheurs ont suivi une campagne de sept semaines qui a exploité des plates-formes fiables et la confiance générée par l’IA pour inciter les utilisateurs à exécuter des commandes malveillantes et à exposer les informations d’identification de l’entreprise.
Les acteurs malveillants abusent des plateformes fiables, notamment Google Ads, les pages GitLab et la fonctionnalité de chat partagé de Claude, pour inciter les utilisateurs à exécuter des commandes malveillantes sur leurs systèmes.
Déguisés en outils de développement d’IA populaires, les acteurs malveillants ont utilisé les attaques d’ingénierie sociale ClickFix, où les victimes ont été amenées à exécuter manuellement des commandes malveillantes. En règle générale, cela impliquait de copier et coller des commandes PowerShell ou de terminal, ont noté les chercheurs de TrendAI.
La campagne a canalisé plus de 2 000 victimes des résultats de recherche Google sponsorisés pour les outils de développement d’IA populaires vers des pages de téléchargement malveillantes avant d’exploiter la fonctionnalité de chat partagé claude.ai comme une autre étape de la chaîne d’attaque.
La campagne montre comment les auteurs de menaces exploitent la confiance dans les plateformes d’IA largement utilisées pour rendre les attaques d’ingénierie sociale plus convaincantes et plus difficiles à détecter.
Au cœur de la campagne en six vagues
Contrairement aux campagnes de malware traditionnelles qui s’appuient sur des domaines suspects ou de faux sites de téléchargement, cette chaîne d’attaque repose presque entièrement sur des services légitimes. Les auteurs de la menace ont utilisé 92 noms d’hôtes malveillants uniques sur les pages GitLab, ont usurpé l’identité de noms de marques légitimes, notamment ChatGPT Codex, Perplexity, Cursor IDE, JetBrains, Claude AI et claude.ai, et ont simultanément exécuté des leurres frauduleux sur les utilitaires Mac.
La campagne s’est étalée sur sept semaines, au cours desquelles des campagnes hebdomadaires ont introduit de nouvelles pages et de nouveaux mots-clés.
La première vague de la campagne a été lancée entre le 8 et le 13 avril, avec claude-code-app.gitlab(.)io comme appât principal, soutenu par claudeapp.gitlab(.)io. Simultanément, des leurres sur le thème des utilitaires Mac (mac-clean-storage.gitlab(.)io, mac-guide-tool.gitlab(.)io) ont également été déployés. Au cours de cette vague, un seul identifiant de campagne Google Ads (23736589328) a généré la majorité du trafic.
Au cours de la vague suivante, qui s’est déroulée du 14 au 21 avril, la campagne a été diversifiée avec les nouvelles variantes sur le thème de Claude, notamment le domaine gitlab.io (claude-tool-app, claud-desktop-app, claudesktop, claude-desktop-apps) ainsi que des leurres utilitaires Mac étendus (macsupp-group, macsupp-usb, jetbrains-apps-group).
L’usurpation d’identité de la marque a été élargie au cours de la troisième vague avec l’introduction de perplexity-platform.gitlab.io et chatgpt-codex.gitlab(.)io, tout en créant également claude-desktop-lm.gitlab(.)io et cladesktop.gitlab(.)io.
Au cours de la quatrième vague, entre le 29 avril et le 5 mai, les opérateurs se sont considérablement orientés vers les marques ChatGPT et Codex avec codexgpt.gitlab(.)io , chatgpt-codex-app.gitlab(.)io et chatgpt-codex-lm.gitlab(.)io, tandis que les attaques sur le thème de Claude se poursuivaient.
Lors de la cinquième vague, qui s’est déroulée du 6 au 14 mai, les auteurs de la menace ont déplacé leur campagne des pages GitLab auto-hébergées vers l’utilisation abusive de la fonctionnalité de chat partagé légitime de claude.ai. Pour cela, la fonctionnalité « partager » de claude.ai a été exploitée pour créer des URL persistantes et accessibles au public sur un domaine entièrement fiable, puis a utilisé Google Ads pour diriger les victimes vers ces pages militarisées, selon la recherche.
Lors de la sixième vague, entre le 21 mai et le 14 juin, les acteurs de la menace s’étaient complètement tournés vers la fonctionnalité de chat partagé de claude.ai.
Selon les experts, la campagne semble avoir été conçue principalement pour cibler les développeurs et les utilisateurs techniques.
« Une interaction avec Claude peut être perçue comme fiable car les utilisateurs se sont habitués à considérer les outils d’IA comme des sources d’astuces de productivité et de conseils techniques. Dans ce scénario, lorsque les utilisateurs reçoivent des instructions nuisibles via une plateforme d’IA, il y a de fortes chances qu’ils s’y conforment automatiquement », a expliqué Devroop Dhar, co-fondateur et PDG indien de Primus Partners.
Les défenses basées sur la réputation ont échoué
Les experts en sécurité affirment que le succès de la campagne découle de sa capacité à exploiter des plateformes fiables à chaque étape de la chaîne d’attaque, faisant apparaître les activités malveillantes comme un comportement normal des utilisateurs.
« Ce qui rend cette chaîne d’attaque particulièrement efficace, c’est qu’elle ne demande pas à la victime de faire confiance à quelque chose de manifestement suspect. Au lieu de cela, elle emprunte la confiance de marques familières, d’une infrastructure publicitaire légitime, d’un hébergement réputé et d’une plate-forme d’IA que de nombreux développeurs utilisent déjà dans leur flux de travail quotidien. Cela a réduit les frictions psychologiques qui obligent normalement les utilisateurs à faire une pause avant de cliquer ou d’exécuter quelque chose », a déclaré Amit Jaju, directeur général d’Ankura Consulting.
C’est également un bon exemple d’empilement de confiance. Chaque couche semble légitime individuellement, de sorte que la chaîne complète semble plus sûre qu’elle ne l’est réellement, a ajouté Jaju.
En exploitant des plates-formes que les organisations autorisent et auxquelles elles font régulièrement confiance, les attaquants ont pu intégrer des activités malveillantes dans les flux de travail normaux des utilisateurs, rendant ainsi la détection beaucoup plus difficile.
Dhar a ajouté que dans la plupart des cas, l’accès à des applications telles que Google, GitLab et les applications d’IA n’est pas bloqué, car cela pourrait entraver les opérations au sein d’une organisation. Les systèmes de sécurité basés sur la réputation ne peuvent pas fonctionner efficacement ici puisque le domaine en question est considéré comme réputé, ce qui signifie que le personnel de sécurité devra approfondir le comportement et les actions des utilisateurs.
Briser la chaîne d’attaque
Si un développeur est victime, le rayon d’explosion peut être beaucoup plus grand qu’un compromis normal de l’utilisateur. Jaju a averti qu’une machine de développeur contient souvent des cookies de session de navigateur, des jetons SSO, des clés SSH, des informations d’identification Git, du code source, des jetons Cloud CLI, des informations d’identification du gestionnaire de packages, des secrets stockés dans des fichiers locaux et un accès à la documentation interne ou aux plateformes de collaboration.
À partir de là, les attaquants peuvent accéder aux référentiels de code, aux pipelines CI/CD, aux environnements cloud, aux registres de conteneurs, aux systèmes de billetterie et aux plateformes de messagerie d’entreprise. Dans certains cas, ils n’auront pas du tout besoin de voler des mots de passe, car les jetons de session ou les sessions de navigateur authentifiées suffisent à contourner une partie de la pile de sécurité.
Même si la campagne s’est largement appuyée sur des plateformes fiables, les organisations peuvent toujours perturber les attaques à plusieurs endroits.
Dhar a souligné que la première chose à comprendre ici est que toutes les cyberattaques ne nécessitent pas nécessairement des logiciels malveillants. De nos jours, de plus en plus d’attaquants tentent de persuader leurs victimes d’agir par elles-mêmes. Par conséquent, une solution pourrait consister à limiter les privilèges administratifs inutiles, à surveiller les exécutions du shell et de PowerShell et à détecter tout comportement suspect. De plus, les PC des développeurs devront peut-être être surveillés en raison du niveau d’accès élevé dont ils disposent.
Du point de vue du contrôle, les entreprises doivent restreindre les droits des administrateurs locaux et appliquer le moindre privilège sur les points de terminaison des développeurs. Ils devraient également segmenter les environnements de développement et séparer la navigation à haut risque des flux de travail d’ingénierie privilégiés, lorsque cela est possible, a ajouté Jaju.
