L'offre d'emploi qui était en fait une attaque

Certains malwares n'arrivent pas comme des malwares. Ils arrivent comme une offre d'emploi.

Certains des malwares les plus sophistiqués qui visent les développeurs crypto n'arrivent pas comme des malwares. Ils arrivent comme une offre d'emploi.

Ces dernières semaines, j'ai été contacté par un flux régulier de recruteurs et de startups Web3 sur LinkedIn. Des projets DEX, des plateformes RWA, des exchanges, une blockchain santé, des startups NFT et gaming. À première vue, beaucoup semblaient parfaitement légitimes. Vrais budgets, roadmaps ambitieuses, communication soignée.

J'ai passé des années à construire des wallets, des bridges et des SDK dans cet écosystème, alors j'ai lu ces offres avec intérêt. Puis j'ai regardé de plus près, et les mêmes schémas revenaient.

Des profils de recruteurs génériques, sans rien de vérifiable derrière. Des sociétés et des sites créés seulement quelques semaines plus tôt. Des descriptions vagues qui ne survivaient jamais à une deuxième question. Des budgets surdimensionnés rattachés à des équipes introuvables. Et, presque à chaque fois, un "test technique" qui exigeait de cloner un dépôt privé, de l'installer et de le lancer en local.

Lance leur code d'abord, parle sérieusement ensuite. C'est cet ordre qui trahit l'attaque.

Dans un cas, j'ai lu le dépôt avant de rien exécuter. À l'intérieur de ce qui ressemblait à un service applicatif ordinaire, il y avait du JavaScript qui récupérait du contenu depuis une URL distante au runtime, le parsait et l'exécutait dynamiquement, et utilisait Function.constructor pour exécuter du code arbitraire tiré de l'extérieur du projet.

Ce n'était pas dans le README. C'était caché dans un fichier conçu pour ressembler à de la plomberie normale.

Si j'avais fait ce que le test demandait, npm install, npm run, ce code se serait exécuté avant que j'aie la moindre raison de faire confiance.

C'est tout l'objectif de ces campagnes. Elles ne cherchent pas à vous recaler à un entretien. Elles cherchent à faire exécuter du code non fiable par un développeur blockchain sur une machine de confiance.

Pour être clair : tous les recruteurs ne sont pas des attaquants et tous les tests ne sont pas des pièges. Beaucoup sont de vraies opportunités. Le problème, c'est l'asymétrie : se tromper une seule fois peut être total. La due diligence cesse donc d'être optionnelle.

Quelques réflexes que j'applique désormais, et que je recommande à toute personne dans cet espace : vérifier la société et l'entité légale, pas seulement la landing page. Vérifier les personnes, chercher des fondateurs avec un historique traçable. Demander une démo live avant de toucher à leur code. Lire le code avant de l'exécuter : appels réseau, évaluation dynamique, hooks postinstall. Ne jamais lancer aveuglément npm install ou npm run sur une base inconnue, les scripts d'installation s'exécutent dès l'installation. Et si vous devez lancer quelque chose d'inconnu, isolez-le : une VM ou un conteneur jetable, sans clés, sans identifiants.

Rien de tout cela n'est de la paranoïa. C'est le même threat modeling que nous appliquons aux smart contracts et aux bridges, pointé vers notre propre workflow. Si vous construisez dans le Web3, votre laptop fait partie de votre surface d'attaque.