Nicolas Berger
Expert en cybersecurite offensive

| 11 juillet 2026 · 14 min de lecture

Campagne de reconnaissance via les API GitHub : des comptes fantomes espionnent vos depots

Le 9 juillet 2026, des chercheurs en securite de plusieurs firmes independantes ont simultanement publie leurs conclusions sur une campagne de reconnaissance d'envergure ciblant les depots GitHub d'entreprises. Cette operation, qualifiee de « methodique et industrialisee » par les analystes, repose sur un mecanisme redoutablement efficace : l'utilisation combinee des API publiques de GitHub et de comptes dits « fantomes » — des profils crees plusieurs annees auparavant, laisses inactifs, puis reactives pour mener des operations de scraping systematique.

Cette decouverte intervient dans un contexte ou les cyberattaques ont augmente de 45 % par rapport a 2025, et ou l'ANSSI enregistre en moyenne 12 incidents majeurs par semaine. En France, 44 % des PME ont deja subi au moins une cyberattaque. La sophistication croissante de ces campagnes de reconnaissance — qui precedent systematiquement les attaques ciblees — impose aux RSSI une vigilance accrue sur l'ensemble de leur chaine de developpement logiciel.

— Ce qui se passe : les API GitHub detournees

Les API publiques de GitHub constituent un tresor d'informations pour quiconque souhaite cartographier l'ecosysteme technologique d'une organisation. L'API REST et l'API GraphQL permettent d'acceder, sans authentification dans de nombreux cas, a une quantite considerable de metadonnees : liste des repositories publics, historiques de commits, noms des contributeurs, fichiers de configuration, graphes de dependances, et meme les discussions dans les issues et pull requests.

La campagne identifiee le 9 juillet exploite ces endpoints de maniere systematique. Les attaquants utilisent des scripts automatises qui interrogent successivement l'endpoint /repos/{owner}/{repo} pour obtenir les metadonnees du depot, /repos/{owner}/{repo}/commits pour analyser l'historique de developpement, /repos/{owner}/{repo}/contributors pour identifier les developpeurs cles, et /repos/{owner}/{repo}/dependency-graph/sbom pour extraire la nomenclature des composants logiciels utilises.

Ce qui rend cette campagne particulierement difficile a detecter, c'est l'utilisation de user agents personnalises qui imitent parfaitement des outils legitimes de developpement. Au lieu d'utiliser des signatures reconnaissables comme python-requests/2.31 ou des bibliotheques de scraping connues, les attaquants se presentent sous des identites telles que GitHub-Hookshot, Dependabot/1.0 ou encore des signatures d'IDE populaires. Cette technique de mimicry rend les requetes pratiquement indistinguables du trafic normal genere par les outils de CI/CD et les integrateurs tiers.

Les donnees collectees permettent aux attaquants de constituer un profil technologique complet de l'organisation ciblee : langages utilises, frameworks deployes, bibliotheques tierces (et leurs versions, potentiellement vulnerables), noms et adresses email des developpeurs, horaires de travail deduits des timestamps de commit, et structure organisationnelle du projet. Autant d'informations qui deviennent des armes pour des attaques de phishing cible, de supply chain ou d'ingenierie sociale.

Le volume de cette campagne est considerable. Les chercheurs estiment que plus de 150 000 repositories ont ete scannes en l'espace de quelques semaines, avec une concentration particuliere sur les organisations basees en Europe et en Amerique du Nord. Les secteurs les plus vises comprennent la finance, la sante, les technologies de l'information et les administrations publiques — des cibles coherentes avec les objectifs habituels des groupes APT (Advanced Persistent Threat).

Avis d'expert

« Ce qui est remarquable dans cette campagne, c'est l'exploitation methodique d'API parfaitement legitimes. Les attaquants n'exploitent aucune vulnerabilite technique au sens classique du terme — ils se contentent d'utiliser les fonctionnalites publiques de GitHub exactement comme elles ont ete concues. La difference reside dans l'intention et dans l'echelle. C'est un peu comme si un cambrioleur faisait le tour de votre quartier en notant minutieusement les modeles de serrures, les horaires de presence et les systemes d'alarme visibles depuis la rue. Rien d'illegal en soi, mais la demarche est profondement inquietante. »

Nicolas Berger, Expert en cybersecurite offensive — WebGuard Agency

— Les comptes fantomes : une arme de reconnaissance discrete

Au coeur de cette campagne se trouve un element particulierement insidieux : l'utilisation de comptes GitHub dits « fantomes » (ghost accounts). Ces profils ont ete crees entre 2021 et 2024, c'est-a-dire il y a deux a cinq ans, puis laisses en dormance complete. Aucune activite, aucun commit, aucune interaction — juste un profil existant dans la base de donnees de GitHub, accumulant silencieusement de l'anciennete.

Cette strategie de maturation des comptes est redoutablement efficace pour contourner les mecanismes de detection d'abus de GitHub. La plateforme, comme la plupart des services en ligne, applique un niveau de scrutiny plus eleve aux comptes nouvellement crees. Un compte enregistre la semaine derniere qui commence soudainement a effectuer des centaines de requetes API par heure sera immediatement signale. En revanche, un compte vieux de quatre ans qui « reprend » de l'activite apres une longue pause passe beaucoup plus facilement sous les radars — apres tout, de nombreux developpeurs ont des comptes GitHub qu'ils n'utilisent que sporadiquement.

Les chercheurs ont identifie plusieurs centaines de ces comptes fantomes agissant de concert. Chaque compte opère avec un volume de requetes modere — suffisant pour collecter des donnees substantielles sans jamais depasser les seuils de limitation de debit (rate limiting) de GitHub. Cette approche distribuee permet de multiplier la capacite de scraping tout en minimisant le risque de detection ou de blocage individuel. Les comptes utilisent des adresses email jetables creees via des services de messagerie temporaire, certaines avec des domaines qui n'existent plus, ce qui rend la tracabilite extremement difficile.

Il est essentiel de distinguer cette campagne de l'attaque TeamPCP de mai 2026, qui avait utilise des extensions VS Code malveillantes pour compromettre directement les postes de developpeurs. Dans le cas present, il n'y a pas de compromission active — uniquement de la collecte passive d'informations. Cependant, cette distinction ne doit pas rassurer les RSSI : la reconnaissance est la premiere etape du cycle d'attaque, et les donnees collectees serviront inevitablement a preparer des operations offensives ulterieures, qu'il s'agisse de phishing cible, d'attaques supply chain ou de compromission de comptes de developpeurs.

L'ANSSI, qui enregistre actuellement une moyenne de 12 incidents majeurs par semaine, a publie un bulletin d'alerte specifique concernant cette campagne. L'agence souligne que la phase de reconnaissance constitue souvent le maillon le plus sous-estime de la chaine d'attaque, alors qu'elle offre la meilleure fenetre d'intervention pour les defenseurs. Detecter et perturber la reconnaissance, c'est empecher l'attaque avant meme qu'elle ne soit lancee.

Avis d'expert

« Les comptes fantomes sont quasiment impossibles a distinguer de developpeurs legitimes qui ont simplement mis leur activite en pause. Nous avons tous dans nos contacts GitHub des collegues qui n'ont pas pousse un commit depuis deux ans. C'est precisement cette normalite de l'inactivite que les attaquants exploitent. La reactivation d'un compte dormant ne genere aucune alerte, aucune notification — c'est un angle mort systemique de la plateforme. La seule parade consiste a surveiller les patterns d'acces a vos propres repositories, pas les profils des visiteurs. »

Nicolas Berger, Expert en cybersecurite offensive — WebGuard Agency

— Le lien avec les attaques supply chain

La campagne de reconnaissance via les API GitHub ne constitue pas une fin en soi — elle represente la phase preparatoire d'un cycle d'attaque plus large, intimement lie aux menaces supply chain qui se sont multipliees ces dernieres annees. En cartographiant les dependances logicielles des organisations ciblees, les attaquants identifient les maillons faibles de la chaine d'approvisionnement numerique : bibliotheques open source peu maintenues, composants avec des vulnerabilites connues non corrigees, ou encore des packages geres par un developpeur unique susceptible d'etre compromis.

Ce modus operandi s'inscrit dans une tendance de fond confirmee par les statistiques. Selon une etude Capgemini publiee au premier semestre 2026, 40 % des attaques de phishing incorporent desormais des elements generes par intelligence artificielle — des emails rediges dans un francais impeccable, personnalises avec des details techniques extraits precisement de ce type de reconnaissance. Lorsqu'un attaquant sait que votre equipe utilise une version specifique de React, une base de donnees PostgreSQL 15.3 et un pipeline Jenkins, il peut creer un email de phishing tellement contextualise qu'il devient presque indiscernable d'une communication interne legitime.

La directive NIS2, applicable depuis janvier 2026, impose des obligations specifiques en matiere de securite de la chaine d'approvisionnement. L'article 21 exige que les entites essentielles et importantes mettent en place des politiques de gestion des risques couvrant explicitement « la securite de la chaine d'approvisionnement, y compris les aspects lies a la securite concernant les relations entre chaque entite et ses fournisseurs directs ou ses prestataires de services ». Concretement, cela signifie que la surveillance des depots de code et de leurs dependances n'est plus seulement une bonne pratique — c'est une obligation reglementaire dont le non-respect peut entrainer des sanctions financieres significatives.

Les attaques supply chain precedentes illustrent parfaitement le danger. L'affaire SolarWinds (2020), l'attaque sur la bibliotheque event-stream (2018), la compromission de Codecov (2021), et plus recemment l'attaque XZ Utils (2024) ont toutes ete precedees par des phases de reconnaissance similaires. La difference est qu'aujourd'hui, cette reconnaissance est industrialisee, automatisee et conduite a une echelle sans precedent. Les attaquants ne ciblent plus une organisation specifique — ils cartographient simultanement des milliers d'environnements pour identifier les opportunites les plus prometteuses.

La correlation entre les donnees de cette campagne de reconnaissance et les attaques supply chain qui pourraient en decouler n'est pas encore completement etablie, mais les indicateurs sont preoccupants. Plusieurs des repositories les plus intensement scannes correspondent a des projets open source largement utilises dans le tissu economique francais, notamment dans les secteurs bancaire et hospitalier. Si les attaquants parviennent a identifier et compromettre un composant utilise par des centaines d'organisations, l'impact pourrait etre devastateur.

Avis d'expert

« La reconnaissance est au cyberattaquant ce que le plan d'architecte est au cambrioleur. Sans elle, l'attaque est aveugle et ses chances de succes sont limitees. Avec elle, chaque action est chirurgicale. Ce que nous observons avec cette campagne, c'est une industrialisation de la phase de renseignement — et c'est precisement ce qui la rend si dangereuse. Les entreprises qui pensent n'avoir "rien a cacher" sur leurs depots publics sous-estiment gravement la valeur des metadonnees pour un attaquant motive. Une version de dependance, un nom de developpeur, un pattern de commit — chaque fragment est une piece du puzzle. »

Nicolas Berger, Expert en cybersecurite offensive — WebGuard Agency

— Comment proteger votre organisation

Face a cette menace, les organisations doivent adopter une approche proactive et structuree. Voici sept mesures concretes que chaque RSSI devrait mettre en oeuvre pour reduire l'exposition de ses environnements de developpement a ce type de campagne de reconnaissance.

Avis d'expert

« La directive NIS2 a change la donne pour les equipes de developpement. Ce qui etait autrefois considere comme relevant uniquement de la DSI — la securite du code source et des pipelines CI/CD — est desormais une obligation reglementaire pour les entites essentielles et importantes. Les RSSI qui n'integrent pas encore la securite de leur chaine DevOps dans leur strategie de conformite NIS2 prennent un risque considerable. Le DevSecOps n'est plus un luxe ou une aspiration — c'est un imperatif legal. Et cette campagne de reconnaissance via les API GitHub illustre parfaitement pourquoi : les attaquants ciblent deja votre code, que vous en soyez conscients ou non. »

Nicolas Berger, Expert en cybersecurite offensive — WebGuard Agency