â€Summary
Das VerstĂ€ndnis der eigenen digitalen AngriffsflĂ€che ist heute essenziell. Eine der am hĂ€ufigsten ĂŒbersehenen Gefahrenquellen ist die externe AngriffsflĂ€che â die Summe aller internetzugĂ€nglichen Systeme, die potenziell von Angreifern ausgenutzt werden könnten. Ein gut konzipiertes Attack-Surface-Mapping-Tool sollte dieses Problem adressieren, indem es eine passive AufklĂ€rung ausschlieĂlich auf Basis eines einzigen Start-Domainnamens durchfĂŒhrt.
Im Gegensatz zu aktiven Scannern sammelt dieser Ansatz Informationen, ohne die Zielinfrastruktur direkt zu berĂŒhren. Es werden ausschlieĂlich öffentliche Quellen wie Zertifikats-Logs, WHOIS-Datenbanken und internetweite Suchmaschinen genutzt, um ein vollstĂ€ndiges Bild der extern sichtbaren Systeme einer Organisation zu erstellen.
Ziel eines Attack Surface Mapping Tools
Ausgehend von einer Hauptdomain (z.âŻB. example.com) sollte das Ziel eines solchen Tools sein:
- Alle möglichen Subdomains und die zugehörigen IP-Adressen zu identifizieren
- IP-Bereiche, die mit der Organisation in Verbindung stehen, zu erkennen
- Detaillierte Metadaten zu öffentlich erreichbaren Diensten zu sammeln â ohne ein einziges Paket an das Ziel zu senden
- Alle gefundenen Informationen logisch zu verknĂŒpfen, um ein konsistentes Gesamtbild der externen Sichtbarkeit zu erhalten
Warum Kundenfeedback und klassische Schwachstellenscanner nicht ausreichen
Viele Unternehmen glauben, sie hĂ€tten bereits einen vollstĂ€ndigen Ăberblick ĂŒber ihre externen Systeme â oder verlassen sich darauf, dass der Einsatz von Schwachstellenscannern wie Nessus ausreicht, um Cyberrisiken zu erkennen.
Das ist jedoch selten der Fall. Fragt man Kunden: âWelche Domains und Server gehören Ihnen?â, erhĂ€lt man hĂ€ufig:
- UnvollstĂ€ndige Informationen â viele Systeme sind vergessen, nicht dokumentiert oder den Sicherheitsteams nicht bekannt
- Veraltete Angaben â DNS-EintrĂ€ge Ă€ndern sich, Cloud-Infrastrukturen wachsen, neue Testumgebungen entstehen
- Fehlannahmen â die Auskunftsperson kennt unter UmstĂ€nden keine externen Dienstleister, Legacy-Systeme oder intern gestartete Tools
Typische blinde Flecken:
- Shadow IT: Mitarbeitende nutzen SaaS, Testumgebungen oder Drittanbieterdienste ohne offizielle Genehmigung
- Ăbernahmen & Fusionen: Alte Domains von ĂŒbernommenen Firmen sind oft noch aktiv â und potenziell verwundbar
- Cloud-Missmanagement: DevOps-Teams veröffentlichen Dienste in AWS, Azure oder GCP, die nicht erfasst werden
- DNS-Delegation & Dienstleister-Wildwuchs: Subdomains werden durch Externe verwaltet und entziehen sich der Kontrolle
Warum Nessus & Co. nur ein Teil der Lösung sind
Tools wie Nessus sind zwar unverzichtbar â aber sie benötigen eine Zieldefinition: IPs, Domains, Netzbereiche. Wenn bei der Bestandsaufnahme Assets fehlen, werden sie nie gescannt â und bleiben ungeschĂŒtzt.
Ein gutes Attack-Surface-Mapping-Tool schlieĂt diese LĂŒcke durch:
- Die Angreifer-Perspektive: Es nutzt nur öffentlich einsehbare Informationen â genau wie ein Angreifer
- Skalierbarkeit und Schnelligkeit: In wenigen Minuten auf viele Domains anwendbar, ohne Risiko
- Keine aktive Interaktion: Es werden keine Pakete gesendet, keine Systeme belastet
- Validierung der Bestandsdaten: Zeigt auf, was der Kunde eventuell ĂŒbersehen hat
Erst wenn die AngriffsflÀche passiv vollstÀndig erkannt ist, kann ein Tool wie Nessus sinnvoll zum Einsatz kommen. Beide Schritte ergÀnzen sich.
Schritt-fĂŒr-Schritt: So sollte ein Attack-Surface-Mapping funktionieren
Schritt 1: Subdomains erkennen
Mittels passiver Methoden wie:
- API-Abfragen bei C99, SecurityTrails, VirusTotal
- Analyse von Certificate Transparency Logs
- Scraping von DNSDumpster
- CNAME-Auflösung zur Identifikation von Shadow-IT und Drittanbietern
Ergebnis: eine breite Ăbersicht aller genutzten FQDNs.
Schritt 2: Auflösung zu IP-Adressen
Alle gefundenen Domains werden per DNS aufgelöst. Nur erreichbare und gĂŒltige Hosts werden berĂŒcksichtigt.
Schritt 3: EigentĂŒmerbestimmung via WHOIS und RDAP
- Abfragen klassischer WHOIS-Datenbanken sowie des Schweizer RDAP fĂŒr .ch/.li
- Nutzung strukturierter WHOAPI-Daten
Ziel: Verifizieren, welche IPs wirklich zur Organisation gehören, und relevante Metadaten sammeln (Land, ISP, Name etc.).
Schritt 4: Erweiterung auf ganze IP-Bereiche
Mittels Organisationseintrag in WHOIS können bei den regionalen Internetregistern (RIRs) wie ARIN, RIPE, APNIC etc. gröĂere Netze gefunden werden.
Warum das funktioniert:
Organisationen, die ĂŒber eigenes IP-Adressmaterial verfĂŒgen (z.âŻB. UniversitĂ€ten, ISPs), registrieren ihre Netze direkt bei einem RIR. Diese EintrĂ€ge enthalten:
- Organisationsname
- Kontaktinformationen
- GröĂe und Zweck der Zuweisung
So lassen sich auch nicht dokumentierte, aber zur Firma gehörende IPs auffinden: z.âŻB. Standorte, veraltete Systeme, Testnetze.
Wann es nicht funktioniert:
- Alles in der Cloud liegt (AWS, GCP, Azure)
- Shared Hosting oder CDN genutzt wird
- Die IT-Infrastruktur ausgelagert ist
Dann taucht der Dienstleister (z.âŻB. Amazon) als EigentĂŒmer im WHOIS auf â nicht das Unternehmen selbst.
Was ein Tool dagegen tun sollte:
- PrĂŒfen, ob der WHOIS-Eintrag zum Unternehmen passt
- Hosting-Provider erkennen (Liste bekannter Anbieter)
- Mehrdeutigkeiten vermeiden (z.âŻB. bei Shared Hosting)
Nur verifizierte OrganisationseintrÀge werden weiterverwendet.
Schritt 5: Reverse Lookup & AktivitĂ€tsprĂŒfung
- Reverse DNS zeigt, welche IPs aktive Hosts haben
- So lassen sich Teilbereiche in groĂen Netzen identifizieren, die tatsĂ€chlich genutzt werden (z.âŻB. in /16-Blöcken)
Keine aktiven Scans â nur passives DNS.
Schritt 6: Anreicherung durch Threat Intelligence
Abfragen via API (z.âŻB. Shodan, ZoomEye), niemals direkt an das Zielsystem:
- Offene Ports
- Bekannte CVEs
- TLS-Konfigurationen und Banner
- Technologien (Apache, RDP, Elasticsearch âŠ)
Ergebnis: tiefgreifende Einblicke, ohne rechtliche Risiken oder Alarmierungen.
Schritt 7: Web-Crawling bei HTTP/HTTPS
Vor dem Crawling:
- PrĂŒfen, ob Port 80/443 offen ist (via API + TCP Connect Scan)
- Nur bei aktivem Webdienst beginnt das Crawling
Was analysiert wird:
- HTML, JS, Links
- Interne Subdomains
- Drittanbieter (APIs, Tracking)
- Versteckte Pfade wie /admin, /staging, alte Tools
Herausforderungen:
- Client-Side Rendering â HTML leer, Inhalte via JS nachgeladen
- Obfuskation â Inhalte schwer auffindbar
- Redirection / Blocking â Geoblocking, CAPTCHA, Bot-Erkennung
- Tiefenbegrenzung: z.âŻB. maximal 2 Link-Ebenen innerhalb derselben Domain
Schritt 8: Shared Hosting & weitere zugehörige Domains erkennen
- Reverse IP Lookup: Welche Domains teilen sich dieselbe IP?
- WHOIS-Vergleich â gehört die Domain zur selben Organisation?
Dann:
- Reverse WHOIS â Alle Domains mit gleichem Registrant
- Diese erneut analysieren (rekursiver Zyklus)
Ziel: auch Marken, Tochterfirmen oder Akquisitionen erkennen.
Fazit: Vorteile des passiven Ansatzes
- UnauffÀllig: Keine Interaktion mit Zielsystemen, keine Alarme
- Breit angelegt: Zahlreiche öffentliche Quellen kombiniert
- Rechtssicher: Ideal fĂŒr Pre-Sales, interne Audits oder MSSPs
- Automatisierbar: Auf hunderte Kunden oder Domains skalierbar
- PrÀzise: Erkennt auch vergessene oder unbekannte Systeme
đFordere jetzt eine Demo an: Darknetsearch.com
Your data might already be exposed. Most companies find out too late. Let âs change that. Trusted by 100+ security teams.
đAsk for a demo NOW â