L'erreur du hacker lui a ouvert la porte
Pendant 22 mois, Vangelis Stykas a observé de l'intérieur une équipe de hackers d'État nord-coréens, non pas parce qu'il s'était introduit dans leurs systèmes, mais parce que leur propre logiciel malveillant avait d'abord infecté leurs propres postes de travail. Stykas, directeur technique de l'entreprise de cybersécurité Kumio, a expliqué lors de la conférence Black Hat à Las Vegas, début août 2026, que les opérateurs s'étaient infectés eux-mêmes, lui ouvrant une fenêtre sur leurs canaux internes Slack et Discord.
Cet accès accidentel lui a offert une vue discrète sur environ 5 téraoctets de données que le groupe avait volées à ses propres victimes, ainsi qu'un regard rare sur le fonctionnement quotidien de l'opération, totalement indétecté par les hackers eux-mêmes.
1 640 entreprises, 57 pays, une douzaine de noms
Stykas a indiqué que le groupe avait compromis 1 640 entreprises dans 57 pays pendant la période où il avait accès. Entre 700 et 800 de ces intrusions, il les a classées comme sévères, c'est-à-dire que les attaquants avaient atteint un accès root aux serveurs, aux environnements cloud AWS ou aux portefeuilles de cryptomonnaies, bien au-delà d'un simple point d'appui sur une seule machine.
Dans sa présentation, Stykas a publiquement nommé une douzaine environ des organisations touchées, dont le fabricant de smartphones Oppo, Coinbase, Uniswap Labs, le Boston Children's Hospital et plusieurs agences gouvernementales qu'il n'a pas identifiées par leur nom.
L'entrée s'est faite par un entretien d'embauche
Indépendamment des recherches de Stykas, les équipes de sécurité d'Elastic Security Labs, de Proofpoint et d'autres entreprises suivent depuis 2026 une campagne nord-coréenne active connue sous le nom de Contagious Interview, liée au Lazarus Group. Les opérateurs se font passer pour des recruteurs sur des plateformes comme LinkedIn, approchent des développeurs de logiciels avec ce qui ressemble à une offre d'emploi authentique, puis envoient un test de programmation hébergé sur un dépôt GitHub.
Le piège se trouve dans le dossier .githooks du dépôt sous forme de hook de pré-commit, de sorte qu'il se déclenche automatiquement dès que le développeur valide son code de test, sans téléchargement ni double clic distinct. D'autres variantes de la même campagne ont dissimulé la charge malveillante dans des fichiers image SVG par stéganographie, et Proofpoint a recensé plus de 250 e-mails de recrutement malveillants rien qu'en avril et mai 2026, concentrés sur les travailleurs de la technologie, de l'éducation et de la finance, avec un accent particulier sur les postes liés aux cryptomonnaies.
Ce que fait réellement le logiciel malveillant
Les familles de logiciels malveillants utilisées dans ces campagnes, dont OTTERCOOKIE et des outils apparentés, sont conçues pour voler les identifiants de navigateur, les portefeuilles de cryptomonnaies et des fichiers, et pour donner aux opérateurs un accès à distance à la machine infectée. Pour un développeur, cet accès atterrit souvent dans le même environnement qui contient les dépôts de l'entreprise, les identifiants cloud et les données clients.
C'est là le lien entre les deux fils. Un groupe capable de mener des intrusions à l'échelle documentée par Stykas, 1 640 entreprises dans 57 pays, mène aussi, de façon documentée, une part significative de son accès par l'acte ordinaire du recrutement, ce qui rend ce vecteur pertinent pour toute entreprise de l'UE ou du Royaume-Uni qui recrute des développeurs ou des prestataires à distance, et pour tout développeur actuellement en recherche d'emploi.
Trois vérifications avant de cloner ce dépôt
La défense pratique est précise, pas un conseil générique contre le phishing. Vérifiez l'identité d'un recruteur de manière indépendante, via la page carrières propre de l'entreprise ou un employé connu, avant d'exécuter tout code qu'il vous envoie. Considérez un test de programmation qui exige de cloner un dépôt complet avec des hooks et des scripts d'installation comme plus suspect qu'un test livré via une plateforme isolée en bac à sable, car le bac à sable supprime précisément le mécanisme dont dépend l'astuce .githooks.
Considérez un calendrier de recrutement inhabituellement rapide et sous pression comme un signal d'alarme plus fort qu'il ne l'aurait été il y a un an, et n'exécutez jamais un script d'installation, npm install ou une commande de build depuis un dépôt de test avant que cette vérification d'identité soit terminée. Rien de tout cela n'exige de nouveaux outils, seulement une pause avant que la première commande ne s'exécute.
À lire ensuite: Changez chaque clé de CI utilisée le 4 août | Le test d'intrusion s'est installé en production
