Offenzív biztonság · Kézi tesztelés
Penetrációs teszt és adversary simulation.
Három megbízás, amit végig tudok vinni: a kívülről elérhető felület, a saját fejlesztésű alkalmazások, és egy egyeztetett kiindulópontról induló, célra menő gyakorlat. Kézzel dolgozom, szkennerrel csak az első napon. Ami nem fér bele, arról lentebb külön szakasz szól, még mielőtt ajánlatot kértek.
NDA alapból. A szkóp, az időablak és a forrás-IP-k írásban vannak, mielőtt az első csomag elmegy.
Utolsó frissítés: 2026. szeptember 4.
Amit el tudok vállalni
Három megbízás, egyben vagy külön-külön.
Ha a szkópot részekre bontjátok, ezek a részek. Mindegyik megáll önmagában, mindegyikről külön ajánlat készül, és mindegyiknek más az előfeltétele.
01
Perem, edge szolgáltatások, VPN-átjárók, ügyfélportálok
Külső támadási felület
Kívülről nézem meg, mi látszik belőletek: publikált szolgáltatások, elfelejtett teszt-aldomain, kifelé nyitva maradt menedzsmentfelület, VPN-átjáró régi build-en, ügyfélportál, ami külön életet él a többitől. Ezt összeírom, aztán megnézem, mihez ér hozzá először egy támadó, és onnan meddig jut el. A kimenet egy hoszt- és szolgáltatáslista azzal, hogy melyiknek egyáltalán nem kellene ott lennie.
Ehhez kell tőletek: Egy tartomány- és IP-lista, plusz írásos nyilatkozat arról, hogy a listán szereplő eszközök a tiétek. Bérelt infrastruktúránál a szolgáltató engedélye is kell, és azt náluk jellemzően napokban mérik.
02
Saját fejlesztésű alkalmazások
Web- és API-penetrációs teszt
Hitelesítés, jogosultságkezelés, injekció, üzleti logika. Szkennerrel kezdek, mert butaság kézzel végigjárni azt, amit egy gép öt perc alatt kilistáz, de a szkenner kimenete itt a nyersanyag, és az érdemi rész utána kezdődik. Amit a gép tisztának lát, az általában a jogosultsági réteg: egy azonosító az URL-ben, amit a másik ügyfél fiókja is elfogad, egy szerepkör, amit a felület elrejt, de az API kiszolgál, egy jóváírás, ami kétszer fut le, ha elég gyorsan küldik egymás után.
Ehhez kell tőletek: Legalább két szerepkörhöz teszt-fiók, egy staging környezet éles személyes adat nélkül, és egy fejlesztő, akit meg lehet kérdezni, ha valami furcsán viselkedik.
03
Egyeztetett kiindulópontról, megnevezett célig
Assumed breach gyakorlat
Abból indulunk, hogy egy munkaállomás vagy egy fiók már a támadóé, mert az adathalászat előbb-utóbb bejön, és az igazi kérdés az, mi történik utána. Onnantól a kill chain mentén megyek egy előre kimondott célig: egy konkrét fájl egy konkrét megosztáson, egy tartományi adminisztrátori jogosultság, egy lekérdezés egy megnevezett adatbázison. A lépéseket időbélyeggel és ATT&CK-technikára hivatkozva naplózom. Közben végig figyelem a másik oldalt is: mire jött riasztás, mire nem, mennyi idő alatt, és ki mit csinált vele. Ez a jelentésben külön fejezet, és a legtöbb cégnél ez a rész szokott fájni.
Ehhez kell tőletek: Egy megnevezett cél, egy kiindulási hozzáférés (fiók vagy gép), és egy döntés arról, hogy a SOC tud-e a gyakorlatról. Mindkettő működik, csak mást mértek vele.
Szabályok
Amit írásban rögzítünk, mielőtt bármi elindul.
- A szkóp hosztonként, tartományonként és alkalmazásonként fel van sorolva. Ami nincs a listán, azt nem érintem akkor sem, ha menet közben látom, hogy nyitva van. Szólok róla, de nem nyúlok hozzá.
- Az időablak napszakra pontos. Ha a havi zárás hetében nem akarjátok, akkor nem akkor.
- Szolgáltatásmegtagadásos teszt nincs. Terheléses próba sincs, és olyan exploit sem, aminek ismert mellékhatása a szolgáltatás elszállása.
- Éles rendszeren adatot módosító vagy törlő műveletet előzetes írásos jóváhagyás nélkül nem futtatok. OT-hálózaton aktív eszközt egyeztetés nélkül soha.
- Két megnevezett kapcsolattartó, telefonszámmal: egy nálatok, egy nálam. Ha teszt közben elkezd furcsán viselkedni egy rendszer, leállok és telefonálok. E-mailt ilyenkor senki nem olvas.
- A forrás-IP-k előre megvannak, hogy a SOC vissza tudja keresni, mi volt tesztforgalom. Ha viszont pont az a kérdés, hogy észreveszik-e, akkor a SOC nem kap előzetes értesítést, csak a két kapcsolattartó.
Amit a végén kaptok
Egy jelentés, amiből dolgozni lehet.
- 01Vezetői összefoglalóEgy oldal annak, aki nem fog parancssort olvasni: mi a három legrosszabb dolog, mi a következménye, és nagyjából mennyi idő megjavítani.
- 02Megállapítások reprodukciós lépésekkelKérés, válasz, képernyőkép, és a pontos sorrend, amivel a fejlesztő maga is elő tudja hozni. Amit nem tudtok reprodukálni, azt javítani sem tudjátok.
- 03Kockázati rangsorCVSS-pontszám, mellette egy mondat arról, hogy nálatok mit jelent. Egy 9.8-as egy elszigetelt teszt-hoszton kevesebbet ér, mint egy 6.5-ös a fizetési útvonalon, és a rangsor ezt tükrözi.
- 04Javítási lépés minden megállapításhozMelyik konfigurációs sor, melyik kódrészlet, melyik tűzfalszabály. Nem „erősítsétek meg a hitelesítést”, hanem az, hogy hol és mit.
- 05Detekciós fejezetMit láttak a védők, mire jött riasztás, mire nem, és mennyi idő telt el az első lépésem és az első reakció között. Assumed breach gyakorlatnál ez a jelentés fele.
- 06UtótesztHogy a javítás után visszamérek-e, milyen terjedelemben és meddig, az az ajánlatban benne van. Nem utólag derül ki, és nem külön alku.
A tanúsítványokról
Ahol CREST vagy CHECK a követelmény, oda csapatot viszek.
Ha a beszerzési szabályzatotok CREST- vagy CHECK-tanúsított szolgáltatót ír elő, azzal is el tudok indulni. Fővállalkozóként viszem a projektet, és bevonok olyan szakembereket alvállalkozóként, akik rendelkeznek ezekkel a minősítésekkel. Nektek ez egy szerződés, egy számla és egy felelős marad; a minősítési követelmény a bevont szakembereken keresztül teljesül.
Amit magamról nem állítok: az OSCP, az AZ-500 és a CISSP nálam még folyamatban van, a HackTheBoxon a globális első ezerben vagyok, és évek óta élesben csinálom ezt a munkát, de egy emberként nem fedek le egy CREST-szintű elvárást, és nem fogom annak nevezni, ami nem az. A projektvezetés, a szkóp tartása és a jelentés az én felelősségem marad, a minősített technikai végrehajtást pedig a bevont szakember adja.
Ha a szabályzat megengedi a szkóp részekre bontását – mondjuk a saját fejlesztésű alkalmazások tesztje nem esik a tanúsítási előírás alá –, azt is végig tudjuk vinni külön. Írjátok meg, pontosan milyen minősítést kell igazolni, és a konkrét nevekkel, önéletrajzokkal, tanúsítványokkal jövök.
A másik fele
A javítást ugyanaz az ember viszi végig.
A legtöbb tesztjelentés élete ott ér véget, hogy bekerül egy mappába, és a következő teszten ugyanaz a megállapítás jön vissza. Itt a javítás lehet ugyanannak a megbízásnak a folytatása: a szegmentálást, a hozzáférés-kezelést, a naplózást és a hardeninget én építem meg, ugyanabban a környezetben, amit az előző héten végigjártam. Nincs átadás a jelentés és a tűzfalat konfiguráló ember között.
A bizonyítékgyűjtés és az alert-triázs automatizálásáról a security automatizálás oldal szól, a NIS2 technikai követelményeiről a NIS2-implementáció, gyártósor mellett pedig az OT/IT biztonság a kiindulás.
Gyakori kérdések
Mennyibe kerül egy teszt?
Célpontlistára és megbízásra szabom, mert egy nyolc hoszt méretű külső felület és egy húsz szerepkörös alkalmazás nem ugyanaz a munka. Az árazáshoz a tartomány- és IP-lista kell, alkalmazásnál pedig a szerepkörök száma és az, hogy van-e staging. A bemutatkozó hívás után írásos ajánlatot kaptok fix terjedelemre.
Szkennert futtatsz, vagy kézzel dolgozol?
Mindkettőt, csak nem egyenlő arányban. A szkenner kilistázza a verziókat, a nyitott portokat és az ismert CVE-ket, ez a munka első napja. Amit fizettek, az a jogosultsági és üzleti logikai réteg átnézése, meg a téves találatok kigyomlálása. Egy PDF-be nyomtatott szkennerjelentés nem penetrációs teszt, és a számlán sem fogom annak nevezni.
Le tudod állítani a rendszerünket?
Nem, mert nem csinálok olyat, amitől leállna: DoS nincs, adatot módosító művelet írásos jóváhagyás nélkül nincs, éles OT-hálózaton pedig aktív eszközt előzetes egyeztetés nélkül nem futtatok. Ha egy rendszer mégis elkezd furcsán viselkedni, leállok, és hívom a kapcsolattartótokat.
Ki fér hozzá a jelentéshez?
Ti, és senki más. NDA minden megbízásnál alap, a jelentés titkosítva megy át, a nyers tesztadat megőrzési idejét pedig a szerződésben rögzítjük. Ha nem kértek mást, a lezárás után törlöm.
Alvállalkozóként is beállsz egy tanácsadó cég mögé?
Igen, ez a leggyakoribb felállás. Ti tartjátok az ügyfélkapcsolatot, a jelentés a ti sablonotokban megy ki, és nem keresem meg az ügyfeleteket a hátatok mögött. Ha a végfelhasználó szabályzata tanúsított szolgáltatót ír elő, azt is meg tudjuk oldani: fővállalkozóként bevonok olyan szakembert alvállalkozóként, aki rendelkezik a szükséges minősítéssel, a projektvezetés és a jelentés pedig nálam marad.
Mikor tudsz kezdeni, és meddig tart?
A külső felület felmérése jellemzően néhány nap, egy alkalmazásteszt egy-két hét, egy assumed breach gyakorlat a szkóptól függ. Egyszerre egy tesztet viszek, tehát az indulás dátuma azon múlik, mi van előtte a sorban. Ezt már az első híváson megmondom, jóval a szerződés előtt.
Kezdjük el
Hozzátok a célpontlistát.
30 perc, díjmentesen. Elég egy tartománylista vagy egy alkalmazásnév. A hívás végén megvan, melyik megbízás a tiétek, nagyjából meddig tart, és mit kell hozzá előkészítenetek.