Red Teaming esettanulmány: nyolc hét, 260 fiók, nulla riasztás
·A lényeg röviden
- Nyolc hét, egyetlen megbízás: nyílt forrású hírszerzés, külső vizsgálat, célzott adathalászat, fizikai bejutás három telephelyen és belső hálózati teszt
- Az internet felőli felület ellenállt: naprakész szerverek, jól beállított tűzfal, működő forgalomfigyelés, tanúsítványhoz és MFA-hoz kötött Wi-Fi
- A célzott adathalász kampány 260 érvényes fiókot hozott, tömeges kiküldés nélkül
- Tűzoltókészülék-ellenőr szerepében jutottunk be a tárgyalóba, ahol saját, 4G-s eszköz került a belső hálózatra
- A tanúsítványkiadó hibás beállítása (ESC8) Domain Admin jogosultságot adott – és nyolc hét alatt egyetlen riasztás sem futott be
Szükség van-e egyáltalán Red Teamingre?
Nagyvállalat, több ezer munkatárs, biztonságra évek óta van keret és figyelem. A kérdésük nem az volt, hogy vannak-e hibáik. Azt akarták tudni, mi történik akkor, ha egy elszánt és jól szervezett támadó éppen őket veszi célba.
Nyolc hetet kaptunk, és alig néhány megkötést. A saját, megtévesztésig hasonló doménről indított adathalász kampány 260 érvényes fiókot adott. A nyílt forrású hírszerzés kirajzolta az embereket és a rendszereket. Az épületbe felépített szereppel és klónozott beléptetőkártyával sétáltunk be, a tárgyalóban pedig ott maradt a saját eszközünk a belső hálózaton. A végén a tartomány hibásan beállított tanúsítványkiadója adta meg a legmagasabb jogosultságot. Az emberi, a technikai és a fizikai réteg máshol szakadt el – és egyik szakadás sem látszik egyetlen szűk hatókörű vizsgálatból.
Mi az a Red Teaming?
A Red Teaming (célzott, ellenfél-szimulációs támadás) a teljes szervezetet méri: azt is, ami az internet felől látszik, és azt is, ahogy az emberek döntenek. Azt játsszuk el, amit egy motivált támadó vagy egy APT-csoport tenne, ha sem az idő, sem a pénz nem korlátozná. Ezért hoz felszínre olyan hibákat, amelyekhez egyetlen alkalmazás vagy egyetlen hálózati szegmens vizsgálata soha nem ér el.
A penetrációs teszthez képest nem a technika más, hanem a kérdés. A penetrációs teszt arra válaszol, hol törik meg egy rendszer. A Red Teaming arra, hogy a szervezet észreveszi-e, amikor megtörik – és mit kezd vele az első óráiban.
Hogyan zajlik egy ilyen megbízás?
Az előkészítésre annyi időt fordítunk, mint magára a támadásra. Elismert Red Teaming módszertanok szerint dolgozunk: hibákat keresünk, kockázatot mérünk, és ellenőrizzük, hogy a megvásárolt védelem a gyakorlatban is működik-e. A munkát öt, egymástól elkülönülő, de egymásra épülő szakaszra bontottuk:
- Nyílt forrású hírszerzés (OSINT)
- A külső infrastruktúra vizsgálata
- Belső hálózati penetrációs teszt két forgatókönyvben
- Fizikai bejutás három telephelyen
- Célzott adathalász kampány a kiválasztott munkatársak ellen
Így jutottunk el a tartomány legmagasabb jogosultságáig
Célzott megbízásban mindig a KÜLSŐ VIZSGÁLATTAL kezdünk, vagyis mindennel, ami az internet felől elérhető. Végignéztük a webalkalmazásokat, a VPN-átjárókat, a levelezőszervereket és a többi szolgáltatást: elavult komponenst, hibás beállítást, kódolási hibát kerestünk. A megbízó itt jól teljesített. A szervereken minden javítás fent volt, kihasználható, ismert CVE-azonosítójú hiba nem maradt. A tűzfalat helyesen állították be, az IDS- és IPS-rendszerek pedig valóban figyelték a forgalmat. A Wi-Fi hálózaton sem jutottunk át: a belépéshez ügyféltanúsítvány és többfaktoros hitelesítés (MFA) kellett.
Az OSINT mutatta meg, mennyi minden áll össze úgy, hogy közben egyetlen rendszerhez sem nyúlunk: szervezeti felépítés, munkatársak nevei, IP-címek, aldomének, partnerek és szerződések. A LinkedInen kevesen vállalták nyíltan a munkahelyüket – a cég láthatóan diszkrécióra neveli a munkatársait. Ekkora létszámnál viszont így is elég profil gyűlt össze a további munkához. A LinkedIn adatait régi, kiszivárgott adatbázisokkal vetettük össze, és ellenőriztük a kapott e-mail-címeket. A fordulópont az volt, amikor az egyik belső rendszer hibája elárulta a pontos címformátumot: keresztnev.vezeteknev@cegnev.com.
A FIZIKAI VÉDELMET több telephelyen próbáltuk ki. Az első látogatás még csak felderítés volt: bejáratok, az őrjárat útvonala és időzítése, a kamerák holtterei. Az épület előtt a tűzvédelmi eszközöket ellenőrző cég autója állt – innen jött a forgatókönyv. Rövid OSINT-előkészítés után tűzoltókészülék-ellenőrként tértünk vissza: munkaruha, a szervizcég logója, fejléces papír, rajta írásos engedély a készülékek ellenőrzésére és a belépésre. A szerep olyan jól működött, hogy felügyelet nélkül maradtunk egy tárgyalóban. A televízió mögött rejtett RJ45-ös aljzatot találtunk. Néhány perc alatt bekötöttünk egy saját, 4G-s mobilkapcsolattal ellátott eszközt, elrejtettük, és kisétáltunk. Riasztás nem szólalt meg, mi pedig ettől kezdve tartósan és láthatatlanul bent voltunk a belső hálózaton.
Hálózati hozzáférésünk már volt, érvényes tartományi fiók viszont még nem. Az OSINT során ellenőrzött címlistára szűk, CÉLZOTT ADATHALÁSZ KAMPÁNYT építettünk: semmi tömeges kiküldés, csak egy megtévesztésig hasonló domén (typosquatting). A levél új belső jutalmazási rendszert ígért, a hamis intranetes bejelentkező oldal pedig gyűjtötte a jelszavakat. A kampányt azonnal leállítottuk, amint megvolt az anyag, hogy minél kisebb legyen a lebukás esélye. A friss tartományi fiókok nyitották meg az utat a hálózat mélyebb rétegei és a jogosultságeszkaláció felé.
A BELSŐ VIZSGÁLAT két forgatókönyvből állt: az ellopott eszköz szimulációjából és a belső hálózat teszteléséből. A tartomány tanúsítványkiadójában ESC8 sérülékenységet találtunk, amellyel bármilyen Active Directory tanúsítványt igényelhettünk – még a tartományvezérlőét (DC) is. A hibát a Certipy eszközzel igazoltuk, majd a Netexec Coerce_Plus moduljával rávettük a tartományvezérlőt, hogy hitelesítse magát a továbbító (relay) szerverünkön. A hitelesítést az NTLMRelayX eszközzel fogtuk el és irányítottuk tovább. A tanúsítványkiadó kiállította a tartományvezérlő tanúsítványát, ezzel pedig megvolt a Domain Admin, vagyis a tartományi rendszergazdai jogosultság. Az Active Directory tartományban ennél feljebb nincs: ez a teljes infrastruktúra átvétele, minden szolgáltatással és minden érzékeny adattal együtt. A jól felépített védelmet is meg lehet kerülni, ha a támadó pontosan céloz.
Eredmények és tanulságok
- Megszerzett fiókok. A célzott adathalász kampány 260 érvényes felhasználói fiókot hozott. A gyenge pont a levélszűrés és a munkatársak felkészültsége volt.
- Fizikai bejutás. A portán senki nem állította meg az emberünket, a beléptetőkártyák klónozása pedig kérdés nélkül ment. Ennyi kellett ahhoz, hogy saját eszköz kerüljön a védett zónába.
- Jogosultságeszkaláció a tartomány csúcsáig. A tanúsítványkiadó hibás beállítása (ESC8) megbízható tanúsítványt adott, azzal pedig teljes tartományi irányítást – észrevétlenül.
- Egyetlen riasztás sem. Sem a peremvédelem, sem az IDS- és IPS-rendszerek, sem a naplózás nem jelzett semmit. A listán ez a legdrágább megállapítás.
Mit mond minderről a magyar szabályozás?
A negyedik pont a legdrágább, és nem csak biztonsági értelemben. A magyar jog azt is előírja, hogy a szervezetek felismerjék és bejelentsék a kiberbiztonsági incidenseket: a Kiberbiztonsági tv. hatálya alá tartozó szervezeteknek az incidenseket a Nemzeti Kiberbiztonsági Intézet (NKI) felé kell jelenteniük. Nyolc hét idegen jelenlét egyetlen riasztás nélkül ebben a logikában egyszerű dolgot jelent: a bejelentési határidő el sem kezdett volna telni. Nem azért, mert nem volt incidens, hanem mert senki nem vette észre.
Magát a Red Teaminget viszont nem írja elő jogszabály. A védelmi intézkedések katalógusa – a 7/2024. (VI. 24.) MK rendelet 2. melléklete – ismeri a műfajt: szerepelnek benne az 5.23 „Vörös csapat” (red team) gyakorlatok és az 5.24, a fizikai környezet behatolásvizsgálata is. Egyik sem kötelező elemi követelmény, egyik biztonsági osztályban sem. Kötelező viszont a sérülékenységek ellenőrzése (15.9) mindhárom osztályban, a folyamatos felügyelet független értékelése (5.16) a „jelentős” és a „magas” osztályban, valamint a behatolásvizsgálathoz független szakértő vagy csapat bevonása (5.22) a „magas” osztályban.
A sorrend tehát fordítva áll ahhoz képest, ahogy a piacon gyakran hangzik. A Red Teaming nem jogszabályi kötelezettség, hanem az a mérés, amelyik megmondja, ér-e valamit a többi kötelezettségre elköltött pénz. Hogy pontosan mit ír elő a szabályozás a tesztelésről, azt cellánként végigvezettük egy másik cikkben.
Ez a cikk tájékoztatás, nem jogi tanácsadás. Az, hogy egy szervezetre pontosan milyen kötelezettség vonatkozik, az ágazattól, a mérettől, a biztonsági osztályba sorolástól és az ellátási láncban betöltött szereptől függ – kétség esetén érdemes jogásszal egyeztetni.
Mit javasoltunk a vizsgálat után?
- Fizikai védelem és látogatókezelés. Beléptető forgókapu a besurranás ellen, következetes személyazonosítás, nyilvántartott és kísért látogató. A recepció ugyanolyan belépési pont, mint a bejelentkező oldal.
- Minden támadási irány rendszeres vizsgálata. Az internet felőli felület, a belső infrastruktúra, a tanúsítványkiadó és a hálózati eszközök – nem csak az, ami éppen fejlesztés alatt áll.
- Adathalászat és social engineering (pszichológiai manipuláció) gyakorlása. Forgatókönyves gyakorlat és oktatás évente többször, nem egyetlen prezentáció januárban. A social engineering vizsgálat azt is megmutatja, mi történik a bejelentés után.
- A belső eszközök és a hálózati forgalom valós idejű figyelése. Az ismeretlen eszköz és a szokatlan hálózati viselkedés azonnal látsszon, ne nyolc hét múlva.
A kiberbiztonság nem eszközkérdés. Emberek, folyamatok és eszközök együtt adják ki, a támadó pedig ott megy be, ahol a legkisebb az ellenállás. Ezért kell a vizsgálatot, a tanulságot és a javítást ismételni. A Red Teaming ebből egyetlen dolgot mér, azt viszont pontosan: mennyi idő alatt veszi észre a szervezet, hogy már bent van valaki.
Red Teaming – gyakori kérdések
01Mi a különbség a Red Teaming és a penetrációs teszt között?
A penetrációs teszt egy rögzített hatókört néz meg mélyen – egy alkalmazást, egy hálózatot, egy felhőkörnyezetet –, és arra válaszol, hol törhető meg. A Red Teaming a teljes szervezetet méri, az emberi és a fizikai réteget is, és arra válaszol, hogy a szervezet észreveszi-e a támadást, és mit kezd vele. A kettő nem helyettesíti egymást: penetrációs teszt nélkül a Red Teaming drága módja annak, hogy ismert hibákat találjunk.
02Mennyi ideig tart egy Red Teaming vizsgálat?
A hatókör dönti el. Az itt leírt megbízás nyolc hétig tartott, mert öt szakaszból állt, és három telephelyen kellett fizikailag is bejutni. Egy szűkebb, egyetlen forgatókönyvre épülő gyakorlat néhány hét alatt lefut. A pontos időt a szabályok írásos rögzítése után tudjuk megmondani.
03Kötelező-e a Red Teaming Magyarországon?
Nem. A 7/2024. (VI. 24.) MK rendelet 2. melléklete nevesíti a red team gyakorlatokat (5.23) és a fizikai környezet behatolásvizsgálatát (5.24), de egyik biztonsági osztályban sem kötelező elemi követelményként. Kötelező a sérülékenységek ellenőrzése (15.9) mindhárom osztályban, a folyamatos felügyelet független értékelése (5.16) a „jelentős” és a „magas” osztályban, valamint független szakértő vagy csapat bevonása a behatolásvizsgálathoz (5.22) a „magas” osztályban. Ez a cikk tájékoztatás, nem jogi tanácsadás.
04Része-e a fizikai bejutás és az adathalászat a vizsgálatnak?
Csak akkor, ha a megbízásban írásban rögzítettük. A hatókört, a megengedett módszereket, a telephelyeket és az időablakot előre leírjuk, és a megbízó oldalán néhány beavatott ember mindvégig tudja, hogy vizsgálat folyik. Fizikai belépésnél írásos engedélyt viszünk magunkkal arra az esetre, ha az őrség megállítja a csapatot.
05Leállhat-e egy rendszer a vizsgálat alatt?
A cél a hozzáférés bizonyítása, nem a kár okozása. Roncsoló műveletet nem futtatunk, a kritikus rendszereken egyeztetett időablakban dolgozunk, és a szabályokat a munka megkezdése előtt írásban rögzítjük. Ha valami mégis váratlanul viselkedik, azonnal szólunk a megbízó kapcsolattartójának.
