von Große Organisationen haben oft hunderte bis tausende Subdomains. Zu produktiven Systemen kommen laufend neue Staging-Umgebungen, temporäre Kampagnenseiten, Testinstanzen und Assets aus alten Marketingprojekten hinzu. Viele dieser Ressourcen geraten schließlich aus dem Blickfeld der IT. Genau hier liegt das Problem, denn eine Subdomain, die niemand mehr im Blick hat, ist trotzdem noch erreichbar. Angreifer nutzen genau diese Lücken, und die Zahl der entsprechenden Vorfälle steigt seit Jahren.
Warum vergessene Subdomains ein echtes Sicherheitsproblem sind
Das klassische Beispiel ist der sogenannte Subdomain Takeover. Er tritt dann ein, wenn eine Subdomain per CNAME auf einen externen Dienst wie GitHub Pages, AWS S3, Azure oder Heroku zeigt und die dortige Ressource gelöscht wurde. Der DNS-Eintrag bleibt bestehen, der Zielendpunkt ist frei, und ein Angreifer kann die Ressource unter gleichem Namen neu registrieren. Damit kann er Content unter einer legitimen Domain ausliefern, was dann Phishing, Cookie-Diebstahl und die Umgehung von Same-Origin-Policies begünstigt.
Wie gravierend das Ausmaß in der Praxis ist, belegen Berichte von Detectify, denen zufolge bei Microsoft einst tausende verwaiste Subdomains identifiziert wurden. Das MITRE ATT&CK Framework führt dieses Vorgehen offiziell als Reconnaissance-Techniken T1590.005 (IP Addresses) sowie T1596.001 (DNS/Passive DNS) und unterstreicht damit die Relevanz für reale Angriffsszenarien.
Auf dem zweiten Risikopfad tummeln sich die alten Anwendungen auf vergessen Hosts. Ein Staging-System mit einer WordPress-Instanz aus dem Jahr 2019, ein alter Jenkins ohne Authentifizierung oder eine phpMyAdmin-Oberfläche auf irgendeiner Test-Subdomain gehören zu häufigen Funden in Pentests. Solche Systeme tauchen auch in den Schwachstellenscans der Produktivumgebung meist nicht auf, weil sie einfach nicht auf der Asset-Liste stehen.
Wie sich die Angriffsfläche systematisch erfassen lässt
Attack Surface Management (ASM) kümmert sich genau darum. Der Ansatz kombiniert fortlaufende Erkennung, Klassifizierung und Bewertung aller extern erreichbaren Assets der eigenen Organisation. Will man die eigene Angriffsfläche kennenlernen, muss man erst einmal herausfinden, welche Namen auf die eigene Infrastruktur zeigen. Für diese Aufklärungsphase greifen Security-Teams sowohl auf etablierte Open-Source-Frameworks wie OWASP Amass und DNSRecon als auch auf webbasierte Dienste wie die Subdomain-Recherche von binsec.tools zurück. Sie führen passive Datenquellen, etwa Certificate Transparency Logs, Passive DNS und Google-Suchergebnisse zusammen, ohne aktiv mit den Zielsystemen zu interagieren.
Typische Datenquellen im ASM-Prozess sind:
- Certificate Transparency Logs nach RFC 6962, die jedes ausgestellte TLS-Zertifikat öffentlich protokollieren
- Passive DNS Feeds, die die Auflösungen in der Zeit speichern
- Suchmaschinen für exponierte Dienste, die Banner und offene Ports indexieren
- WHOIS und RDAP für die Registrierungsdaten
- Öffentliche Code-Repositories, in denen Subdomains häufig in den Konfigurationsdateien auftauchen
Nach der Erfassung werden die Assets anhand von CVSS-Werten, Datenrelevanz und Internet-Erreichbarkeit priorisiert. Das dadurch entstehende, dynamische Inventar schafft die technische Basis, um Compliance-Vorgaben wie ISO/IEC 27001 Annex A.5.9 oder den NIST CSF 2.0 Baustein ID.AM nachhaltig zu erfüllen.
Prozess-Schritte für ein belastbares Subdomain-Monitoring
Ein bewährter Workflow hat sich dabei in der Praxis ergeben. Er lässt sich in fünf Schritte gliedern:
- Definition der Ausgangsdomains, incl. aller Marken und regionalen Varianten
- Passive Enumeration, um bestehende Subdomains ohne aktiven Scan zu erfassen
- Aktive Prüfung, etwa DNS-Bruteforce mit kuratierten Wortlisten und Zonentransfer-Tests
- Abgleich der Ergebnisse mit dem internen CMDB oder Asset-Inventar, Abgleich der Abweichungen
- Neue oder verwaiste Einträge in ein Ticket-System überführen, möglichst mit klarer Verantwortlichkeit
Optimalerweise wird das Verfahren automatisiert und möglichst in kurzen Zyklen (täglich oder wöchentlich) durchgeführt. So werden Änderungen an DNS-Einträgen, neu ausgestellte Zertifikate und plötzlich erreichbare Ports zeitnah erkannt.
