SleeperGem est le nom de la campagne identifiée par Aikido Security en juillet 2026. Trois paquets RubyGems malveillants ont pénétré le registre public et sont passés inaperçus lors de l’intégration continue. De plus, ils ont été conçus pour reconnaître un pipeline et se désactiver au bon moment. Autrement dit, la cible n’était jamais le build. La cible était la machine du développeur.
Pourquoi votre CI n’a absolument rien détecté
La réponse réside dans le comportement du code. Tout d’abord, le chargeur vérifie environ une trentaine de variables d’environnement avant d’exécuter quoi que ce soit. Ces variables correspondent à celles que les plateformes CI définissent par défaut, comme GITHUB_ACTIONS, GITLAB_CI et CIRCLECI. Si l’une d’elles apparaît, le processus se termine immédiatement et ne fait plus rien. Par conséquent, une installation de routine dans le pipeline ne montre aucun signe. Les runners CI sont éphémères et surveillés. De plus, ils ont peu de valeur pour celui qui cherche un accès durable. En revanche, l’ordinateur portable du développeur conserve des identifiants de longue durée, des jetons cloud et des clés SSH. Ce choix de conception révèle où se situe la véritable exposition.
Les trois gems que personne n’a examinées à temps
Les paquets impliqués sont git_credential_manager, Dendreo et fastlane-plugin-run_tests_firebase_testlab. En pratique, le premier imite l’outil officiel de Microsoft, le Git Credential Manager. Deux des trois étaient restés inactifs pendant des années, l’un d’eux n’ayant pas reçu de mise à jour depuis 2020. Puis, des versions nouvelles ont émergé à quelques minutes d’intervalle. Aucune d’elles n’avait de commit ou de tag correspondant dans le dépôt d’origine sur GitHub. Par conséquent, l’origine n’était déjà plus fiable. C’est le genre d’indice que toute équipe devrait surveiller.
SleeperGem: le require devient déclencheur d’exécution
Voici la partie qui fait froid dans le dos. À partir de la version 2.8.2 de git_credential_manager, le code malveillant se déclenche dès le require. Il suffit que le projet charge la bibliothèque en mémoire. Le require ouvre un processus Ruby enfant qui exécute un script d’installation. Puis, ce script accède à un Forgejo contrôlé par l’attaquant. De là, il télécharge un shell script et un binaire natif. Curieusement, le binaire porte le même nom que l’outil qu’il feint d’imiter. La connexion supprime en outre la vérification de certificat. De plus, l’User-Agent devient simplement le mot Git. Ainsi, le trafic malveillant se mêle à l’activité normale du développeur.
Deux versions qui révèlent l’attaquant en train d’itérer
Les deux versions finales montrent l’attaquant en train d’ajuster les choses de manière visible. La version 2.8.2 télécharge le payload, mais laisse la ligne d’exécution kommentée. Ainsi, l’attaque est préparée sans se déclencher. La version 2.8.3 supprime cette barrière. Lors de l’exécution, le script dépose le binaire dans un dossier caché dans le répertoire personnel. Ensuite, il marque le fichier comme exécutable et démarre un daemon en arrière-plan.
Du require au root en quelques étapes
La persistance apparaît en double. Le malware met en place deux mécanismes simultanément. D’abord, il crée un service utilisateur via systemd. Ensuite, il ajoute une entrée dans cron. Tous deux utilisent le nom apparemment innocent git-credential-manager. Par conséquent, supprimer une méthode ne supprime pas l’autre. Puis, le script vérifie si l’utilisateur appartient aux groupes sudo ou wheel. Si le sudo sans mot de passe est actif, il se réexécute en tant que root. À ce stade, il dépose une copie setuid du shell système. Le chemin choisi rappelle celui d’un utilitaire réseau, afin de paraître légitime.
Sur le runner StepSecurity, le sudo sans mot de passe était désactivé. C’est pourquoi ce volet s’est arrêté à l’étape du contrôle de groupe. Néanmoins, le chemin existe et fonctionne dans la version publiée. Toute machine configurée avec du sudo sans mot de passe s’y retrouverait directement. D’ailleurs, cette configuration est courante sur les postes individuels.
Ce que Harden-Runner a enregistré ligne par ligne
A StepSecurity a exécuté chaque version compromise sur le Harden-Runner. L’outil a reconstitué la chaîne complète dans l’ordre. En pratique, l’arborescence des processus a montré chaque étape. D’abord, le require qui ouvre le processus enfant d’installation. Puis le téléchargement et l’exécution de deploy.sh. Ensuite, la copie du binaire dans ~/.local/share/gcm/. Enfin, la montée du daemon, l’installation de systemd et cron et la vérification de groupe avec sudo. Ce niveau de détail sépare l’analyse dynamique d’un examen statique. En effet, l’analyse statique pointe le motif suspect. L’exécution réelle, toutefois, ne peut être confirmée qu’en dynamique.
Les journaux réseau ont bouclé l’affaire. Le processus Ruby a accédé git.disroot.org, l’hôte Forgejo qui servait le payload. De plus, le plugin fastlane a contacté le même hôte. En somme, les trois paquets appartiennent à une seule opération. Le comportement de sortie du daemon échappe toutefois à l’évaluation d’un test au niveau de la gem. Pour confirmer une exfiltration d’identifiants, il faudrait une analyse binaire séparée.
Où votre équipe est réellement exposée
Voici la principale leçon à retenir. L’analyse des dépendances via les hooks CI détecte les malwares qui agissent de la même façon dans les deux environnements. SleeperGem agit toutefois différemment selon l’environnement. Par conséquent, ce type de balayage passe à côté. Et les prochaines campagnes qui copieront la technique échapperont également. Alors que les équipes renforcent le pipeline, la machine du développeur reste peu instrumentée. Or, c’est là que résident les jetons, les clés et les identifiants persistants. Donc le point aveugle a changé d’emplacement.
Comment renforcer la machine du développeur dès aujourd’hui
Tout d’abord, retracez l’origine de vos dépendances. Une gem sans commit ni tag correspondant mérite une suspicion immédiate. Ensuite, examinez les versions qui réapparaissent après des années de silence. De plus, verrouillez les versions et validez les hashs dans votre lockfile. Puis retirez le sudo sans mot de passe des postes de travail. Ainsi, vous fermez le chemin d’escalade vers le root. Il est aussi utile de surveiller les fichiers et les processus sur l’endpoint, et non seulement dans le pipeline. Enfin, observez les connexions sortantes étranges lors du require et de l’installation. Un User-Agent générique comme Git mérite déjà une enquête.
Le changement de stratégie que vous ne pouvez pas ignorer
SleeperGem marque une bascule nette de stratégie. En pratique, l’assaillant évite le build et vise ceux qui écrivent le code. Donc, renforcer uniquement la CI ne suffit plus. La défense doit commencer sur l’ordinateur portable de chaque développeur. Renforcez le point d’extrémité dès aujourd’hui, avant que la prochaine gemne fasse semblant de dormir.
Siguez notre profil sur Instagram !
