A kincstári incidens anatómiája — és miért nem hagyta el a hálózatot 229,1 TB

És a környezet ezt is lehetetlenné tette

• A kimenő forgalom szűrve volt. A támadó saját jegyzete: „nincs kimenő forgalom a pingeken és alap parancsokon kívül.” A Symantec ráadásul blokkolta a kimenő beaconöket.
• Minden Tor / Proton VPN / Mullvad-on át ment. Az anonimizáló csatornák néhány tíz Mbps-re fogják a valós átvitelt — nem a több Gbps-re, amit egy teljes dump igényel.
• A célpontok fogyasztói felhők voltak. Google Drive, pCloud, sync.com, MediaFire. Már a Google Drive is ~750 GB/nap/fiók feltöltési korláttal jár → 229 TB ≈ 305 fiók-nap, és egyik sem képes 229 TB tárolására.

Hova mutatnak valójában a Sliver-jelzések?

A másik két cím egymással kapcsolatban nem álló hálózatban van — nincs közös ASN, prefix, regisztráns vagy upstream szomszéd egyik pár között sem (mindhárom ASN BGP-szomszédlistáját közvetlenül ellenőriztük, nulla átfedéssel), és nyilvános forrás sem köti össze a három címet. Mindhárom külföldi kormányzati / igazságszolgáltatási / közigazgatási hálózatra mutat, nem bulletproof vagy támadó-tulajdonú VPS-térbe — ez összhangban áll azzal, hogy a jelzések visszaélésszerűen használt harmadik fél infrastruktúráján futnak redirectorként, nem dedikált C2-gépeken. Az MVH-egybeesés az egyetlen nyom, amit érdemes közvetlenül továbbvizsgálni — önmagában a WHOIS nem mondja meg, hogy ez a listener a már kompromittált MVH/NISZ-környezeten belül ül-e, vagy csak véletlen szomszéd ugyanabban a nemzeti IP-kiosztásban. Minden itt leírt csak azt mutatja meg, hova ér ki a forgalom — nem azt, ki áll mögötte.

Független megerősítés: a ByteToBreach egy második áldozatától (a grúz bírósági rendszertől, teen.court.ge / hcoj.gov.ge) származó, külön kiszivárgott operátori képernyőképek ugyanezt a mintát mutatják ugyanabban a címtartományban — a 85.209.82.28-at kezdeti belépési pontként használta ki, a 85.209.83.139-et pedig kizárólag SSRF-pivotként, hogy elérjen egyébként kívülről elérhetetlen belső szegmenseket. Mindkettő ugyanahhoz az AS209332-höz és ugyanahhoz a regisztránshoz tartozik, mint a fenti grúz listener IP. Ugyanez a szivárgás mutatja az operátor tényleges, bérelt VPS-ét is — 194.102.105.193, AlexHost SRL, Moldova — egy hétköznapi kereskedelmi hosztot, ami szerkezetileg semmiben nem hasonlít a három kormányzati hálózati listener IP-re. Ez nem igazolja, hogy a 85.209.80.29 maga kompromittálva lett, de megmutatja az operátor bevett szokását: a forgalmat szívesebben vezeti át már feltört, áldozati kormányzati hálózatokon belüli gépeken, mint a saját infrastruktúráján.

Az órák helyes értelmezése

A videóban látható terminál-előzmények szerint az Nmap-futások időbélyege 2026-07-29 01:12–02:37 CEST, egy támadó által kontrollált linuxos pivotgépről (root@NLDW2-AW3) — ez valódi, időrendben előrehaladó műveleti előzmény. Ugyanezeken a képkockákon azonban a felvevő gép asztali órája a teljes 9 perces klip alatt stabilan 17:29 → 17:38 között áll. Ez nem ellentmondás: azt jelenti, hogy a videó egy később rögzített utólagos bemutató, amely a régi terminál-előzményeket lejátssza — nem a művelet valós idejű felvétele. A CEST-időbélyegek azt mutatják, mikor történt a behatolás; a 17:29–17:38 csak azt, mikor készült az utólagos bemutató felvétele, ismeretlen dátumon és időzónában.

Ez pontosítja, nem cáfolja a lenti BloodHound/PDT-megállapítást: legalább három különálló óra van jelen a bizonyítékokban — a kompromittált környezet (CEST), a támadó pivotgépe a művelet idején (CEST), és az elemző/felvevő asztal (ismeretlen zóna) —, és ezeket nem szabad egymással közvetlenül összevetni, mintha egy óra lenne.

Lokalizációs nyomok, amelyek az áldozathoz, nem a támadóhoz tartoznak

A magyar dátum-/hónap-/hétnapformátumok, a Hyper-V/vSphere objektumnevek (teszt, Gép5, achiv_gepek, virusirto1-3), és egy vSphere bejelentkezési banner, amely azt írja: „Hol a tavasz?”, mind a kompromittált magyar rendszerek sajátjai — a kincstár saját IT-csapata által beállított egyedi üzenet, nem támadói vagy gyártói tartalom. Semelyik nem tekinthető támadói attribúciónak.

Külső attribúció — a KELA Cyber megnevezi az operátort

A fentiek mind a támadó saját kiszivárgott anyagaiból származnak: egy gépet és egy módszert profiloznak, nem egy embert. Az egyetlen megalapozott nyilvános kísérlet arra, hogy nevet adjanak a ByteToBreach-nek, a KELA Cyber Intelligence Centertől származik, amely 2025 novemberében profilozta a szereplőt, és 2026. július 17-én frissítette az értékelést.

Hogyan épült fel az azonosítás

A gondolatmenetet érdemes teljes egészében elolvasni, mert tankönyvi eset arról, ahogyan egy operátort nem a jelenlegi eszközhasználata, hanem a saját múltja buktat le:

• Egy újrahasznosított Session ID kötötte össze a két online identitást. A ByteToBreach ProtonMail-, Tuta- és Gmail-címeken, Telegramon (@ByteToBreach, korábban CvHNWwEG és inesslopez), Signalon és Sessionön kommunikált. A Session ID volt a fordulópont: a KELA ezzel kötötte a ByteToBreach online identitását egy másik, korábbi, 2025 júniusában aktív DarkForums-fiókhoz — amely szingapúri cégek adatbázisait szivárogtatta, majd elhallgatott, miután egy másik felhasználó 500 euró átverésével vádolta meg.
• Ez a második felhasználónév algériai infostealer-naplókban bukkant fel. A KELA adattavában keresve két infostealerrel fertőzött gépen jelent meg, mindkettő Algériában, ProtonMail-, Instagram- és TransferWise-belépésként. Az egyiket 2022 szeptemberében fertőzte meg a Raccoon, a másikat 2024 februárjában a StealC — évekkel azelőtt, hogy a ByteToBreach online identitás létezett volna.
• Két konkrét azonosító zárta be a kört. Egyik fertőzött gépen sem volt hekkerfórum-aktivitás, tehát a kapcsolat nem viselkedési hasonlóságon nyugszik, hanem két nyomon: a korábbi inesslopez Telegram-felhasználónév megjelenik az ellopott böngészőadatokban, és egy ugyanott szereplő telefonszám közvetlenül a ma is működő @ByteToBreach Telegram-fiókhoz kötődik.
• Miért állja meg a helyét az érvelés. Három, egymástól független forrástípus fut össze: egy kriptográfiai üzenetküldő-azonosító, amely két fórumidentitást kapcsol össze; kereskedelmi kártevő naplói egy adott ország magángépeiről, ugyanazokkal a belépési adatokkal több, egymással össze nem függő szolgáltatáson; és két közvetlen azonosító, amely ezeket a naplókat a ma is aktív fiókhoz kötik. Egyenként mindegyik gyenge; együtt nem. A döntő pont pedig időrendi: az infostealer-fertőzések akár három évvel megelőzik a bűnözői online identitást. Az operátort hétköznapi felhasználóként kompromittálták, jóval azelőtt, hogy bármi oka lett volna az attribúcióra gondolni — és épp ez a történelmi maradvány leplezte le.

Mit igazol a KELA profilja erről a behatolásról

• A hangoztatott motiváció egyezik. A KELA rögzíti, hogy a ByteToBreach rendszeresen azt állította, előbb megkeresi az áldozatokat, hogy „nem a kormányok, hanem ártatlan emberek az áldozatok”, és hogy a szervezeteknek vállalniuk kell a felelősséget a klienseik adataiért. Ez ugyanaz a beállítódás, mint ennek a szivárogtatásnak a kifejezett megjegyzése, hogy az adat nem eladó és váltságdíjat nem kérnek — szokatlan és következetes ujjlenyomat mindkettőben.
• Az eszközhasználat egyezik. A KELA leírása: ismert sebezhetőségek kihasználása vállalati és felhős infrastruktúrán, opportunista brute force és félrekonfigurálás, valamint megszerzett jelszavak újrahasznosítása — majd munkavállalói adatok, adatbázisok és mentések kiszivattyúzása eladásra vagy bizonyítékként való közzétételre. A fenti idővonal 01–08. lépése pontosan ez a leírás, végrehajtva. Repertoárjának egy eleme itt hiányzik: a kezdeti belépéshez nem volt szüksége adathalászatra vagy infostealer-naplókra, mert azt egy javítatlan, internet felé nyitott hoszt megadta neki — az újrahasznosított jelszavakat pedig a környezeten belül találta.
• Az áldozati profil egyezik. Légitársaságok, bankok, egyetemek, egészségügy és állami szervek Ukrajnában, Kazahsztánban, Cipruson, Lengyelországban, Chilében, Üzbegisztánban és az Egyesült Államokban, több, az érintett szervezetek által utóbb elismert incidenssel. Egy nemzeti kincstár pontosan illik a mintába.
• A hash-törést kiszervezi, 100 dollár per hash áron. Apró részlet, valódi súllyal: a KELA rögzíti, hogy a szereplő fizetett hash-törési szolgáltatást keresett. Olvassa ezt az alábbi jelszóbiztonsági szakasz mellé, ahol a tartomány 11 %-a perceken belül elesett egy saját szólistával, CPU-n. Ebben a környezetben senkinek nem kellett volna fizetnie.
• A 2026 júliusi román eset rímel erre. Két héttel a kincstári szivárogtatás előtt ugyanez a szereplő Románia földhivatalánál (ANCPI) állított behatolást, és olyan Active Directory-adatokat publikált, amelyek Windows XP-t, Windows 7-et és Windows Server 2003-at mutatnak éles üzemben, 69 csoportházirend-objektumot — köztük „DISABLE WINDOWS FIREWALL” és „MIGRARE - ADD ADMINS” nevűeket — és kockázatos AD-jogosultsági viszonyokat. A legacy Windows és az engedékeny címtár nem ennek az operátornak a véletlene; ez a célpontválasztási kritériuma.

Forrás: KELA Cyber Intelligence Center, „ByteToBreach: A Deep Dive into a Persistent Data Leak Operator”, KELA Cyber — Threat Actor Spotlight. Megjelent 2025 novemberében, frissítve 2026. július 17-én. www.kelacyber.com/blog/bytetobreach-a-deep-dive-into-a-persistent-data-leak-operator/ — letöltve 2026. augusztus 3-án. A KELA jelzi, hogy a teljes szereplőprofil további, csak az előfizetői számára elérhető részleteket tartalmaz; az itt idézett minden adat a nyilvános bejegyzésből származik.

A rossz szokások, a károkozás mértéke szerint

• Az ügyfélszolgálat által beállított ideiglenes jelszavak, amelyeket soha nem cserélnek le. A Magyar Államkincstár tartományában a legelterjedtebb jelszó az A1B2c3d4, 389 fiókon. Utána: ABcd1234_ (107), A1B2c3d4_ (79), 111111 (61), abcd1234 (59), Start12345678 (32), ABcd_1234 (32), 123456 (20). Nagyságrendileg 1 300 fiók osztozik legalább egy másik fiókkal ugyanazon a jelszón.
• Egyetlen jelszó 819 vault-soron. Az MvhX*******m123 az Oracle OIM rendszeradminisztrátori jelszava — magának a fióknak a neve, rövid számsorral a végén, itt részlegesen maszkolva. 819-szer szerepel a jelszótárban, újra a kézi blokkban, és újra az {AES} WebLogic blobokban. Bármelyik visszafejtése OIM-adminisztrátori jogot ad — az OIM-admin pedig mind a 9 032 vault-jelszót, nyílt szövegben.
• Kiemelt jogosultságú fiókok ideiglenes alapjelszóval. A 77 _ADMIN / _SMADMIN fiókból kilenc gyenge: három különböző SMADMIN osztozik az ABcd_1234-en; a KUL39104_ADMIN szó szerint a saját felhasználói jelszavát használja; a KUL40582_ADMIN jelszava K@l…@i2, míg a párja, a felhasználói fiók K@l…@i1. A jogosultsági szintekhez külön fiókok tartoznak, de a jelszavak nem különülnek el.
• A jelszó megegyezik a felhasználónévvel. XELOPERATOR:xeloperator és weblogic:weblogic.
• A szervezet saját nevéből képzett infrastruktúra-titkok. Mvh****n@ (vCenter SSO-adminisztrátor), Mvh****0gic, Mvh1**, MvhX*******m123. Mind a 22 {AES} WebLogic blob mindössze három különböző értékre fejt vissza, így egyetlen ellopott SerializedSystemIni.dat nyitotta a teljes middleware-környezetet.
• Név plusz születési dátum mint személyes standard. A 468 emberi jelszóból 225 egy név vagy becenév, utána születési dátum vagy évszám — Dani1993…, Vargak-1981…, B…Dita1966…. Nyilvános adat nyilvános adathoz fűzve.
• Tematikus szótárak, amelyeket minden szólista tartalmaz. 77 kedvenc, állat és mesefigura (Nyuszi1?, Micimacko&06, Pumukli.30), 27 magyar helynév (Tatabánya2800!, Kaposvar1983*/), 21 hónap- vagy évszaknév (Szeptember2021, November01), 16 a munkáltató nevével, és 7 magával a „jelszó" szóval (Jelszó123, Jelszo002002, Titok2017.).
• Még tárolt legacy gyengeségek. 45 fiók továbbra is tárol LM hasht — másodperc alatti visszafejtés, függetlenül attól, mi a jelszó. 13 fióknak valóban üres a jelszava. És az AES mellett des-cbc-md5 Kerberos-kulcsok is jelen vannak, tehát ezeken a fiókoknál a DES etype-ok még engedélyezettek.

Reprezentatív minták a 468 olvasható jelszóból

A felhasználóneveket szándékosan elhagytuk. Ezek visszatérő alakzatok, nem kivételek — az alábbi csoportok mindegyike olyan sablon, amelyet egy szólista és egy szabálykészlet gépiesen újraelőállít. A darabszámok (×n) azt jelzik, hány tartományi fiók használja pontosan ugyanazt a jelszót.

A személyes adatokat a közzétételhez minimalizáltuk: a családnevek kezdőbetűre rövidítve, a születési dátumok évre csonkítva (… jelöli). Felhasználónevet sehol nem közlünk. A csonkítás nélküli halmaz a bizonyítékfájlban marad, azt nem publikáljuk.

A csoportok együtt egyetlen mondatot adnak ki: egy magyar szótár, egy utónévlista, egy helynévtár, a tizenkét hónap és egy évszám négy jegye ennek a halmaznak a túlnyomó többségét újraelőállítaná — pontosan ezt teszi a 4. szakasz egymásodperces szólista-és-szabály sora. Azok a jelszavak állnak ellen, amelyek egyszerűen hosszúak: Chelseafootballclub95, Podmaniczkyutca1975, Agrártámogatások2022, Ezazenjelszavam_013 — egyik sem ötletes, mindegyik legalább 19 karakteres.

5 · Kivetítés a teljes tartományra — 10 073 felhasználói és szolgáltatásfiók

A két „mért" sor közvetlen eredmény. A többi a jelszótár mért hossz- és sablonprofilját vetíti ki az NTDS-populációra — ez védhető, mert mindkét populáció ugyanabból a jelszószabályzatból és ugyanabból a generátorból származik, és szándékosan konzervatívabb a jelszótár saját 99,8 %-ánál, hiszen az NTDS-halmaz olyan fiókokat is tartalmaz, amelyeket a jelszótár soha nem kezelt. A fő állítás mindkét olvasatban áll: nagyságrendileg tíz tartományi fiókból kilenc egy munkahéten belül, egy használt autónál olcsóbb hardveren. A 6 129 számítógépfiók a kivétel — gépi generálású, 120 karakteres titkok; ez a környezet egyetlen valóban rendben lévő jelszóbiztonsági területe, épp azért, mert ezeket soha nem ember választotta.

Tanulságok

• Az a jelszótár, amely nyílt szöveget ad vissza, egyetlen totális hibapont. Egyetlen OIM-export 9 032 identitást kompromittált, nulla törési munkával. A visszafejthető tárolás csak ritka, izolált kivétel lehet, és minden onnan származó exportot teljes környezeti breachként kell kezelni.
• A hossz lényegesen többet számít az összetettségnél. Sózatlan NTLM ellen a modell szerinti sebességgel minden legfeljebb 8 karakteres, nyomtatható ASCII-jelszó két órán belül, minden legfeljebb 9 karakteres pedig körülbelül nyolc napon belül elesik. A Unicode-jelszavakhoz külön jelölthalmaz kell, de a célzott maszkok és nyelvspecifikus szólisták a rövid, kiszámítható választásokat továbbra is kiteszik. Váltás 14 karakteres minimumra, a kényszerített komplexitási szabályok elhagyása, és minden új jelszó ellenőrzése a korábban kiszivárgott jelszavak adatbázisában. Az itt megmaradt néhány jelszó kizárólag a hosszának és kiszámíthatatlanságának köszönhetően maradt meg.
• Jelszógenerátornak soha ne legyen látható sablonja. Az Xx#xxxxx minta négy nagyságrend entrópiát dobott el azért, hogy a jelszó felolvasható legyen. Generáljunk a teljes karakterkészletből, nagyobb hosszon, és a felolvashatóság terhét vigye egy jelszókezelő az entrópia-büdzsé helyett.
• Szüntessük meg a reset-sablont. Kerüljön egyéni tiltólistára az A1B2c3d4*, ABcd*1234*, Start12345678*, abcd1234*, QWer_1234, Jelszo*, Mvh*, Kincstar* és a teljes szervezetnév-család. Minden helpdesk-reset legyen egyszer használatos, véletlen, és következő bejelentkezéskor kötelezően cserélendő.
• A jogosultsági szintek elkülönítéséhez külön hitelesítő adatok is kellenek. Egy külön _ADMIN identitás semmit nem ér, ha a jelszava szó szerint a felhasználó jelszava, vagy az plusz egy. A kiemelt jogosultságú fiókok hitelesítő adatait olyan rendszerben kell kezelni, amely ellenőrzi a kiadásukat és automatikusan cseréli őket. A jelszavakat ne emberek válasszák meg vagy lássák.
• A rotáció ütemterv, nem védelmi intézkedés. A naptár szerinti lejáratot váltsa fel esemény-alapú rotáció — kompromittálódásnál, szerepkörváltásnál, ha a jelszó szerepel egy kiszivárgott jelszóadatbázisban —, a megtakarított energiát pedig adathalászatnak ellenálló MFA-ra kell fordítani, mert az bontja meg valóban azt az ellopott hitelesítő adatok újrafelhasználására épülő támadási láncot, amelyet ebben a behatolásban láttunk.
• Vonjuk ki a legacy kriptográfiát, ami mindezt olcsóvá teszi. NoLMHash beállítása és a 45 tárolt LM hash törlése, a des-cbc-md5 Kerberos etype-ok letiltása, a 13 üres jelszavú fiók azonnali kezelése, és az NTLM teljes kivezetésének megtervezése — épp a sózatlan, nem iterált felépítése az oka, hogy egyetlen asztali GPU-kkal felszerelt gép tízezer fiókot támadhat egyetlen fiók áráért.
• Tekintsük az egész készletet elveszettnek. A teljes NTDS.DIT és a teljes jelszótár birtokában ebben a környezetben egyetlen hitelesítő adat sem tekinthető biztonságosnak. Mind a 16 200 fiók jelszócserét igényel, a számítógépfiókokkal együtt, minden kompromittált tartományban kétszeres krbtgt-rotációval.

Elkapható? — a Yellow Cube válasza

A Golden Ticket használata szándékosan csendes: egy szolgáltatásnak bemutatott hamisított TGT közönséges Kerberosnak tűnik, így a jelek közvetettek — szokatlan élettartamú jegyek, RC4-titkosítás ott, ahol a környezet már AES-re állt át, vagy előzetes hitelesítés nélküli szolgáltatásjegy-kérés. A viselkedésalapú identitásészlelés felszínre hozza ezeket: Varonis, Cynet, Stellar Cyber. Egy elhelyezett honeytoken-fiók egyértelművé teszi — egy olyan identitás bármely használata, amelynek soha nem szabadna hitelesítenie, rendeltetéséből adódóan rosszindulatú: Cynet. A Cymulate pedig bizonyítja, hogy a riasztás működésbe lép, mielőtt szükség lenne rá.

De az észlelés itt a második vonal. Az igazi kontroll az elszigetelés és a rotáció — a 07. lépésben megnevezett vészhelyzeti kétszeres krbtgt-rotáció, minden kompromittált tartományban, a két jelszócsere között előírt várakozással végrehajtva, a Yellow Cube 24×7 SOC és egy Group-IB IR készenléti szerződés keretében nyújtott támogatásával — mert amíg ez nincs kész, a címtárat továbbra is elfoglaltként kell kezelni.

Hogyan olvassa — módszertan

• A termék-hozzárendelések a Yellow Cube saját Security Stack Matrixából származnak — 27 kontrollréteg 9 szekcióban, mindegyiken NIS2-jelöléssel, publikált gyártó–réteg lefedettségi térképpel. Az alábbiakban semmi sem azért került be, hogy kitöltsön egy sort.
• A leírások konkrét védelmi képességekre vonatkoznak. Minden alábbi sor megnevezi a konkrét képességet, amely a munkát végzi, és a terméket, amely biztosítja — mert a konkrét képességtől függ, hogy a védelem hatékony-e. A privilegizált munkamenet rögzítése és a jelszó biztonságos jelszótárban kezelése két különböző feladat; a végponti és a felhős biztonsági konfigurációkezelés két különböző hatókör. Ettől válik a termékek és a védelmi feladatok összerendelése a gyakorlatban is használhatóvá.
• A portfólió tizenhat gyártója közül tizenkettő helyet kap itt; négy nem. Ebben a láncban nincs DDoS, nincs e-mail-vektor és nincs mobileszköz, ezért az ezeket a területeket lefedő gyártók kimaradnak. Csak azokat a kontrollokat megnevezni, amelyek valóban változtattak volna a kimeneten — ez a gyakorlat lényege.
• Végfelhasználói biztonságtudatossági képzés sem szerepel. Ebben a behatolásban nincs adathalászat, nincs makró és nincs felhasználói hiba: nem javított middleware, nyitva hagyott debug port, nyílt szöveges jelszavak és lapos erdőbizalom van. Az egyetlen jogos képzési érv itt a védőkre mutat, nem a munkatársakra — lásd a 04. lépést.
• A konfigurációs kockázatok kezelése önálló védelmi feladat. Amit ez az operátor használt, jórészt nem hiányzó termék volt, hanem egy beállítás. Védelem nélkül hagyott LSASS, még engedélyezett SMBv1, elérhető hibakeresési szolgáltatás, túl engedékeny címtárjogok, nyílt szöveget visszaadó identitástár. A Cynet ESPM-je és a WithSecure Elements biztonsági konfigurációkezelése pontosan ezeket hozza felszínre, folyamatosan — dokumentált kockázatként egy áttekintő felületen, nem felfedezésként valaki más képernyőképein. Minden alábbi Megerősítés sor olyan dolog, amit időben jelzünk.
• Szolgáltatási határ. A Yellow Cube a 24×7 SOC/MDR-t, az incidenskezelési készenléti szolgáltatásokat, a HackLabot és a képzéseket, valamint a stratégiai tervezési auditokat szállítja. A gyakorlati bevezetést, a rendszerek biztonsági megerősítését és üzemeltetést a helyi MSSP-partner végzi. Ahol az alábbi javítás architekturális, ott a felelős ennek megfelelően van megnevezve.

Lefedettség egy pillantásra

Négy NIS2 szempontból kötelező réteg dőlt el teljesen ebben a behatolásban: a privilegizált hozzáférés-kezelés, az identitásalapú fenyegetésészlelés, a menedzselt észlelés és reagálás, valamint a mentés. Egy közigazgatási, alapvető szolgáltatást nyújtó szervezetnél ez a négy nem opcionális érettség — ez a padló.

Az öt pont, ahol ez a lánc valóban megszakad

Tizenkét egyenlő súlyú javaslat nem javaslat. Sorrendben aszerint, hogy melyik mennyit vesz ki a behatolásból:

• A védelmi eszközök jeleztek, de senki nem foglalkozott a riasztásokkal. A 04. és a 09. lépés ugyanaz a hiba kétszer: a kimenő szűrés blokkolta a támadót, a Symantec blokkolta a beaconjait és az LSASS-elérését, de egyikük riasztásaira sem reagált senki. Egy 24×7 SOC/MDR képesség itt a legnagyobb hatású elérhető változtatás — a már megvásárolt kontrollokat valódi reagálássá alakítja, és ez az egyetlen javaslat, amely ezt a behatolást öt és fél napból órákra rövidítette volna.
• Statikus privilegizált jelszavak, mindenhol. Szolgáltatásfiók jelszava shell historyban (06), adminisztrátori jelszó újrahasznosítva a middleware rétegen (09, 10), és 9 032 jelszó úgy tárolva, hogy visszaolvasható (05). Az első kettőre a privilegizált hozzáférés-kezelés a válasz; a harmadik léptékéhez lásd a jelszóbiztonsági szakaszt.
• Az erdőkön átnyúló DCSync láthatatlan volt. A 07. lépés a teljes lánc legtisztább észlelési lehetősége, és észrevétlen maradt — legvalószínűbben azért, mert nem működött megfelelő megfigyelés a bizalmi háló minden erdőjének tartományvezérlőin. Identitásalapú fenyegetésészlelés teljes DC-lefedettséggel, validálva, nem feltételezve.
• Lapos belső hálózat, kitett menedzsment-réteggel. A 02. és a 10. lépés. A szegmentáció nem akadályozta volna meg a kezdeti bejutást, de bezárta volna egy olyan alhálózatba, amelyet a támadó maga nevezett használhatatlannak — ahelyett, hogy elérje a 116 éles VM-et tartó hipervizort.
• 36 TB fájlmegosztás mindenféle adatkezelés nélkül. A 08. lépés. Senki nem tudta, mi van azokban a megosztásokban, ki olvashatja őket, és hogy valaki épp most járta végig mindet. Ez feltárható, javítható állapot — és ez dönti el, mennyire súlyos egy incidens, ha valaki már bent van.

A konfigurációs és tervezési megállapítások — és aki lezárja őket

Amit ez az operátor kihasznált, jórészt beállítás volt, nem hiányzó termék. Ez jó hír: a beállítások megtalálhatók. Minden alábbi pont olyan, amit a biztonsági konfigurációkezelés folyamatosan felszínre hoz, vagy amit egy stratégiai tervezési audit behatárol és bizonyít — majd az MSSP-partnere lezár.

A mentésről — a 10. lépés utolsó mentsvára, és hogy hol a helye

A 10. lépés 229,1 TB virtuális gép helyben történő titkosításának terve volt. A helyben titkosítás ellen pontosan egy kontroll válaszol, és az a módosíthatatlan, offline, tesztelt mentés. Ennek a jelentésben az utolsó mentsvár helye jár — az, ami eldönti, hogy egy incidens rossz hét vagy létkérdés.

És 229,1 TB visszaállítása messze nem triviális. Ugyanaz a fizika, amely a nagy tételű exfiltrációt kivihetetlenné tette a jelentés korábbi részében, a helyreállításnál visszafelé vág:

És mindegyik szám azt feltételezi, hogy a mentések léteznek, módosíthatatlanok, nem titkosították őket az általuk védett környezettel együtt, és hogy egy ilyen léptékű visszaállítást valóban begyakoroltak — nem csak beállítottak. Egy mentési feladat, amelyből még soha nem állítottak vissza, nem kontroll, hanem hit.

A Yellow Cube nem kínál mentési megoldást, és ez pozicionálási döntés, nem hiányosság. A mentés és az üzletmenet-folytonosság kiforrott, kiválóan kiszolgált piac, ahol egy szakosodott kiberdefenzív disztribútor kevés olyat tud hozzáadni, amit a meglévő szereplők ne tudnának jobban. A portfólió alapelve: területenként egy specialista gyártó, és csak olyan területen, ahol valódi értéket lehet hozzátenni. Ez az a terület, ahová a saját meglévő gyártóját érdemes hoznia — a javaslat itt az, hogy a kontroll legyen tesztelt, nem az, hogy tőlünk vásárolja.