A Magyar Államkincstár elleni betörés története első ránézésre „klasszikus Windows/AD-s incidensnek” tűnik, de valójában sokkal többről szól: arról, hogyan omlik össze egy teljes identitás- és jogosultsági architektúra úgy, hogy közben a legtöbb technikai kontroll formálisan „működik”. A támadó, a ByteToBreach néven ismert szereplő, egyetlen operátorként, a Vidékfejlesztési Hivatal (MVH) hálózatán át, erdők közötti (inter-forest) bizalmi kapcsolaton keresztül jutott be a Magyar Államkincstár környezetébe, és négy Active Directory erdőben szerzett tartományi rendszergazdai szintű jogokat. A virtualizációs réteg feletti kontrollt is megszerezte: 116 virtuális gép és 229,1 TB datastore fölött rendelkezett, miközben a védelmi eszközök jelentős része ténylegesen működött.
A történet egyik kulcspontja, hogy a támadó által közzétett 24 képernyőkép és egy videó alapján rekonstruálható a betörés idővonala, és összevethető azzal, mit jelentene fizikailag 229,1 TB adat mozgatása. A számok itt kíméletlenek: a teljes adatállomány kiexfiltrálásához a rendelkezésre álló időablakban tartósan nagyjából 7,5 Gbps sávszélességre lett volna szükség. Ez a gyakorlatban, egy ilyen környezetben, a meglévő szegmentáció és kimenő szűrés mellett reálisan nem kivitelezhető. A nyilvánosan kiszivárgott csomag nagyságrendileg 70 MB – 13 képernyőkép, egy CREDS.txt, egy RECON.txt és egy videó –, vagyis nem tömeges adatlopásról, hanem hitelesítő adatok és architekturális gyengeségek demonstratív feltárásáról beszélünk.
A valódi, tartós kár nem mennyiségi, hanem minőségi: 9 047 jelszó már most is nyílt szövegben elérhető, és a kiszivárgott NTDS.DIT és vault-adatok alapján további több ezer hash várhatóan napok–egy hét alatt törhető egy kisméretű GPU-rigen. Itt lép be a képbe az NTLM egyik alapvető problémája: a hashek nem sózottak és nem iteráltak, így egyetlen jelszójelölt hashelése után az eredmény egyszerre vethető össze az összes tárolt hash-sel. Tízezer fiók támadása gyakorlatilag ugyanannyiba kerül, mint egyetlené. Nyílt forrású jelszótörő eszközök (pl. Hashcat) és egy 4 × RTX 4090-es rig (összesen ~1 TH/s NTLM-en) ma már nem elérhetetlen beruházás egy magányos támadó számára sem.
A CREDS.txt (4,6 MB, 65 885 sor) elemzése három külön réteget mutat: egy kézzel összeválogatott infrastruktúra-credential blokkot, egy Oracle Identity Manager vault-exportot 9 032 fiókkal, és egy teljes NTDS.DIT dumpot 16 200 principal-lal, 40 467 Kerberos-kulccsal. A vault 9 047 jelszavából mindössze 5,5 % valódi, ember által választott jelszó; a többi generátor által előállított, sablonos érték. A 468 „emberi” jelszó profilja tankönyvi példája annak, hová vezet a „minimum 8 karakter, négy karakterosztály, rendszeres rotáció” típusú szabályzat: a medián hossz 11, az átlag 11,9, a jelszavak 44 %-a egyetlen sablonba (Szó + számok + speciális karakter) omlik össze, 326 számjegyre végződik, 157 négyjegyű évszámot tartalmaz, 47 pontosan 8 karakteres (a minimum), és 205 konkrétan „Szó + évszám + !” jellegű. A komplexitási pipák ki vannak pipálva, az entrópia viszont alacsony.
A jelszóhigiénia leglátványosabb kudarca a koncentráció: 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). Egyetlen OIM-admin jelszó (MvhX…m123, részben maszkolva) 819 vault-soron szerepel, és ezzel gyakorlatilag az egész identitáskezelő-réteget őrzi. Három jelszó védi a teljes middleware-környezetet, egyetlen reset-sablon több száz fiókot, és mindez egy olyan NTLM-alapú hash-architektúrán, ahol egy 1 TH/s-es rig néhány perc–nap alatt végigmegy a releváns kulcstéren.
Az NTDS.DIT dump 10 073 felhasználói és szolgáltatásfiókot tartalmaz; ezek közül 1 104 (11,0 %) néhány perc CPU-idő alatt esett el egy 1,3 milliós, saját szólistával, GPU nélkül. A vault hossz- és sablonprofilját a teljes tartományra vetítve konzervatív becsléssel is az jön ki, hogy nagyságrendileg 85 % a két generátormaszk + szólista + szabályok kombinációjával percek–órák alatt, ~90 % pedig egy munkahéten belül törhető egy 1 TH/s-es riggel. A maradék 10 % jellemzően hosszú, kevésbé sablonos jelszó (pl. 19–22 karakteres kifejezések, összetett szavak), amelyek ellen már célzottabb, kombinátoros vagy hibrid támadás kellene.
Az incidens egyik legfontosabb tanulsága, hogy a jelszóhigiénia itt nem a felhasználók szintjén bukott meg, hanem a szabályzat és az architektúra szintjén. A felhasználók pontosan úgy viselkedtek, ahogyan a szabályok terelték őket: rövid, de „komplex” jelszavakat választottak, rendszeresen rotáltak, és a helpdesk reset-sablonokat soha nem cserélték le. A rotáció működött – az átfedő vault/NTDS-fiókok 89 %-a jelszót váltott a két pillanatkép között –, de mivel a generátorsablon nem változott, a teljes készlet újra és újra ugyanabból a 3,2 × 10¹¹-es (8 karakteres sablon) kulcstérből húzott.
A támadó oldaláról nézve a kép meglepően „kicsi”: a videóból kinyert 125 kulcskocka alapján egy Linux Mint/Cinnamon asztalról futtatott VirtualBoxban lévő Kali VM (second_kali) látszik, kali@stephlabs hosztnévvel, Terminator terminálemulátorral, VS Code-dal, Firefoxszal, genmon panel-widgettel. A C2-keretrendszer a Sliver, mTLS-alapú implantokkal, root/oracle jogosultsággal futó Linux/amd64 gépeken, a payload /root/magyar.exe néven. A képernyőn látható eszközök – NetExec, Evil-WinRM, FreeRDP/xfreerdp, Nmap 7.94SVN, TigerVNC, Burp Suite Community Edition, vSphere Client – mind ismert, széles körben használt támadó- és adminisztrációs eszközök. A videón sem VPN-, sem Tor-kliens, sem jelszókezelő, sem személyes háttérkép nem látszik; a hosztnév- és C2-szivárgást leszámítva az OPSEC fegyelmezett.
A Sliver listener IP-k (84.206.46.11 – NISZ/MVH tartomány, Budapest; 84.205.244.140 – görög SYZEFXIS közigazgatási hálózat; 85.209.80.29 – grúz igazságszolgáltatási hálózat) elemzése azt mutatja, hogy a támadó előszeretettel használ kompromittált kormányzati infrastruktúrát redirectorként, nem pedig saját VPS-eket. Ezt erősíti meg egy másik áldozat, a grúz bírósági rendszer (teen.court.ge / hcoj.gov.ge) kiszivárgott képernyőképeinek elemzése is, ahol ugyanebben az AS209332-es tartományban használt pivot- és belépési pontok látszanak. A tényleges, bérelt VPS (194.102.105.193, AlexHost SRL, Moldova) ezzel szemben tipikus kereskedelmi hoszt, semmi „kormányzati” jelleggel. Mindez arra utal, hogy a kormányzati IP-k kompromittált, harmadik félhez tartozó gépek, nem pedig a támadó saját tulajdonú C2-szerverei.
A ByteToBreach személyéhez köthető legátfogóbb nyilvános attribúciót a KELA Cyber Intelligence Center adta: ők fenyegetés-felderítési értékelésükben nagy valószínűséggel egy algériai, oráni lakoshoz, Zakaria Mahdjoubhoz kötik a szereplőt. Az érvelésük több, egymástól független forrástípusra épül: kriptográfiai üzenetküldő-azonosítók (Session ID) újrahasznosítására, infostealer-naplókra (Raccoon, StealC) algériai magángépekről, böngésző-sütikre, Telegram-felhasználónevekre és telefonszámokra. Fontos hangsúlyozni, hogy ez fenyegetés-felderítési, nem jogi attribúció; nincs nyilvános információ vádemelésről vagy ítéletről, és a Magyar Államkincstár-incidensben vizsgált technikai bizonyítékok önmagukban nem bizonyítják az azonosítást. A KELA nyilvános blogbejegyzése (2025 november, frissítve 2026 júliusában) azonban részletesen bemutatja, hogyan kötik össze a ByteToBreach személyiséget korábbi, DarkForums-aktivitással és infostealerrel fertőzött, évekkel korábbi magángépes naplókkal.
A támadási lánc technikai szempontból több, jól ismert építőkockára épül: egy régi, internet felé nyitott WebLogic sebezhetőségre (CVE-2017-10271, deszerializációs RCE), egy legacy Windows Server 2003 gép EternalBlue (MS17-010) kihasználására, JDWP debug portokra, nyílt szöveges jelszót visszaadó identitáskezelőre (Oracle Identity Manager), kétirányú, szelektív hitelesítés nélküli erdőbizalomra, túl széles DCSync-jogokra, védtelen LSASS-ra, és egy olyan vCenter-környezetre, ahol a menedzsment-hálózat nincs megfelelően elszigetelve, a vSphere SSO admin jelszava pedig szervezetnév-alapú, rövid, sablonos érték. Ezek mind konfigurációs és tervezési döntések eredményei, nem „ismeretlen 0-day” típusú problémák.
A krbtgt kulcs ellopása különösen súlyos következményekkel jár: egy tartomány krbtgt fiókjának kulcsával a támadó tetszőleges Ticket-Granting Ticketet (TGT) hamisíthat (Golden Ticket), amelyet a tartomány Kerberos Key Distribution Centerei érvényesnek fogadnak el. Ez azt jelenti, hogy a felhasználói jelszavak visszaállítása – még a Domain Adminoké is – önmagában nem elég; minden kompromittált tartományban kétszeres krbtgt-rotációra van szükség, a két reset között legalább a maximális Kerberos-jegyélettartam (alapértelmezésben 10 óra) kivárásával. Amíg ez nem történik meg, a címtárat gyakorlatilag elfoglaltként kell kezelni, mert a támadó a hamisított jegyekkel bármikor vissza tud térni.
Az incidens egyik legfontosabb, rendszerszintű tanulsága, hogy a kontrollok jelentős része formálisan működött: a DMZ-ben lévő Stormshield tűzfal alapból tiltó kimenő szabálya elvágta a reverse shelleket; a Symantec Endpoint Protection blokkolta a C2-beaconöket és az LSASS-hoz való hozzáférést; a szegmentáció és a SELinux több helyen falat húzott a támadó elé. A probléma az volt, hogy a riasztások öt és fél napon át „egy üres szobába” futottak be: nem volt 24/7 észlelési és reagálási funkció a kontrollok mögött, nem volt olyan SOC/MDR, amely a tiltási események mintázatát (nem az egyedi eseményeket) értelmezte volna, és nem volt begyakorolt incidenskezelési folyamat.
A jövőbeli védekezés szempontjából a legfontosabb lépések nem új termékek beszerzésével kezdődnek, hanem architekturális és szemléletbeli váltással:
- 24/7 észlelés és reagálás a már meglévő kontrollok mögött – hogy a tűzfal-, EDR- és IDS/IPS-riasztások ne maradjanak reakció nélkül.
- Jelszó- és identitásarchitektúra újratervezése: 14+ karakteres minimum, komplexitási kényszerek elhagyása, breach-korpusz alapú jelszóellenőrzés, reset-sablonok megszüntetése, privilegizált fiókok teljes PAM-be terelése, nyílt szöveges jelszót visszaadó vaultok kivezetése.
- Active Directory tierezés és bizalmi kapcsolatok újragondolása: szelektív hitelesítés, SID-szűrés, DCSync-jogok szigorú korlátozása, krbtgt-rotációs eljárás begyakorlása.
- Szegmentáció és menedzsment-hálózat izolálása: hipervizorok, backup-szerverek, identitáskezelők csak jump hoston, PAM-on és MFA-n keresztül legyenek elérhetők.
- Adatréteg-feltárás és jogosultságkezelés: tudni kell, mi van a 10+ TB-os megosztásokon, ki fér hozzájuk, és hogyan lehet a jogosultságokat úgy szűkíteni, hogy a napi munka ne álljon le, de a robbanási körzet drasztikusan csökkenjen.
- Legacy rendszerek kezelése: Windows Server 2003, SMBv1, LM hash, DES-alapú Kerberos etype-ok kivezetése; amíg ez nem lehetséges, szigorú szegmentáció, EDR-támogatás és kompenzáló kontrollok.
- Mentés és visszaállítás: módosíthatatlan, offline, rendszeresen tesztelt mentések, amelyek 100+ TB-os környezetben is reálisan visszaállíthatók; a mentési folyamat tényleges, nem csak papíron létező gyakorlása.
Linuxos szemmel nézve a történet különösen tanulságos: a támadó saját munkaállomása egy Linux Mint/Cinnamon desktop, VirtualBoxban futó Kali VM-mel, nyílt forrású eszközökkel. A célpont viszont egy erősen Windows/AD-centrikus, legacy terhelt infrastruktúra. A két világ találkozásánál dől el minden: a Linuxos oldalon futó eszközök ma már gond nélkül képesek kihasználni a Windows-ökoszisztéma gyengeségeit, ha a jelszó- és identitásarchitektúra nem áll stabil lábakon. A védekezésben is egyre nagyobb szerepet kapnak a Linux-alapú komponensek (SIEM, NDR, forenzikus eszközök), de az alapvető kérdés ugyanaz marad: mennyire kiszámíthatóak a jelszavak, mennyire lapos a hálózat, és van-e ember a riasztások mögött, amikor igazán számít.


Hozzászólások
Vajon..
Beküldte ebcsont -
Értékelés:
Vajon minek kellene történnie ahhoz, hogy felmerüljön a gyanú, hogy a kritikus infrastruktúrákat nem kellene kivülről elérhetővé tenni?
Vajon..
Beküldte T.István -
Értékelés:
Nincs ilyen ami történhet.
Kívülröl elérhetőnek kell lenni, mert a hómofissz.
Azon túl van NIS, meg NIS2 is, tehát vannak történések, de kb. mindenki leszarja.
Vajon..
Beküldte kami911 -
Értékelés:
Nem kellene elérhetőnek lennie, de ... Annyira nem veszik ezt figyelembe.
Vajon..
Beküldte kami911 -
Értékelés:
Lehetne azért két izolált hálózat, ami esetleg nincs egymáshoz köze, csatlakozása. Legalábbis a kritikus infra oldalán. A többiben is kellene növelni a biztonságot, szeparálással, 0 trusttal.
Vajon..
Beküldte ebcsont -
Értékelés:
Igen a külső és a belső rendszer között illene legalább egy "zsilipet" működtetni. Mondjuk az is megérne egy misét, hogy a támadott informatikai rendszer mennyi felesleges adatrögzítési műveletet használ?