A támadás anatómiája: MI-eszköz, infostealer és átcsúszott engedélyek
Nemcsak a Vercel munkatársai, hanem a vállalat partnerei is az események gyújtópontjába kerültek. Egy alkalmazott feltelepítette a Context.ai böngészőbővítményét, majd munkahelyi Google-fiókjával bejelentkezett, teljes körű OAuth-jogosultságot adva az eszköznek. A Context.ai-t egy Lumma Stealer nevű információt gyűjtő vírus fertőzte meg, amely egy másik alkalmazott gépén futott, és onnan szivárgott. Így a támadók hozzáférést szereztek a céges Google Workspace-fiókhoz, majd onnan átvitték a támadást a Vercel rendszereibe. Itt az érzékenynek nem minősített környezeti változókat könnyedén elérték, és ezeken keresztül további jogosultságokat szereztek.
A támadók lépésről lépésre haladtak: először egy személyes gépre települt a Lumma Stealer, onnan továbbléptek a Context.ai AWS-környezetébe, majd egy ellopott OAuth-token révén már egy Vercel-munkatárs Google Workspace-ében is jelen voltak, végül eljutottak a produkciós környezetekig. Ráadásul a céges környezeti változókat nem mindenhol kezelték kellő körültekintéssel: a támadó olyan értékeket is látott, amelyek nem voltak megfelelően védve.
Hosszú és láthatatlan támadási lánc
A Hudson Rock vizsgálata szerint a történet egy Context.ai-s alkalmazott Roblox-csalásokat tartalmazó szkriptek letöltésével kezdődött 2026 februárjában. A böngészési előzmények és az ellopott hitelesítő adatok révén megszerezték a Google Workspace-belépési adatokat, különféle API-kulcsokat és adminisztrátori jogosultságokat a Context.ai Vercel-felületéhez is.
A Context.ai elismerte, hogy a támadás az elavult AI Office Suite terméket érintette, nem a vállalati Bedrock szolgáltatásukat. Márciusban észlelték a jogosulatlan AWS-hozzáférést, majd a CrowdStrike segítségével igyekeztek feltárni a támadás részleteit. Később kiderült: nemcsak AWS-szervereket érintett a támadás, hanem felhasználói OAuth-tokeneket is elloptak, amelyek közül egy jelentette a belépőt a Vercel-keretrendszerébe is.
A legaggasztóbb az incidens észlelése és feltárása között eltelt idő, amely majdnem egy hónap volt. Egyes újabb elemzések szerint a támadók akár 22 hónapon keresztül is jelen lehettek észrevétlenül, mielőtt a Vercel végül nyilvánosságra hozta a történteket.
Hol marad észrevétlen a támadás?
Az infostealer-fertőzéstől a produkciós adatok begyűjtéséig négy lépcsős támadási láncot sikerült végigvinniük a hackereknek, miközben egyik védelmi rendszer sem volt képes teljes lefedettséget biztosítani. A végpontvédelem (EDR) hiányosságai miatt az infostealer adatait senki sem monitorozta, az AWS-környezet kompromittálását ugyan észlelték, de az OAuth-tokenek ellopását már nem. A Google Workspace-auditnaplók sem figyelték az ilyen típusú harmadik feles OAuth-hozzáféréseket; végül a környezeti változókhoz való hozzáférést már csak utólag fedezték fel, nem a támadás pillanatában.
Védelmi lyukak: hat lecke a Vercel-incidensből
Az MI-eszközökkel kapcsolatos OAuth-jogosultságokat senki nem auditálta, így egyetlen munkatárs teljes hozzáférést tudott adni a vállalati rendszerekhez. Az érzékeny környezeti változók helyes megkülönböztetése sem működött megfelelően – végül emiatt tudtak továbblépni a támadók. Az infostealer–SaaS–ellátási lánc típusú támadásokra nincs megfelelő és átfogó védelem egyetlen szervezetnél sem. A gyártó felfedezése és a partnercég értesítése között túl hosszú idő telik el, miközben a támadók ezen idő alatt szabadon mozoghatnak. Az is kiderült, hogy a munkavállalók által saját hatáskörben bevezetett MI-eszközök a legújabb shadow IT-ként jelennek meg, és különösen veszélyesek. Ráadásul az MI által gyorsított támadók minden eddiginél gyorsabban zárhatnak be támadási szakaszokat: a CrowdStrike adatai szerint átlagosan 29 perc alatt teljesítik az elsődleges célokat, ami 65 százalékkal gyorsabb, mint 2024-ben.
Mit kell tennie most egy IT-biztonsági vezetőnek?
Át kell vizsgálni minden céges OAuth-engedélyt, különösen az MI-eszközök esetében, és visszavonni az indokolatlanul tág jogosultságokat. Követelni kell, hogy minden érzékeny környezeti változó alapértelmezetten olvashatatlan legyen, és csak külön engedéllyel lehessen ezt megváltoztatni. Az alkalmazotti doménekhez kapcsolódó infostealer-logokat érdemes figyelni, minden ellopott hozzáférés esetén automatikus hitelesítőadat-cserét kell indítani. Kötelezővé kell tenni, hogy az ilyen incidensekről a partnerek maximum 72 órán belül értesítést kapjanak. Az árnyék-MI-eszközök listáját folyamatosan bővíteni és kontrollálni szükséges, a nem engedélyezett eszközhasználatot pedig azonnal vizsgálni kell.
Ha valaki a következő két OAuth-azonosítót (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com és 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com) látja a Google Workspace adminisztrációs konzolban, akkor érintett lehet az incidensben – függetlenül attól, mit kommunikált a Vercel.
Az új típusú rések és az MI kockázata
Az eset megmutatta, hogy az MI-eszközök beépítésekor adott túlzott OAuth-jogosultságok olyan biztonsági űrt teremtenek, amelyet a legtöbb vállalati IT nem is lát. Egyetlen, ártalmatlannak látszó szoftver telepítése, pár gondatlan kattintás, és kész az út a támadók előtt: négy céghatáron és két nagy felhőszolgáltatón át, mindenféle nulladiknapi sérülékenység nélkül. A Vercel története mostantól tankönyvi példája marad annak, miért veszélyes, ha az MI-alapú integrációk idő előtt, megfelelő kontroll nélkül kerülnek be a vállalati mindennapokba.
