Faux dépôts GitHub : flux IOC pour la campagne d'infostealers par typosquatting (292+ repos)

Un développeur cherche un outil de scan de vulnérabilités, un wallet crypto en ligne de commande, ou un utilitaire macOS un peu obscur. Il tombe sur un dépôt GitHub au nom crédible, avec README propre, quelques étoiles, un installeur fourni. Il clone, il exécute. Ce n'est plus l'outil qu'il croyait installer : c'est un infostealer.

C'est le scénario documenté depuis plusieurs mois autour d'une campagne de typosquatting GitHub à grande échelle : plus de 292 dépôts identifiés à ce jour, imitant des outils de sécurité, des wallets de cryptomonnaies et des utilitaires macOS populaires. La particularité qui rend cette campagne difficile à traiter n'est pas sa sophistication technique, elle est modeste, mais sa vitesse de régénération : un dépôt supprimé après signalement réapparaît sous un nom quasi identique en quelques heures. C'est un vecteur developer-targeted distinct de la problématique de chaîne logicielle légitime que nous traitons par ailleurs (composants open source vulnérables dans un SBOM) : ici, il ne s'agit pas d'une dépendance compromise, mais d'une usurpation délibérée et volontaire d'identité de projet.

Pourquoi le nom du dépôt ne suffit jamais

Le piège classique consiste à vouloir bâtir une détection sur le nom du dépôt ou sur des motifs de typosquatting (un caractère substitué, un tiret ajouté, un suffixe -tool ou -cli). C'est une impasse, et pour une raison simple : des milliers de dépôts légitimes portent des noms qui ressemblent structurellement aux dépôts malveillants. Un fork honnête d'un scanner de sécurité, un wallet en développement actif, un utilitaire macOS maintenu par un seul développeur, tous ressemblent, de loin, à une cible de typosquatting.

La clé anti-faux positif de cette campagne tient en une phrase : ce n'est jamais le nom du dépôt qui prouve la malveillance, c'est le hash de l'installeur livré et le domaine de commande et contrôle qu'il contacte. Deux dépôts au nom identique peuvent avoir un contenu totalement différent ; deux dépôts au nom différent peuvent livrer le même binaire malveillant, recompilé pour l'occasion. Le repo est le vecteur de distribution, pas l'indicateur.

Le pack IOC : ce qu'il contient, et pourquoi il doit tourner en continu

Le pack construit pour cette campagne rassemble trois catégories d'indicateurs :

• Domaines C2 utilisés par les faux installeurs pour l'exfiltration et la persistance de configuration.
• Hashes des faux installeurs (empreintes des binaires ou scripts d'installation observés, pas des heuristiques de nom de fichier).
• Dépôts GitHub identifiés, avec leur statut (actif, supprimé, réapparu sous nouveau nom) pour tracer la réincarnation d'une même campagne.

La logique d'ingestion ne peut pas être ponctuelle. Là où un feed classique de vulnérabilités se rafraîchit à l'échelle de la journée, celui-ci exige un cycle horaire : la vitesse de recréation des dépôts après takedown se mesure en heures, pas en jours. Un pack généré une fois par semaine serait obsolète avant même sa publication.

feed:
  name: github-typosquat-infostealer
  refresh_interval: 1h
  sources:
    - github_repo_registry     # repos flaggés, statut suivi
    - installer_hash_corpus    # hash SHA-256 des installeurs
    - c2_domain_list           # domaines observés en communication post-exécution
  consumers:
    - proxy_web
    - edr_endpoint
    - yara_scanner

Détecter les clones et téléchargements en amont

Avant même l'exécution, le point d'observation le plus précoce se situe côté proxy et EDR, sur les requêtes de récupération de contenu brut. Les faux installeurs sont très majoritairement livrés via des URL raw.githubusercontent.com pointant vers les dépôts flaggés, contournant les pages de rendu GitHub.

Exemple de règle de détection proxy, simplifiée :

detection:
  title: Téléchargement depuis un dépôt GitHub flaggé (campagne infostealer)
  logsource:
    category: proxy
  detection:
    selection:
      url|contains: "raw.githubusercontent.com"
      url|contains|any:
        - "<repo-path-1>"
        - "<repo-path-2>"
    condition: selection
  level: high

Le champ url|contains|any est alimenté dynamiquement par la liste de chemins de dépôts flaggés du pack, mise à jour au rythme horaire. Une correspondance ici ne prouve pas encore l'infection : elle signale un téléchargement à corréler avec l'étape suivante.

Avant (approche naïve sur nom de dépôt) :

detection:
  selection:
    url|contains: "security-scanner"
  condition: selection

Cette règle génère du bruit sur tout développeur cherchant légitimement un scanner de sécurité open source, la grande majorité de ces occurrences seront bénignes.

Après (corrélation nom de dépôt flaggé + confirmation hash côté endpoint) :

detection:
  title: Clone GitHub flaggé suivi d'exécution d'installeur au hash connu
  logsource:
    product: edr
  detection:
    selection_download:
      url|contains: "raw.githubusercontent.com"
      url|contains|any: "<repo-path-list>"
    selection_execution:
      file_hash|in: "<installer-hash-list>"
    condition: selection_download and selection_execution near 1h
  level: critical

La condition combinée réduit le signal à ce qui compte réellement : un téléchargement depuis un dépôt sous surveillance suivi, dans une fenêtre courte, de l'exécution d'un binaire au hash connu.

Repérer l'installeur droppé côté poste de travail

Côté endpoint, l'objectif est de repérer le comportement post-clonage : un fichier exécutable ou un script d'installation apparaissant dans un chemin caractéristique (répertoire de téléchargement, répertoire temporaire, ou dossier de clone Git direct) puis s'exécutant avec des privilèges utilisateur standard, sans passer par un gestionnaire de paquets reconnu.

Les éléments à corréler sur l'EDR :

• Le hash du fichier exécuté, comparé au corpus d'installeurs connus du pack.
• Le chemin d'exécution post-clone (typiquement à l'intérieur ou à proximité d'un répertoire git clone).
• Les connexions réseau sortantes immédiates vers l'un des domaines C2 du pack.

Une règle YARA complémentaire, appliquée sur l'installeur lui-même plutôt que sur son nom de fichier, permet de couvrir les variantes recompilées d'une même famille avant même que leur hash exact soit ajouté au pack.

Sensibiliser sans culpabiliser

Le vecteur d'entrée est presque toujours le même : un développeur cherche un outil légitime (scanner de sécurité, wallet, utilitaire système) et choisit, parmi les résultats, un dépôt qui semble correspondre. Ce n'est pas une négligence isolée, c'est un point aveugle structurel : GitHub n'impose aucune vérification d'identité de projet, et les métriques de confiance habituelles (étoiles, forks, activité de commit) sont trivialement falsifiables à petite échelle.

Deux réflexes réduisent l'exposition sans ralentir le travail : vérifier l'organisation ou le mainteneur du dépôt avant tout clonage d'un outil inconnu, et croiser ce risque avec la surveillance des dépendances déjà en place dans le pipeline (analyse de SBOM). Les deux problématiques sont voisines mais distinctes : l'une porte sur une dépendance déclarée et intégrée au build, l'autre sur un dépôt cloné manuellement par un individu en dehors de tout processus de gestion de dépendances.

En résumé

Cette campagne ne se traite pas avec une liste de noms de dépôts suspects, elle se traite avec un flux qui suit le hash de l'installeur et le domaine de commande et contrôle, rafraîchi assez vite pour suivre une recréation en quelques heures, et consommé simultanément par le proxy web, l'EDR et un moteur de règles sur le binaire. Le nom du dépôt reste un signal faible, à corréler, jamais une preuve à lui seul.

C'est exactement la discipline appliquée dans le flux IOC de ThreatClaw : hash d'installeur, domaine C2 et dépôt flaggé actualisés à un rythme horaire, prêts à être consommés par votre proxy, votre EDR et votre moteur de détection sans que vos développeurs deviennent le point d'entrée de la prochaine intrusion.