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