Les attaquants de GhostAction dissimulent des voleurs d'identifiants dans de fausses polices sur GitHub

L'acteur de menace derrière l'attaque de la chaîne d'approvisionnement GhostAction a changé de tactique, passant de l'injection de workflows malveillants dans des projets GitHub au phishing direct des développeurs. Dans une campagne détaillée par OpenSourceMalware le 19 octobre 2026, le groupe a déployé un voleur d'identifiants déguisé en fichier de police à travers 94 dépôts compromis. Cette évolution permet aux attaquants de collecter des données sensibles même lorsque GitHub bloque leurs workflows automatisés.

Ce qui s'est passé

Les attaquants ont enregistré le domaine "my-github[.]com" le 9 octobre 2026, le pointant vers l'adresse IP 193.32.204[.]199. Cette même IP sert de point d'exfiltration pour les données volées via des GitHub Actions malveillantes. Le jour de l'enregistrement, le groupe a envoyé des e-mails de phishing se faisant passer pour des alertes de sécurité GitHub destinés aux mainteneurs open source. Ces messages avertissaient de connexions suspectes depuis Moscou et dirigeaient les victimes vers une fausse page de connexion. Cette page agissait comme un proxy inverse, capturant les mots de passe et les codes d'authentification à deux facteurs tout en autorisant silencieusement une application OAuth avec des permissions étendues pour modifier les workflows et lire les données de l'organisation.

Une fois l'accès sécurisé, les attaquants ont injecté des fichiers malveillants dans les dépôts. La campagne comprend un composant de deuxième étape conçu pour persister sur les machines des développeurs. Cela implique la validation d'une configuration de tâches Visual Studio Code qui se déclenche automatiquement lorsqu'un dossier est ouvert, un faux fichier de police contenant une charge utile de voleur, et un workflow GitHub Actions de sauvegarde. Le fichier de police, nommé "fa-solid-400.woff2", imite un actif légitime mais collecte en réalité des clés AWS, des jetons PyPI, des jetons npm, des identifiants Git, des identifiants Kubernetes, des clés SSH et des identifiants de fournisseurs d'IA pour Anthropic Claude et Google Gemini.

Ce deuxième stade installe une tâche cron qui exécute du code fourni par l'attaquant toutes les cinq minutes si le voleur initial ne parvient pas à s'exécuter. Les données collectées sont transmises via HTTP simple sur le port 8080. OpenSourceMalware a identifié 94 dépôts appartenant à 66 propriétaires qui contiennent ce composant de deuxième étape. Quinze de ces dépôts ont depuis été supprimés, renommés ou rendus privés. La plupart des projets affectés semblent abandonnés, 65 des 79 dépôts accessibles n'ayant reçu aucun commit depuis plus d'un an.

Détails clés

• Les attaquants ont enregistré "my-github[.]com" le 9 octobre 2026, utilisant la même adresse IP que leur infrastructure d'exfiltration précédente.
• Les e-mails de phishing se faisaient passer pour des alertes de sécurité GitHub, utilisant un proxy inverse pour voler des identifiants et autoriser des applications OAuth sans consentement de l'utilisateur.
• Un faux fichier de police nommé "fa-solid-400.woff2" contient un voleur ciblant les clés cloud, les jetons et les identifiants de fournisseurs d'IA.
• Le malware installe une tâche cron qui s'exécute toutes les cinq minutes pour assurer la persistance et l'exfiltration continue des données.
• 94 dépôts répartis entre 66 propriétaires ont été compromis, beaucoup de projets semblant abandonnés ou inactifs depuis plus d'un an.
• GitHub a commencé à bloquer les workflows malveillants originaux le 9 octobre, incitant le passage à des méthodes de persistance côté client.

Contexte

Les attaques de la chaîne d'approvisionnement ciblent le cycle de vie du développement logiciel en compromettant des composants ou outils de confiance. Dans ce cas, les attaquants ont exploité la confiance que les développeurs placent dans les dépôts open source et les environnements de développement intégrés comme Visual Studio Code. En déguisant le malware sous forme de fichier de police courant, ils ont contourné l'inspection superficielle. L'utilisation du phishing via le flux d'appareil OAuth est particulièrement dangereuse car elle automatise le processus d'autorisation, accordant aux attaquants des jetons API capables de modifier les paramètres du dépôt et d'injecter davantage de code malveillant.

Les tâches cron sont des tâches planifiées qui s'exécutent à intervalles fixes sur les systèmes de type Unix. Bien qu'essentielles pour l'automatisation, elles peuvent être abusées par les attaquants pour maintenir un accès persistant à un système. Si un script malveillant est ajouté au crontab d'un utilisateur, il peut s'exécuter à répétition sans autre interaction, garantissant que les données volées continuent d'être envoyées au serveur de l'attaquant même si le vecteur d'infection initial est supprimé.

Pourquoi c'est important

Pour les équipes qui exécutent leur propre logiciel, cet incident met en évidence le risque de compter uniquement sur les contrôles de sécurité au niveau de la plateforme. La capacité de GitHub à bloquer les workflows malveillants n'a pas arrêté les attaquants ; ils ont simplement opté pour une méthode opérant sur la machine locale du développeur. Cela signifie que même si votre pipeline CI/CD est sécurisé, des dépendances compromises ou des dépôts clonés peuvent introduire des malwares qui volent des identifiants depuis votre environnement local. Ces identifiants incluent souvent l'accès à l'infrastructure de production, rendant l'hygiène locale critique pour la sécurité globale.

Le ciblage de dépôts abandonnés ou inactifs est une préoccupation majeure pour les organisations qui créent des forks ou dépendent de projets open source plus anciens. Ces projets peuvent manquer de mainteneurs actifs capables d'identifier et de supprimer rapidement les commits malveillants. Si votre équipe utilise de telles bibliothèques, vous pouvez involontairement introduire des backdoors discrets dans votre flux de travail de développement. L'utilisation de HTTP simple pour l'exfiltration suggère également que la surveillance réseau pourrait détecter ces attaques, mais seulement si le trafic vers des IP suspectes est étroitement surveillé.

Que pouvez-vous faire

• Révoquez tous les jetons d'accès GitHub et changez vos mots de passe depuis un appareil connu comme propre immédiatement si vous suspectez une exposition.
• Auditez vos dépôts pour des fichiers inhabituels, en particulier dans les dossiers d'actifs publics comme les polices, et vérifiez les configurations de tâches VS Code inattendues.
• Faites pivoter tous les identifiants potentiellement exposés, y compris les clés AWS, les jetons npm et les clés SSH, surtout ceux stockés dans des variables d'environnement.
• Surveillez vos tâches cron locales et vos tâches planifiées pour toute entrée unfamiliar qui s'exécute fréquemment ou se connecte à des serveurs externes.
• Avertissez tous les utilisateurs ayant cloné ou créé des forks des dépôts affectés pour s'assurer qu'ils ne propagent pas le code malveillant.
• Mettez en œuvre une surveillance réseau pour signaler le trafic HTTP sortant vers des IP ou ports inconnus, tels que le port 8080, utilisé dans cette campagne.