Cyberarnaques RH dopées à l’IA : le piège DeceptiveDevelopment

Un chiffre résume l’époque : l’accès initial (le moment où un attaquant met un pied dans votre SI) se fait de plus en plus souvent sans faille technique, mais via un humain. Le cas DeceptiveDevelopment, documenté en 2025 par des chercheurs en sécurité, est emblématique : des développeurs sont infectés non pas parce que leur OS est « vulnérable », mais parce qu’un faux recruteur les convainc de lancer un “test technique” piégé.

Ce qui change en 2025, c’est la qualité de la tromperie, portée par des outils d’IA : identités synthétiques, CV crédibles, scripts de conversation, parfois même face swap en entretien vidéo. Et derrière, un ensemble de malwares multiplateformes (Windows, macOS, Linux) spécialisés dans le vol de données et de cryptomonnaies. La réalité ? Beaucoup d’entreprises continuent à traiter ça comme un sujet “RH” ou “conformité”. C’est un sujet cybersécurité à part entière.

Dans cette publication de notre série « Intelligence artificielle dans la cybersécurité », je vous propose une lecture utile et opérationnelle : comment fonctionne ce type de menace hybride (fraude + intrusion), pourquoi l’IA rend l’attaque plus rentable, et surtout quelles défenses concrètes mettre en place — avec une place centrale pour la détection augmentée par l’IA.

DeceptiveDevelopment : une attaque “recrutement” qui finit en compromission

Point clé : l’entretien d’embauche est devenu une surface d’attaque. DeceptiveDevelopment opère comme un “studio” de social engineering : faux profils, plateformes freelances, messageries, dépôts de code privés… tout est conçu pour amener la victime à exécuter quelque chose “par elle-même”.

Le scénario est rodé : un profil de recruteur (parfois compromis, donc plus crédible) contacte un développeur sur des plateformes professionnelles. L’offre est attirante, souvent liée à la crypto ou au Web3 (cibles à forte valeur, habituées à manipuler des wallets). Puis vient l’étape critique : coding challenge ou projet à récupérer via un dépôt Git privé.

Le piège est simple et efficace : le dépôt contient du code trojanisé. L’implant malveillant peut être caché dans de longs commentaires, hors champ dans l’IDE, ou empaqueté de façon à ressembler à des dépendances banales. L’attaquant n’a pas besoin d’exploiter une CVE : la victime lance elle-même le code.

ClickFix : quand le “support” devient le malware

Point clé : l’attaquant exploite la frustration et l’inertie cognitive. Une variante particulièrement pernicieuse observée en 2025 s’appuie sur une technique de manipulation appelée ClickFix.

Le mécanisme : une fausse plateforme d’entretien demande au candidat de remplir un formulaire long (investissement de temps), puis de “tester la caméra”. Une fenêtre prétend que l’accès caméra/micro est bloqué et propose un lien “How to fix”. Ce lien donne des instructions selon l’OS : ouvrir un terminal et copier-coller une commande.

Cette commande ne “répare” rien : elle télécharge et exécute une charge malveillante.

Une phrase à retenir : si un site d’entretien vous demande d’ouvrir un terminal, ce n’est plus un entretien — c’est une intrusion.

Une chaîne d’infection multiplateforme, pensée pour l’échelle

Point clé : ce n’est pas la sophistication isolée qui impressionne, c’est l’industrialisation. L’arsenal observé s’étend de scripts obfusqués à des RAT plus complets, avec un objectif constant : voler (identifiants, données navigateur, wallets) et monétiser.

Les premiers étages : scripts obfusqués et vol de données

On retrouve des charges initiales typiques en JavaScript ou Python, conçues pour passer pour des fichiers de projet. Leur rôle :

• collecter rapidement des données (logins navigateur, keychains, extensions de wallets)
• télécharger un second étage plus robuste

Le point opérationnel important pour un RSSI : ces charges sont compatibles Windows/macOS/Linux. Donc les environnements dev (MacBook + Linux + conteneurs) ne sont pas “moins exposés”, juste exposés différemment.

WeaselStore : voler, puis garder la main

Point clé : l’infostealer devient un RAT. Un outil comme WeaselStore illustre une tendance : après exfiltration, le malware continue à communiquer et peut exécuter des commandes. On passe du vol opportuniste à une présence exploitable.

Un détail révélateur de la logique “scalable” : certaines variantes sont livrées en code source Go, avec ce qu’il faut pour compiler localement. Ça complique certaines détections basées uniquement sur les binaires connus : le “binaire final” est fabriqué chez la victime.

TsunamiKit : le kit “prêt à l’emploi” et l’économie du dark web

Point clé : les attaquants réutilisent et adaptent. TsunamiKit montre qu’un acteur peut intégrer un projet plus ancien, probablement issu de places de marché clandestines, puis l’insérer dans une chaîne moderne.

Pour les défenseurs, c’est un signal fort : il ne faut pas seulement traquer des familles de malwares “nouvelles”. Il faut détecter des comportements : persistance, exclusions Defender, injection, minage (XMRig/NBMiner), usage de proxy Tor…

L’IA côté attaque : identités synthétiques, entretien proxy, fraude RH

Point clé : l’IA ne sert pas qu’à coder, elle sert à mentir de façon cohérente. L’enquête met en évidence un lien entre la compromission “technique” (malware) et une fraude “métier” : des travailleurs IT nord-coréens opérant sous de fausses identités.

Le modèle est complémentaire :

• DeceptiveDevelopment compromet des développeurs via de fausses offres.
• Des équipes de faux candidats exploitent ensuite identités volées, CV falsifiés, comptes et historiques pour obtenir des missions réelles.

L’IA intervient à plusieurs niveaux :

• retouche photo et cohérence des profils (LinkedIn, portfolios, historique)
• génération de CV et lettres adaptés à chaque offre
• scripts de conversation “naturels” avec recruteurs
• parfois face swap en temps réel pendant les entretiens vidéo

Ce n’est pas seulement une fraude financière. Pour une entreprise, embaucher un “employé” qui n’est pas celui qu’il prétend être crée un risque d’insider threat : accès aux dépôts, aux secrets CI/CD, aux environnements cloud, aux consoles d’admin.

Pourquoi la cybersécurité a besoin d’IA (vraiment) contre ce type de menace

Point clé : vous ne pouvez pas “former” votre SI à la main, il faut l’observer en continu. Les attaques décrites combinent :

• social engineering crédible
• charges obfusquées
• outillage multiplateforme
• exécution via scripts
• variations constantes (dépôts, noms, empaquetage)

Dans ce contexte, une défense purement basée sur des listes statiques (hash, noms de fichiers, règles trop rigides) s’épuise vite. L’IA en cybersécurité apporte deux avantages pratiques.

1) Détection comportementale à grande échelle

Une approche efficace consiste à détecter des enchaînements anormaux plutôt que des signatures :

• un IDE ou un terminal lance une commande qui télécharge un script depuis une source non habituelle
• exécution de python, node, bash, wscript dans un contexte “entretien/recrutement”
• création de persistance + modification de paramètres de sécurité (exclusions Defender)
• collecte et lecture de bases navigateurs, keychains, extensions de wallets

Les modèles (et plus largement l’analytique augmentée) excellent pour corréler ces signaux faibles : un événement isolé est banal, la séquence ne l’est pas.

2) Lutte antifraude : relier RH, IT et sécurité

La meilleure défense contre les faux candidats n’est pas un contrôle unique, c’est un faisceau d’indices.

Voici ce que j’ai vu fonctionner sur le terrain :

• score de risque d’identité (cohérence des données, recoupements, signaux d’anomalie)
• détection d’entretien proxy (incohérences audio/vidéo, comportements, changements de latence, empreintes d’environnement)
• contrôles d’accès contextuels : un nouvel arrivant n’a pas immédiatement accès à tous les secrets, dépôts sensibles et environnements de prod

L’IA n’est pas là pour “remplacer” le recruteur ou le RSSI. Elle sert à prioriser et à déclencher les bons contrôles au bon moment.

Mesures concrètes pour réduire le risque (checklist opérationnelle)

Point clé : sécuriser l’embauche et les tests techniques fait partie de votre posture de sécurité. Voici une liste d’actions réalistes, particulièrement pertinentes fin 2025.

Côté RH / recrutement (prévention de la fraude)

1. Standardiser les tests techniques : pas de dépôts “privés” envoyés par un inconnu. Utiliser une plateforme interne ou un fournisseur validé.
2. Interdire le “copier-coller terminal” dans le processus : si une étape nécessite une commande, elle doit être fournie par l’entreprise, documentée et revue.
3. Vérification d’identité renforcée pour postes sensibles : contrôle documentaire + vérification vidéo encadrée + recoupements (sans tomber dans l’intrusif illégal).

Côté engineering / IT (réduction de surface)

• Exécuter tout “coding challenge” dans une VM jetable ou un environnement isolé (pas sur le poste principal, pas avec accès aux wallets).
• Séparer strictement : machine perso / machine pro / environnements crypto.
• Bloquer ou encadrer l’exécution de scripts non signés (politique PowerShell, contrôle d’applications, durcissement macOS/Linux).

Côté SOC (détection + réponse)

• Mettre en place des règles sur la chaîne d’exécution : navigateur → terminal → téléchargement → exécution.
• Surveiller les accès anormaux aux données navigateur et aux emplacements de wallets.
• Automatiser le triage : quand un signal “ClickFix-like” apparaît, isoler l’hôte, collecter artefacts, révoquer sessions.

Une décision simple qui change tout : tout test technique externe doit être traité comme un code potentiellement hostile.

Ce que cette affaire dit de 2026 : l’entreprise doit penser “écosystème de menace”

DeceptiveDevelopment n’est pas seulement un groupe “malware”. C’est un exemple d’écosystème où l’on mélange fraude à l’embauche, vol d’identités, intrusion et monétisation. Et l’IA agit comme accélérateur : elle réduit le coût de production du mensonge (profils, messages, CV) tout en augmentant le taux de réussite.

La réponse cohérente suit la même logique : IA pour détecter, IA pour corréler, IA pour prioriser, mais aussi gouvernance pour casser la chaîne (processus de recrutement, outillage dev, contrôle d’accès). Si vous traitez ça uniquement comme un problème de sensibilisation, vous perdrez.

Si vous deviez choisir un prochain pas dès cette semaine : cartographiez votre processus d’embauche “tech”, identifiez où un candidat peut vous faire exécuter du code, puis ajoutez une couche de détection comportementale. La question n’est plus “est-ce que ça arrivera ?”, mais à quel moment votre organisation dira non — et comment elle le verra venir.