Attack Surface

Was ist Ihre Cyber-AngriffsflÀche? Warum Attack Surface Mapping entscheidend ist

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

💡 Do you think you’re off the radar?

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 →