AUR compromised: 400+ Arch Linux packages push an eBPF rootkit

Excerpt — On June 12, 2026, over 400 Arch User Repository (AUR) packages were used to distribute an infostealer with an eBPF rootkit. Here’s how an EDR/XDR stack detects it quickly and supports NIS 2/DORA compliance.

What happened

On June 12, 2026, BleepingComputer reported that a threat actor hijacked hundreds of AUR packages to push a booby‑trapped npm package, “atomic-lockfile,” triggering execution of a Linux binary “deps” at install time and collecting tokens, browser cookies, and developer secrets. AUR maintainers confirmed the scope of compromise and initiated purges. Published indicators of compromise (IOCs) include:

• Vector package name: atomic-lockfile (v. 1.4.2) with hook "preinstall": "./src/hooks/deps"
• Linux binary SHA‑256: 6144D433F8A0316869877B5F834C801251BBB936E5F1577C5680878C7443C98B
• Onion C2 decoded at runtime: olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion (POST /api/agent via local SOCKS transport), additional exfiltration to temp.sh
• Persistence: user/root systemd units (Restart=always)
• Rootkit capability: eBPF to hide processes/sockets when privileges permit

See the attack write‑up and full IOCs from Whanos/IFIN and the AUR round‑up at BleepingComputer (BleepingComputer; technical analysis and IOCs: ioctl.fail).

Why this matters for the EU/Luxembourg: many dev/DevOps teams in banks, PSF, insurers, and NIS 2 operators run Linux hosts and CI pipelines that consume community packages. An eBPF‑enabled infostealer targeting tokens/SSH/Vault/Docker can enable privilege escalation, lateral movement, and data exfiltration—triggering notification duties (NIS 2, GDPR) and, for financial entities, a major ICT incident under DORA.

The applicable legal framework

• NIS 2 – Art. 21: mandates proportionate cyber risk management measures, including detection/intelligence, logging, and access control, with demonstrable effectiveness. Official text: EUR‑Lex 2022/2555. In Luxembourg, ILR is the competent authority and operates SERIMA for 24h/72h/1‑month notification (ILR – Incident, ILR – SERIMA). For an operational summary, see our NIS 2 page.
• DORA – Art. 9: requires an ICT risk management framework, abnormal activity prevention/detection, and continuous endpoint/network/access monitoring (lex specialis for financials). Official text: EUR‑Lex 2022/2554. For local implications, see DORA.

In practice, authorities expect the ability to: (1) rapidly detect malicious behavior on endpoints/servers, (2) correlate alerts with IOCs and TTPs, (3) contain/eradicate, (4) maintain legally sound evidential logs, and (5) notify within deadlines (ILR/SERIMA; DORA via CSSF eDesk for financials).

The technical solution to deploy

Managed EDR/XDR covers Linux/Windows/macOS endpoints and cloud workloads; it combines kernel telemetry, behavioral detection, and IOC/Threat Intel enrichment to uncover:

• Abnormal executions during package installs (npm/AUR): unexpected binary (./src/hooks/deps), creation of persistent systemd services, writes under /var/lib and ~/.config/systemd/user.
• eBPF/rootkit loads and attempts to hide processes/sockets.
• Exfiltration to temp.sh and traffic to TOR gateways via a local proxy (detections on unusual local sockets/ports and HTTP patterns POST /api/agent).

In practice, XDR aggregates EDR plus logs (Sysmon/BPF, system logs, proxy/DNS), network (NDR), identities, and CI/CD artifacts. Rules incorporate IOCs (hash, onion domain) and TTPs (npm preinstall, systemd persistence, eBPF load). Orchestration isolates the host (network block, kill process), removes the systemd unit, forces secret rotation, and blocks related domains/IPs.

Standards: ISO 27001:2022 Annex A.8.15 (Logging), A.8.16 (Monitoring), A.5.23 (Cloud services), A.8.32 (Data in transit); NIST CSF 2.0: DE.AE (Anomalies & Events), DE.DP (Detection), RS.MI (Mitigation), RS.CO (Communication).

How Luxgap delivers this

• Our 24/7 managed SOC: Linux/Windows EDR integration, ingestion of public IoC feeds (hash 6144…C98B, temp.sh, TOR patterns) and correlation with system telemetry (systemd, auditd, eBPF). SOAR playbooks: host isolation, service removal, post‑incident IOC scan, impact report generation. Explore our managed SOC.
• Our ISO 27001 governance: policies for third‑party/community packages, repository approval (allow‑list, signatures, SBOM), and log retention/chain of custody to demonstrate compliance with NIS 2 Art. 21 and DORA Art. 9.
• Our dark web monitoring: detection of leaked tokens/API keys tied to internal repos, early indicators of package abuse, and resale of developer access. See our dark web monitoring service.

Method: scoping workshop (endpoint/devbox/CI mapping), pilot‑ring EDR agent deployment, tailored behavioral rules (npm/AUR, systemd, eBPF), SOC integration (use cases + tests), response exercise, then industrialization (policy packs, detection KPIs, ILR/CSSF notification runbook).

Real‑world case in Luxembourg or the EU

A Luxembourg fintech (subject to DORA and NIS 2) with Arch devboxes and GitLab CI runners saw jobs fail after EDR flagged creation of an abnormal systemd --user unit. Our SOC correlated: unknown binary launched from ./src/hooks/deps during an npm install, outbound connections to a local proxy and then temp.sh. Within 90 minutes: host isolation, purge of compromised AUR packages, key rotation (GitHub, Vault, SSH), automated re‑imaging of runners, early ILR notification prepared (no client data confirmed exfiltrated), and an internal DORA report for the governing body.

First concrete steps

1. Block known IOCs: add hash 6144D4…C98B, package atomic-lockfile@1.4.2, HTTP pattern POST /api/agent, and the onion domain to your EDR/IDS/DNS sinkhole. Technical reference: ioctl.fail.
2. Secure the package chain: disallow unapproved npm preinstall hooks, enforce validated/private mirrors, enable signing/verification (pkgbuild, npm/yarn), generate an SBOM, and validate integrity before deployment.
3. Extend EDR to devboxes and CI runners: enable kernel/eBPF telemetry, systemd persistence rules, and detections for exfiltration to public services (temp.sh and equivalents). For support, see our EDR/XDR incident detection.
4. Prepare notification: model the 24h SERIMA (ILR) alert and, for financials, DORA/CSSF thresholds. Maintain a report template with fingerprints, timeline, affected systems, and remedial actions.
5. Test your playbooks: a 2‑hour tabletop simulating a compromised package install on a CI runner; measure TTD/TTI/TTR and log completeness for audit.

Official sources

• News and IOCs: BleepingComputer — Over 400 Arch Linux packages compromised; ioctl.fail — Preliminary analysis of AUR malware (hash, C2, TTP)
• NIS 2 — legal framework: Directive (EU) 2022/2555 — Art. 21; LU notification: ILR — In case of incident (SERIMA)
• DORA — financial framework: Regulation (EU) 2022/2554 — Art. 9

Contact us to quickly assess your exposure and detection capabilities.