DNS-wijzigingen als incidentindicatoren
Tijdens een cyberincident kunnen wijzigingen in DNS-records zowel een oorzaak als een symptoom zijn. Een gewijzigd MX-record kan inkomende e-mail van een organisatie omleiden naar een door een aanvaller beheerde server als onderdeel van zakelijke e-mailfraude. Een gewijzigd NS- of A-record kan een teken zijn dat een domeinregistraraccount is gecompromitteerd en de aanvaller het domein volledig heeft omgeleid, soms om malware of een nep-inlogpagina te hosten vanaf infrastructuur die zij beheren. In andere gevallen helpen DNS-gegevens eenvoudigweg te reconstrueren welke infrastructuur in gebruik was op het moment van het incident, zonder dat DNS zelf de aanvalsvector was.
Een DNS-tijdlijn opbouwen
Verzamel DNS-records zo vroeg mogelijk zodra een incident wordt vermoed, aangezien records kunnen worden teruggezet door een aanvaller of gecorrigeerd door de legitieme beheerder voordat een volledig onderzoek begint. Waar beschikbaar, vergelijk met een eerder opgeslagen momentopname die de organisatie zelf had opgeslagen, zoals een vorig monitoringresultaat of een configuratieback-up, om specifiek te identificeren welke records zijn gewijzigd en ongeveer wanneer, met behulp van DNS TTL-waarden en eventuele beschikbare changelog- of registrar-auditsporen als ondersteunend bewijs van timing.
Controleer de DNS-tijdlijn aan de hand van ander incidentbewijs: e-mailheaders die tonen wanneer e-mail begon aan te komen op een andere server, transparantielogs van certificaten die tonen wanneer een nieuw certificaat voor het domein werd uitgegeven, en server- of applicatielogs die tonen wanneer verkeerspatronen veranderden. DNS-bewijs is het meest nuttig wanneer het deze andere bronnen bevestigt, of ermee in conflict is, in plaats van op zichzelf te staan.
Registrar- en registry-niveau bewijs
Naast de DNS-records zelf kunnen RDAP-registratiegegevens aantonen of de registrar, naamservers of contactpersoon van de registrant van het domein rond dezelfde tijd zijn gewijzigd, wat zou wijzen op een compromittering op accountniveau bij de registrar in plaats van een probleem dat beperkt is tot één DNS-zonebestand. Statuscodes zoals clientTransferProhibited die kort voor een ongeautoriseerde overdracht worden verwijderd, is een specifiek patroon dat de moeite waard is om te controleren in registergegevens.
Documenteren voor respons en herstel
Registreer elke DNS- en RDAP-observatie met zijn tijdstempel en bron als onderdeel van het incidentrecord, aangezien dit bewijs vaak moet worden gedeeld met de registrar, de hostingprovider, de wetshandhaving of een cyberverzekeraar, die elk specifieke vragen kunnen stellen over precies wat er is veranderd en wanneer. Het herstellen van correcte records is een operationele responsstap en moet afzonderlijk worden gedocumenteerd van de bewijsvergaring van wat de incorrecte records waren.
- Leg huidige DNS- en RDAP-records onmiddellijk vast bij verdenking van een incident.
- Vergelijk met een eerder opgeslagen momentopname om te isoleren wat er is veranderd.
- Kruisverwijzing met e-mailheaders, certificaatuitgifte en serverlogs.
- Controleer de statuscodes op registrar-niveau en wijzigingen in contactgegevens, niet alleen DNS-records.
- Houd bewijsverzameling gescheiden van herstelmaatregelen.