Sign in Subscribe

[UPDATE: 26/06/29] Atomic Arch: Az AUR-on keresztüli supply chain támadás testközelben, avagy fogadj örökbe te is árva linux csomagokat... [tl;dr]

tusy

• 12 min read
Share
[UPDATE: 26/06/29] Atomic Arch: Az AUR-on keresztüli supply chain támadás testközelben, avagy fogadj örökbe te is árva linux csomagokat... [tl;dr]

FRISSÍTÉS: 2026. június 29.

Amikor megjelent az eredeti poszt (jún. 15.), azt gondoltam, hogy az incidensnek vége van. Tévedtem. Az elmúlt két hétben több fejlemény is volt, amelyek érdemi kiegészítést indokolnak.

1. A végső szám: közel 2000 érintett csomag

Az eredeti posztban 1500 érintett csomagnál álltunk meg, de a közösség által összeállított és a CachyOS, az Arch Linux és a Garuda project által is hivatkozott végső listán a 1937 megerősített csomagnév szerepel, ami "majdnem 2000" érintett AUR csomag az összes hullámot figyelembe véve. Nem egy gyors lefolyású, kicsi incidensről volt szó.

2. Harmadik hullám: obfuszkált kód és troll-üzenetek oroszul

Még mielőtt a poszt megjelent volna, június 13-14. éjjelén egy harmadik, kifinomultabb hullám jelent meg. A fejlesztő a821 elsőként számolt be az új, érintett csomagokról — Node.js csomagokat, Plasma 6 appletek, Firefox-csomagokat, az Aura böngészőt, LibreWolf-kiterjesztéseket és egy NeoVim plugint tartalmazott az új hullám.

A különbség az előző hullámokhoz képest: az újabb minták a valódi parancsot shell-sztring-felosztással, vegyes idézőjelekkel és hex escape-ekkel rejtik el, hogy megnehezítsék a gyors PKGBUILD-áttekintés során való azonosítást. Az automatizált szkennereket ezzel sikeresen kijátszották.

Ami különösen zavarba ejtő volt: a támadók egyes csomagokon keresztül provokáló üzeneteket terjesztettek a felhasználóknak, például: „you're an idiot using a crap distro… don't use AUR… be thankful I didn't add actual malware", oroszul és angolul egyaránt. Ez szándékos zavartkeltés, nem véletlen.

Megjegyzendő, hogy a harmadik hullámban Nicolas Boichat kutató egy lokálisan futtatott Gemma E2B AI-modelltalkalmazott gyanús PKGBUILD-ek azonosítására. Ez egyelőre ad-hoc megoldás, de jelezheti, hogy az AI-asszisztált PKGBUILD-elemzés a jövőben strukturálisabb szereppel bírhat az AUR védelmi eszköztárában.

3. Az AUR regisztráció még mindig szünetel

2026. június 15-én az Arch Linux fejlesztők leállították az új AUR-fiókregisztrációkat, hogy időt nyerjenek a kártékony commitok eltakarítására és a felelős fiókok törlésére.

Jelen frissítés írásakor (jún. 29.) az AUR főoldala továbbra is a következőt közli: „Account registration is currently disabled." Két héttel az incidens kezdete után még mindig zárva a regisztráció. Az AUR maga elérhető, a csomagok megközelíthetők, de új fiókot nem lehet létrehozni.

Ez önmagában figyelemre méltó döntés egy olyan projekttől, amely a nyitottságára épül.

4. Kapcsolódás az IronWorm / Shai-Hulud kampányhoz

A poszt megjelenése óta a threat intelligence közösség egyre határozottabb képet rajzol a támadó kilétéről, még ha nincs is hivatalos állásfoglalás.

A Rust-alapú credential stealer és az eBPF rootkit ugyanazt a tradecraft-et mutatja, mint egy korábban dokumentált npm-kampány, amelyet JFrog kutatók IronWorm és Mini Shai-Hulud nevekkel azonosítottak.

A SafeDep Threat Intelligence HIGH bizalommal értékeli, hogy az Atomic Arch ugyanazon operátor/eszközkészlet munkája, mint az IronWorm kampány, a következő közös mutatók alapján: Rust-async ELF infostealer, eBPF rootkit, Tor hidden-service C2 (/api/agent végpont), temp.sh adatkiszűrés, és az atomic-* npm névadási konvenció.

Az összkép lassan összeáll: nem egy elszigetelt Arch-specifikus akcióról van szó, hanem egy tartós, fejlesztői infrastruktúrát célzó kampánysorozatról. (lásd a másik kapcsolódó bejegyzésemet: a FortiBleed-el kapcsolatban)

5. Júni 24: Leo Platform npm-támadás (tágabb perspektíva)

Ez az a fejlemény, amelyik engem a legjobban foglalkoztat.

2026. június 24-én, kevesebb mint 3 másodperc alatt, a támadók 20 Leo Platform npm-csomagot kompromittáltak, amelyek együttesen heti ~13 600 letöltéssel rendelkeznek.

A technikai részletek: a czirker nevű maintainer-fiók kompromittálásával a támadók ugyanazt a binding.gyp hook-mechanizmust, háromrétegű obfuszkációs láncot (ROT + AES-128-GCM + obfuscator.io) és Bun runtime-alapú végrehajtást alkalmaztak, amely az Atomic Arch esetében is megjelent.

A Microsoft Threat Intelligence és a Sonatype szerint a payload strukturálisan megegyezik a Miasma-kampánnyal (2026. június 3.), ugyanaz a támadó (threat actor), ugyanaz az eszközkészlet, most egy másik célökoszisztémában.

Az összefüggés tehát: Miasma (jún. 3.) → Atomic Arch (jún. 11.) → Leo Platform (jún. 24.), egyazon operátor, folyamatosan fejlődő, fejlesztőkre optimalizált supply chain kampány.

Ez alapján az Atomic Arch nem egy elszigetelt AUR-specifikus incidens volt. Egy jól finanszírozott, tudatos fenyegetési szereplő próbálta, és próbálja szisztematikusan kompromittálni az open source fejlesztői infrastruktúrát.

6. AUR-governance: vita van, döntés még nincs

Az Arch Linux fejlesztők az incidens nyomán várhatóan újra napirendre tűzik az AUR biztosítékainak kérdését. Szóba kerültek: szigorúbb szabályok az árva csomagok adoptálásához, várakozási időszak új fiókok számára csomagbeküldés vagy -adoptálás előtt, valamint a hirtelen tulajdonosváltások erősebb felülvizsgálata.

Konkrét, véglegesített változásról egyelőre nincs hír. A regisztráció le van zárva, a takarítás folyamatban van, de az orphaned package adoption folyamata tartalmilag változatlan, ami az egész incidens belépési pontja volt. Ez komoly kérdőjel a jövőre nézve.

Ahogy az IT-Connect fogalmazott: "I struggle to see how the AUR can continue operating in the same way." Én sem látom másképp. A change management kérdése megkerülhetetlen.

Mit jelent ez a frissítés után?

Ha az eredeti poszt alapján a vizsgálatot csak a június 10-12-es időablakra végezted el: az nem elég.

Az eredeti poszt a 10-12-es dátumtartományt adta meg, de a harmadik hullám már június 13–14-én is aktív volt, tehát a helyes ellenőrzési ablak június 10-től 14-ig terjed. A detektálási szkript (aur-malware-check) az összes hullámot lefedi, így ha még nem futtattad újra, most tedd meg erre a teljes periódusra.

Az AUR-regisztráció szüneteléséből következően: ha valaki "új, megbízható" AUR-fióknak tűnő forrásból kapott package-ajánlást az elmúlt két hétben az nem lehet valódi regisztráció alapján létrehozott fiók. Ez önmagában is gyanút kell keltsen.

A Leo Platform npm-kompromittálás ráadásul arra emlékeztet: ha a gépen érintett csomag futott, és azon npm-tokenek is elérhetőek voltak akkor azokat a tokeneket felhasználhatták a szélesebb npm-ökoszisztéma elleni laterális mozgáshoz is. Az npm audit log és a publikációs előzmények áttekintése ebben az esetben elengedhetetlen.

AZ EREDETI BEJEGYZÉS ITT FOLYTATÓDIK:

Elég ütős és mozgalmas hétvégée volt (Egy elég durva Metallica koncert csütörtökön, a munkahelyemmel, másnap színház a gyerekekkel, péntek este mozgás éjszakája, szombaton családi nap a kislányom osztályában, vasárnap szülinapi zsúr, meg játszóház, meg ilyenek... ), így amikor végül megnyitottam a hírfolyamomat és megláttam az első cikket a témáról, először azt hittem, hogy valami kisebb, izolált incidensről van szó, meghát már úgyis késő. Ahogy mélyebbre ástam, rájöttem, hogy az elmúlt évek egyik legsúlyosabb, nyílt forráskódú ökoszisztémát érintő supply chain támadásáról van szó — és én személy szerint is érintett lehetek, mert az Arch Linuxot napi szinten használom. Végül szerencsére a digitális-detox hétvége megmentett mert, az arch-ot futtató gépeim a teljes időszak alaptt ki voltak kapcsolva.

Így ez a poszt most nem csupán egy incidens-összefoglaló. Tágabb keretbe helyezem az eseményt, elmagyarázom a technikai részleteket, és konkrét lépéseket adok azoknak, akik esetleg érintettek (ha már én megúsztam). Végül a tanulság az egészből, mindannyian lehetünk áldozatok, és legtöbbször csak a vak szerencse ment meg minket ettől. Nézzük, most mégis, hogy mi is történt és mit lehet..., mit lehetett volna tenni, és mit tegyünk ha már beütött a baj?!

Mi az AUR, és miért volt sebezhetővé tehető?

Az Arch User Repository (AUR) az Arch Linux ökoszisztéma egyik legpraktikusabb funkciója: egy közösség által fenntartott csomagtár, ahol bárki feltölthet PKGBUILD fájlokat — olyan build-szkripteket, amelyek leírják, hogyan kell lefordítani és telepíteni egy szoftvert, amelyet nem tartalmaz a hivatalos Arch repó.

A modell ereje egyben a gyenge pontja is. Az AUR nem esik át olyan szigorú felülvizsgálaton, mint a hivatalos Arch csomagok. A csomagokat önkéntes maintainerek tartják karban, akik néha elhagyják a projektjeiket — így a csomag "árvává" válik. Az AUR-ban létezik egy legális folyamat erre az esetre: bárki kérheti egy árva csomag adoptálását, átvéve annak nevét, előzményeit és — ami a lényeg — az évek alatt felépített felhasználói bizalmat.

Mégis fontos megérteni, hogy az ARCH és minden leszármazottjának egyik kiemelkedő ereje ez a bizonyos AUR "közösségi" repo, ami jól formalizált egységes és jobbára működő formában ad sokszor minden más módon csak bonyolultan beszerezhető cutting-edge eszközöket a az ARCh felhasználók kezébe.

Ez a mechanizmus lett most sajnnos "Atomic Arch" kampány belépési pontja.

Mi történt? Az "Atomic Arch" kampány anatómiája

2026. június 11-én Eyad Hasan, a Sonatype kutatója először azonosította a fenyegetést. A szervezett kampány legalább június 10-én kezdődhetett, és a támadók rendkívül tudatosan közelítettek a feladathoz.

Az támadás lépései

1. Árva csomagok adoptálása — legitimnek látszó úton. A támadók kiválasztottak olyan AUR-csomagokat, amelyeket eredeti maintainereik elhagytak, de amelyeknek aktív felhasználói bázisa volt. Ezeket az AUR szokásos adoptálási folyamatán keresztül vették át. Egyik pillanatban egy megbízható szoftver volt, a következőben már a támadó irányított.

2. PKGBUILD módosítása — egy sor hozzáadásával. Miután átvették a csomagot, egyetlen sort adtak hozzá a PKGBUILD fájlhoz (post-install hook-ban): egy npm-parancsot, amely lehívja a atomic-lockfile, js-digest, vagy lockfile-js nevű rosszindulatú csomagokat. Az egyszerűség megtévesztő: nem kellett semmi nagyot megváltoztatni ahhoz, hogy a backdoor élesedjen.

3. Commit-metaadat hamisítása. A kutatók felfedezték, hogy a támadók git commit metaadatokat hamisítottak egy valódi, ismert AUR-maintainer (arojas, a KDE projekt egyik fejlesztője) személyazonosságának felhasználásával. Ez nem azt jelenti, hogy az igazi maintainer érintett — a commit history egyszerűen meghamisítható. David Runge (Arch fejlesztő) június 12-én egyértelműsítette, hogy arojas-t megszemélyesítették, nem ő a valódi támadó.

4. A malware csendes végrehajtása. Amikor egy felhasználó telepítette vagy frissítette az érintett csomagot, a PKGBUILD automatikusan lehívta és futtatta a rosszindulatú npm csomagot — a háttérben, felhasználói interakció nélkül.

A kampány mérete

Ez az, ami igazán megdöbbentett. Az első hullámban a Sonatype 408 érintett csomagot azonosított. Egy nappal később, június 12-re a közösségi kutatások alapján ez a szám 1500 fölé emelkedett (Privacy Guides). A kampány CVSS-értéke 8.7 (Sonatype-2026-003775). Ez nem egy kis incidens. Mondhatnám azt is, hogy az egyik legnagyobb amit az elmúlt időszakban láthattunk.

Mi a malware valójában? Technikai részletek

Az atomic-lockfile (és variánsai) npm csomagok egy Rust-ban írt credential stealer-t rejtenek, amely opcionálisan eBPF-alapú rootkit funkcionalitással is rendelkezik. Egy igazán hatékony kis svájci bicska... Ami kifejezetten azt célozza, hogy fejlesztőket, fejlesztői pipeline-okat kompromittáljon. Így véleményem szerint fel kell készülnünk további nagyot durranó ellátási láncot érintő támadásokra, a most kiszivárgott és nem megfelelően kezelet, vagy akár nem detektált fejlesztői accountok felhasználsásval

Mit lop el?

A payload kifejezetten fejlesztői és CI/CD-célpontokra fókuszál — nem véletlenszerű fogyasztói adatokat keres:

  • SSH kulcsok és known_hosts fájlok
  • Böngésző cookie-k és munkamenet tokenek (SSO, cloud konzolokon, SaaS alkalmazásokban)
  • GitHub, npm, PyPI és egyéb fejlesztői tokenek
  • Slack, Discord, Telegram munkamenet-adatok
  • Docker/Podman hitelesítő adatok
  • Cloud access keyek (AWS, GCP, Azure)
  • .env fájlokban tárolt titkok

Az eBPF rootkit: miért különösen veszélyes?

Ha a malware root jogosultságokkal futott (amit AUR helper-rel való telepítésnél a makepkg / sudo folyamat könnyen biztosíthat), az eBPF-alapú persistence-mechanizmus aktiválódhat. Az eBPF (Extended Berkeley Packet Filter) a Linux kernelbe ágyazott technológia, amellyel hagyományos detektálási eszközök (pl. ps, ls, standard rkhunter-scan) kijátszhatók: a rootkit elrejtheti saját folyamatait és fájljait a normál rendszerfunkcióktól.

A /sys/fs/bpf/hidden_* elérési útvonalon ellenőrizhető a jelenlétük — de csak megbízható, külső médiumról bootoló környezetből.

Commit identity forgery: a csendes vörös zászló

Különösen aggasztónak tartom a commit-hamisítás dimenzióját. A git commit metaadat egyszerűen manipulálható — ez nem egy APT-szintű képesség, hanem bárki számára elérhető technika. Mégis elegendő volt ahhoz, hogy az akár még kifejezetten biztonságtudatosnak tekinthető felhasználók se kételkedjenek a legitimációban. Ez rávilágít arra, hogy önmagában a git history vizuális ellenőrzése nem elegendő biztonsági garancia.

Kiket érint?

Közvetlenül érintett

  • Arch Linux felhasználók, akik 2026. június 10–12. között telepítettek vagy frissítettek AUR-csomagokat.
  • Arch-alapú disztribúciók felhasználói: EndeavourOS, Manjaro (ha AUR-t használnak).
  • CI/CD pipeline-ok, ahol Arch fut: önálló runnerek, build agent-ek, Docker build-környezetek.
  • WSL2 felhasználók, akik Arch Linuxot futtatnak Windows alatt és AUR-csomagokat telepítettek.

Nem közvetlenül érintett

  • A hivatalos Arch Linux csomagtár (pacman -S ... paranccsal telepített csomagok) nem volt érintett.
  • GitHub-hosted runnerek (Ubuntu/Windows/macOS) nem használnak AUR-t.
  • Debian/Ubuntu, RHEL/Rocky, openSUSE rendszerek önmagukban nem érintettek — kivéve ha valamilyen szinten Arch konténert vagy WSL instance-t futtatnak.
  • macOS Homebrew felhasználók ebben a kampányban nem érintettek, de strukturálisan ugyanez a sebezhetőség fennáll a Homebrew formula-adoptálási folyamatában is.
Fontos megjegyzés: Még ha te magad nem is futtattál Arch-ot, ha egy csapatod tagja vagy egy CI-runner igen, a lopott credentialek a te production-ödet is veszélyeztethetik. A payload nem Arch-specifikus célpontok után megy — GitHub tokenek, cloud keyek bárhol pusztíthatnak.

Hogyan ismerheted fel, ha érintett voltál?

1. lépés: Ellenőrizd az érintett csomaglistát

bash

# AUR csomagok listázása
pacman -Qm

# A közösség által összeállított detektálási szkript futtatása
# (GitHub: lenucksi/aur-malware-check)
./aur_check-v2.sh

# Egyszerű one-liner az összevetéshez
comm -1 -2 \
  <(pacman -Qq | sort) \
  <(curl -s https://raw.githubusercontent.com/lenucksi/aur-malware-check/main/package_list.txt | sort)

2. lépés: PKGBUILD history auditja

Ellenőrizd, hogy a 2026. június 10–12. között frissített vagy telepített csomagok PKGBUILD fájljai tartalmaznak-e gyanús sorokat:

bash

# Keress npm/bun parancsokat PKGBUILD-ekben
grep -r "npm install" ~/.cache/yay/
grep -r "bun install" ~/.cache/yay/
grep -r "atomic-lockfile\|js-digest\|lockfile-js" ~/.cache/yay/

3. lépés: eBPF rootkit keresése

Ezt csak megbízható külső médiumról (pl. Arch Live ISO) bootolt környezetből szabad elvégezni:

bash

# eBPF object-ek ellenőrzése
ls /sys/fs/bpf/

# Gyanús systemd unit-ok keresése
systemctl list-units --type=service | grep -i "systemd\|kernel\|net"

# Nemvárt hálózati kapcsolatok
ss -tulpn

4. lépés: Gyanús folyamatok és hálózati forgalom

bash

# Hálózati aktivitás monitorozása
sudo netstat -tulpn
sudo ss -tulpnH

# Rootkit keresés (megbízható médiumról)
rkhunter --check --sk
chkrootkit

Mit tegyél most, ha érintett vagy (ez fájni fog!)?

⚠️ Alapelv: Az uninstall nem elegendő.

Ha a malware már futott, a szoftver eltávolítása nem oldja meg a problémát. A payload már elvégezte a dolgát. A teendők:

1. Azonnal rotáld a hitelesítő adatokat

Ez nem opcionális, és nem halasztható:

  • SSH kulcspár generálása: ssh-keygen -t ed25519, majd frissítsd az összes szerver és szolgáltatás authorized_keys-ét.
  • GitHub Personal Access Token-ek visszavonása és újragenerálása — az összes repositoryhoz való hozzáféréssel rendelkező tokenét.
  • Cloud access keyek rotálása: AWS IAM, GCP Service Account, Azure Service Principal.
  • npm/PyPI auth tokenek törlése és újragenerálása.
  • Docker Hub / ghcr.io hitelesítő adatok frissítése.
  • Böngészői munkamenetek érvénytelenítése: GitHub, GitLab, cloud konzolokon, SaaS eszközökön. Ahol elérhető, invalidáld az összes aktív session-t.
  • Jelszókezelők ellenőrzése: ha a böngésző-integráció aktív volt, az ott tárolt jelszavak is kompromittálódhattak.
  • Slack/Discord/Telegram tokenek: ahol lehetséges, invalidáld az összes aktív eszközhöz kötött session-t.

2. Vizsgáld meg a CI/CD rendszereidet

  • Ellenőrizd, hogy a lopott GitHub tokenekkel történt-e jogosulatlan commit, workflow-módosítás vagy package-kiadás.
  • GitHub Audit Log → Settings > Security > Audit log.
  • Ellenőrizd az npm publish, PyPI release előzményeket.

3. Fontold meg a teljes rendszer-újratelepítést (arch linuxon úgyis ritkán csináljuk...)

Ha root jogosultságokkal futott a malware (és tipikusan fut, ha sudo yay vagy hasonlóval telepítettél), az eBPF rootkit jelenléte miatt a rendszer alapvetően megbízhatatlannak tekintendő. Ebben az esetben:

  • Bootolj Arch Live ISO-ról.
  • Csatold fel a fájlrendszert és keresd meg a gyanús systemd unit-okat.
  • Erősen fontolóra venném a teljes újratelepítést, majd friss credentialekkel való visszaállítást.

4. Vizsgáld meg a git history-t

bash

# Megváltozott konfiguráció fájlok keresése
git -C ~ log --all --oneline -- .ssh/
# Shell history áttekintése gyanús parancsok után
cat ~/.bash_history | grep -E "curl|wget|nc |ncat"

Hogyan előzhető meg hasonló a jövőben?

Egyéni szinten

1. Mindig olvasd el a PKGBUILD-et telepítés előtt. Ez a legalapvetőbb, és mégis a leggyakrabban átugrott lépés. Egy AUR helper alapértelmezetten nem kér rá — de be lehet állítani, hogy mindig mutassa a PKGBUILD-et manuális jóváhagyás előtt:

bash

# yay esetén
yay -S --editmenu csomagtev

# paru esetén (config fájlban)
# ~/.config/paru/paru.conf
[options]
BottomUp
SkipReview = false

2. Legyen meg a tudásod, mit keresel egy PKGBUILD-ben. Gyanús jelzők:

  • Nem kapcsolódó npm/pip/cargo parancsok a package() vagy post-install hook-ban.
  • curl vagy wget végrehajtható fájl letöltésére és azonnali futtatására.
  • Obfuszkált vagy base64-kódolt parancsok.
  • Külső script-ek futtatása forrás-ellenőrzés nélkül.

3. Minimalizáld az AUR-függőséget. Ahol lehetséges, preferáld a Flatpak, AppImage, vagy official repo csomagokat. Az AUR fantasztikus erőforrás, de tudatosan kell használni.

4. Privilegizált telepítés kerülése. A makepkg nem igényel root jogot a build fázishoz — a telepítés (pacman -U) viszont igen. A build fázist futtasd normál felhasználóként, és csak a tényleges telepítésnél emeld a jogosultságot.

5. AUR csomagok frissítésének tudatos kezelése. Ne frissíts automatikusan, ha nem nézted át a változásokat. A paru --fm nvim lehetővé teszi az interaktív fájl-szerkesztővel való áttekintést.

Szervezeti/infrastrukturális szinten

6. CI/CD pipeline-ok Arch-mentesítése — vagy legalább AUR-mentesítése. Ha Arch-alapú build agentet futtatsz, komolyan fontolja meg a csapatod az áttérést valamilyen stabilabb, kötöttebb repómodellű disztribúcióra (Debian/Ubuntu, RHEL). Ha az Arch indokolt, legalább zárja ki az AUR-csomagok automatikus telepítését pipeline-okban.

7. Supply chain monitoring. Sonatype, Snyk, Semgrep és hasonló eszközök segíthetnek automatizáltan jelezni a nyílt forráskódú dependenciák kockázatait.

8. Titkos adatok (secrets) izolálása a build környezetektől. A malware célzottan keresi a ~/.ssh, ~/.aws, ~/.npmrc, ~/.gitconfigés .env fájlokat. Ezek ne legyenek hozzáférhetők a build agent gépeken — használj secrets manager-t (HashiCorp Vault, AWS Secrets Manager stb.) és just-in-time credential injection-t.

A tágabb kép: miért ez az egyik legsúlyosabb supply chain támadás

Az elmúlt években megszoktuk, hogy a supply chain támadások npm-csomagokat, PyPI-t, vagy GitHub Actions workflow-kat céloznak. Az "Atomic Arch" egy új lépcsőfokot képvisel, amelyből érdemes tanulni:

Ownership hijacking > typosquatting. A klasszikus typosquatting (pl. color helyett colour csomag) már ismert védekezési mintákkal kezelhető. Az orphaned package adoption ezzel szemben teljesen legitim folyamat, amelyet az ökoszisztéma maga kínál fel. Nem lehet egyszerűen "kiszűrni".

Bizalomszerzés már megtörtént. A támadók nem build trust from scratch — az adoptált csomag évek alatt összegyűlt felhasználói bizalmat örökölt. Ez a fenyegetési modell különösen ravasz.

A payload fejlesztői infrastruktúrára van optimalizálva. Ez nem egy zsarolóvírus, amely encryption után váltságdíjat kér. Ez egy csendes, precíz credential thief, amely pont azokat az adatokat keresi, amelyek a teljes SDLC-t kompromittálhatják. Egy lopott GitHub token vagy cloud key katasztrofális következményekkel járhat.

Az eBPF rootkit dimenzió. Az, hogy a payload eBPF-et használ a perzisztenciához és az elrejtőzéshez, technikai kifinomultságra utal, amely eddig főként APT-csoportokhoz volt köthető. Látva ezt a képességet "commodity" supply chain attack eszközkészletben, ez egy komoly figyelmeztetés.

Összefoglalás: Azonnali teendők (TL;DR)

Ha Arch Linuxot használsz (akár személyesen, akár infrastruktúrában), és 2026. június 10–12. között telepítettél vagy frissítettél AUR-csomagot:

  1. Futtasd az aur-malware-check detektálási szkriptet (GitHub: lenucksi/aur-malware-check).
  2. Ha érintett csomag szerepel a listán: rotáld az összes credentialt azonnal.
  3. Ellenőrizd a CI/CD rendszereidet jogosulatlan aktivitás után.
  4. Teljes rendszer-újratelepítés fontolóra vétele, ha root jogosultságokkal futhatott a malware.
  5. PKGBUILD-ellenőrzés beállítása alapértelmezettként minden AUR-helperben.
  6. vezessetek be a olyan OSINT/CTI platformot (pl.: Noruas), ami segít IDŐBEN megtalálni a credential-leak-eket.

Források

Ha hasznosnak találtad ezt a posztot, oszd meg kollégáiddal — különösen azokkal, akik Linux-fejlesztői környezetet futtatnak. Kérdések, kiegészítések: kommentben vagy közvetlenül kereshetsz.