Subdomain-Takeover: wie es passiert und wie man es erkennt

Ein Subdomain-Takeover passiert, wenn ein DNS-Record, meist ein CNAME, auf eine externe Ressource zeigt, die nicht mehr existiert, und jemand anderes diese Ressource unter demselben Namen neu anlegt. Ab diesem Moment liefert Ihre Subdomain Inhalte aus, die Sie nicht kontrollieren. Der Angreifer bekommt eine Seite unter Ihrer Domain, mit Ihrem guten Namen als Deckung: glaubwürdiges Phishing, Malware-Verteilung und je nach Konfiguration Zugriff auf Cookies der übergeordneten Domain. Das DNS selbst wurde nie kompromittiert. Es hat schlicht weiter die Wahrheit über ein Ziel gesagt, das Sie aufzuräumen vergessen haben. Dieser Artikel erklärt den Mechanismus, die typischerweise betroffenen Dienste, das Self-Audit und die Prävention.

Der Mechanismus: der verwaiste Record

Die Schwachstelle folgt einem Lebenszyklus, den jeder kennt, der ein paar Jahre lang eine Website betreibt:

1. Sie legen blog.beispiel.de als CNAME auf einen gehosteten Dienst an, etwa ihrefirma.eine-plattform.com.
2. Der Dienst läuft monate- oder jahrelang. Alles funktioniert.
3. Sie kündigen das Abo oder löschen das Projekt. Die Plattform gibt den Namen ihrefirma frei.
4. Niemand löscht den CNAME. Er zeigt jetzt auf eine Ressource, die nicht mehr existiert: ein verwaister Record, im Englischen „dangling record".

So sieht das Vorher und Nachher aus:

Vorher (Dienst aktiv):
blog.beispiel.de.  CNAME  ihrefirma.eine-plattform.com.
                          -> die Plattform liefert IHREN Inhalt

Nach der Kündigung (verwaist):
blog.beispiel.de.  CNAME  ihrefirma.eine-plattform.com.
                          -> der Name ist auf der Plattform frei

Die DNS-Auflösung funktioniert weiterhin. Der Record ist gültig, die Infrastruktur der Plattform antwortet. Es fehlt nur die Ressource hinter dem Namen. Lässt die Plattform beliebige Kunden den freigewordenen Namen registrieren, empfängt derjenige, der ihn zuerst beansprucht, den gesamten Traffic von blog.beispiel.de. Besucher sehen Ihre URL in der Adresszeile und dahinter eine funktionierende Seite. Genau das macht den Angriff für Phishing so wirksam: Nichts wirkt verdächtig.

Der CNAME ist der häufigste Vektor, weil er einen kompletten Hostnamen an einen Dritten delegiert. Ein A-Record, der auf eine zurückgegebene Cloud-IP zeigt, erzeugt aber dasselbe Problem. Wie sich diese Record-Typen verhalten, erklärt unser Leitfaden zu DNS-Record-Typen.

Typischerweise betroffene Dienste

Jede Plattform, die kundengewählte Namen auf Hostnamen abbildet, kann betroffen sein. Ist die Ressource hinter einem verwaisten Record verschwunden, liefert die Plattform meist eine wiedererkennbare Fehlermeldung. Nach diesen Signalen sucht man beim Audit:

Dienst	Signal einer verwaisten Ressource
GitHub Pages	„There isn't a GitHub Pages site here"
AWS S3	Fehlerseite „NoSuchBucket"
Heroku	Fehlerseite „No such app"
Azure (cloudapp, azurewebsites)	NXDOMAIN oder Azure-Standardfehler
Shopify	„Sorry, this shop is currently unavailable"
Vercel	404 mit „DEPLOYMENT_NOT_FOUND"

Viele Anbieter haben in den letzten Jahren nachgeschärft. GitHub Pages und andere verlangen inzwischen einen Nachweis der Domain-Inhaberschaft, bevor sich eine eigene Domain verknüpfen lässt. Das schließt den einfachen Weg. Das Zeitfenster ist damit kleiner geworden, aber nicht verschwunden: Ältere Plattformen, regionale Hoster und Dienste ohne Verifizierung bleiben beanspruchbar, und die Verifizierung nützt nichts, wenn Ihr verwaister Record auf einen Dienst zeigt, der sie nie eingeführt hat.

Die eigene Domain prüfen

Für einen ersten Durchgang brauchen Sie kein Spezialwerkzeug. Drei Schritte:

1. Exportieren Sie Ihre DNS-Zone bei Ihrem Provider (Cloudflare, Route 53, Ihr Registrar) und listen Sie jeden CNAME- und A-Record auf, der aus Ihrer eigenen Infrastruktur hinauszeigt.
2. Prüfen Sie für jeden Eintrag, ob die Zielressource noch antwortet und noch Ihnen gehört. Rufen Sie den Hostnamen im Browser auf und stellen Sie sicher, dass der Inhalt Ihrer ist und keine Plattform-Fehlerseite.
3. Löschen Sie jeden Record, dessen Zieldienst gekündigt oder migriert wurde oder den niemand mehr zuordnen kann.

Einen einzelnen Record prüfen Sie auf der Kommandozeile so:

dig CNAME shop.beispiel.de +short

Zeigt die Antwort auf eine SaaS-Plattform, laden Sie die Seite und lesen Sie die Antwort. Eine Plattform-Fehlermeldung wie in der Tabelle oben, auf einem Hostnamen, den Sie weiterhin im DNS veröffentlichen, ist genau das Signal, nach dem Gelegenheitsangreifer suchen. Behandeln Sie es als dringend: Record löschen oder Ressource noch am selben Tag zurückholen.

Dauerhaft vorbeugen

Die eigentliche Lösung ist prozessual, nicht technisch. Wenn Sie einen Dienst kündigen, löschen Sie den DNS-Record im selben Ticket, im selben Pull Request oder im selben Änderungsfenster. Eine Stilllegung ist erst abgeschlossen, wenn beide Seiten weg sind. Die meisten Takeovers gehen auf eine Kündigung zurück, bei der dieser Schritt vor Jahren übersprungen wurde.

Darüber hinaus lohnt sich ein lebendes Inventar: jede Subdomain, die auf einen externen Dienst zeigt, mit internem Verantwortlichen, regelmäßig durchgesehen. Ein Quartalsrhythmus reicht den meisten Teams. Unser Überblick, was DNS-Monitoring abdeckt, zeigt, wo Kontrollen auf Record-Ebene in diese Routine gehören.

Wenn Sie Domain Sentinel nutzen, können Sie im Feld Extra names des DNS-Monitorings bis zu zehn kritische Subdomains pro Domain anlegen, jede als eigener überwachter Hostname. Ihre CNAME- und A-Records werden täglich erfasst, und jede Änderung löst eine E-Mail-Warnung aus. Zehn sind nicht viel, nehmen Sie also die Subdomains, die auf einen externen Dienst zeigen. Das hält Ihr Inventar ehrlich: Ein Record, der sich ohne passendes Ticket ändert oder neu auftaucht, fällt auf. Zu den Grenzen gehört Klarheit: Das Werkzeug protokolliert, was Ihr DNS antwortet, es testet nicht, ob die Zielressource auf der Plattformseite noch existiert. Die Verteidigung ist das Löschen veralteter Records; das Monitoring ist das Sicherheitsnetz, das Abweichungen meldet.

Fangen Sie heute mit dem Export an: Zonendatei ziehen, Records mit externen Zielen auflisten, jeden prüfen, tote Einträge löschen. In fast jeder Zone, die älter als ein paar Jahre ist, steckt mindestens eine Überraschung. Und weil der verwaiste Record nur einer von mehreren Wegen ist, auf denen eine Subdomain fremde Inhalte ausliefert, lesen Sie auch unseren Artikel zur Erkennung von DNS-Hijacking, dem verwandten Angriff, bei dem die Zone selbst verändert wird.