DNS wird massiv unterschätzt

DNS als Schaltzentrale

Um zu verstehen, warum an DNS so viel hängt, lohnt sich ein Blick darauf, was es eigentlich tut. Das Internet ist dezentral aufgebaut, und damit Systeme trotzdem zuverlässig miteinander arbeiten können, übersetzt DNS technische IP-Adressen in sprechende Namen. Soweit kennen die meisten noch das „www" vor einer Adresse, aber danach hört das Verständnis oft auf, obwohl genau dahinter die interessanten und sicherheitsrelevanten Einträge liegen.

Denn DNS regelt nicht nur, unter welcher Adresse eine Website erreichbar ist. Es entscheidet auch, wohin E-Mails gehen, welche Server als vertrauenswürdig gelten und welche Dienste unter einer Domain überhaupt antworten. Damit ist es die Schaltzentrale, an der Erreichbarkeit und Vertrauen des eigenen Produkts zusammenlaufen, und genau deshalb ist es ein lohnendes Ziel.

Der Eintrag, an dem die E-Mail hängt

Ein gutes Beispiel dafür ist die Frage, wie E-Mails eigentlich ihren Weg zum Empfänger finden. Dafür gibt es im DNS die sogenannten MX-Records, kurz für Mail Exchange. Wenn ein Mailserver eine Nachricht an hero@foo.de zustellen will, fragt er zuerst den DNS, wer für die E-Mail von foo.de zuständig ist, und die Antwort liefert genau dieser MX-Record.

Damit ist der MX-Record die Weiche, die entscheidet, wo eingehende Post landet. Dass er öffentlich abfragbar ist, gehört zum Normalbetrieb und ist für sich genommen kein Problem. Zum Risiko wird er erst, weil er sich ändern lässt, sobald jemand Kontrolle über die Zone hat, und genau diese Änderbarkeit unterschätzen die meisten.

Ein Übernahme-Szenario, Schritt für Schritt

Damit die Gefahr greifbar wird, lohnt es sich, einen Angriff einmal durchzuspielen, so wie er in der Praxis tatsächlich abläuft. Am Anfang steht selten ein spektakulärer Hack, sondern ein gestohlener Zugang zum DNS-Provider, etwa weil die Anmeldung dort nur mit Passwort geschützt war oder weil ein Credential Stealer auf dem Rechner einer Person mit Produktionszugriff gelandet ist.

Mit diesem Zugang biegt der Angreifer den MX-Record der Domain auf seinen eigenen Server um, sodass ab diesem Moment alle eingehenden E-Mails zuerst bei ihm ankommen. Er muss den echten Mailserver also gar nicht anrühren, weil ihm die Weiche im DNS genügt, um sich zwischen Absender und Empfänger zu schieben.

Jetzt nutzt er aus, dass sich fast jeder Account im Internet über „Passwort vergessen" per E-Mail zurücksetzen lässt. Er stößt bei den SaaS-Diensten und Cloud-Plattformen des Unternehmens einen Reset an, fängt die Bestätigungsmail ab und übernimmt so einen Zugang nach dem anderen, ohne je ein einziges Passwort erraten zu haben.

Besonders perfide wird es dadurch, dass der Angreifer die restlichen Mails transparent an den echten Server weiterleiten kann. Die Reset-Mails behält er, alles andere wird ganz normal zugestellt, sodass im Alltag zunächst nichts auffällt und die Übernahme unbemerkt weiterläuft. Genau dieses Muster ist keine Theorie mehr, sondern wird beobachtet: Sicherheitsforscher haben 2025 Fälle beschrieben, in denen Angreifer gekaperte Domains bei SaaS-Anbietern verifizierten und über umgeleitete E-Mails die Passwort-Reset-Funktion privilegierter Konten missbrauchten.

Warum MFA hier nicht rettet

An dieser Stelle kommt oft der Einwand, dass man ja Multi-Faktor-Authentifizierung aktiviert habe. Das ist gut und wichtig, greift in diesem Szenario aber nur begrenzt, weil viele Passwort-Reset-Flows den zweiten Faktor gleich mit zurücksetzen oder umgehen, sobald die Kontrolle über das E-Mail-Postfach besteht.

Der Schutz liegt deshalb nicht allein beim einzelnen Login, sondern eine Ebene tiefer, nämlich in der Kontrolle über DNS und über die Zugänge, die daran hängen. Wer den MX-Record umbiegen kann, hebelt einen Teil der Anmeldesicherheit aus, bevor MFA überhaupt zum Zug kommt.

Warum das Risiko gerade jetzt wächst

Wer das alles für ein Randthema hält, unterschätzt, wie stark sich die Bedrohungslage zuletzt verschoben hat. Angriffe über die Software-Lieferkette und kompromittierte Open-Source-Bibliotheken haben massiv zugenommen, und mehrere unabhängige Auswertungen für 2025 zeigen Zuwächse bösartiger Pakete im dreistelligen Prozentbereich, angetrieben von automatisiert gestohlenen Zugangsdaten und Tokens.

Der Grund dahinter ist unangenehm einfach, denn ein gestohlener Token oder ein abgegriffenes Passwort ist heute oft leichter zu bekommen, als ein System direkt anzugreifen. Wie schnell aus einer harmlos wirkenden Abhängigkeit ein Einfallstor wird, beschreiben wir ausführlicher im Artikel Warum „wir scannen nach dem Git Commit" nicht reicht. Für DNS bedeutet das: Die Zugänge zur Zone sind ein ebenso lohnendes Ziel wie der Code selbst.

Der vergessene Eintrag: Dangling MX

Ein Sonderfall verdient eigene Aufmerksamkeit, weil er so leicht übersehen wird. Wenn eine Domain nicht mehr aktiv für E-Mail genutzt wird, der MX-Record aber weiter auf einen Dienst zeigt, der gar nicht mehr betrieben oder nie sauber eingerichtet wurde, entsteht ein sogenannter Dangling-MX-Record. Ein solcher hängender Eintrag lässt sich unter Umständen von Dritten übernehmen, sodass eine eigentlich stillgelegte Domain plötzlich wieder für glaubwürdige Angriffe taugt.

Gerade wer über die Jahre mehrere Domains angesammelt hat, trägt oft eine Handvoll solcher Altlasten mit sich, ohne es zu wissen. Deshalb gehört nicht nur die aktiv genutzte Zone auf den Prüfstand, sondern auch jede Domain, die man einmal registriert und dann aus dem Blick verloren hat.

Was konkret zu tun ist

Der erste Schritt ist ein Inventar, das ehrlich beantwortet, welche Domains überhaupt existieren, wo sie gehostet werden und wer Zugriff darauf hat. In der Praxis sind es fast immer deutlich mehr Domains und DNS-Zonen als gedacht, und schon dieses Aufräumen bringt Klarheit.

Auf dieser Grundlage lohnt es sich, die DNS-Einträge regelmäßig zu kontrollieren, insbesondere die MX-Records, damit eine unerwünschte Änderung nicht monatelang unbemerkt bleibt. Parallel sollten die Rechte minimiert werden, denn niemand braucht standardmäßig Full-Admin in der Produktion, und die Umgebungen für Entwicklung, Staging und Produktion gehören sauber getrennt, auch wenn gerade kleinere Teams hier gern an der falschen Stelle sparen, bis es teuer wird.

Den größten Unterschied macht am Ende ein Monitoring, das automatisch alarmiert, sobald sich ein kritischer DNS-Eintrag verändert. Denn eine manipulierte Weiche fällt selten von allein auf, während eine Benachrichtigung im richtigen Moment den Unterschied zwischen einem abgewehrten und einem geglückten Angriff ausmacht.

Wo die Wirkung entsteht

DNS wirkt unscheinbar, aber wenn jemand die Kontrolle darüber übernimmt, kontrolliert er oft den Rest gleich mit, bis hin zu Zugängen zu SaaS-Diensten, Cloud-Plattformen und extern eingekauften Systemen, die sich alle über E-Mail-Accounts zurücksetzen lassen. Genau deshalb ist DNS kein reines Technik-Thema, sondern eine Frage, wie belastbar der Betrieb des eigenen Produkts wirklich ist.

Der wiederkehrende Kern ist dabei die Lücke zwischen dem dokumentierten und dem tatsächlichen Zustand, und genau an dieser Lücke setzt unser Produkt Driftguard an, das sichtbar macht, wenn der reale Zustand einer Cloud von dem abweicht, was auf dem Papier steht. Ein umgebogener MX-Record ist genau so eine Abweichung, die nicht wegdriften darf, ohne dass es jemand merkt.

Wenn du deine aktuelle Sicherheitslage einmal ehrlich einordnen möchtest, schauen wir gemeinsam drauf, pragmatisch und ohne Buzzword-Bingo. Meistens lassen sich solche Lücken leichtgewichtig schließen, indem man einen internen Prozess anpasst oder eine kleine technische Änderung vornimmt, statt ein großes Projekt daraus zu machen.