Un faux processus de recrutement peut devenir une porte d’entrée dans l’environnement d’un développeur. Dans son rapport du 6 octobre 2026, Unit 42 décrit une campagne baptisée Blinder Tunnel qui a visé une personne travaillant dans le secteur des infrastructures critiques en Irak. Le leurre imitait Dubai Airports et transmettait un projet Visual Studio présenté comme un exercice de programmation.
Un parcours de recrutement conçu pour inspirer confiance
Les chercheurs indiquent que l’infrastructure était préparée depuis novembre 2025, puis activée en mars 2026. Le premier contact présentait un portail de recrutement hors ligne se faisant passer pour Dubai Airports IT. La victime potentielle était ensuite invitée à compléter une évaluation technique à domicile.
Unit 42 suit cette activité sous le nom CL-STA-1178 et estime avec un haut niveau de confiance qu’elle est liée à un acteur iranien. Il s’agit d’une évaluation de l’équipe de recherche, pas d’une attribution publiée par une autorité irakienne. Les chercheurs précisent ne pas avoir trouvé de preuve d’une compromission des systèmes de Dubai Airports.
Le fichier Visual Studio comme déclencheur
Le candidat recevait une archive contenant un projet C# présenté comme un test technique. D’après Unit 42, le fichier .csproj modifiait une cible que Visual Studio peut évaluer en arrière-plan. L’ouverture du projet pouvait donc lancer du code avant même que la personne ne compile ou exécute consciemment l’application.
La chaîne observée incluait le chargement de ShelbyLoader V2 et des mécanismes d’accès distant et de tunnel réseau. Les attaquants utilisaient notamment l’API GitHub pour communiquer avec l’infrastructure compromise. Ces détails décrivent l’échantillon analysé; ils ne permettent pas d’affirmer que tous les faux tests ou toutes les victimes ont reçu la même charge.
Pourquoi les développeurs sont exposés
Les projets logiciels ne sont pas de simples documents. Les formats de projet, scripts de construction, dépendances et outils de développement peuvent exécuter des tâches avec les droits de l’utilisateur. Un exercice de recrutement paraît crédible précisément parce que son destinataire s’attend à ouvrir et examiner du code.
Le risque concerne aussi l’accès disponible sur le poste : dépôts, jetons d’API, connexions VPN ou secrets d’environnement. Un projet piégé peut chercher à dépasser le simple ordinateur de test et atteindre des ressources professionnelles accessibles depuis la session du développeur.
Vérifications à appliquer avant un test technique
Confirmez l’identité du recruteur par un canal trouvé indépendamment sur le site de l’employeur. Vérifiez que le domaine, l’adresse de contact et le processus correspondent à une offre réelle. Une entreprise usurpée n’est pas nécessairement à l’origine du message.
N’ouvrez pas de projets inconnus sur votre poste quotidien. Si l’exercice doit être analysé, utilisez une machine virtuelle jetable ou un environnement isolé sans accès aux dépôts, secrets, VPN et comptes personnels. Prévenez l’équipe de sécurité avant toute exécution douteuse; ne vous contentez pas d’un antivirus local comme garantie.
Le lien avec Soclyde
Soclyde ne détecte pas les projets Visual Studio malveillants et ne protège pas les postes compromis. Son coffre chiffré local-first aide à limiter la réutilisation des mots de passe et à organiser les accès d’équipe. Les jetons et clés d’API doivent rester hors des projets non fiables et être révoqués dans leur service d’origine en cas d’exposition.
À retenir
Blinder Tunnel transforme une candidature de développeur en vecteur d’exécution : selon Unit 42, l’ouverture d’un projet Visual Studio piégé pouvait suffire à lancer la chaîne malveillante. Vérifiez les recruteurs, isolez les exercices externes et gardez les secrets professionnels hors de portée des environnements de test. Pour structurer les accès d’une petite équipe, consultez notre guide de politique de mots de passe PME.