„Meine Website wurde gehackt.„

Diesen Satz hören Web- und Digitalagenturen vermutlich nicht besonders gerne. Gleichzeitig gehört der Umgang mit solchen Situationen zum professionellen Kundenservice.

Das Problem: Die Aussage des Kunden ist zunächst keine technische Diagnose. Eine fremde Website, eine Weiterleitung auf eine unbekannte Seite oder plötzlich ausbleibende E-Mails können ganz unterschiedliche Ursachen haben.

Vielleicht wurde tatsächlich das CMS kompromittiert. Oder es wurden Dateien auf dem Webserver verändert. Vielleicht wurde aber auch die DNS-Konfiguration manipuliert. Und wenn Website und E-Mail gleichzeitig betroffen sind, muss die Ursache nicht zwangsläufig auf dem Webserver liegen.

Gerade Agenturen, die neben Websites auch die E-Mail-Systeme ihrer Kunden betreuen, sollten deshalb wissen, wie sich die einzelnen Ebenen voneinander unterscheiden lassen.

Denn eine wichtige Grundregel lautet: Das sichtbare Problem ist nicht automatisch die kompromittierte Ebene.

Welche Ebene ist überhaupt betroffen?

Wenn ein Kunde von einem Hack berichtet, lohnt sich zunächst ein Blick auf die verschiedenen technischen Ebenen.

• Die Website ist die eigentliche Webanwendung, beispielsweise eine WordPress-Installation mit Dateien, Datenbank, Themes und Plugins.
• Das Hosting stellt die technische Umgebung bereit, auf der diese Website betrieben wird.
• Die Domain ist der registrierte Name, über den die Website und andere Dienste erreichbar sind.
• Das DNS sorgt dafür, dass zu einem Namen die passenden technischen Informationen gefunden werden. Dazu gehören beispielsweise A-, AAAA-, MX-, CNAME- oder TXT-Records.
• Die Nameserver sind die autoritativen DNS-Server, die für eine Domain zuständig sind und die entsprechende DNS-Zone bereitstellen.
• Und die E-Mail ist ein eigener Dienst mit Mailservern, Postfächern und weiteren Komponenten. Welcher Mailserver für eingehende Nachrichten zuständig ist, wird unter anderem über MX-Records im DNS festgelegt.

Diese Bereiche hängen eng zusammen, sind technisch aber nicht dasselbe.

Genau diese Unterscheidung hilft einer Agentur dabei, einen Sicherheitsvorfall systematisch einzugrenzen.

Eine fremde Website bedeutet nicht automatisch einen gehackten Webserver

Nehmen wir einen typischen Fall – Ein Kunde ruft an und sagt:

„Wenn ich meine Domain aufrufe, erscheint eine fremde Website.“

Die erste Vermutung liegt nahe: Der Webserver wurde gehackt. Das ist möglich. Es ist aber nicht die einzige Erklärung.

Bevor die Agentur beispielsweise WordPress-Dateien untersucht oder ein Backup einspielt, sollte zunächst geprüft werden, wohin die Domain aktuell zeigt.

Angenommen, die Website befindet sich normalerweise auf einer bestimmten IP-Adresse. Wenn der A-Record inzwischen auf eine andere IP-Adresse zeigt, kann der Besucher dort eine völlig andere Website sehen.

Der ursprüngliche Webserver muss in diesem Fall nicht kompromittiert worden sein. Eine unbefugte DNS-Änderung kann also ein Erscheinungsbild erzeugen, das für den Kunden wie ein klassischer Website-Hack aussieht. ICANN beschreibt unautorisierte Änderungen an DNS-Konfigurationen als relevantes Sicherheitsrisiko, da dadurch beispielsweise der Datenverkehr einer Domain auf andere Systeme gelenkt werden kann.

Für die Agentur ist deshalb eine einfache Frage besonders hilfreich:

Welche DNS-Antwort bekommt ein Besucher aktuell?

DNS und Nameserver sind nicht dasselbe

Gerade im Kundenkontakt werden DNS und Nameserver häufig synonym verwendet. Für die technische Fehlersuche sollte man sie jedoch auseinanderhalten.

Die Nameserver sind die autoritativen DNS-Server, die für eine Domain zuständig sind.

In der dort bereitgestellten DNS-Zone befinden sich die einzelnen DNS-Records.

Vereinfacht kann eine DNS-Zone beispielsweise so aussehen:

example.de       A        203.0.113.10
example.de       MX       mail.example.net
www.example.de   CNAME    example.de

Für die Domain können wiederum beispielsweise diese Nameserver delegiert sein:

example.de       NS       ns1.provider.example
example.de       NS       ns2.provider.example

Wird ein A-Record verändert, kann sich das Ziel der Website ändern.

Werden die Nameserver selbst verändert, wird dagegen die Zuständigkeit für die DNS-Auflösung der Domain auf andere autoritative DNS-Server verlagert.

Das sind zwei unterschiedliche Vorgänge.

Für eine Agentur ist deshalb wichtig zu wissen, wo die DNS-Zone eines Kunden verwaltet wird. Das muss nicht zwangsläufig beim Hoster der Website sein. DNS kann beispielsweise beim Registrar, einem Hosting-Anbieter oder einem spezialisierten DNS-Dienst liegen.

Wenn die Agentur dort keine Verwaltungsrechte besitzt, sollte sie auch nicht davon ausgehen, Änderungen selbst vornehmen zu können.

E-Mail: DNS-Probleme sind nicht dasselbe wie ein gehacktes Postfach

Für Agenturen, die E-Mail-Systeme ihrer Kunden betreuen, ist die Abgrenzung besonders wichtig.

Ein Kunde kann beispielsweise melden: „Seit dem Vorfall kommen keine E-Mails mehr an.“

Auch hier sollte man nicht automatisch davon ausgehen, dass ein Postfach kompromittiert wurde. Zunächst kann geprüft werden, ob die DNS-Konfiguration für die E-Mail noch korrekt ist.

Der MX-Record legt fest, welche Mailserver für die Zustellung von E-Mails an eine Domain zuständig sind. Wird dieser Eintrag unbefugt verändert, kann sich dadurch das Mailrouting verändern.

Das bedeutet allerdings nicht automatisch, dass ein Angreifer Zugriff auf ein Postfach erhalten hat.

Ein manipulierter MX-Record und ein kompromittiertes E-Mail-Konto sind zwei unterschiedliche Sachverhalte.

Bei einem kompromittierten Postfach muss dagegen der Zugang zum Mailkonto selbst betrachtet werden. Je nach verwendetem Maildienst sollten unter anderem Passwort, aktive Sitzungen, Weiterleitungen, Filterregeln und (sofern vorhanden) zusätzliche Authentifizierungsmechanismen geprüft werden.

Gerade Weiterleitungen sind einen Blick wert: Ein Angreifer kann unter Umständen Regeln einrichten, durch die bestimmte Nachrichten zusätzlich an eine fremde Adresse weitergeleitet werden. Das Postfach kann dabei auf den ersten Blick weiterhin völlig normal funktionieren.

Wenn Website und E-Mail gleichzeitig betroffen sind

Besonders interessant wird ein Sicherheitsvorfall, wenn mehrere Dienste gleichzeitig Probleme machen.

Ein Kunde meldet beispielsweise: „Die Website zeigt eine fremde Seite und seit gestern kommen auch keine E-Mails mehr.“

Hier sollte die Agentur nicht sofort von zwei unabhängigen Problemen ausgehen. Eine gemeinsame Ursache ist möglich.

Wenn beispielsweise die DNS-Konfiguration verändert wurde, können sowohl Website als auch E-Mail betroffen sein. Ein veränderter A-Record kann das Ziel der Website beeinflussen, während ein manipulierter MX-Record das Mailrouting verändert.

Das bedeutet allerdings nicht automatisch, dass tatsächlich ein Angriff vorliegt. DNS-Einträge können auch aufgrund eines geplanten Umzugs, eines Providerwechsels oder einer anderen autorisierten Änderung anders aussehen als zuvor.

Deshalb sollte eine Agentur vor dem Zurücksetzen einer auffälligen Konfiguration möglichst klären:

Wer hat die Änderung vorgenommen, wann wurde sie vorgenommen und war sie autorisiert?

Gerade bei DNS kann ein gut gemeintes Zurücksetzen sonst einen legitimen Systemwechsel unterbrechen.

Was sollte eine Agentur bei einem Sicherheitsvorfall prüfen?

Der erste Schritt sollte immer darin bestehen, das konkrete Fehlerbild möglichst genau festzuhalten.

Seit wann besteht das Problem? Was sieht der Kunde genau? Ist nur die Startseite betroffen oder die gesamte Website? Funktioniert das Backend noch? Sind E-Mails betroffen? Gibt es unbekannte Benutzer oder auffällige Weiterleitungen?

Danach kann die Agentur die Systeme untersuchen, auf die sie tatsächlich Zugriff hat.

Bei einer Website können beispielsweise CMS- und Webserver-Logs, Login-Aktivitäten, Dateien und Datenbankinhalte relevante Hinweise liefern. Bei E-Mail können, abhängig vom eingesetzten System, Login-Aktivitäten, Weiterleitungen, Filterregeln und andere Kontoeinstellungen relevant sein.

Parallel sollte geprüft werden, ob sich die DNS-Konfiguration gegenüber dem bekannten Normalzustand verändert hat.

Besonders interessant sind dabei beispielsweise:

• A- und AAAA-Records
• MX-Records
• CNAME-Records
• TXT-Records
• die delegierten Nameserver

Dabei geht es zunächst nicht darum, jede Abweichung als Angriff zu bewerten. Es geht darum, Abweichungen zu erkennen und ihre Ursache zu klären.

Erst dokumentieren, dann bereinigen

Wenn eine Website tatsächlich kompromittiert wurde, ist der Wunsch verständlich, möglichst schnell wieder einen sauberen Zustand herzustellen. Trotzdem sollte eine Agentur nicht unüberlegt Dateien löschen, Logs überschreiben oder die komplette Umgebung verändern. Denn genau diese Informationen können später dabei helfen, herauszufinden, was passiert ist.

Sinnvoll kann es deshalb sein, relevante Informationen wie Zeitpunkte, Logs, verdächtige Dateien, aktuelle DNS-Einstellungen und bereits vorgenommene Änderungen zu dokumentieren. CISA empfiehlt bei Cybersecurity-Vorfällen ebenfalls, relevante Logs und andere Beweismittel zu sichern und nicht unnötig zu verändern oder zu löschen.

Das bedeutet nicht, dass jede Agentur bei jedem Vorfall eine forensische Untersuchung durchführen muss.

Es bedeutet vielmehr: Vor einer Bereinigung sollte man überlegen, welche Informationen dadurch verloren gehen könnten.

Bei schwerwiegenden oder wiederkehrenden Vorfällen kann es sinnvoll sein, spezialisierte Incident-Response- oder Forensik-Unterstützung hinzuzuziehen.

Wenn die Website selbst kompromittiert wurde

Natürlich kann die Ursache tatsächlich auf der Website liegen. Bei einem CMS wie WordPress kommen beispielsweise verwundbare Plugins oder Themes, veraltete Software, gestohlene Zugangsdaten oder kompromittierte Benutzerkonten als mögliche Ursachen infrage. Hinweise können unter anderem manipulierte Inhalte, unbekannte Benutzer, unerwartete Weiterleitungen oder veränderte Dateien sein.

Entscheidend ist aber auch hier die Frage nach der Ursache.

Eine Website aus einem Backup wiederherzustellen, kann den sichtbaren Schaden beseitigen. Wenn die ursprüngliche Schwachstelle weiterhin besteht oder Zugangsdaten kompromittiert wurden, kann das Problem jedoch erneut auftreten. Deshalb sollte eine Wiederherstellung nicht automatisch mit einer vollständigen Sicherheitsprüfung gleichgesetzt werden.

Die Agentur sollte sich fragen:

Was wurde verändert und wie konnte es verändert werden?

Domain- und DNS-Zugänge gehören ebenfalls zur Sicherheitsbetrachtung

Eine Agentur hat nicht zwangsläufig Zugriff auf die Domainverwaltung oder den DNS-Anbieter eines Kunden. Das ist auch nicht erforderlich.

Wichtig ist aber, dass klar ist, wer diese Bereiche verwaltet.

Wenn die Agentur feststellt, dass eine Domain plötzlich auf eine unbekannte IP-Adresse zeigt, muss sie wissen, wer die entsprechende DNS-Zone kontrolliert. Wenn die Nameserver selbst verändert wurden, muss geklärt werden, wer Zugriff auf die Domainverwaltung hat. Welche Änderungen dort möglich sind, hängt vom jeweiligen Registrar, der TLD und den eingesetzten Sicherheitsmechanismen ab.

Bei einem Verdacht auf einen kompromittierten Verwaltungszugang sollte der zuständige Anbieter beziehungsweise Registrar eingebunden werden. Gleichzeitig sollten betroffene Zugangsdaten abgesichert und (sofern verfügbar) zusätzliche Authentifizierungsmaßnahmen aktiviert werden.

Anschließend sollte nachvollzogen werden, welche Änderungen vorgenommen wurden.

Wenn mehrere Domains oder Dienste über denselben Account verwaltet werden, sollte außerdem geprüft werden, ob weitere Systeme betroffen sein könnten.

Domain Security beginnt bei sicheren Zugängen

Domain Security besteht nicht nur aus DNSSEC und korrekten DNS-Einträgen. Auch die Zugänge zu CMS, Hosting, Domainverwaltung, DNS und E-Mail sind Teil der Sicherheitskette.

Wo ein Dienst es unterstützt, sollte Multi-Faktor-Authentifizierung aktiviert werden. Passwörter sollten nicht für mehrere Dienste wiederverwendet werden und administrative Zugänge sollten nur den Personen zur Verfügung stehen, die sie tatsächlich benötigen. Auch alte Zugänge sollten regelmäßig überprüft und deaktiviert werden.

Gerade Agenturen arbeiten häufig mit mehreren Mitarbeitern, Freelancern und externen Dienstleistern. Ein längst nicht mehr benötigter Administrationszugang kann dabei zu einem unnötigen Sicherheitsrisiko werden.

Eine gute Sicherheitsstrategie bedeutet deshalb auch, regelmäßig zu wissen:

Wer kann eigentlich was verwalten?

DNSSEC richtig einordnen

Spricht man von DNSSEC spricht man von einer wichtigen Sicherheitsmaßnahme für DNS. Diese wird aber häufig überschätzt.

Es steht für Domain Name System Security Extensions. Damit können DNS-Daten kryptografisch signiert werden. Ein validierender Resolver kann dadurch überprüfen, ob die signierten DNS-Daten authentisch sind und nicht unbemerkt verändert wurden.

DNSSEC schützt jedoch weder das WordPress-Backend noch ein E-Mail-Postfach.

Auch ein kompromittierter Registrar-, Hosting- oder DNS-Account wird durch DNSSEC nicht automatisch verhindert.

Wenn ein Angreifer gültige Zugangsdaten für einen Verwaltungsdienst besitzt und darüber eine autorisierte Änderung vornimmt, ist das ein anderer Angriffspfad.

Für Agenturen bedeutet das:

DNSSEC ist eine sinnvolle Schutzschicht, ersetzt aber keine sicheren Zugänge und keine saubere Administration.

Zuständigkeiten sollten vor dem Ernstfall geklärt sein

Eine der einfachsten Maßnahmen für Agenturen ist gleichzeitig eine der wichtigsten: Dokumentieren, wer wofür verantwortlich ist.

Für jeden Kunden sollte möglichst klar sein:

• Wer verwaltet die Domain?
• Wo wird DNS verwaltet?
• Wo wird die Website gehostet?
• Wer administriert das CMS?
• Wer betreut die E-Mail?
• Welche Mailserver sind vorgesehen?
• Und wer darf Änderungen vornehmen?

Das ist besonders wichtig, wenn eine Agentur Website und E-Mail betreut, die Domain aber beispielsweise beim Kunden selbst oder einem externen IT-Dienstleister liegt.

Im Sicherheitsvorfall sollte nicht erst recherchiert werden müssen, bei welchem Anbieter die DNS-Zone liegt oder wer Zugriff auf den Registrar-Account hat. Eine einfache Dokumentation des technischen Normalzustands kann ebenfalls sehr hilfreich sein.

Wenn bekannt ist, welche Nameserver, IP-Adressen und MX-Records normalerweise verwendet werden, lassen sich unerwartete Änderungen wesentlich schneller erkennen.

Ein Praxisbeispiel aus dem Agenturalltag

Ein Kunde meldet am Montagmorgen:

„Unsere Website zeigt eine fremde Seite und seit gestern kommen keine E-Mails mehr an.“

Die Agentur prüft zunächst das Fehlerbild.

Die Domain ist erreichbar, aber die Website sieht anders aus als erwartet. Gleichzeitig funktioniert die E-Mail-Zustellung nicht.

Statt sofort die WordPress-Installation neu aufzusetzen, wird zunächst die DNS-Konfiguration geprüft.

Dabei fällt auf: Der A-Record zeigt auf eine unbekannte IP-Adresse. Auch der MX-Record entspricht nicht mehr der dokumentierten Konfiguration.

Damit gibt es einen konkreten Hinweis darauf, dass nicht zwingend die Website selbst kompromittiert wurde.

Die Agentur dokumentiert den aktuellen Zustand und klärt, wer die DNS-Zone verwaltet.

Parallel kann sie den eigentlichen Webserver untersuchen. Wenn sich dort keine entsprechenden Manipulationen finden, spricht das zusätzlich dafür, dass die Ursache außerhalb des Webservers liegen könnte.

Erst jetzt wird die zuständige Stelle für Domain oder DNS eingebunden und die weitere Vorgehensweise abgestimmt.

Das Beispiel zeigt, warum eine saubere technische Abgrenzung so wichtig ist.

Ohne diese Prüfung hätte die Agentur möglicherweise lange an der Website gearbeitet, obwohl die eigentliche Ursache in der DNS-Konfiguration lag.

Fazit: Nicht nur die Website betrachten

Wenn ein Kunde sagt: „Meine Website wurde gehackt„, ist das für eine Agentur der Beginn der Analyse und nicht das Ergebnis.

Eine professionelle Domain-Security-Strategie bedeutet, Website, Hosting, Domain, DNS, Nameserver und E-Mail voneinander unterscheiden zu können.

Gerade für Agenturen, die zusätzlich die E-Mail-Systeme ihrer Kunden betreuen, ist diese Trennung wichtig. Eine DNS-Manipulation kann beispielsweise Website und Mailrouting gleichzeitig beeinflussen, ohne dass die Website oder ein Postfach selbst kompromittiert sein müssen.

Umgekehrt kann eine kompromittierte WordPress-Installation völlig unabhängig von Domain und DNS sein.

Die wichtigste Frage lautet deshalb nicht:

„Wurde die Website gehackt?„

Sondern:

„Welche technische Ebene ist tatsächlich betroffen?„

Wer diese Frage systematisch beantwortet, kann Sicherheitsvorfälle schneller eingrenzen, Kunden besser informieren und unnötige Änderungen vermeiden.

Domain Security bedeutet dabei nicht, jede technische Ebene selbst zu verwalten. Es bedeutet, die Zusammenhänge zu verstehen, Zuständigkeiten zu kennen und im Ernstfall zu wissen, wo man hinschauen muss.