cybersecurity

A Miasma kampány mit árul el az új ellátási lánc fenyegetési modellről és a fejlesztői hitelesítések feketepiaci forgalmáról.

Forrás: tenable.com 17 perc olvasás

Megosztás

A Miasma kampány mit árul el az új ellátási lánc fenyegetési modellről és a fejlesztői hitelesítések feketepiaci forgalmáról.

Összefoglalót olvas. A teljes tartalom itt érhető el: tenable.com.

Egy ellopott munkamenet süti hét héten át ült a feketepiacon, mielőtt a támadók felhasználták volna, hogy megfertőzzenek 32 Red Hat csomagot az npm szoftverregiszterben, ez a modern ellátási lánc támadások mögötti ipari megközelítés példája. Kulcsfontosságú megállapítások A Miasma egy önmagát terjesztő npm féreg, amely a Mini Shai-Huludból származik, és amelyet a TeamPCP nyílt forráskódúvá tett május 12-én. A teljes fegyverezett eszközkészlet nyilvános kiadása lehetővé teszi, hogy bármely üzemeltető replikálja a strukturálisan azonos ellátási lánc kampányokat. A Miasma kampány 89-nél több npm csomagot kompromittált három hullámban (június 1-5), érintve a Red Hat, Vapi.ai és Microsoft Azure tárolókat. A féreg gonosz csomagokat állított elő érvényes SLSA Build Level 3 származási attestációkkal, ellentmondva az ellátási lánc integritásának legmagasabb szintű ellenőrzésének. A gyökérok egy ellopott fejlesztői azonosító volt, amely hét héten át ült az infostealer naplókban, mielőtt fegyverezni kezdték. Ez az infostealer-ellátási lánc csővezeték a Fejlesztői Azonosító Gazdaság meghatározó modellje. A Miasma kampány harmadik hulláma (június 5) jelentős eszkalációt hozott: tartós fájlokat vezetett be, amelyek az AI kódsegítőket célozták (Claude Code, Cursor, Gemini CLI, VS Code), így bővítve a támadási felületet a csomagregiszterektől a fejlesztő helyi környezetéig. Az végrehajtási rétegen alapuló észlelés, mint például az EDR, nem elegendő az ellátási lánc fenyegetéseivel szemben, mivel az EDR eszközök nem látnak bele az átmeneti CI/CD környezetekbe, ahol az azonosító lopás és fegyveresítési folyamatok zajlanak. A szervezeteknek úgy kell kezelniük a fejlesztői azonosítókat, mint a vezérlő sík infrastruktúráját, és egy fázisokkal rendelkező Folyamatos Fenyegetés Kitettségi Kezelés (CTEM) megközelítést kell alkalmazniuk: erősítsék meg a generációs réteget, semlegesítsék a begyűjtött titkokat valós időben, és érvényesítsenek emberi jóváhagyású közzétételi ellenőrzéseket. Háttér a Miasma féreg és az npm ellátási lánc támadásról Június 1-jén a Miasma önmagát terjesztő féreg 32 hivatalos npm csomagot kompromittált az @redhat-cloud-services névterületen, körülbelül 80 000 és 117 000 heti letöltés becslésével. Öt nap alatt a kampány három különböző támadási hullámon keresztül eszkalálódott, és arra kényszerítette a GitHubot, hogy 73 tárolót leállítson négy Microsoft szervezetben. A Miasma ellátási lánc támadás műszaki részletei riasztóak: érvényes SLSA származási attestációk a gonosz csomagokon; egy új végrehajtási technika, amely megkerüli a telepítő szkript figyelést; és egy új tartóssági mechanizmus, amely az AI kódsegítőket célozza. De a legfontosabb részlet egy időbélyeg. A sötét webet figyelő Whiteintel cég április 13-án észlelte a Red Hat egyik alkalmazottjának GitHub azonosítóját és munkamenet sütijét az infostealer naplókban. Egy második észlelés május 15-én történt. Az azonosító körülbelül hét hétig ült a feketepiacokon, mielőtt a támadók fegyverezni kezdték június 1-jén. Ez a hét hét jelzi egy új fenyegetési modell megjelenését, amelyet a Tenable Research Special Operations (RSO) csapata Fejlesztői Azonosító Gazdaságnak nevezett, és amelyet 2026 márciusa óta követnek. A Fejlesztői Azonosító Gazdaság egy strukturált fekete piac a magas privilegizáltságú fejlesztői azonosítók számára, ahol az open-source ellátási lánc kompromittálások az azonosító generálás infrastruktúrájaként működnek, a feketepiacok, mint terjesztési réteg szolgálnak, és több fenyegető szereplő különböző motivációkkal fegyverezik le a begyűjtött hozzáféréseket. A Miasma kampány a legvilágosabb példa erre a modellre eddig, és érvényesíti azt a mintát, amely 2026 során felgyorsult az npm, PyPI és GitHub ökoszisztémákban. A háromrétegű gazdaság, amely a Miasma révén magyarázható Amikor márciusban először értékelték ezt a mintát, a Tenable RSO az elemzést a TeamPCP láncolat kampány köré építette (Trivy, KICS, LiteLLM, Telnyx és 66+ npm csomag) és a Sapphire Sleet/UNC1069 Axios kompromittálás köré. A tézis egy háromszintes szerkezetet azonosított: azonosító generálás, terjesztés és fegyverezés. Három hónappal később a Miasma kampány világosan érvényesítette mindhárom réteget. RétegSzereplő / csoportMűködési fókuszElsődleges célpontokMiasma érvényesítés GenerációTeamPCPÁtfogó azonosító begyűjtés eszköz kihasználáson keresztülTrivy, KICS, TanStack, Red Hat npm területA Miasma payloadja GitHub tokeneket, felhőazonosítókat, CI/CD titkokat, SSH kulcsokat és .env fájlokat söpör el minden fertőzött környezetből TerjesztésFekete piacok, infostealer aggregátorokAzonosító közvetítés és eszközök elterjedéseEllopott fejlesztői azonosítók; nyílt forráskódú féregkódA Red Hat alkalmazottjának azonosítója hét hétig ült az infostealer naplókban fegyverezés előtt; a Shai-Hulud forráskód közzétéve május 12-én FegyverezésSapphire Sleet (DPRK-háttér), LAPSUS$, Miasma üzemeltető, utánzó szereplőkÁllami szintű exfiltráció, adatlopás, láncolatos ellátási lánc kompromisszumAxios (npm), Mercor AI, @vapi-ai/server-sdk, Azure/durabletaskMinden Miasma hullám új azonosító pool-t generál, táplálva a következő hullámot, lehetővé téve az alsóbb szintű szereplők hozzáférését 1. réteg: Azonosító generálás A Fejlesztői Azonosító Gazdaság első rétege az extrakció. A fenyegető szereplők a fejlesztői eszközöket és az open-source infrastruktúrát nem elsősorban azért kompromittálják, hogy rosszindulatú szoftvert juttassanak el a végfelhasználóknak, hanem hogy begyűjtsék azokat az azonosítókat, amelyeket ezek a környezetek tartalmaznak, mint például GitHub tokenek, npm publikálási tokenek, felhőszolgáltatók azonosítói, CI/CD titkok, SSH kulcsok és API kulcsok. A TeamPCP ezt nagy léptékben kezdeményezte 2025 szeptemberében az eredeti Shai-Hulud féreggel. Meghatározó innovációja a láncolatos azonosító extrakció volt: kompromittálni egy megbízható eszközt, begyűjteni a benne található azonosítókat, és ezeket az azonosítókat felhasználni a következő eszköz kompromittálásához a függőségi láncban. A Trivy sebezhetőségi szkenner kompromittálása CI/CD futók titkait eredményezte. Ezek a titkok lehetővé tették a KICS kompromittálását. A KICS további felhőazonosítókat hozott létre. Minden egyes láncszem bővebb privilegizált hozzáférést generált. Májusra a TeamPCP ezt a Mini Shai-Hulud változatra finomította, amely két új képességet vezetett be, amelyek jelentősen javították a generációs réteget: Féreges terjedés: A rosszindulatú szoftver az npm regisztert kérdezi le minden csomagról, amelyet a kompromittált azonosító publikálhat, és automatikusan újrapublikálja magát az összesen. CI/CD pipeline eltérítés OpenID Connect (OIDC) tokenek kifosztása révén: Ahelyett, hogy statikus azonosítókat lopna, a Mini Shai-Hulud rövid élettartamú OIDC tokeneket kér a GitHub Actions-on keresztül, lehetővé téve számára, hogy érvényes kriptográfiai származású csomagokat publikáljon. A Miasma ellátási lánc kampány során ez a generációs réteg egy Red Hat alkalmazottjának kompromittált GitHub fiókján keresztül működött. A féreg payloadja a fertőzött környezetet söpörte el: GitHub tokenek és személyes hozzáférési tokenek npm publikálási tokenek AWS, GCP és Azure felhőazonosítók HashiCorp Vault tokenek Kubernetes szolgáltatói fiók tokenek SSH privát kulcsok Docker regiszter azonosítók GPG kulcsok .env fájlok A júniusi változat dedikált gyűjtőket adott hozzá a GCP és Azure felhőazonosítókhoz, túllépve a titkok kivonásán, hogy felsorolja az összes felhőhöz való hozzáférést, amelyet a fertőzött gép birtokol. Minden gép, amely futtatott npm install-t egy kompromittált @redhat-cloud-services csomag verzióval, azonosító generálási csomóponttá vált. 2. réteg: Terjesztés A második réteg a piactér. Az ellopott azonosítók a generálási rétegből a feketepiacokra, infostealer naplóaggregátorokhoz és hozzáférés közvetítő szolgáltatásokhoz áramlanak, ahol bármely vásárló számára elérhetők. A Miasma ellátási lánc támadás idővonala ezt a réteget olyan módon teszi láthatóvá, ahogyan a korábbi kampányok nem tették. A Whiteintel észlelte a Red Hat alkalmazottjának GitHub azonosítóját és munkamenet sütijét az infostealer naplókban április 13-án. Ez az azonosító nem egy Red Hat ellen irányuló célzott ellátási lánc támadás eredményeként keletkezett; egy közönséges infostealer lopta el, az egyik 13,2 millió infostealer fertőzés közül, amelyet a SpyCloud 2025-ös Azonosítási Expozíciós Jelentése dokumentált, átlagosan 50 azonosítóval fertőzésenként. Az azonosító a terjesztési rétegbe került, mint egy adatpont a milliárdok között: a SpyCloud 5,3 milliárd azonosító párt, 18,1 millió kiszivárgott API kulcsot és tokent, és 8,6 milliárd ellopott munkamenet sütit rögzített a bűnözői földalatti figyelésből csupán 2025-ben. Hét héten keresztül az azonosító a terjesztési rétegben ült, mielőtt valaki cselekedett volna. Ez a tartózkodási idő az a szisztematikus rés, amelyet a Fejlesztői Azonosító Gazdaság kihasznál. Azok a szervezetek, amelyek nem figyelik a feketepiacokat a kiszivárgott fejlesztői azonosítók után, azt a feltételezést teszik, hogy a generálási és fegyverezési csővezeték nem létezik, vagy hogy annyira lassan működik, hogy nem számít. A Miasma azt mutatja, hogy még egy hét hetes időszak, amely a feketepiacok mércéje szerint hosszúnak számít, több mint elegendő a fegyverezéshez. A terjesztési réteg tovább bővült május 12-én, amikor a TeamPCP közzétette a Mini Shai-Hulud összesített forráskódját a GitHub-on MIT Licenc alatt az üzenettel: „Shai-Hulud: A Káosz Nyílt Forrásúvá Tétele.” A kiadás tartalmazta a CI cache-poisoning szkripteket, az OIDC token kivonót és az azonosító lopót a terjesztési logikájával. Ez az ellátási lánc megfelelője annak, amikor egy működő kihasználási keretrendszert tesznek közzé: maga az eszköztervezés terjesztési csatornává vált, csökkentve a belépési korlátot bármilyen üzemeltető számára, aki strukturálisan azonos kampányt szeretne futtatni. 3. réteg: Fegyverezés A harmadik réteg a működési felhasználás. Különböző motivációkkal rendelkező szereplők az azonosítókat a terjesztési rétegből szerzik meg, és fegyverezik őket konkrét célpontok ellen. Márciusban az RSO csapat legalább három különböző szereplőt dokumentált, akik ugyanabból az azonosító poolból működtek: a TeamPCP nagy léptékben begyűjtötte; a Sapphire Sleet/UNC1069 (DPRK-háttér) lopott npm tokeneket használt fel pénzszerzés céljából az Axios kompromittálás során, míg a LAPSUS$ a LiteLLM megsértésével ellopott Tailscale VPN azonosítókat használt fel adatok lopására a Mercor AI-ból. Ugyanaz az azonosító ökoszisztéma táplálta őket mindhármat. A Miasma fegyverezési rétege továbbra is fejlődik, de a három hullámon keresztül követett irányvonal bemutatja a mintát: 1. hullám (június 1.) a lopott Red Hat azonosítókat használta fel 32 @redhat-cloud-services csomag kompromittálására, minden egyes fejlesztői környezetből új azonosító kört generálva, amely telepítette a kompromittált verziót. 2. hullám (június 3.) 57 további csomaghoz igazított, új technikával, amelyet a kutatók „Phantom Gyp”-nak hívnak, amely egy 157 bájt méretű binding.gyp fájlt használ arra, hogy kódvégrehajtást triggereljen az npm install során, megkerülve a korábban a védők által telepített preinstall-script figyelését. 3. hullám (június 5.) egy korábban kompromittált közreműködő fiókot használt fel, ugyanazt, mint a május 19-i PyPI támadás során, hogy rosszindulatú commitokat toljon a Microsoft Azure/durabletask tárolóba, arra kényszerítve a GitHubot, hogy 73 tárolót letiltson egy 105 másodperces automatikus lekérdezésben. Minden hullám táplálta a következőt: az 1. hullámban ellopott azonosítók hozzáférést biztosítottak a 2. hullám célpontjaihoz, és ugyanazok a kompromittált fiókok fennmaradtak a 3. hullámban. A féreg önmagát terjesztő viselkedése biztosítja, hogy az azonosító pool minden sikeres fertőzéssel bővüljön, létrehozva egy kumulatív ciklust, ahol a generálás és a fegyverezés átfedi egymást. Az eszkaláció, ami miatt minden biztonsági csapatnak aggódnia kell Három aspektus a Miasma kampányban valódi eszkalációt jelent, amely túlmutat a biztonsági közösség által a korábbi ellátási lánc támadások során tapasztaltakon. 1. A származási attestáció már nem elegendő A Miasma 1. hullámban megjelent csomagok érvényes SLSA Build Level 3 származási attestációval rendelkeztek, az ellátási lánc integritásának legmagasabb szintje. A Red Hat legitim CI/CD pipeline-ja készítette ezeket a csomagokat, a Red Hat megbízható OpenID Connect (OIDC) azonosítóját felhasználva, azokat a GitHub Actions munkafolyamokat, amelyeket a támadó injektált a pipeline-ba. A kriptográfiai tanúsítvány pontos volt. A csomag valóban azzal a pipeline-nal készült. A pipeline éppen akkor tartalmazott rosszindulatú szoftvert. Ez nem a származásellenőrzés megkerülése. Ez azt bizonyítja, hogy a származásellenőrzés más kérdésre ad választ, mint amit a védekezők feltételeznek. A csatolt tanúsítvány bizonyítja, hogy egy adott pipeline készített egy csomagot. Nem bizonyítja, hogy a pipeline tiszta volt. A szervezeteknek, akik a származásellenőrzésre támaszkodnak mint elsődleges ellátási láncellenőrzésre, úgy kell kezelniük a Miasmát, mint egy strukturális korlátozást, és nem egy egyszeri kudarcot. 2. Az AI kódsegítők most támadási felületté váltak A Phantom Gyp hullám (június 3.) és az Azure hullám (június 5.) bevezettek egy tartóssági mechanizmust, amelyet eddig nem dokumentáltak az ellátási lánc kampányokban: a rosszindulatú szoftver konfigurációs fájlokat helyez el a projekt könyvtáraiban az AI kódsegítők számára, beleértve a .claude/settings.json-t a Claude Code-hoz, .cursor/rules-t a Cursorhoz, valamint konfigurációs fájlokat a Gemini CLI és VS Code számára. Ezek nem trojanizált kiterjesztések vagy kompromittált bővítmények. Utasítási réteg felülírások, amelyek csendben megváltoztatják az AI segítő viselkedését, amikor a fejlesztő legközelebb megnyitja a projektet. Ha egy fejlesztő fertőzött projektet nyit meg egy AI-asszisztált IDE-ben, a hátsó ajtó végrehajtódik. A támadó rejtett utasításai ezután befolyásolhatják az AI által generált kódot, potenciálisan finom sebezhetőségeket bevezetve, amelyek nehezen megkülönböztethetők a jogos javaslatoktól. Ez jelentős bővítése a támadási felületnek a csomagregiszterektől és a CI/CD pipeline-októl a fejlesztő helyi környezetéig és AI-asszisztált munkafolyamatáig. A támadás nem igényli az npm install-t; akkor aktiválódik, amikor a fejlesztő megnyit egy tárolót. Ez az első megfigyelt ellátási lánc kampány, amely szisztematikusan célozza meg az AI-asszisztált fejlesztési munkafolyamatot mint tartóssági és terjedési felületet. Ahogy az AI kódsegítők standard eszközökké válnak a vállalati fejlesztési környezetekben, valószínű, hogy ezt a támadási vektort replikálják és finomítják. 3. A nyílt forráskódú eszközök másolatok ökoszisztémáját hozták létre A Mini Shai-Hulud már nem korlátozódik a TeamPCP-re. A fegyverezett eszközkészlet teljes nyilvános kiadása május 12-én lehetővé teszi, hogy bármely üzemeltető strukturálisan azonos kampányokat valósítson meg új célökoszisztémák ellen. A Miasma payloadja a nyílt forráskódú kódon alapul, kozmetikai módosításokkal, amelyek a Dűne univerzummal kapcsolatos utalásokat görög mitológiai témákra cserélnek („Miasma”, „spártai”, „nemeai-hydra”). Nem világos, hogy ez a TeamPCP új név alatt működve vagy egy külön szereplő, aki tanulmányozta a közzétett kódot és továbbfejlesztette azt. Ami világos, az a következmény. Az npm ellátási lánc támadások végrehajtásának akadálya jelentősen és tartósan csökkent. A bizonyítékok azt sugallják, hogy ez a proliferáció már zajlik. A Palo Alto Networks Unit 42 dokumentálta, hogy a Shai-Hulud eszközkészlet használatával másolási tevékenység nehezítette a jövőbeli attributions végét, és a Phantom Gyp hullám fejlődése (binding.gyp végrehajtás, AI ügynökök célozása, módosított exfiltrációs csatornák) összhangban áll a TeamPCP folytatásával vagy egy képes üzemeltető működésével a nyilvánosan elérhető infrastruktúrára építve. Miért nem oldják meg az EDR és a reakciós észlelés ezt a problémát A narratíva az ellátási lánc védelméről nagymértékben támaszkodott a végrehajtási réteg észlelésére: az az elképzelés, hogy a végpont észlelés és válasz (EDR) eszközök elkapják a payload-ot, amikor az aktiválódik, így a szervezetek védve vannak. A Miasma kampány megvilágítja, hogy miért hibás struktúrájában ez a feltételezés. Az EDR végrehajtást figyel, nem expozíciót. Az EDR-re támaszkodni egy ellátási lánc támadás megállításához olyan, mint konyhában nyitott benzinkanna mellett füstérzékelőre támaszkodni. Az EDR nem látja a nem megfelelően konfigurált GitHub Action-t, a túlprivilegizált npm tokent vagy a hét hetes ellopott azonosítót, amely egy feketepiacra került. Mire egy EDR ügynök aktiválódik egy rosszindulatú payload-ra, az azonosító lopás, amely lehetővé teszi a következő hullámot, már megtörtént. A lefedettségi rés az a hely, ahol a lopás megtörténik. Az EDR-nek nulla láthatósága van az átmeneti CI/CD futókra és építési környezetekre, ahol a Miasma az azonosító begyűjtést végrehajtja. Ezek a környezetek elindulnak, futtatják a kompromittált npm install-t, exfiltrálják a titkokat, és leállnak, mindezt azon előtt, hogy egy emberi elemző triázs egy riasztásra. A Fejlesztői Azonosító Gazdaságban a lopás ott történik, ahol az ügynökök nem találhatók. Az észlelés megkerülése gyorsabban előz be, mint az észlelés. A májusi TanStack kompromittálás után a védők az észlelés ellenőrzéseként preinstall-szkript figyelést vezettek be. A Phantom Gyp hullám, amely mindössze három héttel később érkezett, teljes mértékben megkerülte ezt az ellenőrzést azáltal, hogy a végrehajtást a binding.gyp-re helyezte, egy olyan fájlra, amelyet a legtöbb biztonsági eszköz nem figyel. Az Azure hullám pedig teljesen elhagyta a csomag telepítését, átállva a tárolószintű konfigurációs fájlokra, amelyek aktiválódnak az IDE/editor megnyitásakor. Minden védelmi válasz új megkerülési célt teremt, és az iterációs ciklus napokban mérhető, nem hónapokban. Az EDR megkerülése egy aktív, iparosított képesség, és az ellátási lánc támadói ugyanazt az alkalmazkodó viselkedést mutatják. Míg az EDR-nek szerepe van, a tünetet kezeli (a rosszindulatú payload végrehajtáskor), nem a betegséget (a kezelhetetlen expozíciót, amely a fejlesztői azonosítókat és CI/CD infrastruktúrát körülveszi). A Fejlesztői Azonosító Gazdaság által teremtett szisztematikus kockázat semlegesítéséhez alapvetően más megközelítés szükséges: az expozíciós feltételek azonosítása és megszüntetése előtt, mielőtt a támadók kihasználnák őket. Az ökoszisztéma válaszol, de a strukturális rés megmarad Az npm ökoszisztéma nem maradt passzív. Az npm 2025. május 19-én végrehajtott egy platformszintű token érvénytelenítést, amely arra kényszerítette az összes fenntartót, hogy újra hitelesítse magát. Az npm CLI 11.15.0 verziója bevezette a lépcsős publikálást, amely emberi 2FA jóváhagyási kapukat követel meg, megkövetelve egy szándékos emberi megerősítési lépést, mielőtt bármely csomag verzió élesbe kerül. A GitHub nyilvánosságra hozta, hogy körülbelül 3,800 belső tárolót exfiltráltak a Shai-Hulud kampányok során. Isaac Schlueter, az npm alapítója kötelező nem-MFA publikálást sürgetett. Bár jelentős, ezek a válaszok strukturálisan reaktívak: mindegyik a korábbi hullám során tapasztalt technikát kezeli, miközben a támadó már a következő hullámra lépett. A lépcsős publikálás kezeli az 1. hullámban tapasztalt OIDC token kihasználást. Nem foglalkozik a 2. hullám binding.gyp végrehajtásával. Egyik sem foglalkozik a 3. hullám AI kódsegítő tartósságával. Az előrelépéshez át kell lépni a reaktív észlelésből a megelőző expozíciókezelésre: az azonosító generáló pontok azonosítása és bezárása, mielőtt a támadók fegyverezhetik azokat. Egy fázisos megközelítés az azonosító gazdaság zavarására A Fejlesztői Azonosító Gazdaság egy egyszerű elv mentén működik: az expozícióval kapcsolatos azonosítók, amelyeket a védők nem ismernek, nem cserélhetők le, és ezért sebezhetőek maradnak. Egy fázisos CTEM megközelítés zavarja a támadási láncot minden rétegen. 1. fázis: A generációs réteg megszorítása Az első prioritás az azonosító lopás lehetőségeinek megszüntetése. A szervezeteknek azonnal át kell auditálniuk a lockfile-okat és le kell állítaniuk a lifecycle hookokat (--ignore-scripts), hogy megszüntessék a postinstall és preinstall vektorokat. De a Miasma Phantom Gyp hulláma azt mutatja, hogy a lifecycle hookok már nem az egyetlen végrehajtási felület: adjunk hozzá binding.gyp figyelést a csomagbeviteli ellenőrzésekhez, és auditáljunk minden klónozott tárolót AI kódsegítő tartós fájlok (.claude/settings.json, .cursor/rules, .gemini/ konfigurációs fájlok) után. A biztonsági eszközöket kritikus infrastruktúraként kell kezelni. A 2026-os események ezt többször is bizonyították: a Trivy, a Checkmarx KICS és a Nx Console VS Code kiterjesztések mind értékes belépési pontként működtek, éppen azért, mert a fejlesztők bíznak bennük. A biztonsági eszközökkel szemben ugyanezeket az integritásellenőrzési és elszigetelési kontrollokat kell alkalmazni, amelyek a termelési rendszerekre vonatkoznak. 2. fázis: A begyűjtött titkok valós idejű semlegesítése A Miasma támadásának idővonalán a hét hetes azonosító tartózkodási idő az a kihasználási ablak, amelyre a Fejlesztői Azonosító Gazdaság támaszkodik. Ennek az ablaknak a bezárása megköveteli, hogy a periódikus rotáción túl folyamatos láthatóságot nyújtsunk arról, hogy hol vannak az azonosítók ki exponálva, beleértve a feketepiacokat, CI/CD futókat és az átmeneti építési fázisokat, ahol az EDR-nek nincs nyoma. Valós idejű sötét web analítikai figyelést kell végrehajtani a fejlesztői fiókok (GitHub, npm, PyPI, Docker Hub) számára automatizált rotációval észlelés esetén. Kötelező MFA érvényesítése csökkentett személyes hozzáférési token élettartammal. A Tenable Cloud és AI Security Risk Report 2026 eredményei szerint a felhő környezetek 65%-a „kísértet” azonosítókat, inaktív szolgáltatói fiókokat és nem rotált kulcsokat tartalmaz, amelyek kész célpontok a támadók számára. Minden kísértet azonosító ingyenes belépő az egyes szereplők számára a terjesztési rétegben. Használja a Tenable One-t a teljes támadási felület feltérképezésére, beleértve a CI/CD pipeline-okat és az olyan felhőalapú építési szakaszokat, ahol a végrehajtás réteg észlelése nem érhető el. 3. fázis: Emberi jóváhagyással rendelkező publikálás érvényesítése és a automatizálási lánc megszakítása A féreg önmagát terjesztő viselkedése teljes mértékben automatizált publikáláson alapul: lopni egy tokent, felsorolni a publikálható csomagokat, újrapublikálni rosszindulatú programmal, ismételni. Kényszerű emberi megerősítési lépés beillesztése megszakítja ezt az automatizálási láncot. Az npm lépcsős-publikálási funkciója (npm CLI 11.15.0) egy konkrét megvalósítása ennek a kapunak, amely emberi 2FA jóváhagyást követel meg, mielőtt bármilyen csomag verzió élesbe kerül. A szervezeteknek: Azonnal fogadják el a lépcsős publikálást vagy az azzal egyenértékű emberi jóváhagyású munkafolyamatokat Vizsgálják meg a GitHub Actions OIDC token létrehozási terjedelmét, hogy a write csak a védett ágon lévő kiadási munkafolyamatokra korlátozódjon, Készítsenek minimumReleaseAge kontrollokat új csomagverziók karanténba helyezésére a fogyasztás előtt Érvényesítsenek észlelési szabályokat a Miasma indikátorok számára: GitHub tárolók, amelyek leírása „Miasma: A Terjedő Belsőség;”; a GCP felhasználói ügynök sztring google-api-nodejs-client/7.0.0; és a dead-drop GitHub fiók liuende501 Nyomon követés az anomálias npm publikálási események és engedély nélküli GitHub tároló létrehozásának figyelésére a szervezeti fiókokban. Ezek nem opcionális megerősítő intézkedések. Ezek közvetlen válaszok a vadonban bemutatott képességekre, amelyek most már nyílt forráskódú eszközként elérhetők bármilyen üzemeltető számára. Hová tart ez innen A Fejlesztői Azonosító Gazdaság a kiberbűnözés jelentős érését jelenti, túllépve a lehetőségi támadásokon és egy kifinomult, skálázható és rendkívül specializált piactér létrehozásáról. A március és június közötti események e megállapítást éles és világos módon érvényesítették: a TeamPCP a Shai-Hulud féreg nyílt forráskódúvá tétele; a másolati változatok, mint a Miasma elterjedése; az ökoszisztémák közötti elterjedése az npm-től a PyPI-ig, a GitHub Actions-ig és a VS Code bővítményekig; és az AI kódsegítő célzásának bevezetése mint új tartóssági felület. Ez az evolúció a saját fejlesztői eszközeinket fordítja ellenünk, hogy begyűjtse a nagy léptékű kompromittáláshoz szükséges hozzáférést. Az előrelépés egy alapvető váltást jelent a kitettségi intelligenciára, amely lehetővé teszi az azonosító generáló pontok azonosítását és bezárását, mielőtt a támadók fegyverezhetnék őket. Azok a szervezetek, amelyek túlélni fogják ezt a váltást, azok lesznek, akik a fejlesztői környezeteket vezérlő sík infrastruktúráként kezelik, nem munkagépként, és a CTEM keretrendszer által nyújtott folyamatos láthatósággal és proaktív megszorítással kezelik ezeket. A Miasma hét hetes azonosító nyoma nem a legrosszabb eset. Ez egy alapvonal, és a következő hullám már készül ugyanazon nyílt forráskódú eszközökből. További információ Mini Shai-Hulud: Gyakran ismételt kérdések a TeamPCP ellátási lánc kampányról A fejlesztői azonosító gazdaság: Miért új kitettségi adatok képviselik az új frontvonalat az ellátási lánc háborúban Az Axios ellátási lánc fenyegetésének megszüntetése a Tenable Hexa AI segítségével: Használati esetek ügynöki AI-val Gyakran ismételt kérdések az Axios npm ellátási lánc támadásról, amelyet az UNC1069 észak-koreai fenyegető szereplő hajtott végre Letöltési nyomás: Új npm megtévesztési technika az ellátási lánc támadásokhoz Csatlakozzon a Tenable Research Special Operations (RSO) csapatához a Tenable Connect-en további beszélgetésekre a legújabb kiberfenyegetésekről. Tudjon meg többet a Tenable One-ról, a modern támadási felületért felelős kitettségkezelő platformról.

A teljes cikk az eredeti weboldalon

Külső link: tenable.com

Kapcsolódó cikkek