Atomic Arch : 408 packages AUR compromis, rootkit eBPF déployé

Les faits

Le 11 juin 2026, plusieurs contributeurs de la communauté Arch Linux repèrent des anomalies dans les scripts de build de packages hébergés sur l'Arch User Repository. Ce qui ressemblait d'abord à un incident isolé s'est révélé être une campagne coordonnée de grande ampleur, baptisée « Atomic Arch » par les analystes de Sonatype. En moins de vingt-quatre heures, les trackers communautaires ont catalogué 408 packages compromis, dont plusieurs figuraient parmi les plus téléchargés du dépôt. L'attaque combine détournement de comptes mainteneurs, injection de charges utiles dans les fichiers PKGBUILD et déploiement d'un implant furtif au niveau du noyau : cette chaîne AUR supply chain rootkit eBPF permet aux opérateurs de masquer processus, connexions réseau et fichiers aux outils d'investigation classiques. Retour détaillé sur le mode opératoire, l'impact réel et les mesures de remédiation.

Le vecteur d'entrée est redoutablement élégant. Les attaquants ont ciblé des packages orphelins : des projets légitimes abandonnés par leurs mainteneurs d'origine. L'AUR dispose d'un processus standard d'adoption permettant à n'importe quel utilisateur enregistré de reprendre la maintenabilité d'un package orphelin. Les acteurs de la menace ont exploité ce mécanisme pour réclamer des dizaines de packages populaires, s'appropriant ainsi la confiance accumulée par ces projets auprès de la communauté. Une fois en possession des droits de mainteneur, ils ont procédé à des modifications chirurgicales des fichiers PKGBUILD — les scripts qui orchestrent la compilation et l'installation des packages sous Arch Linux.

La modification est minimaliste et difficile à détecter lors d'une relecture rapide : l'ajout d'une commande d'installation de deux packages npm frauduleux, atomic-lockfile et js-digest. Ces packages, publiés sur le registre npm, servent de dropper pour un payload ELF Linux nommé deps. Ce binaire est au cœur de la campagne : il s'agit d'un credential stealer complet avec un module optionnel de rootkit eBPF, activé uniquement lorsque le processus dispose des privilèges root sur le système cible.

Le champ des cibles du payload deps est particulièrement révélateur des intentions des attaquants. L'infostealer extrait les données de navigation (Chrome, Chromium, Firefox), les tokens stockés dans les applications Electron (Slack, Microsoft Teams, Discord), les identifiants GitHub et npm, les secrets HashiCorp Vault, les configurations Docker et Podman, les clés SSH et le matériel VPN, ainsi que les historiques shell bash et zsh. Cette liste n'est pas celle d'un attaquant cherchant à voler des cartes bancaires — c'est celle d'un acteur ciblant spécifiquement les développeurs pour pivoter vers des environnements de production et des dépôts de code source.

Le composant rootkit exploite eBPF (extended Berkeley Packet Filter), le framework d'exécution de programmes dans le noyau Linux introduit dans les versions 3.18+ et massivement enrichi depuis. Contrairement aux rootkits traditionnels basés sur des modules noyau (LKM) qui modifient directement le code du kernel, un programme eBPF est exécuté dans une sandbox noyau vérifiée par le verifier eBPF. Cette caractéristique lui confère une double propriété mortelle pour les défenseurs : une stabilité système comparable au code noyau natif, et une furtivité accrue face aux outils de sécurité conventionnels. Une fois chargé avec les privilèges suffisants, le rootkit eBPF peut intercepter des appels système, masquer des processus et des connexions réseau, et persister après la suppression du package malveillant initial.

La chaîne d'infection complète se déroule de manière transparente pour l'utilisateur final. Un développeur Arch Linux exécute yay -S nom-du-package ou paru -S nom-du-package. Le helper AUR télécharge et exécute le PKGBUILD modifié, qui installe silencieusement les packages npm malveillants en arrière-plan pendant la compilation du package légitime. Le payload deps s'exécute, exfiltre les secrets vers une infrastructure de command and control non encore publiquement identifiée, et — si l'utilisateur dispose des droits root — charge le rootkit eBPF dans le noyau. L'installation du package demandé se termine normalement, sans aucun signe visible de compromission.

La réponse de la communauté a été rapide. Dans les heures suivant la découverte, un outil de détection baptisé aur-malware-check a été publié sur GitHub (dépôt lenucksi/aur-malware-check), consolidant les Gists communautaires initiaux. Cet outil automatise la vérification des PKGBUILD installés contre la liste des packages compromis et recherche la présence d'atomic-lockfile ou js-digest dans les scripts de build. L'équipe Arch Linux a été notifiée et procède à la suppression des packages compromis du dépôt, mais les systèmes déjà infectés ne sont pas automatiquement assainis.

L'attribution de la campagne reste en cours. Le niveau de sophistication — notamment la maîtrise du développement eBPF kernel-level, combinée à la patience nécessaire pour adopter des dizaines de packages orphelins sans éveiller les soupçons — pointe vers un acteur structuré. La concentration exclusive sur les secrets développeur plutôt que sur des cibles financières suggère une opération d'espionnage industriel ou de préparation d'attaques supply chain en cascade. Selon BleepingComputer, « Atomic Arch » constitue l'incident supply chain le plus significatif jamais enregistré sur l'AUR.

Impact et exposition

Sont exposés tous les utilisateurs d'Arch Linux — particuliers, entreprises, environnements CI/CD — ayant installé l'un des packages compromis via un helper AUR entre mi-mai 2026 et le 12 juin 2026. Les images Docker basées sur Arch Linux utilisant des packages AUR sont également concernées. La compromission d'un seul poste de développement peut avoir des conséquences en cascade : un token GitHub valide suffit à accéder à des dépôts privés d'entreprise, à empoisonner des pipelines CI/CD, ou à injecter du code malveillant dans des projets open source publiés depuis la machine compromise.

Recommandations

• Exécuter immédiatement aur-malware-check (GitHub : lenucksi/aur-malware-check) pour identifier les packages compromis installés
• Révoquer et régénérer sans délai tous les tokens présents sur les machines à risque : GitHub Personal Access Token, npm, Docker Hub, HashiCorp Vault, clés SSH
• Auditer les pipelines CI/CD ayant tourné sur des runners Arch Linux : vérifier l'intégrité des artefacts publiés depuis mai 2026
• Scanner les systèmes avec Falco ou Tetragon pour détecter des programmes eBPF non autorisés (sudo bpftool prog list)
• Renforcer la politique AUR : n'installer que des packages AUR avec PKGBUILD relus manuellement ou depuis des sources de confiance établies