Subdomain-Takeover-Schwachstellen erkennen und verhindern

1. Was eine Subdomain-Takeover-Schwachstelle eigentlich ist

Eine Subdomain-Takeover-Schwachstelle entsteht, wenn ein DNS-Eintrag, meist ein CNAME, auf einen externen Cloud-Dienst zeigt, dieser Dienst aber nicht mehr existiert oder nicht mehr im Besitz des ursprünglichen Betreibers ist. Solange die DNS-Zone diesen Eintrag nicht entfernt, bleibt die Subdomain technisch erreichbar und wartet nur darauf, dass jemand den Zieldienst erneut beansprucht. Weil viele Cloud-Plattformen Ressourcennamen nach dem Prinzip first come, first served vergeben, kann ein Angreifer genau diesen freien Namen registrieren und damit faktisch die Kontrolle über die Subdomain übernehmen.

Das Perfide an dieser Schwachstellenklasse ist ihre Unsichtbarkeit im normalen Betrieb: Die eigentliche Hauptdomain bleibt unberührt, TLS-Zertifikate der Hauptseite funktionieren weiterhin, und niemand bemerkt das Problem, solange kein Nutzer zufällig die betroffene Subdomain aufruft. Genau diese Stille macht Subdomain-Takeover zu einem beliebten Ziel für automatisierte Scanner, die kontinuierlich große Mengen an DNS-Zonen nach verwaisten Einträgen durchsuchen.

2. Der klassische Ablauf: Verwaister CNAME auf einen abgeschalteten Cloud-Dienst

Ein typisches Szenario beginnt mit einer Marketing-Kampagne: Ein Team richtet unter promo.mironsoft.de eine Landingpage bei einem Page-Builder-Dienst ein und legt dafür einen CNAME-Eintrag an, der auf eine vom Dienst vergebene Adresse zeigt, etwa mironsoft.pagebuilder-app.com. Nach Ende der Kampagne wird die Landingpage im Page-Builder-Dienst gelöscht, der DNS-Eintrag in der eigenen Zone jedoch vergessen. Der Zielhost existiert nun nicht mehr, der CNAME zeigt ins Leere und die Anfrage landet beim Page-Builder-Anbieter auf einer generischen Fehlerseite.

Ein Angreifer, der systematisch DNS-Zonen nach CNAME-Einträgen auf bekannte Cloud-Dienste durchsucht, erkennt genau diese generische Fehlerseite als Fingerabdruck einer verfügbaren Uebernahme. Er registriert beim selben Anbieter einfach ein neues Projekt mit dem Namen mironsoft, der Dienst verbindet daraufhin automatisch den bereits bestehenden DNS-Eintrag mit dem neuen Angreifer-Projekt, und promo.mironsoft.de liefert von diesem Moment an Inhalte, die vollständig unter der Kontrolle des Angreifers stehen, unter einer scheinbar vertrauenswürdigen Adresse.

# Verdächtigen CNAME identifizieren
dig promo.mironsoft.de CNAME +short
# mironsoft.pagebuilder-app.com.

# Auflösen des Zielhosts prüfen
dig mironsoft.pagebuilder-app.com A +short
# (keine Antwort oder generische Fehlerseite beim Aufruf)

curl -sI https://promo.mironsoft.de | head -n 5
# HTTP/1.1 404 Not Found
# Server: PageBuilderApp
# X-App-Status: no-such-project

3. Welche Cloud-Dienste besonders häufig betroffen sind

Statisches Hosting bei GitHub Pages, App-Plattformen wie Heroku, Objektspeicher wie Amazon S3 mit aktiviertem Static-Website-Hosting, Azure App Services, Fastly-Konfigurationen sowie Helpdesk- und Landingpage-Baukästen zählen zu den klassischen Kandidaten, weil sie Projektnamen nach dem first come, first served Prinzip vergeben und gleichzeitig einfache CNAME-Anbindung an eigene Domains erlauben. Projekte wie can-i-take-over-xyz dokumentieren öffentlich, welche Fehlermeldungen bei welchem Anbieter auf eine übernehmbare Ressource hindeuten.

Nicht jeder Dienst ist gleichermaßen anfällig: Manche Anbieter prüfen inzwischen aktiv, ob ein neu registrierter Ressourcenname bereits per DNS auf sie verweist, und blockieren die Vergabe in diesem Fall oder verlangen einen zusätzlichen Verifizierungsschritt. Diese Schutzmechanismen unterscheiden sich stark je Anbieter und ändern sich mit der Zeit, weshalb ein einmal als sicher eingestuftes Setup nicht dauerhaft als sicher gelten sollte.

4. Die Auswirkungen: Von Phishing bis Cookie-Diebstahl

Sobald ein Angreifer eine Subdomain übernommen hat, kann er dort beliebige Inhalte ausliefern, typischerweise gefälschte Login-Formulare für Phishing-Kampagnen, die dank der scheinbar legitimen Domain deutlich glaubwürdiger wirken als eine fremde Adresse. Nutzer, die Links aus alten Marketing-E-Mails oder Suchmaschinen-Caches folgen, landen ohne Warnung auf einer Seite, die optisch und adressseitig zur eigentlichen Marke gehört.

Noch gravierender wird es, wenn Cookies ohne restriktives Domain-Attribut gesetzt sind: Ein Session-Cookie, der für die gesamte Domain mironsoft.de gilt, ist auch für die übernommene Subdomain sichtbar und kann von dort ausgelesen oder manipuliert werden. Ist die übernommene Subdomain zusätzlich als vertrauenswürdige Quelle in der Content-Security-Policy der Hauptseite eingetragen, kann sie sogar zum Einschleusen von Skripten in die eigentliche Hauptseite missbraucht werden.

5. Systematisches Audit: Alle DNS-Einträge gegen aktive Services prüfen

Der Ausgangspunkt jedes Audits ist ein vollständiger Export der eigenen DNS-Zone, idealerweise direkt aus der Verwaltungsoberfläche des DNS-Providers oder per Zonendatei, statt sich auf eine unvollständige, aus dem Gedächtnis gepflegte Liste zu verlassen. Jeder einzelne CNAME- und ALIAS-Eintrag wird anschliessend aufgelöst und geprüft, ob das Zielsystem tatsächlich existiert und eine plausible, zur eigenen Marke passende Antwort liefert, statt einer generischen Fehlermeldung des Cloud-Anbieters.

Besonders wichtig ist der Abgleich mit einer aktuellen Inventarliste aller aktiv genutzten Cloud-Ressourcen. Nur wenn beide Listen, DNS-Einträge und tatsächlich existierende Cloud-Projekte, übereinstimmen, lässt sich zuverlässig ausschließen, dass ein Eintrag verwaist ist. Dieses Audit sollte kein einmaliges Projekt bleiben, sondern in regelmäßigen Abständen wiederholt werden, da neu verwaiste Einträge durch jede Marketing-Kampagne, jeden Testserver und jede Teamumstrukturierung entstehen können.

6. Certificate-Transparency-Logs als zusätzliche Entdeckungsquelle

Neben dem direkten DNS-Export liefern öffentliche Certificate-Transparency-Logs wie crt.sh eine wertvolle, unabhängige Quelle für die Subdomain-Inventarisierung. Jedes öffentlich vertrauenswürdige TLS-Zertifikat wird in diesen Logs erfasst, wodurch sich auch Subdomains aufspüren lassen, die in internen Dokumentationen längst vergessen wurden, aber irgendwann einmal ein Zertifikat erhalten haben, etwa für einen kurzlebigen Testserver.

Ein regelmäßiger Abgleich der über Certificate-Transparency-Logs gefundenen Subdomains gegen die eigene, gepflegte Inventarliste deckt genau jene Lücken auf, die ein reiner DNS-Export übersieht, wenn Einträge zwar existieren, aber nirgends dokumentiert sind. Manche Sicherheitsteams richten automatisierte Benachrichtigungen ein, die bei jedem neu ausgestellten Zertifikat für eine unbekannte Subdomain der eigenen Domain sofort Alarm schlagen.

7. Automatisierte Erkennungswerkzeuge im Ueberblick

Für große DNS-Zonen mit hunderten Einträgen lohnt sich der Einsatz spezialisierter Open-Source-Werkzeuge, die eine kuratierte Fingerprint-Datenbank bekannter Cloud-Dienste nutzen, um verwaiste Einträge automatisiert zu erkennen. Solche Werkzeuge lösen jeden CNAME auf, rufen den Zielhost per HTTP auf und vergleichen die Antwort mit bekannten Fehlermeldungsmustern der jeweiligen Cloud-Plattform, statt jeden Eintrag manuell zu prüfen.

Automatisierte Scans ersetzen das manuelle Audit nicht vollständig, weil Fingerprint-Datenbanken naturgemäß hinter neuen oder weniger bekannten Cloud-Diensten zurückbleiben. Sinnvoll ist eine Kombination: automatisierte Scans als regelmäßiges Grundrauschen für bekannte Muster, ergänzt durch periodische manuelle Stichproben bei ungewöhnlichen oder selten genutzten Einträgen, die kein Fingerprint-Werkzeug zuverlässig erkennt.

8. Der saubere Aufräum-Prozess beim Abschalten eines Cloud-Dienstes

Der wirksamste Schutz ist organisatorisch, nicht technisch: Das Löschen eines DNS-Eintrags muss fester Bestandteil jedes Deprovisionierungs-Prozesses sein, bevor oder unmittelbar nachdem eine Cloud-Ressource abgeschaltet wird, nicht Wochen oder Monate später. Am zuverlässigsten ist die Reihenfolge umgekehrt zur Einrichtung: Zuerst wird der DNS-Eintrag entfernt, erst danach die Cloud-Ressource gelöscht, sodass zu keinem Zeitpunkt ein toter CNAME auf ein bereits freies Namensfeld zeigt.

Während einer geplanten Migration oder Abschaltung hilft eine kurzzeitig reduzierte TTL, um Aenderungen schnell wirksam werden zu lassen und das Zeitfenster eines möglichen Missbrauchs zu minimieren. Teams, die Infrastructure-as-Code nutzen, sollten DNS-Einträge im selben Terraform- oder Pulumi-Modul verwalten wie die zugehörige Cloud-Ressource, sodass ein Löschen der Ressource automatisch auch den DNS-Eintrag entfernt, statt zwei unabhängige, leicht auseinanderlaufende Prozesse zu pflegen.

9. Organisatorische Maßnahmen: Subdomain-Inventar und Verantwortlichkeiten

Technische Maßnahmen allein reichen nicht, wenn niemand im Team weiß, welche Subdomain für welchen Zweck existiert und wer dafür verantwortlich ist. Ein zentrales, gepflegtes Subdomain-Inventar mit Angabe des Zweckes, des zuständigen Teams und des zugrunde liegenden Cloud-Dienstes verhindert, dass Wissen ausschließlich in den Köpfen einzelner Mitarbeiter existiert und mit deren Weggang verloren geht.

Gerade bei wachsenden Teams und häufigen Marketing- oder Produktkampagnen empfiehlt sich ein verbindlicher Prozess, der jeden neuen DNS-Eintrag automatisch in dieses Inventar einträgt und bei jeder Deprovisionierung explizit nach dem zugehörigen DNS-Eintrag fragt. Ein vierteljährlicher Review-Termin, bei dem das gesamte Subdomain-Inventar gegen die tatsächliche DNS-Zone abgeglichen wird, fängt Lücken auf, die durch informelle, undokumentierte Aenderungen entstanden sind.

10. Zusammenfassung

11. FAQ: Subdomain-Takeover: Das Wichtigste auf einen Blick