Ponad 400 pakietów Arch Linux AUR przejętych w ataku supply chain z infostealerem i rootkitem eBPF

Wprowadzenie do problemu / definicja

Arch User Repository (AUR) ponownie znalazło się w centrum poważnego incydentu bezpieczeństwa. W czerwcu 2026 roku napastnicy przejęli setki porzuconych pakietów społecznościowych i zmodyfikowali ich receptury budowania w taki sposób, aby podczas instalacji pobierały oraz uruchamiały złośliwy kod.

Warto podkreślić, że incydent nie dotyczył oficjalnych repozytoriów Arch Linux. Problem uderzył przede wszystkim w model zaufania, na którym opiera się AUR, a także w praktykę przejmowania i utrzymywania opuszczonych pakietów przez nowych opiekunów.

W skrócie

Skala kampanii okazała się bardzo duża. Zidentyfikowano ponad 400 przejętych pakietów AUR, a liczba ta mogła rosnąć wraz z kolejnymi analizami społeczności i badaczy bezpieczeństwa.

• napastnicy przejmowali osierocone pakiety i modyfikowali pliki PKGBUILD lub skrypty instalacyjne,
• w procesie budowania dodawano zewnętrzne zależności pobierane z ekosystemu npm oraz bun,
• końcowym ładunkiem był binarny infostealer napisany w Rust,
• w części przypadków malware mógł aktywować komponent eBPF służący do ukrywania swojej obecności, jeśli działał z uprawnieniami roota.

Kontekst / historia

AUR różni się od klasycznych repozytoriów tym, że udostępnia receptury budowania pakietów, a nie gotowe binaria. Dzięki temu użytkownicy mają dużą elastyczność, ale jednocześnie ponoszą większą odpowiedzialność za weryfikację zawartości plików PKGBUILD oraz skryptów instalacyjnych przed ich uruchomieniem.

W tym przypadku atak nie wykorzystywał typowej podatności typu remote code execution ani włamania do oficjalnej infrastruktury Arch Linux. Napastnicy uderzyli w sam proces zaufania: zachowywali nazwy oraz historię porzuconych pakietów, a następnie wprowadzali pozornie zwyczajne zmiany utrzymaniowe, które w rzeczywistości dostarczały malware.

Kampania została powiązana z operacją określaną jako „Atomic Arch”. Początkowo mówiono o mniejszej liczbie pakietów, jednak późniejsze ustalenia wskazały na znacznie szerszą skalę kompromitacji, obejmującą setki pozycji w AUR.

Analiza techniczna

Rdzeniem ataku była zmiana logiki budowania pakietów. W zainfekowanych recepturach pojawiały się polecenia wykorzystujące między innymi npm install lub bun install do pobrania złośliwych zależności, takich jak atomic-lockfile oraz w kolejnej fali także js-digest. Oznaczało to, że użytkownik sam uruchamiał złośliwy kod w trakcie standardowej instalacji pakietu z AUR.

Złośliwy pakiet zawierał hook preinstall, który uruchamiał binarny plik ELF identyfikowany jako deps. Analizy wskazują, że był to infostealer napisany w Rust, ukierunkowany przede wszystkim na środowiska deweloperskie i systemy buildowe.

Zakres zbieranych danych był szeroki i obejmował zarówno dane użytkownika, jak i sekrety organizacyjne:

• tokeny GitHub i npm,
• poświadczenia do usług typu Vault,
• klucze SSH oraz pliki known_hosts,
• historię powłoki,
• dane Docker i Podman,
• profile VPN,
• ciasteczka sesyjne i tokeny z aplikacji opartych na Chromium oraz Electron.

Exfiltracja danych odbywała się przez HTTP do zewnętrznego serwisu uploadowego, natomiast komunikacja sterująca była realizowana z użyciem usługi ukrytej w sieci Tor i lokalnego proxy loopback. Taki model utrudniał prostą analizę ruchu oraz blokowanie zagrożenia wyłącznie na podstawie wskaźników domenowych.

Mechanizm utrwalania opierał się na usługach systemd. Jeśli malware działało z uprawnieniami roota, kopiowało się do katalogów systemowych, tworzyło własną jednostkę w /etc/systemd/system/ i konfigurowało automatyczny restart. W kontekście zwykłego użytkownika wykorzystywało katalog domowy oraz ~/.config/systemd/user/.

Szczególnie groźnym elementem był komponent eBPF. Nie odpowiadał za eskalację uprawnień, lecz za ukrywanie obecności złośliwego oprogramowania po uzyskaniu wysokich przywilejów. Rootkit mógł maskować procesy, nazwy procesów oraz inody gniazd sieciowych, co znacząco utrudniało analizę i odzyskanie zaufania do zainfekowanego hosta.

Konsekwencje / ryzyko

Incydent stanowi poważne zagrożenie zwłaszcza dla deweloperów, administratorów i zespołów DevOps. To właśnie na ich stacjach roboczych oraz hostach buildowych znajdują się często tokeny CI/CD, sekrety chmurowe, klucze SSH i dostęp do repozytoriów kodu źródłowego.

Kradzież takich danych może prowadzić do wtórnych naruszeń bezpieczeństwa, ruchu bocznego w środowisku organizacji, przejęcia pipeline’ów buildowych, a nawet do dalszych ataków supply chain wymierzonych w klientów lub partnerów.

Dodatkowym problemem jest fakt, że złośliwy kod był osadzony w naturalnym i zaufanym procesie instalacji pakietów AUR. To zmniejszało czujność użytkowników i zwiększało szanse skutecznego uruchomienia ładunku bez wzbudzania podejrzeń.

Jeżeli malware zostało uruchomione jako root i aktywowało komponent eBPF, integralność systemu należy uznać za poważnie naruszoną. W takim scenariuszu ręczne czyszczenie środowiska może nie dać wystarczającej pewności bezpieczeństwa.

Rekomendacje

Użytkownicy Arch Linux oraz dystrybucji pochodnych powinni pilnie przeprowadzić ocenę ekspozycji, szczególnie jeśli instalowali lub aktualizowali pakiety AUR od 11 czerwca 2026 roku.

• zidentyfikować wszystkie pakiety AUR instalowane lub aktualizowane w analizowanym okresie,
• sprawdzić historię budowania oraz cache pod kątem wywołań npm install atomic-lockfile, bun install js-digest i artefaktów związanych z plikiem deps,
• uznać host za skompromitowany, jeśli złośliwy pakiet został zbudowany lub uruchomiony,
• natychmiast zrotować tokeny GitHub, npm, SSH, sekrety CI/CD, poświadczenia chmurowe i sesje aplikacyjne,
• przeanalizować jednostki systemd w kontekście systemowym i użytkownika,
• sprawdzić obecność artefaktów eBPF oraz anomalii w /sys/fs/bpf/,
• monitorować ruch wychodzący pod kątem połączeń związanych z Torem i nietypowych transferów danych.

Jeżeli istnieje podejrzenie, że ładunek działał z uprawnieniami roota, najbezpieczniejszym rozwiązaniem pozostaje pełna reinstalacja systemu z zaufanego nośnika oraz odbudowa środowiska wyłącznie ze zweryfikowanych źródeł.

Długofalowo warto również wdrożyć dodatkowe środki ochronne:

• obowiązkowy przegląd plików PKGBUILD i skryptów .install przed instalacją,
• reguły wykrywające odwołania do zewnętrznych menedżerów pakietów w procesie budowania,
• ograniczenie korzystania z AUR na systemach uprzywilejowanych i serwerach buildowych,
• segmentację środowisk deweloperskich,
• stosowanie krótkotrwałych tokenów i centralnego zarządzania sekretami,
• monitoring nowych usług systemd i wykorzystania eBPF na poziomie hosta.

Podsumowanie

Incydent związany z AUR pokazuje, że współczesne ataki na łańcuch dostaw coraz częściej omijają klasyczne exploity i koncentrują się na nadużyciu zaufania do procesów utrzymaniowych oraz automatyzacji budowania pakietów. W tym przypadku przejęcie osieroconych projektów wystarczyło, aby dostarczyć infostealera i komponent ukrywający aktywność malware.

Dla użytkowników Arch Linux kluczowa lekcja jest jednoznaczna: bezpieczeństwo w ekosystemie AUR zależy nie tylko od tego, jaki pakiet jest instalowany, ale również od tego, kto go utrzymuje i jakie zmiany pojawiają się w recepturze budowania.

Źródła

1. Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit — https://thehackernews.com/2026/06/over-400-arch-linux-aur-packages.html
2. Atomic Arch npm Campaign Adds Malicious Dependency — https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency?hs_amp=true
3. Active AUR malicious packages incident — https://archlinux.org/news/active-aur-malicious-packages-incident/
4. June 2026 – Aur-general mailing list — https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/2026/6/
5. Hundreds of AUR packages compromised — https://lwn.net/Articles/1077718/