Zacznij od domeny, nie od strony
Infrastruktura phishingowa zazwyczaj obejmuje kilka warstw: domenę w linku, serwer hostujący stronę, system pocztowy, który dostarczył przynętę, a czasem drugą domenę używaną wyłącznie do zbierania danych uwierzytelniających. Przed zbadaniem zawartości strony, zbierz domenę rejestrowalną, jej rekord rejestracyjny RDAP, odpowiedzi DNS oraz wszelkie związane z nią certyfikaty. Zapewnia to stabilny punkt odniesienia, który nie zależy od tego, czy strona jest nadal online.
Rejestruj datę utworzenia, rejestratora, serwery nazw i bieżący status z RDAP. Domena zarejestrowana kilka dni przed rozpoczęciem kampanii, korzystająca z usługi prywatności i wskazująca na serwery nazw niezwiązane z jakąkolwiek legalną marką, jest powszechnym, ale nie uniwersalnym wzorcem. Traktuj każdą z tych informacji jako jeden punkt danych, a nie ostateczny dowód.
Kontekst hostingu i sieci
Rozwiąż nazwę hosta do jej rekordów A/AAAA i sprawdź właściciela sieci dla każdego adresu IP za pośrednictwem odpowiedniego Regionalnego Rejestru Internetowego (RIR) za pomocą RDAP. Zestawy phishingowe są często hostowane na skompromitowanych, legalnych serwerach, tanim hostingu masowym lub za siecią dostarczania treści (CDN), która ukrywa pochodzenie. Identyfikacja rzeczywistego właściciela sieci pozwala ustalić, który dział ds. nadużyć może realistycznie usunąć stronę.
Gdy strona znajduje się za CDN lub odwrotnym proxy, widoczny adres IP należy do tego dostawcy, a nie do operatora. Należy to wyraźnie zaznaczyć w raporcie, zamiast nazywać CDN hostem odpowiedzialnym za treść.
Certyfikaty i powiązane nazwy hostów
Dzienniki przejrzystości certyfikatów, przeszukiwalne za pośrednictwem usług takich jak crt.sh, rejestrują każdy publicznie zaufany certyfikat wydany dla danej nazwy. Przeszukiwanie domeny głównej i wspólnych prefiksów może ujawnić powiązane nazwy hostów, takie jak subdomeny login, secure, mail lub pay, które zostały przygotowane do tej samej kampanii, ale nie zostały jeszcze powiązane innymi środkami. Dziennik pokazuje również najwcześniejszą datę wydania, co może potwierdzić lub zaprzeczyć osi czasu rejestracji.
Wiele pozornie niepowiązanych domen, które mają ten sam wzorzec wydawania certyfikatów, tego samego rejestratora i tę samą datę rejestracji, jest użyteczną wskazówką do identyfikacji szerszej kampanii, ale sama wspólna infrastruktura nie ustanawia wspólnego właścicielstwa.
Dowody dostarczenia poczty e-mail
Jeśli przynęta phishingowa dotarła e-mailem, nagłówki wiadomości oraz konfiguracja MX, SPF i DMARC domeny stanowią odrębną linię dowodową. Domena ze skonfigurowanymi rekordami MX i liberalną lub brakującą polityką SPF/DMARC jest gotowa do wysyłania i odbierania poczty, co jest istotne, gdy kampania obejmuje inżynierię społeczną opartą na odpowiedzi, a nie tylko link.
Zachować oryginalny plik e-mail w niezmienionej formie. Wyniki uwierzytelniania należy odczytywać z własnej zaufanej infrastruktury odbiorczej, a nie przeliczać po fakcie, ponieważ rekordy DNS mogą ulec zmianie po incydencie.
Sporządzanie raportu
Przydatny raport infrastruktury phishingu rozdziela to, co zaobserwowano (odpowiedzi DNS, pola RDAP, wpisy certyfikatów, nagłówki e-maili) od tego, co jest wnioskowane (prawdopodobne powiązania kampanii, prawdopodobny zamiar). Każda obserwacja powinna zawierać swoje źródło i znacznik czasu UTC. Potwierdź zebrane dowody za pomocą hasha kryptograficznego, aby później można było wykazać, że pozostały niezmienione, a następnie przedłóż precyzyjne, poparte dowodami raporty o nadużyciach do rejestratora, hosta i wszelkich zaangażowanych CDN.
- Domena rejestrowalna, data utworzenia RDAP, rejestrator i status.
- DNS: A/AAAA, NS, MX, TXT, SOA ze znacznikami czasu kolekcji.
- Właściciel sieci IP dla każdego rozwiązanego adresu, z uwzględnieniem użycia CDN.
- Wyszukiwanie przejrzystości certyfikatów dla domeny i wspólnych subdomen.
- Postawa SPF/DMARC i, jeśli ma zastosowanie, zachowana oryginalna wiadomość e-mail.
- Zapieczętowany, hashowany raport przed złożeniem zawiadomień o nadużyciach.