Zmiany DNS jako wskaźniki incydentów
Podczas incydentu cybernetycznego zmiany w rekordach DNS mogą być zarówno przyczyną, jak i objawem. Zmieniony rekord MX może przekierować przychodzącą pocztę organizacji na serwer kontrolowany przez atakującego w ramach oszustwa BEC (Business Email Compromise). Zmieniony rekord NS lub A może być sygnałem, że konto rejestratora domeny zostało naruszone, a atakujący całkowicie przekierował domenę, czasami w celu serwowania złośliwego oprogramowania lub fałszywej strony logowania z kontrolowanej przez siebie infrastruktury. W innych przypadkach dowody DNS po prostu pomagają zrekonstruować, jaka infrastruktura była używana w momencie incydentu, bez tego, by sam DNS był wektorem ataku.
Tworzenie osi czasu DNS
Zbierz rekordy DNS tak wcześnie, jak to możliwe po podejrzeniu incydentu, ponieważ rekordy mogą zostać zmienione przez atakującego lub poprawione przez prawowitego administratora, zanim rozpocznie się pełne dochodzenie. Tam, gdzie to możliwe, porównaj je z wcześniejszą migawką zapisaną przez samą organizację, taką jak poprzedni wynik monitorowania lub kopia zapasowa konfiguracji, aby zidentyfikować, które konkretnie rekordy uległy zmianie i w przybliżeniu kiedy, używając wartości DNS TTL oraz wszelkich dostępnych dzienników zmian lub ścieżek audytu rejestratora jako dowodów potwierdzających czas.
Porównaj oś czasu DNS z innymi dowodami incydentu: nagłówkami e-maili pokazującymi, kiedy poczta zaczęła docierać na inny serwer, logami przejrzystości certyfikatów pokazującymi, kiedy wydano nowy certyfikat dla domeny, oraz logami serwera lub aplikacji pokazującymi, kiedy zmieniły się wzorce ruchu. Dowody DNS są najbardziej użyteczne, gdy potwierdzają lub kolidują z tymi innymi źródłami, zamiast występować samodzielnie.
Dowody na poziomie rejestratora i rejestru
Poza samymi rekordami DNS, dane rejestracyjne RDAP mogą pokazać, czy rejestrator, serwery nazw lub dane kontaktowe rejestrującego domeny zmieniły się w tym samym czasie, co wskazywałoby na kompromitację na poziomie konta u rejestratora, a nie problem ograniczony do pojedynczego pliku strefy DNS. Kody statusu, takie jak usunięcie clientTransferProhibited na krótko przed nieautoryzowanym transferem, to specyficzny wzorzec, który warto sprawdzić w danych rejestrowych.
Dokumentowanie dla reagowania i odzyskiwania
Rejestruj każdą obserwację DNS i RDAP wraz ze znacznikiem czasu i źródłem jako część rekordu incydentu, ponieważ te dowody często muszą być udostępniane rejestratorowi, dostawcy usług hostingowych, organom ścigania lub ubezpieczycielowi cybernetycznemu, z których każdy może zapytać o szczegóły dotyczące tego, co dokładnie się zmieniło i kiedy. Przywrócenie prawidłowych rekordów jest krokiem reagowania operacyjnego i powinno być dokumentowane oddzielnie od zbierania dowodów dotyczących tego, jakie były nieprawidłowe rekordy.
- Natychmiastowe przechwytywanie bieżących rekordów DNS i RDAP po podejrzeniu incydentu.
- Porównaj z każdą wcześniej zapisaną migawką, aby wyizolować, co się zmieniło.
- Porównanie z nagłówkami e-maili, wydaniami certyfikatów i logami serwera.
- Sprawdź kody statusu na poziomie rejestratora oraz zmiany danych kontaktowych, a nie tylko rekordy DNS.
- Oddzielić gromadzenie dowodów od działań naprawczych.