Domain- és infrastruktúra-OSINT pentest felderítéshez

Gyakorlati útmutató domain- és infrastruktúra-OSINT pentest felderítéshez: CT-naplók, passzív DNS, Shodan, Censys, urlscan, tanúsítvány-pivoting és scope-határok.

Infrastruktúra- és doménfelderítés

Kinek: Biztonsági szakemberek

Domain- és infrastruktúra-OSINT pentest felderítéshez

A felderítés az a fázis, amelyen egy penetrációs teszt megnyerhető vagy elveszíthető, mielőtt egyetlen exploit is lefutna. Minél gazdagabb képet alkotsz a célpont domain-lábnyomáról és internet felőli infrastruktúrájáról az engagement előtt, annál pontosabban irányíthatod az aktív tesztelést — és annál kevesebb időt vesztegetsz olyan eszközök kalapálásával, amelyek harmadik félhez tartoznak. Ez az útmutató végigvezet a domain- és infrastruktúra-OSINT pentest felderítéshez használt alapvető adatforrásokon és láncolási technikákon, és egyértelmű határt húz a passzív megfigyelés és az aktív interakció között.

Scope-emlékeztető: A cikkben szereplő minden technika passzív OSINT, kivéve ahol kifejezetten másként jelöljük. Ezeknek a módszereknek az alkalmazása olyan infrastruktúra ellen, amelynek tesztelésére nem kaptál engedélyt, sértheti a Computer Fraud and Abuse Act-et, az Egyesült Királyság Computer Misuse Act-ját vagy a joghatóságod szerinti egyenértékű jogszabályokat. Mindig aláírt Rules of Engagement dokumentum keretein belül tevékenykedj.

Miért számít a passzív felderítés, mielőtt bármit megérints?

Az aktív szkennelés — csomagküldés, portok vizsgálata, endpointok fuzzing — észlelhető, naplóbejegyzéseket hagy maga után, és jogi szempontból is releváns, amint átlépi a scope határát. A passzív OSINT ezzel szemben olyan adatokat kérdez le, amelyeket harmadik felek már összegyűjtöttek és elérhetővé tettek. Ez lehetővé teszi, hogy:

• A teljes attack surface-t feltérképezd még a végleges scope elfogadása előtt, hogy megalapozott párbeszédet folytathass az ügyféllel.
• Felderítsd az árnyék-IT-t, elfelejtett subdomaineket és olyan infrastruktúrát, amelyről az ügyfél saját csapata sem tudhat.
• Pivoting-láncokat (IP → tanúsítvány → domain → ASN → további IP-k) építs fel, amelyek az aktív szkennelés óráit másodpercekre csökkentik.
• Elkerüld a scope-on kívüli eszközök tesztelését, ami mind téged, mind az ügyfeledet védi.

Certificate Transparency naplók: az első pivot-pont

Minden nyilvánosan megbízható TLS-tanúsítványt naplóznak Certificate Transparency (CT) naplószervereire a böngészőbeli megbízhatóság feltételeként. Ez azt jelenti, hogy minden subdomain, amelyre valaha tanúsítványt adtak ki, véglegesen és nyilvánosan rögzített — függetlenül attól, hogy a subdomain még él-e.

Kulcsfontosságú források:

• crt.sh — Ingyenes, böngészőből elérhető, SQL-lel lekérdezhető. Keress %.example.com-ra az adott domain Subject Alternative Name (SAN) mezőben szereplő összes tanúsítvány lekéréséhez. A % helyettesítő karakter SQL LIKE operátorként viselkedik.
• Google Transparency Report — Jelentősen átfed a crt.sh-val, de időnként korábban indexel tanúsítványokat.
• Cert Spotter (SSLMate) — Monitorozási feedet kínál, amely védők számára hasznos, de a keresési felület felderítési célra is használható.

A tanúsítvány-alapú pivoting az, ahol a CT-naplók igazán hatékonnyá válnak. Egyetlen tanúsítvány akár tíz SAN-t is fedhet több apex domain-en — feltárva üzleti egységeket, felvásárlásokat vagy belső elnevezési konvenciókat, amelyek nem szerepelnek a nyilvános DNS-ben. Vedd ki a kibocsátó szervezet mezőjét: egyes belső CA-tanúsítványok a CT-naplókba kerülnek, ha egy vállalat véletlenül nyilvánosan megbízható CA-t használ belső infrastruktúrájához.

Gyakorlati munkafolyamat:

1. Kérdezd le a %.example.com-ot a crt.sh-n.
2. Exportálj minden egyedi SAN-t és apex domain-t.
3. Ellenőrizd az apex domain-eket az ügyfél ismert jogi entitásaival szemben — minden ismeretlen domain scope-pontosítást igényel az aktív tesztelés megkezdése előtt.

Passzív DNS: történeti infrastruktúra-feltérképezés

A passzív DNS (pDNS) adatbázisok rögzítik a résztvevő resolverek által idővel megfigyelt DNS-lekérdezés/válasz párokat. Egy élő DNS-lekérdezéssel ellentétben a pDNS megmutatja, hogy hat hónapja mire mutatott egy IP-cím — felbecsülhetetlen értékű jelzés a leállított, áthelyezett vagy átnevezett, de esetleg még elérhető infrastruktúra megtalálásához.

Kulcsfontosságú források:

• SecurityTrails — Az egyik legátfogóbb pDNS-archívum. Megjeleníti az A, AAAA, MX, NS, TXT és CNAME előzményeket bármely domainhez. Az ingyenes szint korlátozott, de elegendő a kezdeti felderítéshez.
• Farsight DNSDB — Az iparági referenciapont a passzív DNS adatmennyiség és a történeti mélység tekintetében. Előfizetés szükséges; akadémiai és biztonsági kutató hozzáférési programok léteznek.
• RiskIQ PassiveTotal (ma Microsoft Defender Threat Intelligence) — Egyetlen pivot felületen kombinálja a pDNS-t, a WHOIS-előzményeket és a tanúsítvány-adatokat.
• VirusTotal (alább részletesebben tárgyalva) — Domainekhez és IP-khez pDNS-rekordokat tartalmaz a Relations fülön.

DNS-előzmény pivot munkafolyamat:

1. Keressük a cél apex domain-jét. Jegyezzük fel az összes korábbi A-rekordot.
2. Minden korábbi IP-re fordítva kérdezzük le a pDNS-t: milyen más domainekre mutatott ez az IP valaha? Ez felfedi a megosztott tárhely kapcsolatokat, testvérszolgáltatásokat és örökölt infrastruktúrát.
3. Ellenőrizzük az NS-rekord előzményeket: a névszerverek változása jelezhet domain-átruházást, felhőmigrációt — vagy leginkább azt, hogy melyik volt az eredeti tárhelyszolgáltató, mielőtt egy CDN-t helyeztek elé.
4. Az MX-rekord előzményei gyakran feltárják az e-mail biztonsági szállítókat (Proofpoint, Mimecast, Google Workspace) és — alkalmanként — a CDN-t megkerülő közvetlen levelezőszerver IP-ket.

Infrastruktúra-keresőmotorok: Shodan, Censys és Netlas

Ezek a platformok folyamatosan szkennelnek az interneten és indexelik a bannereket, tanúsítványokat és szolgáltatás-metaadatokat. Lekérdezésük passzív — az összegyűjtött adatokat olvasod, nem küldesz csomagokat a célpontnak.

Shodan

A Shodan port-bannereket, HTTP-fejléceket, TLS-tanúsítványokat és szolgáltatás-ujjlenyomatokat indexel. Hasznos lekérdezések pentest felderítéshez:

• ssl.cert.subject.cn:"example.com" — Megtalálja azokat a hosztokat, amelyek az adott domainre szóló tanúsítványt mutatnak, nem szabványos portokon is.
• org:"Example Corp" — ASN szervezetnév szerint szűr. Kombinálható port: szűrőkkel a szűkítéshez.
• http.title:"Example" — Oldalcímekre illeszkedik. Hasznos, ha staging-környezetre gyanakszunk felismerhető cím, de ismeretlen subdomain esetén.
• hostname:.example.com — Fordított DNS találatok.

A Shodan Shodan Monitor terméke védők számára készült, de az alapul szolgáló adat ugyanaz, amit lekérdezünk.

Censys

A Censys strukturáltabb, SQL-szerű lekérdező nyelvet kínál, és az IPv4, IPv6 és tanúsítvány-adatokat külön indexeli. A tanúsítvány-keresése gyakran frissebb, mint a Shodané, mert aktívan újrakúszik a CT-napló bejegyzéseket.

• parsed.names: example.com (a Certificates indexben) — Visszaadja az összes tanúsítványt, ahol az example.com szerepel bármely névelőzménymezőben.
• services.tls.certificates.leaf_data.subject.common_name: "example.com" (a Hosts indexben) — Megtalálja az adott tanúsítványt mutató élő hosztokat.

A Censys különösen erős az IPv6 enumeráció és az olyan hosztok megtalálásában, ahol a tanúsítvány az egyetlen megbízható azonosító.

Netlas

A Netlas egy újabb szereplő, amelyet érdemes beilleszteni a munkafolyamatba. Indexeli a HTTP/HTTPS válasz törzseket, fejléceket és tanúsítványokat, és lehetővé teszi a teljes szöveges keresést a válasz tartalom ellen — ez egy olyan képesség, amelyet a többiek csak részben kínálnak.

• Keress belső terméknevekre, copyright-szövegekre vagy a célpont tech stack-jére jellemző egyéni HTTP-fejlécekre.
• A domain: szűrő és a tanúsítvány-alapú keresések nagyjából tükrözik a Shodan és Censys funkcionalitását, de a válasz törzs indexelése olyan admin paneleket és API endpointokat tárhat fel, amelyek nem jelennek meg a tanúsítvány- vagy banner-adatokban.

urlscan.io: passzív böngészőalapú felderítés

Az urlscan.io egy sandboxolt URL-szkenner, amely rögzíti az elküldött URL-ek képernyőképeit, DOM-tartalmát, kimenő kérelmeit, sütiket és átirányításokat. A felderítés szempontjából kritikus, hogy nyilvános archívumot tart fenn más felhasználók által elküldött szkennelésekből — ami azt jelenti, hogy valaki már esetleg beszkennelte a célpont bejelentkezési portálját, staging-környezetét vagy belső alkalmazását, amely kiszivárgott az internetre.

Felderítési felhasználások:

• Keress page.domain:example.com-ra a célpont domainjén lévő oldalak összes nyilvános szkennelésének megtalálásához.
• Tekintsd át a képernyőképeket alkalmazásnevekre, verzióstringekre vagy belső branding-re.
• Bármely szkennelés Requests füle felsorolja az összes erőforrást, amelyet az oldal betöltött — CDN URL-eket, API endpointokat, analitikai platformokat és néha belső IP-címeket, amelyek HTTP-fejléceken vagy JavaScript source map-eken keresztül szivárogtak ki.
• Szűrj dátum szerint, hogy megtaláld az olyan oldalak szkenneléseit, amelyek már nem léteznek az élő DNS-ben — ez megszüntetett alkalmazások bizonyítéka.

Az urlscan eredményei különösen értékesek a harmadik féltől származó SaaS-termékek és integrációk azonosításához, amelyek tágítják a logikai attack surface-t, még ha a közvetlen IP-scope-on kívül is vannak.

VirusTotal: infrastruktúra-kapcsolatok nagy léptékben

A VirusTotal grafikus és kapcsolati funkcióit sok pentester nem használja ki kellőképpen. A kártevő-szkennelés mellett a VT összesíti:

• pDNS-rekordokat domainekhez és IP-khez (több szolgáltatótól forrásozva).
• Subdomaineket passzív forgalomban megfigyelve.
• Kommunikáló fájlokat — kártevőminták, amelyek egy IP-re beaconöztek, amely kontextust nyújthat arról, hogy egy IP-nek van-e C2-előzménye — hasznos felhő-infrastruktúra scope-olásakor.
• Resolutions — a teljes kétirányú IP-domain feloldási előzmény.
• Referrer URL-ek — más URL-ek, amelyek a célpontra hivatkoztak, néha nyilvánosságra nem hozott admin portálokat tárva fel.

A VirusTotal Graph eszköz vizuális pivot-térképet tesz lehetővé: kezdj egy domainnel, bővítsd IP-kre, majd azokat az IP-ket testvérdomainekre, tanúsítványokra és fájlokra — mindez egyetlen munkamenetben anélkül, hogy megérintenéd a célhálózatot.

Attack surface enumeráció: a pivot-lánc összeállítása

Az infrastruktúra-OSINT valódi képessége az adatforrások láncolásában rejlik, hogy minden megállapítás a következő lekérdezés magját adja. Egy reprezentatív pivot-lánc így néz ki:

crt.sh (subdomainek) 
  → pDNS (subdomainenkénti korábbi IP-k) 
    → Shodan/Censys (szolgáltatások ezeken az IP-ken) 
      → Felfedezett szolgáltatások tanúsítvány SAN-jai 
        → crt.sh (új subdomainek ezekből a tanúsítványokból) 
          → urlscan (alkalmazás-ujjlenyomat) 
            → VirusTotal (testvérdomainek, kártevő-előzmények)

Minden lépésnél nyomon kell követned:

1. IP-tartományok és ASN-ek — Építs CIDR-térképet. Vannak-e közvetlenül az ügyfélhez regisztrált tartományok, szemben az AWS/GCP/Azure-on üzemeltetettekkel? A felhő IP-k aktív tesztelés előtt kifejezett engedélyt igényelnek.
2. Tech stack jelzések — A szerver-fejlécek, TLS titkosítási csomagok, Jarm ujjlenyomatok (elérhető a Shodanban) és HTTP válasz törzsek mind hozzájárulnak a technológiai profilhoz.
3. Szervezeti metaadatok — WHOIS regisztrációs adatok (ahol nem adatvédelem-titkosítottak), visszaélés-értesítési kapcsolattartók és regisztrációs dátumok. A közelmúltban regisztrált domainák új terméket vagy adathalász-kampányt jelezhetnek.
4. Tanúsítvány-anomáliák — Önaláírt tanúsítványok, belső hoszt neveket tartalmazó SAN-nal rendelkező tanúsítványok, vagy váratlan CA által kibocsátott tanúsítványok tesztkörnyezeteket vagy helytelen konfigurációjú infrastruktúrát jelezhetnek.

Automatizálás és eszközök

Számos nyílt forráskódú eszköz automatizálja a lánc részeit:

• Amass — Aktívan karbantartott, integrálja a CT-naplókat, pDNS-t (API-kulcsokon keresztül) és brute-force subdomain enumerációt. Megjegyzés: a brute-force modul aktív, és le kell tiltani a csak passzív fázisokban.
• Subfinder — Passzív subdomain enumeráció több API-ból; tiszta kimenet, amely pipe-olásra alkalmas.
• theHarvester — Összesíti a domain-, e-mail- és IP-adatokat keresőmotorokból és adatforrásokból.
• DNSx — Gyors DNS-feloldás és rekordlekérdezés; hasznos annak ellenőrzéséhez, hogy a felfedezett subdomainök melyike él jelenleg.

Ezek az eszközök mind támogatják a csak passzív módokat. Olvasd el a dokumentációt, és tilts le minden olyan modult, amely DNS-lekérdezéseket küld közvetlenül a célpont autoritatív névszervereire, mivel ez aktív felderítésnek minősül.

Ahol az OSINT véget ér és az aktív tesztelés kezdődik

Ez a különbségtétel jogilag és szakmailag is jelentős. Ökölszabályként:

Az autoritatív DNS-lekérdezések a leggyakrabban félreértett határterület. Ha dig example.com @ns1.example.com-ot futtatsz, a lekérdezésed eléri a célpont névszerverét, és naplózható. A legtöbb érett biztonsági csapat nem monitorozza ezt, de néhány igen. Ha a Rules of Engagement-ed passzívval kezdődik, korlátozd a DNS-lekérdezéseket nyilvános rekurzív resolverekre (8.8.8.8, 1.1.1.1) és pDNS-archívumokra, amíg az aktív tesztelés nem engedélyezett.

CDN- és WAF-megkerülés: Az infrastruktúra-OSINT egyik közös célja az CDN mögötti origin IP megtalálása. Ennek az IP-nek a CT-naplókon és pDNS-en keresztüli felfedezése passzív. Kérések küldése közvetlenül erre az IP-re aktív, és kifejezett engedélyt igényel, még ha az IP nyilvánosan elérhető is.

Felhőeszköz-enumeráció: Permutáció-alapú S3-bucket vagy Azure blob enumeráció (pl. example-backup.s3.amazonaws.com) HTTP-kérések küldését jelenti az AWS infrastruktúrára. Ez aktív tesztelés, nem OSINT, és scope-ban kell lennie.

Gyakorlati scope-kezelés a felderítés során

Egy jól strukturált felderítési fázis az aktív tesztelés megkezdése előtt egy deliverable-t állít elő: javasolt scope-bővítési dokumentumot. Ez tartalmazza:

• Az OSINT révén felfedezett IP-tartományokat és ASN-eket, amelyek nem szerepeltek az eredeti scope-ban.
• Az ügyfélhez tanúsítvány- és DNS-pivotokon keresztül kapcsolódó subdomaineket és apex domain-eket.
• Az urlscan-en és VirusTotalon azonosított, az adott scope-on kívül eső, de logikai támadási vektort képviselő harmadik fél SaaS-platformokat.
• Az ügyféllel kapcsolatos felhő-régiókat és -fiókokat.

Ennek az ügyfél elé terjesztése az aktív tesztelés megkezdése előtt két célt szolgál: bemutatja az alaposságot, és lehetőséget ad az ügyfélnek arra, hogy kifejezetten belefoglalja vagy kizárja az újonnan felfedezett eszközöket. Ez jogilag véd téged, és általában átfogóbb végső jelentést eredményez.

Ismételhető munkafolyamat felépítése

A következetes eredmények érdekében az engagementek során kódold a felderítési láncodat:

1. Seed domain-ek — Gyűjts össze minden apex domain-t a Statement of Work-ből, és egészítsd ki CT-napló keresésekkel a szervezet bejegyzett jogi nevére.
2. Subdomain enumeráció — Futtasd a Subfindert az összes konfigurált API-kulccsal (Shodan, Censys, SecurityTrails, VirusTotal, urlscan). Csak passzív mód ebben a fázisban.
3. IP-feloldás — Oldd fel az összes élő subdomain-t nyilvános resolvereken keresztül. Duplázz ki, és térképezd az ASN-ekre whois-on vagy BGP-eszközökön (pl. bgp.he.net) keresztül.
4. Szolgáltatás-ujjlenyomat (passzív) — Kérdezd le a Shodant és a Censyst minden felfedezett IP-tartományra. Exportáld a port-, banner- és tanúsítvány-adatokat.
5. Tanúsítvány-pivoting — Vond ki az összes SAN-t a felfedezett tanúsítványokból. Táplálj vissza új apex domain-eket az 1. lépésbe.
6. Történeti kontextus — Kérdezd le a pDNS-t és a VirusTotalt minden felfedezett domainre és IP-re. Jegyezd fel a korábbi infrastruktúrát és technológiai változásokat.
7. Alkalmazás-ujjlenyomat — Keress az urlscan.io archívumban a felfedezett domainekre. Tekintsd át a képernyőképeket és a kimenő kérelmek gráfjait.
8. Scope-felülvizsgálat — Állítsd össze az összes újonnan felfedezett eszközt, és kérj írásos engedélyt az aktív tesztelés megkezdése előtt.

Összefoglalás

A domain- és infrastruktúra-OSINT pentest felderítés nem egy előzetes ellenőrző négyzet — ez egy olyan diszciplína, amely közvetlenül meghatározza minden egymást követő fázis minőségét. A CT-naplók olyan subdomaineket tárnak fel, amelyeket az aktív brute-force kihagyott. A passzív DNS szándékosan homályosított infrastruktúrát fed fel. A Shodan, Censys és Netlas ujjlenyomatozzák azokat a szolgáltatásokat, amelyeket egyetlen bug bounty programban sem hirdettek. Az urlscan és a VirusTotal alkalmazási és kapcsolati kontextust nyújt, amelyet a puszta hálózati szkennelés nem tud. És ezeknek a forrásoknak a láncolása — módszeresen, egyértelmű megjegyzésekkel arról, mi figyelhető meg a következtetettekkel szemben — olyan attack surface térképet produkál, amely egyszerre átfogó és védhető.

Tartsd a passzív/aktív határt egyértelműnek a feljegyzéseidben és a jelentésedben. Az itt tárgyalt adatforrások pontosan azért hatékonyak, mert kartávolságból dolgoznak a célponttól. Abban a pillanatban, amikor csomagot küldesz, más jogi és szakmai területre léptél — amelyen írásos engedély és aláírt scope-dokumentum szükséges, mielőtt továbblépnél.