# ByteToBreach → Magyar Államkincstár — Behatolási idővonal > A Magyar Államkincstár elleni támadás időrendi rekonstrukciója 24 támadói képernyőkép alapján: hogyan vezetett az mvh erdők közötti bizalmi kapcsolat a bejutáshoz, és miért nem hagyta el a hálózatot 229,1 TB adat. - Kanonikus URL: https://yellowcube.eu/hu/reports/bytetobreach-allamkincstar/ - Kiadó: Yellow Cube - Nyelv: hu Webinárfelvétel **2026\. aug. 13-i előadásunk** — 30 percben végigvesszük ezt a rekonstrukciót: mely védelmi kontrollok működtek, miért nem lett a riasztásokból reagálás, és hol lehetett volna megszakítani a támadási láncot. [Felvétel megtekintése →]() [Diasor megtekintése →]() Támadó: ByteToBreach · Célpont: Magyar Államkincstár ## A kincstári incidens anatómiája — és miért nem hagyta el a hálózatot 229,1 TB A Magyar Államkincstárba az mvh erdők közötti (inter-forest) bizalmi kapcsolaton át történt behatolás időrendi rekonstrukciója — a támadó által közzétett 24 képernyőkép és a rajtuk látható időbélyegek alapján. A jelentés azt is megvizsgálja, hogy mennyi időt venne igénybe 229 terabájt adat továbbítása. **Időszak:** 2026. júl. 25. – 31. **Belépés:** esb.mvh.allamkincstar.gov.hu **Időzóna:** CEST-re normalizálva (UTC+2) **Készült:** 2026-08-06 Behatolás időtartama 5,5 nap bejutás → nyilvános szivárgás Adatkivitelre rendelkezésre álló idő a 229 TB megtalálása után ~68 óra (júl. 28. → júl. 31.) ESXi-ben látott datastore-kapacitás 229,1 TB 116 VM, du -sh /vmfs A tömeges adatkivitel értékelése Kivitelezhetetlen — és nem is ez volt a terv nyilvános szivárgás ≈ 70 MB bizonyíték #### Vezetői összefoglaló 2026\. július 25. és 31. között egyetlen operátor tört be a Magyar Államkincstárba a Vidékfejlesztési Hivatallal (MVH) fennálló kétirányú, erdők közötti bizalmi kapcsolaton keresztül, tartományi rendszergazdai jogosultságot szerezve négy Active Directory erdőben, és teljes kontrollt a virtualizációs környezet felett — 116 virtuális gép és 229,1 TB adattár. **A védelmi eszközök jórészt jelen voltak és jórészt működtek.** A DMZ kimenő szűrése elvágta az operátor reverse shelljeit, a Symantec pedig blokkolta a beaconjeit és a hitelesítő adatokhoz való hozzáférését — egészen addig, míg kézzel le nem állította a Symantecet. Nem a kontrollok mondtak csődöt, hanem a reagálás: a riasztásaikra öt és fél napon át senki nem reagált. **Tömeges adatkivitel nem történt.** 229,1 TB mozgatása a behatolás időablakában fizikailag kivitelezhetetlen volt — tartós ~7,5 Gbps kellett volna hozzá —, és nem is ez volt a terv. A nyilvános szivárogtatás egy ~70 MB-os bizonyítékcsomag volt, azzal a kifejezett megjegyzéssel, hogy váltságdíjat nem kérnek. A tartós kárt a hitelesítő adatok kiszivárgása okozza, nem az ellopott adatok mennyisége: 9 047 jelszó már nyílt szövegben van, és további több ezer jelszó egy héten belül feltörhető GPU-val. **Az első lépés egy képesség, nem egy termék:** 24×7 észlelési és reagálási szolgáltatás a meglévő védelmi eszközökhöz, majd a jelszókezelés és az identitásarchitektúra hiányosságainak megszüntetése. A javítás lépései [A lánc megszakítása]() szakaszban található. #### Tartalom 1. [Támadási lánc]() — a 12 lépéses idővonal 2. [Valóban elhagyhatta a hálózatot 229,1 TB?]() 3. [A támadó azonosítása és eszközkészlete]() 4. [Jelszóbiztonság és a kinyert hitelesítő adatok]() 5. [A számok mögötti szokások]() 6. [Mit szerez egy magányos támadó egy GPU-kkal felszerelt gépen]() 7. [A krbtgt kulcs & a Golden Ticket]() 8. [A lánc megszakítása & hol kezdje]() ## Támadási lánc Hozzáférés Felderítés Begyűjtés Hatás / közzététel Minden lépésen ott van egy **sárga Yellow Cube sáv** a rövid válasszal arra, hogy „mi állítja ezt meg?”. A teljes kifejtés — megelőzés, észlelés, megszakítás és biztonsági megerősítés — a jelentés végén, [A lánc megszakítása]() szakaszban található. A lépésszámok a támadási láncot követik; ahol több művelet július 26-án ugyanabba a néhány órába esik, a sorrend a támadó párhuzamos munkameneteinek munkafolyamatát tükrözi, nem szigorú óra szerinti rendet. Minden kártya meg van jelölve az elsődleges MITRE ATT&CK technikájával. 1. júl. 25.22:14–22:22 CEST 01Kezdeti hozzáférés[T1190]() ### WebLogic RCE — a kezdeti hozzáférés A támadó a CVE-2017-10271 deszerializációs sérülékenységet kihasználva Python-alapú reverse shellt indít az ESB virtuális kiszolgálóján. Nem éles kiszolgáló — de bejárat a Vidékfejlesztési Hivatal (MVH) hálózatába. `CVE-2017-10271``reverse shell → 91.229.23.96``1_FOOTHOLD.png` Yellow Cube Alapból tiltó kimenő szabály a DMZ-ben (**Stormshield**) elvágja a reverse shellt; a **WithSecure** sebezhetőség-kezelés és a **Group-IB ASM** külső támadásifelület-felmérés egy kilenc éve nyitott, internet felé kitett WebLogic CVE-t hoz felszínre — még más előtt. [Hogyan ↓]() 2. júl. 25→26.éjszaka folyamán 02Perzisztencia & oldalirányú mozgás[T1210]() ### MS17-010 a belépési alhálózaton EternalBlue egy régi Win2003 gép ellen a 10.254.5.x-en, Sliver C2 SOCKS5 pivottal. „Haszontalan gép, de perzisztenciát ad” — a védett hálózatok más szegmenseken vannak. `MS17-010``Sliver C2``2_PERSISTENCE.png` Yellow Cube A **Cynet** az egyik kevés modern EDR, amely ma is fedi a Windows Server 2003-at — SOC által támogatott észlelés azon a gépen, amit mások elhagytak; a **Stormshield** szegmentálja, a **Stellar Cyber** látja a beacont. [Hogyan ↓]() 3. júl. 26.14:28 CEST 03Második vektor[T1190]() ### Elfelejtett JDWP debug port Egy nyitva hagyott Java Debug Wire Protocol port egy WebLogic gépen egy második, tisztább RCE-t ad az oracle felhasználóként. `JDWP RCE``munkamenet @ 2026-07-26 14:28:20 +0200``3_FORGOTTEN_JDWP.png` Yellow Cube Portszűkítés (**Stormshield**) és külső támadásifelület-felmérés (**Group-IB ASM**) bezárja azt a debug portot, amely senkit sem hitelesít. [Hogyan ↓]() 4. júl. 26.napközben 04Felderítés / szegmentáció[T1046]() ### Nekiütközve a szegmentációnak A kimenő forgalom pingekre és alap parancsokra korlátozva (valószínűleg SELinux + egress-szűrés); a WebLogic-sebezhetőségek jelen vannak, de korlátozottak. A szomszédos alhálózatok már falakba ütköznek. `nincs kimenő forgalom az ICMP-n kívül``4_POKING_WEBLOGIC.png` Yellow Cube A tiltások már működtek — csak senki nem olvasta őket. A **Stellar Cyber** központosítja a tiltási eseményeket, a **Yellow Cube 24×7 SOC** pedig embert állít mögéjük. [Hogyan ↓]() 5. júl. 26.11:46 CEST 05Identitásrendszer[T1552]() ### Oracle Identity Self-Service Hozzáférés a Magyar Államkincstár identitásportáljához — több ezer kormányzati fiók, módosíthatóan, visszafejthető jelszavakkal. A tartományközi kapcsolat mértéke kezd kirajzolódni. `OIM 10.254.21.121:14000``5_BIG_IDENTITY_MESS.png` Yellow Cube Szegmentált portál (**Stormshield**), biztonságos jelszótárban kezelt rendszergazdai hitelesítő adatok (**Imprivata**), csali fiókok (**Cynet**) — a visszafejthető jelszótárolás problémájára pedig egy **stratégiai tervezési audit** határozza meg a javítás lépéseit. [Hogyan ↓]() 6. júl. 26.19:55 CEST 06Hitelesítő adatok & bizalmi kapcsolat[T1552.003]() · [T1482]() ### Az exchmentes admin és az erdők közötti bizalom A shell-előzmények felfednek egy teljes AD-jogú szolgáltatásfiókot (exchmentes / Papi\*\*\*\*\*\*\_44\_) és egy **kétirányú, erdők közötti bizalmi kapcsolatot**: MVH ↔ allamkincstar.gov.hu. Teljes admin — de csak ha elérhető a tűzfallal védett 10.10.x szegmens. `bejelentkezés innen: 185.195.232.103``bizalom: FOREST_TRANSITIVE``7_HISTORY_TREASURES.png` Yellow Cube Széfben tárolt, automatikusan rotált szolgáltatásjelszó (**Imprivata**) soha nem kerül shell history-ba; a **Varonis** azonnal jelez, amint erdőhatáron át hitelesít. [Hogyan ↓]() 7. júl. 27.00:28–02:21 CEST 07Erdők feltérképezése[T1003.006]() · [T1482]() ### BloodHound és DCSync az erdőkön át NTDS-titkok kinyerve, tartományi bizalmak feltérképezve: MVH.LOCAL ↔ ALLAMKINCSTAR.GOV.HU ↔ MAK gyermek-erdő, plusz a NYUFIG / ONYF nyugdíj-erdők. A Tier-0-ig vezető elérhető útvonal feltérképezve. `BloodHound-gyűjtés 2026-07-27T00:28Z``bejelentkezés 185.195.232.163``9_CROSSING_FRONTIERS.png · 10_FSP.png` Yellow Cube A nem tartományvezérlőről futó DCSync az AD egyik legtisztább jelzése — **Varonis** vagy **Cynet** minden erdő DC-jén, a **Cymulate** pedig igazolja, hogy a riasztás elsül. [Hogyan ↓]() 8. júl. 27.14:33 CEST 08Adathozzáférés & tárolók felderítése[T1083]() · [T1039]() ### OIM-adatbázis + a tárolókörnyezet feltérképezése Az Oracle Identity Manager sémája DBeaverben böngészve; vállalati fájlmegosztások felderítve (Terinfo 15,9 TB, Adat 15,9 TB, ATF 5 TB, shadowcopy). Mindenhol kis tárolók — a kincstári adatokat **lassan letöltik**, a VM-eket titkosítják. `DBeaver-lekérdezés 2026-07-27 14:33:15``8_ORACLE_OIM_VAULT.png · 11_SCOUTING_STORAGES.png` Yellow Cube A **Varonis** pontosan ezért készült: legkisebb jogosultság 36 TB megosztáson, és riasztás abban a pillanatban, amint valaki végigpásztázza őket. [Hogyan ↓]() 9. júl. 27.18:24–22:05 CEST 09Védelmi rendszerek megkerülése[T1685]() · [T1003.001]() ### Szembeszállás a Symanteccel (SEP) SCCM titkos-házirend kinyerése; a Symantec blokkolja a kimenő beaconöket és a named-pipe LSASS-hozzáférést. Megkerülés: RDP a SEP-gépre, az smc.exe / SepMasterService leállítása, majd LSASS-dump — „lsass works :)”. `loot/2026-07-27_18-24-42_policies``nmap 22:05 CEST``12_CONFRONTING_SYMANTEC.png` Yellow Cube A Symantec működött — amíg le nem állították. A manipulációt vagy az ügynök kiesését jelző riasztás (**Cynet**, **WithSecure**) a **24×7 SOC**\-kal az éjszaka leghangosabb eseményévé teszi ezt. [Hogyan ↓]() 10. júl. 28.13:41–15:25 CEST 10Virtualizáció átvétele[T1078]() ### vCenter és a 229,1 TB-os datastore-ok A vCenter hitelesítő adatai végre megvannak (administrator@vsphere.local); 116 VM, 3 host, Primera/IBM datastore-ok összesen **229,1 TB** (du -sh /vmfs). A terv: a VM-ek helyben titkosítása ESXi-ből. A dia így zárul: „To be continued”. `FreeRDP 10.17.0.200``du -sh /vmfs → 229.1T``13_VCENTER_TAKEOVER.png` Yellow Cube Zárja el a menedzsment-hálózatot (**Stormshield**), tárolja biztonságos jelszótárban a vSphere SSO rendszergazdai fiók hitelesítő adatait (**Imprivata**), és küldje az ESXi syslogot oda, ahol valaki figyeli (**Stellar Cyber**). [Hogyan ↓]() 11. júl. 30.19:36 CEST 11Előkészítés & feltöltés[T1567.002]() ### Bizonyíték-csomag a Google Drive-ra 16 elem feltöltve egy „MAGYAR” Drive-mappába a „Loic Matrier” fiókkal: a képernyőképek közül 13, a CREDS.txt, a RECON.txt és egy videó — összesen nagyjából **70 MB**. Nem tömeges adatkivitel. `Drive-tevékenység 2026. júl. 30. 19:36``google-drive-uploader.png` Yellow Cube Ez a feltöltés a támadó saját gépéről ment, nem kincstári hostról — így semmilyen hálózaton belüli kontroll nem éri el. Itt a **Group-IB** Digital Risk Protection válaszol: figyeli az alvilági piactereket, és jelez abban a pillanatban, amint az ellopott hitelesítő adatok eladásra kerülnek — a 9 047 már nyílt szövegben lévő, és az a több ezer gyenge hash, amit egy kis GPU-kkal felszerelt gép napok alatt feltör. [Hogyan ↓]() 12. júl. 31.11:27 CEST 12Nyilvános közzététel— ### Szivárogtatás a spear\[.\]cx-en A „The Magyar Conquest” topik élesben, a képernyőkép-készlettel és tartalék tükrökkel (pCloud, sync.com, MediaFire). Kifejezett megjegyzés: **„az adat nem eladó… nem kérünk váltságdíjat.”** `spear[.]cx DLS · szerkesztve +46 perc``DLS.png` Yellow Cube A **Group-IB** Digital Risk Protection hetekről órákra rövidíti a felderítést, és leszedi a tükörpéldányokat. [Hogyan ↓]() ## Valóban elhagyhatta a hálózatot 229,1 TB? [↑ tartalom]() #### A teljes 229,1 TB mozgatásához kellene | Tartós sebesség, 0–24 | Ennyi idő alatt | | --- | --- | | ≈ 7,5 Gbps | 68 órás ablak | | ≈ 3,9 Gbps | 5,5 napos behatolás | | ≈ 707 Mbps | 30 nap | #### 229,1 TB mozgatási ideje tartós sebességen | Vonali sebesség | Időtartam | | --- | --- | | 100 Mbps | ≈ 212 nap | | 1 Gbps | ≈ 21 nap | | 10 Gbps (ideális) | ≈ 2,1 nap | #### É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. Következtetés **229,1 TB soha nem volt exfiltrációs célpont.** Ez annak a virtualizációs környezetnek a mérete, amelyet a támadó **helyben, ESXi-ből történő titkosításra** készített elő — egy kettős zsarolás (double-extortion) pusztító fele. A képernyőképek egyértelműen kimondják: „a VM-eket közvetlenül ESXi-ből titkosítjuk… miközben az államkincstári adatokat lassan letöltjük.” Az exfiltráció **szándékosan szelektív** volt — OIM / kincstári adatbázisok, hitelesítő anyagok és egy összeválogatott bizonyíték-készlet — nem a teljes 229 TB lemásolása, amit sem az időkeret, sem a hálózati sáv nem enged. A nyilvános szivárgás egy **~70 MB-os bizonyíték-csomag** volt, kifejezetten „nem eladó, nincs váltságdíj”. Nem volt ideje mindent elvinni — és saját terve szerint sosem ezt akarta. ## A támadó azonosítása és eszközkészlete (videobizonyíték) [↑ tartalom]() A 24 képernyőkép mellett a támadó egy képernyőfelvételt is hátrahagyott. A videóból kinyert 125 kulcskockát képkockánként átnéztük olyan nyomok után kutatva, amelyek nem az áldozatot, hanem magát az _operátort_ jellemzik — asztali környezet, eszközverziók, saját hosztnevek, C2-infrastruktúra és óra-artefaktumok. #### Megerősítve a támadó saját asztalán - **Saját hosztnév szivárgott ki:** több terminálprompt is kali@stephlabs\-t mutat (zsh, ismétlődő „corrupt history file /home/kali/.zsh\_history” hibával). A támadó VM neve second\_kali, Oracle VM VirtualBoxban fut egy Linux Mint/Cinnamon asztalon (Terminator, VS Code, Firefox kitűzve; genmon tálca-widget). - **C2-keretrendszer:** egy élő sliver > konzol mTLS-implantokat listáz, amelyek a támadó által kontrollált infrastruktúra felé kommunikálnak, root/oracle jogosultsággal futva Linux/amd64 gépeken az áldozat Hyper-V/vSphere-környezetében. - **Payload-elnevezés:** a kihelyezett implant a támadó saját /root/magyar.exe fájlból származik — a „magyar” szó tudatos utalás az áldozat nemzetiségére, nem áldozat-oldali artefaktum. - **Képernyőn látott eszközök:** NetExec, Evil-WinRM (v3.5 → v3.9), FreeRDP/xfreerdp, Nmap 7.94SVN, TigerVNC, Burp Suite Community Edition egy dedikált „PortSwigger - Chromium” profillal, vSphere Client. - **Szokások:** két Terminator keresősáv előre kitöltve sshd és encrypted szavakkal — kézi log-/kulcsszókeresésre utal a rögzített kimenetben. - **OPSEC:** a 125 kulcskocka semelyikén nem jelent meg VPN/Tor-kliens, jelszókezelő, személyes háttérkép, könyvjelzősáv vagy nem angol nyelvű megjegyzés — a hosztnév- és C2-szivárgástól eltekintve fegyelmezett, kizárólag munkához használt asztali környezet. #### A videóból kinyert indikátorok | Típus | Érték | | --- | --- | | Operátor hosztnév | kali@stephlabs | | Támadó VM | second\_kali (VirtualBox) | | C2-keretrendszer | Sliver (mTLS) | | C2 listener IP-k | 84.206.46.11 · 84.205.244.140 · 85.209.80.29 | | Payload | /root/magyar.exe | | Újrahasznált hitelesítő adat | exchmentes / Papi\*\*\*\*\*\*\_44\_ | #### Hova mutatnak valójában a Sliver-jelzések? | Listener IP | Helyszín | Hálózat | | --- | --- | --- | | 84.206.46.11 | Budapest, HU | AS31581 NISZ (Magyarország nemzeti e-kormányzati szolgáltatója) — az MVH nevére regisztrált blokk, ugyanaz az erdő, amelynek az allamkincstar.gov.hu-ba mutató bizalmi kapcsolata a Tier-0-hoz vezető utat adta (06-os esemény) | | 84.205.244.140 | Athén, GR | AS35506 Information Society S.A. — Görögország SYZEFXIS közigazgatási hálózata (proxy18.syzefxis-hosting.gr) | | 85.209.80.29 | Tbiliszi, GE | AS209332 — a Grúz Igazságszolgáltatási Legfelsőbb Tanács, Rendes Bíróságok Osztálya | 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. A KELA értékelése A KELA értékelése szerint a ByteToBreach-et **valószínűleg Zakaria Mahdjoub, egy algériai, oráni lakos üzemelteti** — ezt technikai bizonyítékokkal támasztja alá, köztük infostealerrel fertőzött eszközökről visszanyert adatokkal, böngészősütikkel és kapcsolódó digitális nyomokkal. A „valószínűleg” a KELA saját megfogalmazása, és szándékosan így adjuk vissza. Ez fenyegetés-felderítési értékelés, nem jogi megállapítás: vádemelésről, eljárásról vagy ítéletről nincs tudomásunk, és _ebben_ a jelentésben vizsgált bizonyítékok közül semmi nem támasztja alá önállóan az azonosítást. Azért szerepel itt, mert ez a legjobban alátámasztott elérhető nyilvános attribúció, és mert az érvelése a maga keretein belül értékelhető. #### 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. ## Jelszóbiztonság — mit fed fel valójában a kinyert hitelesítő adatok [↑ tartalom]() A kiszivárgott CREDS.txt (4,6 MB, 65 885 sor) nem egy lista, hanem három: egy kézzel összeválogatott infrastruktúrához tartozó hitelesítőadat-blokk, egy **nyílt szöveges** Oracle Identity Manager jelszótárexport 9 032 fiókkal, és egy teljes NTDS.DIT dump 16 200 fiókkal, 40 467 Kerberos-kulccsal. Mivel ezek közül 9 047 jelszó nyílt szövegként áll rendelkezésre, a szervezet valódi jelszóbiztonsága nem becsülhető, hanem közvetlenül mérhető — és ebből a mérésből számszerűsíthető, hogy a csak hash-ként meglévő maradékból mennyit szerezne meg egy egyedül dolgozó támadó egy néhány GPU-ból álló gépen. #### 1 · Mennyit tudunk már, és mennyi esik el ezután A 10 073 tartományi felhasználói és szolgáltatásfiók az NTDS dumpban **1 104** már megfejtve 11,0 % — mért, csak CPU-val **≈7 960** esik el egy héten belül 79,0 % — becsült, 1 TH/s rig **≈1 010** valószínűleg ellenáll 10,0 % — becsült Miből áll össze a már megfejtett 1 104 fiók **503** nyílt szöveggel igazolt az NT hash egyezik egy jelszótárban tárolt jelszóval **13** üres jelszó NT hash 31d6cfe0… **588** ebben az elemzésben megfejtve csak CPU, saját 1,3 M-os lista **10 073 fiókból 1 104 (11,0 %) néhány perc CPU-idő alatt esett el**, mindössze 197 különböző jelszóból — GPU és publikus szólista nélkül. Ez az alsó korlát, nem a felső; a felső korlátot a 4. szakasz állapítja meg. Nyers hitelesítőadat-leltár
Nyílt szöveges jelszó a dumpban9 0479 032 jelszótár + 15 infrastruktúra
NTLM hash sorok (NTDS.DIT)16 20216 200 egyedi fiók
— felhasználói és szolgáltatásfiók10 073de csak 8 777 különböző hash
— számítógépfiók6 129gépi generálású, nincs veszélyben
Kerberos-kulcs sorok40 467aes256 / aes128 / des-cbc-md5
Üres jelszavú fiók13NT hash 31d6cfe0…
Még LM hasht is tároló fiók45másodperc alatti visszafejtés
Egy fontos részlet: 4 664 jelszótárban szereplő felhasználónév az NTDS dumpban is szerepel, de ezek közül már csak 503 hash egyezik a jelszótárban tárolt jelszóval. A rotáció tehát _működik_ — az átfedő fiókok kb. 89 %-a jelszót váltott a jelszótár-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 jelszótárexport az első napon ugyanezt a populációt kompromittálja újra. ## A számok mögötti szokások [↑ tartalom]() #### 2 · Hogyan oszlik meg a 9 032 vault-jelszó | Kategória | Db | Arány | | --- | --- | --- | | Gépi generálású, 8 karakter Xx#xxxxx | 5 076 | 56,2 % | | Gépi generálású, 10 karakter Xx#xxxxxxx | 2 641 | 29,2 % | | Egyetlen közös szolgáltatásjelszó MvhX\*\*\*\*\*\*\*m123 | 819 | 9,1 % | | Felhasználó által választott, olvasható | 468 | 5,2 % | | Felhasználó által választott, ad hoc random | 26 | 0,3 % | | Üres mező | 2 | — | A jelszótár mindössze **5,5 %-át** választotta valóban ember. Ebben a 494 jelszóban lakik az összes rossz szokás — és ez az a alcsoport, amely elsőként törik meg. #### 3 · A 468 ember által választott jelszó profilja | Tulajdonság | Db | | --- | --- | | Szó + számok (+ jel) alak | 205 | | Számjegyre végződik | 326 | | Négyjegyű évszámot tartalmaz | 157 | | Egyáltalán nincs benne speciális karakter | 193 | | Pontosan 8 karakter (a szabályzat minimuma) | 47 | | Mind a négy karakterosztályt használja | 298 | | Magyar ékezetet tartalmaz | 33 | Medián hossz 11, átlag 11,9, legrövidebb 8, leghosszabb 22. A komplexitási szabályzat _teljesül_, miközben szinte semmilyen entrópiát nem ad: ezek 44 %-a egyetlen kiszámítható sablonba omlik össze. #### 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. Reset- és alapértelmezett sablonok — a tartomány legtöbbször újrahasznosított jelszavai `A1B2c3d4_×389_``ABcd1234__×107_``A1B2c3d4__×79_``111111_×61_``abcd1234_×59_``Start12345678_×32_``ABcd_1234_×32_``ABcd1234_×23_``Start12345678._×21_``123456_×20_``ABcd1234?_×14_``Abcd1234_×9_``abcd12345_×7_``Mvh12345_×7_``Alma01_×6_``A1B2c3d4?_×6_``QWer_1234_×5_``Abcd-123_×5_``asdfgh_×5_``Jelszo.01_×4_``qwertz_×3_``Alma,123_×3_` Maga a „jelszó" vagy „titok" szó `Jelszó123``Jelszo002002``IdmJelszo11.``HMVHjelszo2``Danijelszo11@``Titok2017.``Password-1``Ezazenjelszavam_013` Kedvencek, állatok, mesefigurák — 468-ból 77 `Nyuszi1?``Macsek66!``Malacka98*``Micimacko&06``Mikkamakka06``Pumukli.30``Felixnyuszi.12``Bodzakutya12345``Norcamacska1999``Oposszum234``pingviN1967``Galagonya33``Kokorcsin.01``LunaLovegood95``Magneto95.``Spongya12345``Csiga?4321``Medve?54``Pele4Mokus_``AgroMokus0808.``Ricsikutya1997…``Accipiter1992``Saxicola_rubicola_2` Ételek és italok `+3MákosTészta!``Spagetti78``Krumplieshus16``MogyiSzotyi0224``Barackospite2``Gofri618Gofri618``Mákos202210``Rebarbara@02``Coca1Cola``Cumpi11!!!``Almafa2012` Helynevek — 468-ból 27 `Tatabánya2800!_város + postakód_``Kaposvar1983*/``Szeged2023``Miskolc73``2100Gödöllő_postakód + város_``Isaszeg2020!``Kulsovat_1349.``Podmaniczkyutca1975_utcanév_``NorvegiaBergen2003``Manchester1998``Rovinj1991!``Damaszkusz.288452``Oktogon21!``Bekesmegye1987_megye_``Szlovenia18` Hónapok, évszakok, dátumok — 468-ból 21 `Szeptember2021``November01``Oktober,77``December2021!``Januar-2020``Január02``Februarban02*``2022Augusztus.``1991Szeptember…``Tavasztündér:)9``ÉTavasz_8``Szerda0323/` Márkák, csapatok, popkultúra `Chelseafootballclub95``BrigiSlipknot10``RockyBalboa-0017``Tourdefrance1``Showderklub2020!``Jobaratok911_tv-sorozat_``Lucifer96``Windows.8888``Opelastra1.600``Hondacb6502``Sencor.1977``Datalogic.2020``Tiger_1981``Anthology13``Cappy2005.` A munkáltató saját neve és rendszerei — 468-ból 16 `Államkincstár69``Agrártámogatások2022``Idmrendszer7600``Dr§Kincstarnok01``Mák@munka02_MÁK + „munka"_``Mvhpgy01!``HmvH_MvH202209``MvhX*******m123``Menedzsment88``Kincsem2022``Mak.hu11``2345Idm1` Név plusz születési dátum — a legnagyobb csoport, 468-ból 225 `Dani1993…``Vargak-1981…``B…Dita1966…``Csutkasor1975…``Ferenc.L…95…``Marcell2017…``Ági1990…``Évike_1995``Bettike1982``B…katka2005``R…Rebeka18``Kriszta2019.``Andi.1977``Zsombor…``LucaKata2018…``Viktoria1983…` Kifejezések és érzelmek — köztük a törést túlélő néhány jelszó többsége `Ezazenjelszavam_013_„ez az én jelszavam"_``Nemtudom2+``00Gondoltam1T``Dolgozz02_``liciDOLGOZIK21?1``SZEretleksasad123``Változás2023``Bizalom_1985``Optimizmus1998``T@rtsKiAdrik@7!!``Nándimese1``F***off1986@``Bobi-Kacsa-Bruni12` A jelszó megegyezik a felhasználónévvel, vagy az plusz egy `xeloperator``weblogic``K@l…@i1_felhasználói fiók_``K@l…@i2_ugyanaz _ADMIN fiókja_``Vargak-1981…_a felhasználónevét ismétli_` 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. ## Mit szerez meg valójában egy magányos támadó egy néhány GPU-ból álló gépen [↑ tartalom]() Itt nem egy adatközponttal felszerelt APT-csoportról van szó. A bizonyítékok egyetlen operátorra utalnak, egy VirtualBoxban futó Kali VM-mel — a reális kérdés tehát az, hogy _ő_ mit szerez meg. A válasz kényelmetlen, egyetlen szerkezeti ok miatt: **az NTLM nem sózott és nem iterált.** Minden jelszójelöltet egyszer kell hashelni, és az eredmény egyszerre hasonlítható mind a 16 200 hashhez — tízezer fiók törése pontosan annyiba kerül, mint egyetlené. Egy RTX 4090 kb. 252 GH/s-t tart NTLM-en; négy darab, vagyis egy otthon is megvehető és üzemeltethető rig, kb. 1 TH/s-t. Az alábbi számok mind 1 TH/s-sel készültek. #### 4 · A 9 030 vault-jelszó visszafejtési ideje ≈1 TH/s NTLM mellett (4 × RTX 4090) 0,3 s **Maszkos támadás** a 8 karakteres generátorsablonra: ?u?l?d?l?l?l?l?l — 3,2 × 10¹¹ jelölt 5 07656,2 % össz. ≈1 s **Szólista + szabályok** — 10 M-os magyar/angol/névlista × 52 e szabály, 5,2 × 10¹¹ jelölt +1 19169,4 % össz. 3,6 perc **Maszkos támadás** a 10 karakteres generátorsablonra: ?u?l?d?l?l?l?l?l?l?l — 2,2 × 10¹⁴ jelölt +2 64198,6 % össz. 1,8 óra **Teljes 8 karakteres brute force** — a 95 nyomtatható ASCII-karakter teljes kulcstere, 6,6 × 10¹⁵. Minden legfeljebb 8 karakteres, nyomtatható ASCII-jelszót lefed; a Unicode-karakterekhez, például a magyar ékezetes betűkhöz külön maszk vagy szólista kell +4799,1 % össz. 7,3 nap **Teljes 9 karakteres, nyomtatható ASCII brute force** — 6,3 × 10¹⁷. Még jóval egy operátor türelmi határán belül +5799,8 % össz. 1,9 év **Ami még áll** — teljes 10 karakteres kulcstér (6,0 × 10¹⁹) vagy célzott hibrid támadás kell hozzá 180,2 % marad meg **A jelszótár 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 jelszótárból származó 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 már célzott maszkkal, minimális ráfordítással feltörheti. 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 | Támadási lépés | Eltelt idő | Fiók | Alap | | --- | --- | --- | --- | | Már nyílt szövegben, hash-egyezéssel igazolva | 0 | 503 | mért | | Saját 1,3 M-os lista, csak CPU-val | percek | 1 104 (11,0 %) | mért | | Teljes nyomtatható ASCII-kulcstér ≤ 8 karakterig | 1,8 óra | ≈ 5 700 (57 %) | vault-hosszprofil; csak ASCII-modell | | Két generátormaszk + szólista és 52 e szabály | < 5 perc | ≈ 8 600 (85 %) | becsült | | A fentiek együtt, plusz teljes nyomtatható ASCII-kulcstér ≤ 9 karakterig | ≈ 8 nap | ≈ 9 060 (90 %) | becsült | | Maradék — célzott vagy hibrid munkát igényel | hónapok + | ≈ 1 010 (10 %) | becsült | 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. Következtetés — jelszóbiztonság **Ennek a környezetnek a jelszóbiztonsága nem a felhasználónál bukott meg, hanem a szabályzat szintjén.** A felhasználók pontosan úgy viselkedtek, ahogyan a szabályok terelték őket. Minimum 8 karakter, négy karakterosztály, kényszerített rotáció — ez mérhetően a Szó + születési év + ! alakot termeli: 468 emberi jelszóból 205 egyetlen sablonban, 326 számjegyre végződik, 157-ben évszám, medián hossz 11. Minden formai összetettségi követelmény teljesült, de ez még egyórányi védelmet sem nyújtott a jelszótöréssel szemben. **A rotáció működött, és mégsem változtatott semmin.** Az átfedő fiókok 89 %-a jelszót cserélt a két pillanatkép között, a környezet mégis teljesen kitett maradt — mert az új jelszavak mögötti generátorsablon azonos volt a régivel. Egy kiszámítható sablonon belül cserélni a titkot nem rotáció, hanem újrahúzás ugyanabból a 3,2 × 10¹¹-es készletből. **A katasztrófát nem a gyengeség, hanem a koncentráció okozta.** Három jelszó őrizte a teljes middleware-réteget. Egyetlen jelszó — az MvhX\*\*\*\*\*\*\*m123 — őrizte azt az identitáskezelőt, amely a másik 9 032-t nyílt szövegben tartotta. Egyetlen jelszó-visszaállítási sablon, az A1B2c3d4, 389 tartományi fióknál volt használatban. Az operátornak nem kellett jónak lennie a jelszótörésben: pontosan egy titokra volt szüksége egy nagyon rövid listáról, és az architektúra mindegyikhez több utat is felkínált. #### 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. ## A krbtgt kulcs és a Golden Ticket — miért él túl ez a betörés minden jelszócserét [↑ tartalom]() A [07\. lépésbeli DCSync]() nem csupán a felhasználói jelszóhasheket másolta ki. Egy tartomány teljes NTDS.DIT\-replikációja átadhatja az adott tartomány krbtgt fiókjának kulcsát is — azt a titkot, amellyel a tartomány Kerberos Key Distribution Centerei aláírják a jegyeket —, és ez a kulcs a **Golden Ticket** fő hozzávalója. Tehát igen: minden olyan tartományban, amelynek krbtgt kulcsa bekerült a replikált adatokba, az operátornak megvolt minden a jegyhamisításhoz. #### Mit ad a támadó kezébe a krbtgt kulcs - **Saját kezűleg gyártott Ticket-Granting Ticket a kompromittált tartományban.** Az adott tartomány krbtgt kulcsával az operátor tetszőleges, az adott tartományban elfogadott identitást, SID-et és csoporttagságot hordozó TGT-t hamisíthat jelszótörés nélkül. A tartomány- vagy erdőhatáron átnyúló hozzáférés továbbra is a trust konfigurációjától és a SID filtering beállításától függ. ATT&CK [T1558.001](). - **Perzisztencia, amit a kézenfekvő javítás nem érint.** A kompromittált felhasználói jelszavak visszaállítása — még minden Domain Admin jelszaváé is — semmit sem tesz egy Golden Tickettel, mert azt a krbtgt írja alá, nem a megszemélyesített fiók. Az ellopott kulcs érvénytelenítéséhez az adott tartomány krbtgt jelszavát _kétszer_ kell rotálni, a két jelszócsere között legalább a konfigurált maximális Kerberos-jegyélettartamot kivárva — ez az alapértelmezett szabályzat mellett 10 óra. - **Kompromittált tartományonként egy kulcs — nem erdőnként.** Az Active Directory minden tartományban külön krbtgt fiókot tart fenn. Ezért a bizonyítékok alapján pontosan meg kell állapítani, mely tartományok címtáradatai replikálódtak: minden megszerzett krbtgt kulcs a saját tartományában teszi lehetővé a jegyhamisítást, a trust konfigurációja pedig meghatározza, meddig ér tovább ez a hozzáférés. Pontosan ezért szól a [jelszóbiztonsági szakasz]() hitelesítőadat-tanulsága úgy, hogy **„az egész készletet tekintse elveszettnek”.** Ha az NTDS-dump és a krbtgt kulcsok egyszer kint vannak, semmilyen szelektív felhasználóijelszó-visszaállítás nem állítja helyre a címtárba vetett bizalmat — minden kompromittált tartományban **kétszeres krbtgt\-rotáció** kell, a két jelszócsere között előírt jegyélettartamnyi várakozással. Bármely tartomány, amelynek ellopott kulcsa érvényes marad, továbbra is visszautat biztosít. #### 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. ## A lánc megszakítása — mi állította volna meg az egyes lépéseket [↑ tartalom]() A fenti tizenkét lépés mindegyikén ott van a sárga Yellow Cube sáv a rövid válasszal. Ez a szakasz a hosszú válasz: lépésenként, mi **akadályozta volna meg**, mi **tette volna láthatóvá** menet közben, mi **szakította volna meg** végrehajtás közben, és mely konfigurációs gyengeségeket jelezte volna a biztonsági konfigurációkezelésünk jóval azelőtt, hogy bármi elkezdődött volna. Megelőzés — a lépés nem történhet meg Észlelés — láthatóvá válik Megszakítás — végrehajtás közben megáll Megerősítés — a félrekonfigurálás, amit időben jelzünk #### 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. ##### 01 · WebLogic RCE kezdeti hozzáféréssel _CVE-2017-10271 · kilenc éve javítatlan_ Egy internet felé nyitott ESB vhost 2017-es deszerializációs hibával, kihasználva egy Python-alapú reverse shell indítására, közvetlen IP-címre. Megelőzés Találja meg az internet felé nyitott kiszolgálót és a middleware CVE-t a támadó előtt — külső és hitelesített sebezhetőség-vizsgálat, valamint folyamatos külső támadásifelület-felmérés. WithSecure Elements, Group-IB ASM. Az NGFW behatolásgátlása **blokkolhatja** a deszerializációs payloadot — de ez egy 2017-es CVE aláírás-lefedettségén és a vhost TLS-átláthatóságán múlik: Stormshield. Észlelés Egy oracle alatt futó Java-folyamat, amely python\-t indít és kimenő socketet nyit, tankönyvi végponti észlelés: Cynet, WithSecure. Maga a reverse shell munkamenet a hálózaton: Stellar Cyber. A riasztást 22:14-kor is értékelő szakértői csapat: Yellow Cube 24×7 SOC. Megszakítás Automatikus gépizolálás és folyamatleállítás: Cynet, WithSecure. Alapból tiltó kimenő szabály a DMZ-szegmensben, hogy a shellnek ne legyen hova telefonálnia: Stormshield. Megerősítés A kilencéves patch-rés nem ismeretlen tényező — hanem egy el nem olvasott megállapítás. A folyamatos sebezhetőség- és biztonsági konfigurációkezelés dátummal ellátott munkalappá alakítja: a Cynet ESPM és a WithSecure Elements jelzi a javítatlan middleware-t, az internet felé nyitott kitettséget és a kiszolgáló hiányos biztonsági konfigurációját — és addig jelzi, amíg le nem zárják. A javítás telepítése a platformcsapat vagy az MSSP-partner dolga; az, hogy tudja: kilenc éve késik, és hogy ezt minden nap a szemébe mondja valaki, a miénk. Ahol a patch-ciklus valóban nem tud mozdulni, ott a Stormshield IPS és a DMZ-szegmentáció a kompenzáló kontroll, amit köré tervezünk. ##### 02 · MS17-010 a belépő alhálózaton _Windows Server 2003 · Sliver + SOCKS5_ EternalBlue egy olyan legacy gép ellen, amelyet a támadó maga nevezett használhatatlannak, és kizárólag perzisztenciáért tartott meg, tetején SOCKS5 pivottal. Megelőzés Kelet–nyugati szegmentáció, hogy az SMB soha ne érje el ezt a gépet onnan, ahol érték van: Stormshield. A biztonsági konfigurációkezelés jelzi az életciklus végi operációs rendszert és az engedélyezett SMBv1 dialektust — megállapításként, jóval azelőtt, hogy bárki kihasználná: Cynet ESPM, WithSecure Elements. És érdemes kimondani, mert szinte mindig félreértik: az **MS17-010 megjelent Server 2003-ra** is, soron kívüli javításként 2017 májusában — a „nem támogatott, tehát nem javítható” itt tényszerűen téves. Észlelés **Itt a portfólió olyat tud, amit szinte senki más: a Cynet ma is támogatja a Windows Server 2003-at.** Ez tudatos gyártói döntés, és az ilyen környezetekben rendkívül sokat ér — a legacy gépek pontosan azok, ahonnan az operátorok indulnak, épp azért, mert mindenki más ügynöke Server 2012-nél megáll. Egy modern, SOC által támogatott EDR egy 2003-as gépen a támadó kedvenc vakfoltját figyelt terepre változtatja: az EternalBlue kihasználása, a Sliver implant és a SOCKS5 pivot mind láthatóvá válik magán a hoszton. Emellett egy hálózati szenzor függetlenül is látja mindkét felét — az SMBv1 exploit-kísérletet, majd a beacon periodicitását és a tunnel alakját: Stellar Cyber, Group-IB. A csali gépek és megosztások pedig elkapják azt, aki nem tudja megkülönböztetni őket az igaziaktól: Cynet deception. (A Cynet publikált támogatási mátrixa a Windows Server 2003-at Service Pack 2-től listázza, jelezve, hogy egyes védelmi képességek rajta részlegesen korlátozottak — az észlelés és a reagálás, ami egy ilyen gépen számít, jelen van: [help.cynet.com/en/articles/47-supported-operating-systems]().) Megszakítás Gépizolálás magán a 2003-as gépen — ami csak azért lehetséges, mert van rajta ügynök: Cynet. A forrásgép vagy a teljes szegmens karanténba helyezése a tűzfalon: Stormshield. SOC-vezérelt elszigetelés: Yellow Cube 24×7 SOC, Group-IB IR. Megerősítés A Server 2003-on az SMBv1 nem kapcsolható ki a fájlmegosztás megtartása mellett — ez az egyetlen támogatott SMB-protokollváltozat —, így ez a gép a kivonásáig maradék kockázatot fog hordozni. A biztonsági konfigurációkezelés épp azt adja meg, ami a kivonáshoz kell: a leltárt, a kockázati pontszámot és azt a bizonyítékot, amivel a migráció megfinanszírozható. A különbség az időzítésben van. Egy felügyelet nélküli legacy gép helyett, amelyet a támadó talál meg, egy felügyelt, szegmentált és ügynökkel védett gépet kap, amelyhez kivonási terv is tartozik. A védelem a kivonásig fennmarad. ##### 03 · Elfeledett JDWP debug port _tiszta RCE oracle\-ként_ Egy Java Debug Wire Protocol port éles WebLogic gépen hallgatózva — második, az exploitnál is tisztább bejárat. Megelőzés Bejövő portszűkítés, hogy a debug transport akkor se legyen elérhető, ha valaki bekapcsolva hagyja: Stormshield. Külső és belső portfeltárás, hogy előbb jelenjen meg egy leltárban, mint egy behatolásban: Group-IB ASM, WithSecure. Észlelés A JDWP-Handshake jellegzetes a hálózaton, és jellegzetes az is, amit az oracle fiók ezután tesz a gépen: Stellar Cyber, Cynet, WithSecure. Megszakítás Gépizolálás: Cynet, WithSecure. Kimenő tiltás, mint a 01. lépésben: Stormshield. Megerősítés A JDWP senkit sem hitelesít — ez a specifikáció, nem hiba —, tehát nincs mire várni javítás gyanánt, és épp ezért az a kontroll, ami számít, hogy _félrekonfigurálásként_ elkapjuk. Egy elérhető hibakeresési szolgáltatás pontosan az a megállapítás-típus, amiért a biztonsági konfigurációkezelés létezik: a Cynet ESPM és a WithSecure Elements a hoszton jelzi, a Group-IB ASM kívülről jelzi, és mindkettő addig jelzi, amíg le nem zárják. A stratégiai tervezési audit alapján a kiadás előtti ellenőrzésbe is be kell építeni ezt a vizsgálatot. ##### 04 · A szegmentációs falnál _a védelem, ami működött_ Kimenő forgalom ICMP-re szorítva, SELinux az útban, a szomszédos alhálózatok elzárva. A támadó maga írta le: „nincs kimenő, csak pingek és alapvető parancsok." **Ez a teljes lánc legerősebb megállapítása** — a kontrollok elvégezték a munkájukat. Csak nem olvasta senki a kimenetüket. Megelőzés Már működik. Tartsa meg az alapból tiltó politikát, és a tiltások _naplózását_ tegye kötelezővé, ne opcionálissá: Stormshield. Észlelés Központosítsa a tűzfal- és SELinux-tiltási eseményeket, és a mintázatra riasszon, ne az egyedi eseményre — ismételt blokkolt kimenő próbálkozás egy gépről, a szomszédos alhálózatok sorozatos felderítése. Ehhez harmadik felektől származó naplóforrások széles támogatása kell — pontosan erre készült a Stellar Cyber: a tűzfalak, kiszolgálók és hálózati eszközök telemetriája egy helyen, a végponti adatokkal együtt. Megszakítás Ember a riasztás mögött, hajnali kettőkor, minden éjjel: Yellow Cube 24×7 SOC, WithSecure MDR, Group-IB MXDR. Folyamatos bizonyíték arra, hogy a riasztás valóban elsül, még mielőtt szükség lenne rá: Cymulate. És pontosan ennek a hibamódnak a begyakorlása — a kontroll elsült, senki nem reagált: CYBER RANGES és a Yellow Cube HackLab. ##### 05 · Oracle Identity Self-Service _több ezer fiók · visszafejthető jelszavak_ Az identitásportál a 14000-es porton: több ezer állami fiók, módosíthatóan, olyan jelszótárolással, amelyből nyílt szövegben visszaolvasható. Megelőzés Egy internet felé nyitott ESB-szegmensből semmi sem érhetné el a :14000\-et: Stormshield. Többfaktoros hitelesítés a portál előtt, és biztonságos jelszótárban kezelt, ellenőrzött módon kiadott rendszergazdai hitelesítő adatok: Imprivata — az integráció hatókörét validálni kell, nem feltételezni. Észlelés Csali identitások az identitástárban, amelyek használata definíció szerint rosszindulatú, tehát nem kell hozzá küszöbhangolás: Cynet. Rendhagyó privilegizált munkamenet az adminisztrációs úton: Varonis, Stellar Cyber. Megerősítés **Ez az egész ügy legnagyobb hatású megállapítása.** A visszafejthető, nyílt szövegben visszanyerhető jelszótárolás konfigurációs döntés — és ez az oka, hogy egyetlen export 9 032 identitást adott át, nulla törési munkával (lásd a [jelszóbiztonsági szakaszt]()). A biztonsági konfigurációkezelés a gyenge identitástár- és önkiszolgáló-konfigurációt állandó megállapításként hozza felszínre, nem meglepetésként: Cynet ESPM, WithSecure Elements. A Varonis feltérképezi, ki és milyen joggal érheti el a tárat. Magát a döntést pedig — kapcsolja ki a visszafejthető titkosítást, szüntesse meg az önkiszolgáló visszanyerést, szegmentálja a portált — egy stratégiai tervezési audit készíti elő: bizonyítékokkal alátámasztott feladatokat határoz meg, és követi a végrehajtásukat. Ez az a megállapítás, amiért az az audit létezik. ##### 06 · Szolgáltatásfiók és erdőbizalom _jelszó a shell historyban_ Egy teljes AD-jogosultságú szolgáltatásfiók egy shell history fájlban, és egy kétirányú FOREST\_TRANSITIVE bizalmi kapcsolat az MVH-tól az allamkincstar.gov.hu felé. Megelőzés Egy széfben tárolt, rotált, igény szerint kiadott privilegizált jelszó soha nem létezik szkriptben vagy history fájlban, hogy megtalálják: Imprivata PAM. Adathalászat-ellenálló többfaktoros hitelesítés minden útvonalon, ahol az a fiók használható: Imprivata, illetve Stormshield a VPN- és tűzfaladminisztrációhoz. Észlelés Egy szolgáltatásfiók interaktívan lép be, kereskedelmi hosting IP-ről, erdőhatáron át — három anomália egyetlen eseményben: a Varonis a legerősebb AD-natív választás itt, Cynet és Stellar Cyber támogatásával. Megszakítás Fiók letiltása és jelszócsere, forrás blokkolása, gép izolálása: Cynet, WithSecure, Stellar Cyber. Megerősítés Ez a bizalmi kapcsolat az egyetlen ok, amiért a behatolás egyáltalán elérte a Kincstárat — épp ezért érdemli meg, hogy látható legyen, ne feltételezett. A Varonis feltérképezi az Active Directory jogosultsági viszonyokat és az erdők közötti kitettséget, ami a „van egy bizalmi kapcsolatunk” állításból pontozott listát csinál arról, milyen utakat nyit meg valójában; a biztonsági konfigurációkezelés emellett jelzi magát a bizalmi konfigurációt. A szelektív hitelesítés, a SID-szűrés vagy a karantén alkalmazása ezután az MSSP-partnerrel szállított tervezési változtatás — az azt feltáró audit által behatárolva, nem incidens közben improvizálva. ##### 07 · BloodHound és DCSync erdőkön át _Az NTDS.DIT adatai kinyerve_ Bizalmi kapcsolatok gráfba szedve, az NTDS-titkok négy erdőn át kireplikálva, a Tier-0-ig vezető elérhető útvonal feltérképezve. Észlelés A DRSUAPI-replikáció, amelyet nem tartományvezérlő kér, az Active Directory biztonság egyik legnagyobb pontosságú észlelése: Varonis, Cynet, WithSecure, Stellar Cyber. Két feltételen múlik, hogy itt működik-e: gyűjtők **minden** erdő tartományvezérlőin — beleértve a MAK gyermekerdőt és a nyugdíjbiztosítási erdőket —, valamint engedélyezőlista a legitim replikációs partnerekre és a directory-sync eszközökre. Egy ilyen alakú környezetben a valós hibamód nem a téves riasztás, hanem egy erdő, amelyben senki nem állította be a szükséges megfigyelést. A csalifiókok (honeytoken) a másik oldalról zárják a rést: ha egy csali jelszó megjelenik egy ellopott NTDS-dumpban, annak bármely későbbi használata egyértelmű. Cynet. Megszakítás Őszintén: végrehajtás közben nem megszakítható. Az NTDS kinyerése másodpercek alatt lefut. Ami valós: a forrásgép gyors elszigetelése és soron kívüli, kétszeres krbtgt\-rotáció minden kompromittált tartományban, a két jelszócsere között legalább a konfigurált maximális Kerberos-jegyélettartamot kivárva: Yellow Cube 24×7 SOC, Group-IB IR. És annak igazolása, hogy az észlelés létezik — még az előtt az éjszaka előtt, amikor számít: Cymulate. Megerősítés A Varonis a túlzott címtárjogokat — köztük a nem tartományvezérlőhöz tartozó fiókoknál lévő DS-Replication-Get-Changes jogot — konfigurációs kockázatként hozza felszínre, még mielőtt bárki visszaélne velük; ez messze a legköltséghatékonyabb pillanat a megvonásukra. A tierezés érvényesítése, hogy DCSync-képes identitás soha ne legyen elérhető egy webes rétegben nyitott shellből, a tervezési feladat, amelyet a partnerrel közösen végzünk el. És egy szakmai pont, ami valódi pénzt takarít meg: a BloodHound-féle nagy tételű LDAP-felderítés valóban nehezen választható el a leltár- és IAM-eszközök működésétől, ezért a súlyt a DCSync-jelzésre és a csalifiókra tesszük, nem ennek hajszolására. Annak tudása, melyik jelzésben lehet bízni, a különbség egy SOC és egy riasztási várólista között. ##### 08 · OIM-adatbázis és tárolók felderítése _36 TB megosztás bejárva_ Az identitáskezelő sémája adatbázis-kliensben böngészve, a vállalati fájlvagyon bejárva: 15,9 TB, 15,9 TB, 5 TB, plusz árnyékkötetek. Megelőzés Legkisebb jogosultság a megosztásokon, az elavult és nyitott hozzáférések felszámolása, és érzékenyadat-feltárás, hogy a egy incidens várható hatóköre előbb legyen ismert, mint hogy más mérje meg. A Varonis ennek a láncnak bármely lépéséhez a legjobban illő portfólióelem, Teramind támogatással a végponti oldalon. Észlelés Nagy tételű megosztás-felderítés, pásztázó mintázatok, árnyékkötet-hozzáférés, és rendhagyó hozzáférés olyan identitástól, amelynek semmi keresnivalója ott: Varonis, Teramind, Stellar Cyber. Csalifájlok a valódi megosztásokban: Cynet. Megszakítás Automatikus jogosultság-visszavonás, fióktiltás vagy megosztás-karantén, amelyet a rendhagyó hozzáférés riasztása indít, nem pedig egy ticket: Varonis, Cynet. Megerősítés Ez a lépés azért működött, mert senki nem tudta, mi van azokban a megosztásokban, ki olvashatja őket, és hogy valaki épp most járta végig mindet — ez megfelelő eszközökkel kezelhető hiányosság, és pontosan ezért van a Varonis. Az adatbázis oldalán a biztonsági konfigurációkezelés jelzi a hoszt konfigurációját és kitettségét, az Oracle saját auditja pedig — amelynek rögzítenie kellett volna a sémahozzáférést, és láthatóan nem tette — olyan konfiguráció, amit az auditban ellenőrizünk, nem feltételezünk. A bekapcsolása semmibe nem kerül, és zajossá tette volna a 08. lépést. ##### 09 · Szembeszállás a Symanteckel _ügynök kézzel leállítva, majd az LSASS memóriája kinyerve_ Az egész behatolás fordulópontja — és az a lépés, ahol az üzleti érv a legerősebb, épp azért, mert **a meglévő termék működött**. A Symantec blokkolta a kimenő beaconokat, és blokkolta a named pipe-on át az LSASS elérését. Egészen addig működött, amíg valaki le nem állította: RDP a biztonsági eszközt futtató gépre, két szolgáltatás leállítása, LSASS dump. A támadó saját jegyzete így szól: „lsass works :)". Megelőzés Semmilyen interaktív, helyi rendszergazdai RDP arra a gépre, amely a biztonsági eszközöket futtatja. Helyette közvetített, többfaktoros, just-in-time és rögzített munkamenet: Imprivata PAM a széfhez és a közvetítéshez, Teramind a privilegizált munkamenet rögzítéséhez. Észlelés Ennek a lépésnek a valódi kontrollja nem a blokkolás, hanem az **észrevétel**. Ügynök-életjel kiesése és biztonsági szolgáltatás leállítására utaló manipulációs esemény, korrelálva és percek alatt eszkalálva: Cynet, WithSecure, a naplóadatok feldolgozására Stellar Cyber, eszkalálva a Yellow Cube 24×7 SOC által. A Symantec aznap éjjel már blokkolta a támadási kísérleteket, de a jelzéseire senki nem reagált. Megszakítás Automatikus izolálás, amelyet a manipuláció vagy az életjel kiesése indít — így az ügynök leállítása _maga_ lesz az elszigetelés kiváltója: Cynet, WithSecure. Bizonyíték arra, hogy a manipuláció → riasztás → izolálás lánc végig működik: Cymulate. És pontosan fogalmazva, mert a különbség számít: a manipuláció elleni védelem megnöveli az ügynök leállításának költségét, és magas megbízhatóságú manipulációs eseményt bocsát ki — de nem teszi lehetetlenné az eltávolítást egy olyan támadónak, aki már helyi rendszergazda. Megerősítés **Ez a lépés jól mutatja, miért van szükség biztonsági konfigurációkezelésre.** Védelem nélkül hagyott LSASS, kikapcsolt Credential Guard, be nem állított RunAsPPL, még mindig szükséges interaktív adminisztráció egy biztonsági eszközt futtató gépen, engedélyezve hagyott legacy hitelesítés és túl engedékeny kliensházirend a menedzsmentkiszolgálón — ezek mindegyike _beállítás_, és mindegyikük pontosan az, amit a Cynet ESPM és a WithSecure Elements biztonsági konfigurációkezelése folyamatosan jelez. A döntő pedig, hogy **időben** jelzi: pontozott dokumentált kockázatként egy áttekintő felületen, hetekkel azelőtt, hogy egy operátor jelszavak kinyerésére használja ki őket — nem utólagos forenzikus következtetésként. A támadó ebben a lépésben nem győzött le egy kontrollt. Átment egy konfiguráción, amit senki nem ellenőrzött — az ellenőrzése pedig egy licenc és egy folyamat, és mi mindkettőt szállítjuk. ##### 10 · vCenter és a 229,1 TB _terv: helyben titkosítás ESXi-ről_ A vSphere SSO adminisztrátori jelszó megkerült, 116 VM és 229,1 TB datastore felmérve, és kimondott terv a környezet helyben történő titkosítására. Megelőzés Elszigetelt menedzsment-hálózat, amely kizárólag egy biztonságosan konfigurált ugrógépen át érhető el — ennél a lépésnél ez a legnagyobb értékű változtatás: Stormshield. A vSphere SSO rendszergazdai fióknál használjon biztonságos jelszótárat és többfaktoros hitelesítést, rendszeresen cserélje a hitelesítő adatokat, és váltsa le a szervezet nevére épülő hatkarakteres jelszómintát: Imprivata. Találja meg a jelszót tartalmazó fájlt a támadó előtt: Varonis, Teramind. Észlelés vCenter- és ESXi-syslog egy olyan platformra küldve, amelyet valaki figyel — SSH bekapcsolva egy hoston, új helyi fiók, nagy tételű VM-, snapshot- vagy datastore-műveletek. Ez szabványos, jól támogatott naplóforrás: Stellar Cyber. Megszakítás Menedzsment-VLAN izolálása a munkamenet elvágásához: Stormshield. SOC-elszigetelés és már meglévő incidenskezelési készenléti szerződés — nem az incidens közben megtárgyalva: Yellow Cube 24×7 SOC, Group-IB IR. Megerősítés Egy hipervizort a hozzáférési útvonalán védünk, nem egy benne futó külső ügynökkel — ez a VMware saját architektúrája, és épp ezért a fenti három kontroll a helyes válasz, nem kompromisszum: zárja el a menedzsment-réteget, tegye széfbe az oda elérő jelszavakat, és vegye át a telemetriát, amit már így is kibocsát. A biztonsági konfigurációkezelés jelzi a menedzsment-réteg kitettségét és az ide vezető jelszó-újrahasznosítást. A hatóköröket pontosan külön kell választani: a felhős észlelés és reagálás IaaS- és SaaS-környezetekre terjed ki. A helyben futó vSphere esetében ezért szegmentációra, privilegizált hozzáférés-kezelésre és naplóelemzésre építünk. Minden platformhoz a rá alkalmazható védelmi intézkedést kell választani. A helyben titkosított VM-ekből való visszaállást lentebb tárgyaljuk. ##### 11 · Bizonyítékcsomag a Google Drive-ra _70 MB · a támadó saját gépéről_ Tizenhárom képernyőkép, a kinyert hitelesítő adatok, a recon kimenet és egy videó — összesen kb. 70 MB — feltöltve egy személyes felhőfiókba, „Loic Matrier” néven. A bizonyítékok egyértelműen a **támadó saját virtuális gépére** mutatnak, nem kincstári végpontra — az adat már kint volt, mire böngészőbe került, így nincs olyan hálózaton belüli feltöltés, amit tűzfal, proxy vagy végponti ügynök elkaphatna. Ezt kimondani a lépés lényege: egy jelentés, amely ide védelmi terméket tenne, rossz dolgot adna el önnek. Észlelés Ebben a szakaszban a megfelelő eszköz a **hitelesítőadat-kitettség figyelése**, nem az egress-kontroll. A Group-IB Digital Risk Protection figyeli az alvilági piactereket, szivárogtató csatornákat és fórumokat, és riaszt abban a pillanatban, amint e dump hitelesítő adatai eladásra kerülnek — és kerülni fognak, gyorsan. **9 047 már nyílt szövegben van**, a fenti jelszóbiztonsági elemzés pedig további **≈7 960 felhasználói és szolgáltatásfiók jelszavának feltörését vetíti előre egy héten belül** egy néhány GPU-ból álló gépen: a gyenge hash-ek gyorsan törnek, és éppolyan gyorsan érnek piacra. Ez egy csendes, növekvő kitettséget dátumozott, cselekvésre kész megállapítássá alakít — ugyanabból a digitális kockázatvédelmi képességből és forrásból, amelyre ez a jelentés a ByteToBreach szereplőprofil kapcsán már támaszkodik. Megerősítés Mivel az exfiltráció egy soha nem kontrollálható gépről ment, a fogás nem a feltöltésnél van — hanem annak két oldalán. Előtte: a Varonis az adatokon és az Imprivata a jelszavakon dönti el, mennyit tud egy operátor egyáltalán előkészíteni (05. és 08. lépés). Utána: e dump minden hitelesítő adatát nyilvánosként kell kezelni — a 9 047 nyílt szövegűt azonnal, a törhető maradékot pedig a fenti elemzés napok–egy hét idővonalán — és ennek megfelelően rotálni, miközben a Group-IB DRP megmondja, melyikük bukkan fel eladásra, és mikor. A peremen történő feltöltés-blokkolás itt sosem volt a terv; az, hogy tudjuk mi szivárgott ki, és figyeljük hova kerül, igen. ##### 12 · Nyilvános közzététel _szivárogtató bejegyzés + felhős tükrök_ A bejegyzés élesben, a képernyőkép-csomaggal és három fogyasztói felhőszolgáltatáson tükrözve, azzal a kifejezett megjegyzéssel, hogy váltságdíjat nem kérnek. Észlelés Szivárogtató oldalak, underground fórumok és tükrök figyelése, hozzárendelt szereplő-attribúcióval: Group-IB Digital Risk Protection — a portfólió digitális kockázatvédelmi képessége, és ugyanaz a forrás, amelyre ez a jelentés a ByteToBreach szereplőprofil kapcsán már támaszkodik; ennél konkrétabb lefedettségi bizonyíték nem szokott lenni. Pontosan kell azonban keretezni: ez egy **tudomásszerzési idő** csökkentését szolgáló védelmi intézkedés. Az észlelés a közzététel _után_ érkezik, jellemzően órákon–napokon belül, és előzetes figyelmeztetés csak akkor van, ha a támadó előre elárulta a célpont kilétét — gyakori, de soha nem garantált. Megszakítás A tartalom eltávolításának lehetőségeit külön kell értékelni. A támadó saját szivárogtató oldalának eltávolítására a gyakorlatban kevés az esély. A lakossági felhőszolgáltatásokon tárolt másolatok és a 11. lépés Drive-mappája viszont igen, a szolgáltatók visszaélés-bejelentési csatornáin — és pontosan ez a kézzelfogható szolgáltatás: Group-IB, plusz egy incidenskezelési készenléti szerződés az összehangolt válaszhoz. Megerősítés Amikor már létezik a szivárogtató bejegyzés, nincs mit megelőzni, és ezt kimondani is a munka része — ilyenkor a feladat a NIS2 incidensbejelentés, a jogi tanácsadás és a kommunikáció, és ezt jóval azelőtt kell begyakorolni, hogy szükség lenne rá. Ami valóban kontrollálható, az a fenti két sor: milyen gyorsan tud róla, és milyen gyorsan kerülnek le a tükrök. A „nem eladó, váltságdíjat nem kérünk” megszünteti a tárgyalást, de a bejelentési határidőn nem változtat semmit. #### Lefedettség egy pillantásra | Lépés | Legyőzött kontrollrétegek | NIS2 | A portfólió válasza | | --- | --- | --- | --- | | 01 WebLogic RCE | Sebezhetőség-kezelés · Konfigurációbiztonság · NGFW · EDR · MDR | kötelező | Lefedve — észlelés, elszigetelés, és a patch-rés időben jelezve | | 02 EternalBlue | Konfigurációbiztonság · Szegmentáció · EDR · NDR · Deception | implicit | Lefedve — EDR-rel a Server 2003-on is | | 03 JDWP | NGFW · Konfigurációbiztonság · NDR | kötelező | Lefedve — a konfigurációkezelés jelzi a félrekonfigurálást | | 04 Figyelmen kívül hagyott tiltások | SIEM · MDR · BAS · Cyber range | kötelező | Lefedve — a lánc legjobb lehetősége | | 05 Visszafejthető identitástár | MFA · PAM · ITDR · Deception | kötelező | Lefedve — konfigurációs kockázat és audit-felelősség | | 06 Jelszó a historyban + bizalom | PAM · MFA · ITDR · Konfigurációbiztonság | kötelező | Lefedve — a bizalmi kitettség feltérképezve és figyelve | | 07 DCSync erdőkön át | ITDR · SIEM · BAS · Deception | kötelező | Lefedve — magas megbízhatóságú észlelés, jogok időben jelezve | | 08 36 TB megosztás bejárva | Adatkezelés · Konfigurációbiztonság · UEBA | felette | Lefedve — a Varonis birtokolja az adatréteget | | 09 Biztonsági ügynök leállítva | Konfigurációbiztonság · PAM · EDR · XDR · MDR · BAS | kötelező | Lefedve — manipulációs riasztás és 24×7 válasz | | 10 vCenter és 229,1 TB | Szegmentáció · PAM · SIEM · Backup | kötelező | A hozzáférési útvonalon lefedve — lásd a mentési megjegyzést | | 11 Feltöltés személyes felhőbe | Hitelesítőadat-kitettség figyelése · DRP · IR | implicit | A célpont peremén kívül — kitettségfigyelés, hitelesítőadat-rotáció és a tükrök leszedésének koordinálása | | 12 Nyilvános közzététel | Digital risk protection · IR | kötelező | Lefedve — tudomásszerzési idő és tükrök leszedése | 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. | Lépés | Konfigurációs vagy tervezési megállapítás | Felszínre hozza → lezárja | | --- | --- | --- | | 01 | Kilenc év fel nem telepített middleware-javítás egy internet felé nyitott hoszton | Cynet ESPM / WithSecure → partneri patch-ciklus | | 02 | Életciklus végi Server 2003 routolható szegmensen, engedélyezett SMBv1-tel | Konfigurációbiztonság-leltár → életciklus-terv (közben a Cynet fedi) | | 03 | Éles környezetben hallgatózó JDWP debug transport | Cynet ESPM / Group-IB ASM → release-kapu | | 05 | Visszafejthető, nyílt szövegben visszanyerhető jelszótárolás az identitáskezelőben | Konfigurációbiztonság + stratégiai tervezési audit → platformváltozás | | 06 | Kétirányú erdőbizalom szelektív hitelesítés és SID-szűrés nélkül | Varonis → AD-tervezési változtatás a partnerrel | | 07 | Replikációs jogok nem tartományvezérlő fiókoknál | Varonis konfigurációelemzés → jogosultság-tisztítás | | 08 | Az Oracle saját auditja nem rögzíti a sémahozzáférést | Konfigurációbiztonság + audit → natív audit bekapcsolása | | 09 | Védelem nélküli LSASS — kikapcsolt Credential Guard, beállítatlan RunAsPPL | Cynet ESPM / WithSecure → GPO-változtatás | | 09 | Túl engedékeny kliensházirend és legacy szolgáltatásfiók a menedzsmentkiszolgálón | Konfigurációbiztonság-megállapítás → SCCM-újratervezés a partnerrel | | 10 | Módosíthatatlan, offline, tesztelt VM-mentés | A saját mentési gyártója → lásd az alábbi megjegyzést | | 11 | 16 202 hitelesítő adat kitéve — ma nyílt szöveg, a gyenge hash-ek egy héten belül | Group-IB DRP piactér-figyelés → rotálás, mintha nyilvánosak lennének | | 12 | A közzététel itt már nem előzhető meg, de a bejelentésre előre fel lehet készülni | Begyakorolt NIS2-bejelentési folyamat | #### 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: | Tartott visszaállítási sebesség | 229,1 TB visszaállítási ideje | | --- | --- | | 500 MB/s (jellemző dedup appliance, egy szál) | ≈ 5,3 nap | | 1,5 GB/s (jól hangolt, párhuzamos szálak) | ≈ 42 óra | | 10 Gbps (ideális, vonali sebesség) | ≈ 2,1 nap | É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. Hol kezdje **Ez a behatolás nem azért járt sikerrel, mert nem volt védelem.** A kimenő szűrés tartott. A SELinux tartott. A Symantec blokkolta a beaconokat és blokkolta az LSASS-t. A támadó a saját képernyőképein írta le a saját frusztrációját. Mindegyik kontroll azt tette, amiért megvásárolták — a jelzéseikre azonban öt és fél napig senki nem reagált. **Az első lépés tehát nem termék, hanem szemléletváltás.** Állítson 24×7 észlelési és reagálási képességet a már meglévő kontrollok mögé, majd zárja be a mögötte lévő jelszó- és identitásarchitektúra-réseket. Cymulate, hogy folyamatosan bizonyítsa: a detekciók elsülnek — ne feltételezze; CYBER RANGES és a Yellow Cube HackLab, hogy pontosan azt a hibát gyakorolják be, amit ez a jelentés dokumentál — a kontroll elsült, senki nem reagált; és egy stratégiai tervezési audit a 27 rétegű Security Stack Matrix mentén, hogy a maradék réseket ön találja meg előbb, mint más. A bevezetést és a rendszerek biztonsági megerősítését a helyi MSSP-partnere végzi. A Yellow Cube biztosítja a következőket: a portfólió, a mögötte álló 24×7 SOC, az incidenskezelési készenléti szerződés arra az éjszakára, amikor számít, és a képzés és műszaki támogatás, amely mindhárom hatékony használatához szükséges. **Attribúciós árulkodó jel:** a BloodHound-gyűjtő gép **PDT (UTC−7)** időzónában jelentett időbélyegeket, miközben minden kompromittált rendszer CEST-ben futott — a támadó elemző munkaállomásának órája amerikai csendes-óceáni időzónára volt állítva. A kiszivárgott utólagos bemutató-videó két további nyomot ad: a támadó saját Kali VM-jének hosztneve **stephlabs**, és Sliver C2-implantjai a **84.206.46.11, 84.205.244.140, 85.209.80.29** címekre kommunikálnak — három egymással kapcsolatban nem álló kormányzati hálózat Magyarországon, Görögországban és Grúziában, egyikük (a magyar blokk) magára az MVH-ra regisztrálva; lásd a fenti C2-infrastruktúra panelt. 24 támadói képernyőképből (spear\[.\]cx DLS „The Magyar Conquest”), a támadó kiszivárgott utólagos bemutató-videójából kinyert 125 kulcskockából, a Group-IB ByteToBreach szereplőprofiljából (gyártói felderítés), a KELA Cyber nyilvános ByteToBreach szereplőprofiljából és fájl-metaadatokból rekonstruálva. Szereplő: ByteToBreach (más néven dodhlojka · dodhlo · kalabaz), először látva 2025. jún. 8. Célpont: Magyar Államkincstár az mvh erdők közötti bizalmi kapcsolaton át. Az időpontok az Europe/Budapest (CEST, UTC+2) zónára normalizálva; a 229,1 TB decimálisan értelmezve (2,291 × 10¹⁴ bájt) minden számításban. **Adatvédelem.** Ez a jelentés a nyilvános szivárogtatásból származó hitelesítő adatokat csak annyiban idézi, amennyit az egyes megállapítások megkívánnak. A személyes adatokat végig minimalizáltuk: felhasználóneveket egyáltalán nem közlünk, a családneveket kezdőbetűre rövidítettük, a születési dátumokat évre csonkítottuk vagy elhagytuk. Az éles jelszavak részlegesen maszkolva szerepelnek. A csonkítás nélküli bizonyítékhalmaz külön kezelés alatt marad, azt nem publikáljuk. Semmi nem szolgál egyetlen munkavállaló azonosítására sem. **Az információ forrása.** A behatolásra vonatkozó minden technikai megállapítás a támadó saját adatszivárogtató oldalán (DLS) közzétett anyagból származik — hxxps\[://\]spear\[.\]cx\[/\]Thread-Selling-HU-The-Magyar-Conquest, DLS-bejegyzés: **„The Magyar Conquest”** — az ott publikált operátori képernyőképekkel, kulcskockákkal és hitelesítő adatokat tartalmazó fájlokkal együtt. Egyetlen kivétel a szereplő azonosítása: az a fent hivatkozott Group-IB és KELA Cyber szereplőprofilokra épül, nem magára a szivárogtatásra. Az URL-t szándékosan nem kattintható formában közöljük; vállalati hálózatról vagy azonosítható böngészőből ne nyissa meg. Yellow Cube Cyberdefense Digitális forenzika és incidenskezelés · offenzív biztonság · XDR-valídáció Készítette: **Akos Bodis** · [akos.bodis@yellowcube.eu]() · +36 20 932 1240 [yellowcube.eu]() ## Forrásmegjelölés és hatókör Ez a Markdown-változat ugyanazokból a jóváhagyott tartalmi rekordokból készül, mint a kanonikus HTML-oldal. Hivatkozáskor a kanonikus URL-t használja.