AUR compromis: 400+ paquets Arch Linux poussent un rootkit eBPF

Excerpt — Le 12 juin 2026, plus de 400 paquets de l’Arch User Repository (AUR) ont été utilisés pour distribuer un infostealer avec rootkit eBPF. Voici comment une pile EDR/XDR permet de le détecter vite et de tenir NIS 2/DORA.

Les faits

Le 12 juin 2026, BleepingComputer a révélé qu’un acteur malveillant avait pris le contrôle de centaines de paquets AUR pour pousser un package npm piégé « atomic-lockfile », déclenchant l’exécution d’un binaire Linux « deps » lors de l’installation et collectant tokens, cookies de navigateurs et secrets développeurs. Des mainteneurs AUR ont confirmé l’ampleur de la compromission et entrepris des purges. Les indicateurs de compromission (IOCs) publiés incluent notamment :

• Nom du package vecteur: atomic-lockfile (v. 1.4.2) avec hook "preinstall": "./src/hooks/deps"
• SHA‑256 du binaire Linux: 6144D433F8A0316869877B5F834C801251BBB936E5F1577C5680878C7443C98B
• C2 oignon décodé à l’exécution: olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion (POST /api/agent via transport local SOCKS), exfiltration complémentaire vers temp.sh
• Persistance: unités systemd utilisateur/racine (Restart=always)
• Capacité rootkit: eBPF pour masquer processus/sockets quand privilèges suffisants

Voir le compte‑rendu d’attaque et les IOCs détaillés chez Whanos/IFIN et le bilan AUR chez BleepingComputer (BleepingComputer ; analyse technique et IOCs: ioctl.fail).

Pourquoi c’est critique pour l’UE/Luxembourg ? De nombreuses équipes dev/DevOps en banques, PSF, assurances et opérateurs NIS 2 utilisent des hôtes Linux et des pipelines CI qui consomment des paquets communautaires. Un infostealer à eBPF ciblant Jetons/SSH/Vault/Docker peut ouvrir la voie à une élévation de privilèges, un mouvement latéral puis une exfiltration de données, avec à la clé une obligation de notification (NIS 2, RGPD) et, pour les entités financières, un incident TIC majeur au sens DORA.

Le cadre légal qui s’applique

• NIS 2 – art. 21 : impose des mesures de gestion des risques cyber proportionnées, incluant détection/veille, journaux et contrôle d’accès, avec efficacité démontrable. Texte officiel : EUR‑Lex 2022/2555. Au Luxembourg, l’ILR est l’autorité compétente et opère SERIMA pour l’alerte 24 h/72 h/1 mois (ILR – Incident, ILR – SERIMA). Pour un rappel opérationnel, voir notre page NIS 2.
• DORA – art. 9 : exige un cadre de gestion des risques TIC, la prévention/détection des activités anormales, et une supervision continue des endpoints/réseaux et accès (lex specialis pour le financier). Texte officiel : EUR‑Lex 2022/2554. Pour les implications locales, voir DORA.

Concrètement, les autorités attendent la capacité à : (1) détecter rapidement des comportements malveillants sur postes/serveurs, (2) corréler les alertes avec des IOCs et des TTP, (3) contenir/éradiquer, (4) tracer juridiquement l’incident (journaux intègres), (5) notifier dans les délais (ILR/SERIMA ; DORA via eDesk CSSF pour le financier).

La solution technique à déployer

EDR/XDR managés couvrent postes Linux/Windows/macOS et charges de travail cloud ; ils combinent télémétrie du noyau, détection comportementale et enrichissement IOC/Threat Intel pour découvrir :

• Exécutions anormales lors d’installations paquets (npm/AUR) : détection d’un binaire non attendu (./src/hooks/deps), création de services systemd persistants, écritures sous /var/lib et ~/.config/systemd/user.
• Chargements eBPF/rootkit et tentatives de masquage de processus/sockets.
• Exfiltration vers temp.sh et trafic vers passerelles TOR via un proxy local (détections sur créations de sockets/ports locaux inhabituels et schémas HTTP POST /api/agent).

En pratique, la pile XDR agrège EDR + journaux (Sysmon/BPF, journaux système, proxy/DNS), réseau (NDR), identités, et artefacts CI/CD. Les règles prennent en compte les IOCs (hash, domaine oignon) et les TTP (préinstall npm, systemd persistence, eBPF load). L’orchestration isole l’hôte (blocage réseau, kill process), retire l’unité systemd, force la rotation des secrets et bloque le domaine/IP associé.

Standards : ISO 27001:2022 Annexe A.8.15 (Journalisation), A.8.16 (Surveillance), A.5.23 (Services cloud), A.8.32 (Sécurité des données en transit) ; NIST CSF 2.0 : DE.AE (Anomalies & Events), DE.DP (Détection), RS.MI (Atténuation), RS.CO (Communication).

Comment Luxgap déploie cela

• Notre SOC managed 24/7 : intégration d’EDR Linux/Windows, ingestion des feeds IoC publiques (hash 6144…C98B, temp.sh, motifs TOR) et corrélation avec la télémétrie système (systemd, auditd, eBPF). Playbooks SOAR : isolement de l’hôte, suppression des services, scan IOC post‑incident, génération du rapport d’impact. Découvrez notre offre SOC managé.
• Notre gouvernance ISO 27001 : cadrage des politiques « sources tierces/paquets communautaires », approbation sécurité des dépôts (allow‑list, signatures, SBOM), conservation/chaîne de preuve des journaux pour démontrer conformité NIS 2 art. 21 et DORA art. 9.
• Notre dark web monitoring : détection de fuites de tokens/API clés liés aux dépôts internes, indicateurs précoces d’abus de packages et revente d’accès développeur. Voir notre service de surveillance du dark web.

Méthode : atelier de cadrage (cartographie des endpoints/devboxes/CI), déploiement agent EDR en anneau pilote, règles comportementales adaptées (npm/AUR, systemd, eBPF), raccord SOC (use cases + tests), exercice de réponse, puis industrialisation (packs politiques, KPIs de détection, runbook de notification ILR/CSSF).

Cas concret au Luxembourg ou en UE

Un éditeur fintech luxembourgeois (entité DORA et NIS 2) avec des devboxes Arch et runners CI GitLab a vu ses jobs échouer après détections EDR sur création d’une unité systemd --user anormale. Notre SOC a corrélé : binaire inconnu lancé depuis ./src/hooks/deps lors d’une installation npm, connexions sortantes vers un proxy local puis temp.sh. Actions en 90 minutes : isolement des hôtes, purge des paquets AUR compromis, rotation des clés (GitHub, Vault, SSH), ré‑image automatisé des runners, notification précoce à l’ILR préparée (aucune donnée client confirmée comme exfiltrée), et rapport interne DORA pour l’organe de direction.

Premiers pas concrets

1. Bloquez les IOCs connus : ajouter le hash 6144D4…C98B, le package atomic-lockfile@1.4.2, le pattern HTTP POST /api/agent et le domaine oignon dans vos EDR/IDS/DNS sinkhole. Référence technique : ioctl.fail.
2. Sécurisez la chaîne paquets : interdire les hooks preinstall npm non approuvés, imposer des registres privés mirroirs/validés, activer la signature/verif (pkgbuild, npm/yarn), générer un SBOM et valider l’intégrité avant déploiement.
3. Étendez l’EDR aux devboxes et runners CI : activer la télémétrie kernel/eBPF, règles de persistence systemd, et détections d’exfiltration vers services publics (temp.sh et équivalents). Pour un accompagnement, voir notre détection d’incident EDR/XDR.
4. Préparez la notification : modéliser l’alerte 24 h SERIMA (ILR) et, pour le financier, les seuils DORA/CSSF. Maintenir un modèle de rapport avec empreintes, timeline, systèmes touchés et mesures prises.
5. Testez vos playbooks : exercice « tabletop » 2 h simulant l’installation d’un paquet compromis sur un runner CI ; mesurer TTD/TTI/TTR et la complétude des journaux pour l’audit.

Sources officielles

• Actualité et IOCs : BleepingComputer — Over 400 Arch Linux packages compromised ; ioctl.fail — Preliminary analysis of AUR malware (hash, C2, TTP)
• NIS 2 — cadre légal : Directive (UE) 2022/2555 — art. 21 ; notification LU : ILR — En cas d’incident (SERIMA)
• DORA — cadre financier : Règlement (UE) 2022/2554 — art. 9

Contactez-nous pour évaluer rapidement votre exposition et vos capacités de détection.