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 lábké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 élő ellentmondás: azt jelenti, hogy a videó egy később rögzített végigjátszás, 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 a végigjátszás felvétele, ismeretlen dátumon és időzónában.

Ez finomítja, nem ellentmondja a lenti BloodHound/PDT-megállapításnak: 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 személyiséget. 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 személyiséget 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 személyiség 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 személyiséget. 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óhigiéniai 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.

1 · Mennyit tudunk már, és mennyi esik el ezután

Egy fontos részlet: 4 664 vault-felhasználónév az NTDS dumpban is szerepel, de ezek közül már csak 503 hash egyezik a vaultban tárolt jelszóval. A rotáció tehát működik — az átfedő fiókok kb. 89 %-a jelszót váltott a vault-pillanatkép és az NTDS dump között. Csak éppen semmit sem hozott, mert a generátor sablonja nem változott (lásd 4. szakasz): egy friss vault-export az első napon ugyanezt a populációt kompromittálja újra.

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

• Helpdesk-reset sablonok, 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 vaultban, ú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.
• Privilegizált fiókok reset-alapértelmezéseken. 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 tierszeparáció identitásként létezik, titokként nem.
• 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 principalokon 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.

4 · A 9 030 vault-jelszó visszafejtési ideje ≈1 TH/s NTLM mellett (4 × RTX 4090)

A vault 98,6 %-a négy perc alatt elesik; 99,8 %-a nyolc napon belül. 9 030 jelszóból mindössze 18 maradna állva — olyanok, mint az Ezazenjelszavam_013, Chelseafootballclub95, Agrártámogatások2022, Bobi-Kacsa-Bruni12, Podmaniczkyutca1975. A hosszú és váratlan minden esetben legyőzi a rövidet és komplexet. És közülük is több elesik egy kombinátoros vagy hibrid támadásban, tehát a 18 az optimista olvasat.

A két maszkos sor a legfontosabb megállapítás. A „véletlen" 8 és 10 karakteres vault-jelszavak nem véletlenek: fix sablont követnek — két betű, egy számjegy, majd öt vagy hét kisbetű. Ez a sablon a látszólagos 8 karakteres keresési teret 6,6 × 10¹⁵-ről 3,2 × 10¹¹-re zsugorítja, azaz 20 000-szeres könnyítést ad. Aki bármilyen más úton visszafejt néhányat, azonnal meglátja a mintát, és a többit ingyen maszkolja le. A generátort láthatóan azért választották így, hogy a jelszó telefonon felolvasható legyen; ez négy nagyságrend entrópiába került.

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 vault 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 vault saját 99,8 %-ánál, hiszen az NTDS-halmaz olyan fiókokat is tartalmaz, amelyeket a vault 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ó áránál kevesebbe kerülő 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óhigiéniai területe, épp azért, mert ezeket soha nem ember választotta.

Tanulságok

• Az a vault, 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 legyőzi a komplexitást, és nem is szorosan. Sózatlan NTLM ellen minden ≤ 8 karakteres jelszó két órán belül, minden ≤ 9 karakteres egy héten belül elesik, akármilyen ügyesek a karakterek. Váltás 14 karakteres minimumra, a kényszerített komplexitási szabályok elhagyása, és minden új jelszó ellenőrzése egy breach-korpusszal. 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 tierszeparációnak a titkok szeparációjának kell lennie. Egy külön _ADMIN identitás semmit nem ér, ha a jelszava szó szerint a felhasználó jelszava, vagy az plusz egy. A privilegizált fiókok helye egy kiadás–rotáció rendszer, amelyben az értéket ember nem választja meg, és nem is látja.
• 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, breach-korpusz-találatnál —, a megtakarított energiát pedig phishing-ellenálló MFA-ra kell fordítani, mert az bontja meg valóban azt a credential-replay 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-rig 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 vault birtokában ebben a környezetben egyetlen credential sem menthető. Mind a 16 200 principal jelszócserét igényel, a számítógépfiókokkal együtt, dupla krbtgt-rotációval.

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.
• Az állítások képességre szólnak, nem rétegcímkére. Minden alábbi sor megnevezi a konkrét képességet, amely a munkát végzi, és a terméket, amely szállítja — mert ezen a szinten dől el, hogy egy kontroll tart-e vagy nem. A privilegizált munkamenet rögzítése és a jelszó széfbe zárása két különböző feladat; a végponti és a felhős posture-kezelés két különböző hatókör. Ez a pontosság teszi a leképezést használhatóvá, nem dekoratívvá.
• 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 gyengeséget elsőrangú kontrollként kezeljük. 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, hallgatózó debug transport, túl engedékeny címtárjogok, nyílt szöveget visszaadó identitástár. A Cynet ESPM-je és a WithSecure Elements posture-kezelése pontosan ezeket hozza felszínre, folyamatosan — megállapításként egy dashboardon, nem felfedezésként valaki más képernyőképein. Minden alábbi Keményí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 retainereket, a HackLabot és a képzéseket, valamint a Strategic Planning auditokat szállítja. A gyakorlati bevezetést, hardeninget é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 kontrollok elsültek, és senki nem olvasta el őket. 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, és mindkettő üres szobába riasztott. 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 fenti jelszóhigiéniai 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 volt műszerezé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 megvetett lábat, 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 posture-kezelés folyamatosan felszínre hoz, vagy amit egy Strategic Planning 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.