Określ, czego dotyczy wiadomość
Wiadomość może imitować firmę na kilka różnych sposobów. Może umieścić dokładną domenę firmy w widocznym adresie Od, użyć wyświetlanej nazwy znanej osoby z niepowiązanym adresem lub wysłać z innej domeny wybranej tak, aby przypominała firmę. To nie są mechanizmy wymienne. Wymagają różnych dowodów i ujawniają różne granice kontroli. Wywoływanie wszystkich trzech przypadków a DMARC awaria zachęca do nieprawidłowej naprawy i może ukryć incydent wymagający weryfikacji biznesowej, a nie edycji DNS .
RFC 9989 zakresy DMARC do RFC5322 domena i dopasowane uwierzytelnianie. Wyraźnie wyklucza ataki wykorzystujące nazwy wyświetlane, analizę treści i uwierzytelnianie podmiotów innych niż domeny. Odbiorca może nadal stosować dodatkowe zabezpieczenia, ale zabezpieczeń tych nie należy przypisywać samemu DMARC . W tym artykule przedstawiono metodę klasyfikacji na potrzeby segregacji obronnej, bez rzeczywistej kontroli wiadomości ani zarzutów dotyczących wskazanego nadawcy.
Dokładne użycie domeny wymaga dokładnego porównania
Zacznij od rzeczywistej domeny w analizowanym adresie Od, a nie od tekstu wyświetlanego przez aplikację pocztową. Porównaj ją z domeną biznesową odpowiednią dla żądania. Zachowaj dokładną pisownię i źródło dowodów w zastrzeżonym rejestrze dochodzenia. Jeśli domeny są identyczne, kolejnym pytaniem jest, czy dowód zaufanego odbiorcy wskazuje na wyrównane uwierzytelnienie, awarię, brak zasad lub nieokreślony wynik. Sam dokładny wygląd domeny nie mówi, co się wydarzyło.
Nieautoryzowany nadawca korzystający z dokładnej domeny może się nie powieść wyrównanie, ale zainfekowane autoryzowane konto lub usługa może generować dopasowaną pocztę. Ta sama widoczna domena może zatem występować w bardzo różnych zdarzeniach. Przepustka DMARC nie dowodzi, że wiadomość została zatwierdzona przez osobę, a awaria sama w sobie nie dowodzi złośliwych zamiarów. Przekazywanie, błędy konfiguracyjne i niekompletne dowody mogą skomplikować interpretację. Przed przypisaniem przyczyny określ wąski, zaobserwowany fakt.
Nazwy wyświetlane stanowią osobną powierzchnię tożsamości
RFC 5322, sekcja 3.4, odróżnia opcjonalną nazwę wyświetlaną skrzynki pocztowej od jej adresu. Nazwa wyświetlana może identyfikować osobę lub rolę dla czytelnika, ale nie jest to domena oceniana przez DMARC . Na przykład fikcyjna wiadomość może wyświetlać „Zespół ds. kont”, a jej adres należy do niepowiązanej przykładowej domeny. Znana etykieta nie jest dowodem własności organizacji.
Widok na małym ekranie lub widok zwinięty może na pierwszy rzut oka nie ujawniać wszystkich pól tożsamości. Działanie obronne polega na sprawdzeniu pełnego adresu przy użyciu zaufanego interfejsu aplikacji odbierającej, a następnie niezależnej ocenie żądania biznesowego. Nie wymyślaj uniwersalnej zasady interfejsu użytkownika ani nie obiecuj, że każdy klient zwróci uwagę na niezgodność. W standardzie rozróżnienie między etykietą a adresem jest stabilne; prezentacja i ostrzeżenia ochronne zależą od klienta i odbiorcy.
Domeny Lookalike mogą zostać pomyślnie uwierzytelnione
Inna domena może być wizualnie podobna do domeny zaufanej ze względu na pisownię, interpunkcję lub wybrane znaki. Jeśli operator w sposób zgodny z prawem kontroluje konfigurację wysyłania, poczta z tej domeny może zostać przekazana SPF, DKIM i DMARC dla tej domeny. Uwierzytelnianie nie musi koniecznie działać nieprawidłowo. Uznanie przez odbiorcę zamierzonej organizacji nie powiodło się lub zostało zmanipulowane na innym poziomie.
Porównaj rzeczywistą domenę z zaufaną dokumentacją biznesową uzyskaną poza wątpliwą wiadomością. Nie odwiedzaj podanej witryny internetowej ani nie odpowiadaj na wątpliwy adres jedynie w celu ustalenia własności. Znajome słowo marki osadzone w dłuższej nazwie nie wystarczy. Zachowaj ostrożność w interpretacji nazw międzynarodowych i zasięgnij fachowej analizy, jeśli formularze wyświetlane i formularze podstawowe różnią się; ta wersja robocza nie zapewnia pełnego algorytmu klasyfikacji Unicode ani publicznych sufiksów.
Użyj zaufanych dowodów uwierzytelniających
Jakiś Authentication-Results pole jest przydatne tylko w granicach zaufania odbiorcy. RFC 8601 wyjaśnia, dlaczego konsumenci muszą odróżniać potwierdzenia zaufanego uwierzytelnienia od dowolnych pól zawartych w wiadomości. Skopiowanie linii z informacją o przekazaniu wiadomości lub zrzutu ekranu nie oznacza, że został on wyprodukowany przez odpowiedniego odbiorcę. Zapisz, który odbiorca ocenił wiadomość i w jaki sposób badacz uzyskał wynik.
Zachowaj widoczność domeny Z, nadawca kopertowy domena, domena podpisująca DKIM i tożsamość Reply-To są odrębne. Różnice między nimi mogą mieć uzasadnione wyjaśnienia i nie powinny być automatycznie uznawane za stwierdzenie oszustwa. W przypadku DMARC zidentyfikuj wyrównaną ścieżkę uwierzytelniania, zamiast traktować każde przejście SPF lub DKIM jako wystarczające. W przypadku wniosku biznesowego sprawdź żądane działanie i uprawnienia osoby, która rzekomo je wykonuje.
Arkusz porównania tożsamości
Przygotuj wiersz zawierający zaufaną domenę biznesową, widoczną etykietę wyświetlaną, przeanalizowany adres nadawcy, adres zwrotny, jeśli istnieje, domeny uwierzytelnione, wynik odbiorcy, pochodzenie dowodu i proponowaną klasyfikację. Dodaj kolumny dla tego, co pozostaje nieznane i który niezależny kanał może zweryfikować żądanie. Zminimalizuj identyfikatory osobiste w dowolnej udostępnionej wersji, zachowując jednocześnie to, czy dwie domeny są identyczne, czy różne. Zmiana wszystkich wartości na jeden symbol zastępczy niszczy relację, którą arkusz ma pokazywać.
Użyj trzech tymczasowych kategorii: użycie dokładnej domeny, imitacja nazwy wyświetlanej i podobieństwo do innej domeny. Kombinacje zezwoleń i nierozwiązana kategoria. Wiadomość może zawierać zarówno mylącą nazwę wyświetlaną, jak i literę podobna domena. Arkusz powinien także umożliwiać włamanie na autoryzowane konto jako hipotezę, gdy wydaje się, że dostosowana poczta pochodzi z prawdziwej organizacji. Klasyfikacja jest sposobem ukierunkowania dochodzenia, a nie ostatecznym określeniem zamiarów lub odpowiedzialności.
Fikcyjne porównanie z trzema wiadomościami
Wyobraź sobie, że fikcyjny zespół finansowy otrzymuje trzy nietypowe prośby związane z przykładem Northbridge. Pierwsza ma dokładną domenę Northbridge, ale dowody zaufanego odbiorcy wskazują, że nie ma wyrównanego przejścia. Drugi wykorzystuje nazwę wyświetlaną dyrektora finansowego z niepowiązanym adresem, który uwierzytelnia jego własną domenę. Trzeci używa podobnie wyglądającej, ale innej domeny i również uwierzytelnia się w tej domenie. Są to wymyślone obserwacje, a nie wiadomości zebrane w trakcie tej pracy.
Pierwszy przypadek prowadzi do sprawdzenia uwierzytelnienia i ścieżki wysyłania. Drugi prowadzi do weryfikacji nazwy wyświetlanej i urzędu biznesowego. Trzeci prowadzi do porównania domen i obsługi podszywania się. Żadna nie gwarantuje płatności wyłącznie dlatego, że pojawia się znajoma nazwa i żadnej nie należy „naprawiać” poprzez dodanie niepowiązanego nadawcy do listy Northbridge Rekord SPF. Jeśli czwarta wiadomość przejdzie dopasowanie przy użyciu rzeczywistej domeny Northbridge, naruszenie konta lub usługi pozostaje możliwe i wymaga własnych dowodów.
Zweryfikuj żądanie znajdujące się poza komunikatem
The Doradztwo BEC dotyczące poczty elektronicznej IC3 w chmurze, opublikowany w 2020 r., zaleca weryfikację podejrzanych żądań biznesowych za pomocą znanych metod kontaktu. Jego wiek jest wyraźny: wspiera ogólną kontrolę, a nie twierdzenie o bieżącym zdarzeniu lub obecnym interfejsie konkretnego odbiornika. Skorzystaj z numeru lub przepływu pracy już zarejestrowanego niezależnie i zweryfikuj konkretną żądaną zmianę, zamiast tylko pytać, czy ktoś wysłał wiadomość e-mail.
Wymagany zredagowany scenariusz nadużycia obejmujący dowód tożsamości, granicę kontroli i niezależną weryfikację biznesową pozostaje niespełniony. Fikcyjne porównanie tego rękopisu nie zadowala go. Nie zapytano o żadne konto, nie odwiedziono żadnej podejrzanej domeny ani nie skontaktowano się z żadną stroną. Przed wydaniem zachowaj autoryzowane prawdziwe dowody, poproś wykwalifikowanego recenzenta o sprawdzenie klasyfikacji, potwierdzenie zastosowania źródła i tras produkcji, dokonanie pełnego przeglądu dostępności i uzyskanie zgody właściciela. Wynikiem powinno być dające się obronić wyjaśnienie, która tożsamość została potwierdzona i co faktycznie ustaliły kontrole.