DNS-Änderungen als Vorfallsindikatoren
Während eines Cyber-Vorfalls können Änderungen an DNS-Einträgen sowohl Ursache als auch Symptom sein. Ein geänderter MX-Eintrag kann die eingehende E-Mail einer Organisation auf einen vom Angreifer kontrollierten Server umleiten, als Teil einer Business Email Compromise (BEC). Ein geänderter NS- oder A-Eintrag kann ein Zeichen dafür sein, dass ein Domain-Registrar-Konto kompromittiert wurde und der Angreifer die Domain vollständig umgeleitet hat, manchmal um Malware oder eine gefälschte Anmeldeseite von der von ihm kontrollierten Infrastruktur aus zu bedienen. In anderen Fällen helfen DNS-Beweise einfach, die Infrastruktur zu rekonstruieren, die zum Zeitpunkt des Vorfalls verwendet wurde, ohne dass DNS selbst der Angriffsvektor war.
Erstellung einer DNS-Zeittafel
Sammeln Sie DNS-Einträge so früh wie möglich, sobald ein Vorfall vermutet wird, da Einträge von einem Angreifer zurückgeändert oder vom legitimen Administrator korrigiert werden können, bevor eine vollständige Untersuchung beginnt. Vergleichen Sie, falls verfügbar, mit einem früheren Schnappschuss, den die Organisation selbst gespeichert hatte, z.B. einem früheren Überwachungsergebnis oder einem Konfigurations-Backup, um spezifisch zu identifizieren, welche Einträge sich geändert haben und ungefähr wann, wobei DNS TTL-Werte und alle verfügbaren Änderungs- oder Registrar-Audit-Protokolle als unterstützende Beweismittel für den Zeitpunkt dienen.
Gleichen Sie die DNS-Zeitleiste mit anderen Beweismitteln des Vorfalls ab: E-Mail-Header, die zeigen, wann E-Mails auf einem anderen Server ankamen, Zertifikattransparenz-Protokolle, die zeigen, wann ein neues Zertifikat für die Domain ausgestellt wurde, und Server- oder Anwendungsprotokolle, die zeigen, wann sich Verkehrsmuster änderten. DNS-Beweismittel sind am nützlichsten, wenn sie diese anderen Quellen bestätigen oder ihnen widersprechen, anstatt für sich allein zu stehen.
Beweismittel auf Registrar- und Registerebene
Über die DNS-Einträge selbst hinaus können RDAP-Registrierungsdaten zeigen, ob sich der Registrator, die Nameserver oder der Registranten-Kontakt der Domain etwa zur gleichen Zeit geändert haben, was eher auf einen Account-Kompromiss beim Registrator als auf ein Problem, das auf eine einzelne DNS-Zone beschränkt ist, hindeuten würde. Statuscodes wie clientTransferProhibited, die kurz vor einer unautorisierten Übertragung entfernt werden, sind ein spezifisches Muster, das in Registrierungsdaten überprüft werden sollte.
Dokumentation für Reaktion und Wiederherstellung
Jede DNS- und RDAP-Beobachtung mit Zeitstempel und Quelle als Teil des Vorfallsberichts dokumentieren, da diese Beweismittel oft an den Registrar, den Hosting-Anbieter, die Strafverfolgungsbehörden oder einen Cyberversicherungsanbieter weitergegeben werden müssen, die jeweils spezifische Informationen über genaue Änderungen und Zeitpunkte anfordern können. Die Wiederherstellung korrekter Einträge ist ein operativer Reaktionsschritt und sollte getrennt von der Beweismittelsammlung der falschen Einträge dokumentiert werden.
- Erfassen Sie sofort aktuelle DNS- und RDAP-Einträge bei Verdacht auf einen Vorfall.
- Vergleichen Sie mit einem zuvor gespeicherten Schnappschuss, um zu isolieren, was sich geändert hat.
- Gegenprüfung mit E-Mail-Headern, Zertifikatsausstellung und Serverprotokollen.
- Überprüfen Sie Statuscodes auf Registrare bene und Kontaktänderungen, nicht nur DNS-Einträge.
- Trennen Sie die Beweismittelsammlung von den Sanierungsmaßnahmen.