A nyilvánosságra került információk alapján felmerült, hogy a támadók akár 229 terabájtnyi adatot is megszerezhettek; a Yellow Cube incidens-rekonstrukciója azonban jelentősen árnyalja ezt a képet. A 229 terabájt ugyanis nem a bizonyítottan ellopott adatmennyiséget, hanem az elért virtualizációs környezet teljes tárolókapacitását jelentette.

A támadás kapcsán különösen fontos különbséget tenni a hozzáférhető adatok mennyisége és a ténylegesen kimentett adatok mennyisége között. A két fogalom nem ugyanaz, és a most ismertetett rekonstrukció éppen ezt a különbséget világítja meg.

A támadó, aki ByteToBreach néven vállalta magára az akciót, a saját állítása szerint pénzszerzési céllal hajtotta végre a támadást, és cáfolta azokat a feltételezéseket, amelyek orosz állami szereplőkhöz kötötték volna az incidenst.

Egy régi sérülékenységen keresztül jutottak be

A Yellow Cube által felvázolt idővonal szerint a támadás 2026. július 25-én kezdődött. A támadó egy már évek óta ismert, internet felől elérhető WebLogic-sérülékenységet használt ki.

Innen az MVH hálózatán keresztül, a különböző informatikai rendszerek közötti bizalmi kapcsolatok kihasználásával tudott továbbhaladni az államkincstári környezet irányába.

A behatolás során a támadó végül több Active Directory-erdőben is magas szintű jogosultságokat szerzett, majd hozzáfért a VMware vCenter környezethez is.

Ez azért volt különösen jelentős, mert a vCenterben 116 virtuális gép és összesen 229,1 terabájtnyi datastore-kapacitás volt látható.

Ez azonban nem jelenti azt, hogy 229 terabájt adatot ki is másoltak.

Mit jelent valójában a 229 terabájt?

A szám elsősorban azt mutatja meg, hogy a támadó egy olyan virtualizációs környezetet ért el, amelyben ekkora tárolókapacitás állt rendelkezésre.

A teljes kapacitás tartalma ugyanis nem automatikusan azonos azzal az adatmennyiséggel, amelyet egy támadó ténylegesen megszerzett és kivitt a rendszerből.

A Yellow Cube rekonstrukciója szerint a rendelkezésre álló idő, a hálózati körülmények és a kimenő forgalom korlátozásai miatt a teljes 229 terabájtos állomány kimentése gyakorlatilag nem lett volna reális.

A nyilvánosságra került bizonyítékcsomag mérete ezzel szemben nagyjából 70 megabájt lehetett.

Ez természetesen nem jelenti azt, hogy biztosan csak ennyi adatot látott vagy szerzett meg a támadó, de a jelenlegi bizonyítékok alapján a 229 terabájtos adatlopásra vonatkozó korábbi értelmezés nem állja meg a helyét.

A valódi veszélyt nem csak az ellopott adatok jelentik

A támadás egyik legsúlyosabb aspektusa az identitáskezelés és a hitelesítő adatok biztonsága lehet.

A rekonstrukció szerint a támadó jelentős mennyiségű hitelesítő adathoz jutott hozzá, köztük olyan jelszavakhoz is, amelyek nyílt szövegben vagy nem megfelelően védett formában voltak hozzáférhetők.

A nyilvánosságra került anyagokban több, kifejezetten gyenge jelszóminta is szerepelt.

A Jelszó123, Password-1 és Ezazenjelszavam_013 is, de az BrigiSlipknot10, az Államkincstár69, az Andi.1977 vagy a F***off1986@ is használatban volt.

Ez azért különösen veszélyes, mert egy kompromittált jelszó nem feltétlenül csak az adott szerver vagy felhasználói fiók problémája. Ha ugyanazt a hitelesítési adatot több rendszerben is alkalmazták, a támadó újabb környezetekbe léphet be vele.

Ráadásul egy ilyen incidens után nem elegendő egyszerűen újraindítani a szervereket és visszaállítani a mentéseket. A kompromittált fiókokat, jogosultságokat, kulcsokat, tokeneket és jelszavakat is újra kell értékelni és szükség esetén teljes körűen cserélni.

Voltak védelmi rendszerek – a reakció lehetett a gyenge pont

A Yellow Cube elemzése alapján a történet egyik fontos tanulsága, hogy nem arról volt szó, hogy egyáltalán nem működött semmilyen kiberbiztonsági védelem.

Több kontroll is működött: a kimenő forgalom szűrése bizonyos műveleteket akadályozott, a végpontvédelem egyes tevékenységeket blokkolt, és több olyan esemény is történt, amely alkalmas lehetett volna riasztás kiváltására.

A probléma az elemzés szerint inkább az lehetett, hogy a rendelkezésre álló riasztásokból és jelekből nem alakult ki időben hatékony incidenskezelés.

Egy fejlett kibertámadás esetében ugyanis önmagában nem elegendő, hogy egy biztonsági rendszer észlel egy gyanús eseményt. A kritikus kérdés az, hogy ki, milyen gyorsan és milyen protokoll alapján reagál rá.

Az államkincstári rendszerek esetében különösen nagy a tét

A támadás azért is kapott kiemelt figyelmet, mert olyan állami informatikai infrastruktúrát érintett, amelynek működése alapvető fontosságú a közigazgatási és agrártámogatási folyamatok szempontjából.

A Kincstár korábbi tájékoztatása szerint lakossági ügyféladatok nem kerültek illetéktelen kezekbe, a fertőzött szervereket pedig leválasztották a hálózatról.

A mostani rekonstrukció ugyanakkor arra hívja fel a figyelmet, hogy egy ilyen támadásnál nem pusztán az a kérdés, hogy mekkora adatcsomagot sikerült ellopni.

Legalább ilyen fontos, hogy milyen jogosultságokat szerzett a támadó, milyen hitelesítő adatokat kompromittált, milyen rendszerekhez fért hozzá, és mennyire lehet biztosan kizárni, hogy a későbbiekben újra felhasználja a megszerzett hozzáféréseket.

A 229 terabájtos szám tehát látványos, de a történet valódi súlyát nem feltétlenül az ellopott adatok mennyisége határozza meg. Egy néhány megabájtos bizonyítékcsomag mögött is lehet olyan kompromittált infrastruktúra, amelynek helyreállítása, megtisztítása és biztonságos újraépítése jóval nagyobb feladat, mint maga az adatmentés.

A kibertámadás egyik legfontosabb tanulsága ezért nem az, hogy „229 terabájt tűnt el”, hanem az, hogy egy internet felől elérhető sérülékenység, a rendszerek közötti bizalmi kapcsolatok, a túlzott jogosultságok és a gyenge hitelesítőadat-kezelés együtt egy sokkal kisebb kezdeti résből is képesek rendkívül mélyre vezető támadási útvonalat létrehozni.

Forrás: Portfolio.hu

Indexkép: Pexels