Bezpieczeństwo, spoofing i przejęcie konta

Pierwsze 15 minut

1. Zachowaj oryginalne nagłówki (raw headers) i uzyskaj Message-ID w celu przeprowadzenia śledzenia wiadomości (message trace).
2. Przejrzyj ujednolicone zdarzenia audytu (unified audit events) oraz kontekst źródłowego IP logowania dla podejrzanego konta.
3. Zawieś użytkownika Google Workspace podejrzanego o przejęcie konta, aby zresetować ciasteczka sesyjne i tokeny OAuth.

Teraz

• Zawieś użytkownika Google Workspace podejrzanego o przejęcie konta, tak aby jego obecne ciasteczka sesyjne i tokeny OAuth zostały zresetowane.

Najbliższe 24 godziny

• Utrzymuj zawieszenie podejrzanego konta, dopóki jego zresetowane ciasteczka sesyjne i tokeny OAuth traktowane są jako unieważnione poświadczenia.

Najbliższe 7 dni

• Dodaj udokumentowaną procedurę kontrolną polegającą na zawieszaniu użytkowników do swojego schematu reagowania (response procedure) na przyszłe podejrzenia przejęcia w Google Workspace.

Kontrole techniczne

Kryteria weryfikacji

• Śledzenie wiadomości (message trace) identyfikuje oryginalne źródło i docelowych odbiorców dla zachowanego Message-ID.
• Zapisy z audytu i logowań potwierdzają oczekiwaną aktywność konta lub identyfikują nieautoryzowaną aktywność wymagającą powstrzymania (containment).

Kryteria eskalacji

• Eskaluj sprawę do działu bezpieczeństwa, gdy zapisy z audytu lub logowań wykazują aktywność albo źródłowe adresy IP, których właściciel konta nie potrafi wyjaśnić.
• Eskaluj sprawę do administratora Google Workspace, gdy zachodzi konieczność zawieszenia podejrzanego użytkownika w celu zresetowania jego sesji i tokenów OAuth.

Zapobieganie

• Zdefiniuj, które podmioty zapisujące nagłówki Authentication-Results znajdują się wewnątrz zaufanej granicy odbiorczej (trusted receiving boundary).
• Przechowuj i przeglądaj dowody z audytu konta i logowań, upewniając się, że masz wystarczające uprawnienia do prowadzenia dochodzeń w sprawach włamań.

Wpływ na biznes

• Podejrzenie przejęcia konta może wymagać zawieszenia użytkownika, co skutkuje zresetowaniem aktywnych plików cookie i tokenów OAuth.
• Dowody z audytu i logowania mogą ujawnić działania użytkownika lub administratora, które wymagają reakcji bezpieczeństwa.

Uwagi dostawcy

• Microsoft 365 dostarcza narzędzi do śledzenia wiadomości (message trace), zunifikowanego audytu i logowań Entra wyłącznie wtedy, gdy dostępne są odpowiednie uprawnienia, rejestrowanie (logging) i retencja logów.

Otwarte pytania

• Nie dostarczono oryginalnych nagłówków, zaufanych wyników uwierzytelniania, wyników śledzenia wiadomości, zdarzeń z audytu ani zdarzeń logowania, dlatego kwestia, czy to spoofing, czy włamanie na konto, pozostaje nierozstrzygnięta.
• Pomyślny wynik uwierzytelniania sam w sobie nie potwierdza, że w momencie wysyłki konto było kontrolowane przez człowieka - pierwotnego właściciela.
• Nazwy logów, okres ich retencji oraz kontrole mające na celu powstrzymanie ataków (containment controls) różnią się w zależności od dostawcy poczty (mailbox provider).

Pierwsze 15 minut

1. Pogrupuj podejrzane strumienie z raportów zbiorczych DMARC (aggregate reports) według wyników uwierzytelniania, dyspozycji (disposition) oraz identyfikatora.
2. Zachowaj oryginalne nagłówki i użyj funkcji message trace w Microsoft 365, aby zidentyfikować źródło, odbiorców i Message-ID dla podejrzanych przypadków.

Teraz

• Zastosuj zabezpieczenia przed spoofingiem i podszywaniem się pod domeny z usługi Microsoft Defender w odniesieniu do dotkniętych odbiorców lub domen.

Najbliższe 24 godziny

• Przeprowadź inwentaryzację legalnych nadawców i skonfiguruj ich zgodnie z wymogami (align) przed rozszerzeniem egzekwowania DMARC.

Najbliższe 7 dni

• Rozpocznij od polityki p=none, przeglądaj raporty przez tydzień, a następnie zastosuj kwarantannę dla niewielkiego odsetka ruchu przed szerszym egzekwowaniem polityk.

Kontrole techniczne

Kryteria weryfikacji

• Raporty zbiorcze pokazują, że znane legalne strumienie przechodzą DMARC poprzez poprawne i zgodne (aligned) SPF lub DKIM.
• Lokalne różnice w polityce dostawców poczty (receivers) są odnotowywane, a nie traktowane jako dowód jednolitego egzekwowania.

Kryteria eskalacji

• Eskaluj do działu bezpieczeństwa, gdy message trace zidentyfikuje aktywne podejrzane źródła lub obranych za cel odbiorców.
• Eskaluj do właściciela bezpieczeństwa w Microsoft 365, gdy dotknięci odbiorcy wymagają objęcia polityką anti-spoofingową lub zapobiegającą podszywaniu się pod domeny.

Zapobieganie

• Utrzymuj etapowe egzekwowanie DMARC, sprawdzając raporty i upewniając się, że legalni nadawcy są uwierzytelnieni i prawidłowo skonfigurowani (aligned).
• Utrzymuj zabezpieczenia przed spoofingiem i podszywaniem się przypisane do odpowiednich odbiorców lub domen w Microsoft 365.

Wpływ na biznes

• Wskazani odbiorcy lub domeny mogą pozostać narażeni na spoofing i podszywanie się pod domenę (domain impersonation), dopóki nie obejmą ich zabezpieczenia antyphishingowe.

Uwagi dostawcy

• Etapowa sekwencja wdrażania DMARC to zalecenie Google, podczas gdy funkcja message trace oraz kontrole antyphishingowe opisane tutaj to funkcje Microsoft 365.

Otwarte pytania

• Obecna polityka DMARC, dostawcy obsługujący dotkniętych odbiorców, podejrzane źródłowe adresy IP oraz inwentarz autoryzowanych zewnętrznych nadawców nie są określone.
• Egzekwowanie polityk i lokalne zasady dostawców się różnią, więc publikacja polityki p=reject nie gwarantuje identycznego postępowania u każdego z nich.
• Zabezpieczenia przed spoofingiem tej samej domeny nie wyjaśniają, czy kampania wykorzystująca domeny łudząco podobne (lookalike-domain) lub przejęte konta nie jest również aktywna.

Pierwsze 15 minut

1. Pogrupuj wiersze raportu zbiorczego (aggregate report) według źródłowego adresu IP, wyniku uwierzytelniania, dyspozycji, identyfikatora i liczby wiadomości.
2. Zanim oznaczysz błąd DMARC jako złośliwe działanie, sklasyfikuj przekazywanie (forwarding) i znanych nadawców zewnętrznych.

Teraz

• Utrzymaj politykę na obecnym etapie, podczas gdy codzienna analiza raportów pozwoli sklasyfikować legalne oraz nierozpoznane źródła.

Najbliższe 24 godziny

• Przed rozszerzeniem egzekwowania polityk popraw uwierzytelnianie i zgodność identyfikatorów (alignment) dla legalnych usług wysyłkowych.

Najbliższe 7 dni

• Przechodź stopniowo od p=none przez częściową kwarantannę w stronę szerszego egzekwowania dopiero po tym, jak legalne usługi zostaną prawidłowo skonfigurowane (align).

Kontrole techniczne

Kryteria weryfikacji

• Raporty zbiorcze dostarczają sklasyfikowanych danych o uwierzytelnianiu, dyspozycjach, identyfikatorach oraz liczbach wiadomości dla sprawdzonych źródeł.
• Raporty zbiorcze określają wyniki uwierzytelniania i dyspozycje dla badanych legalnych strumieni.
• Przypadki zignorowania polityki przez odbiorców (receiver overrides) są udokumentowane, dzięki czemu publikacja polityki nie jest mylona z jednolitym odrzucaniem wiadomości.

Kryteria eskalacji

• Eskaluj do działu bezpieczeństwa, gdy po wykluczeniu przekazywania i autoryzowanych nadawców zewnętrznych raporty zbiorcze nadal zawierają nierozpoznane źródła.
• Eskaluj do właściciela danej wysyłki, gdy znana usługa ma problemy z uwierzytelnieniem lub zgodnością identyfikatora.

Zapobieganie

• Codziennie przeglądaj raporty zbiorcze DMARC, podczas gdy polityka jest wdrażana etapami, a legalni nadawcy są odpowiednio konfigurowani (aligned).
• Wymagaj, aby identyfikatory podpisujące DKIM były zgodne (align) z widoczną domeną autora w celu uwierzytelnienia DMARC.

Wpływ na biznes

• Błąd DMARC nie przesądza o tym, czy każda dotknięta nim wiadomość została odrzucona, ponieważ odbiorcy (receivers) mogą ignorować opublikowaną politykę (override).

Uwagi dostawcy

• Wskazówki Google dotyczące etapowego wdrażania przewidują przejście od p=none przez częściową kwarantannę w stronę szerszego egzekwowania, a p=reject instruuje respektujących tę politykę odbiorców do odrzucania błędów DMARC.

Otwarte pytania

• Nie podano źródłowych adresów IP raportu, liczby wiadomości, domeny z nagłówka From, domen SPF/DKIM, zastosowanej dyspozycji ani listy autoryzowanych nadawców.
• Błąd DMARC może wynikać z przekazywania (forwarding) lub nieprawidłowo skonfigurowanego (misaligned) autoryzowanego nadawcy, więc złośliwy spoofing nie jest potwierdzony, dopóki źródła nie zostaną sklasyfikowane.
• Udział dostawców poczty i egzekwowanie przez nich polityk mogą się różnić; raporty zbiorcze nie obejmują każdego z nich i nie stanowią dowodu na jednolite blokowanie.

Pierwsze 15 minut

1. Traktuj każde potencjalne publiczne ujawnienie jako wystarczający powód, aby rozpocząć proces wymiany i usuwania klucza.
2. Przejrzyj ustawienia konta, klucze API, uprawnienia członków zespołu, zarządzanie dostępem IP, webhooki i subkonta pod kątem podejrzanych zmian.

Teraz

• Wymień i usuń ujawniony klucz, niezależnie od tego, jak krótkotrwałe było to ujawnienie.

Najbliższe 24 godziny

• Ogranicz nowy klucz wyłącznie do uprawnień (scopes) punktów końcowych API, których potrzebuje dana integracja.

Najbliższe 7 dni

• Przeprowadź audyt pozostałych kluczy API w SendGrid i zawęź wszelkie uprawnienia, które wykraczają poza ich zamierzone zastosowanie.

Kontrole techniczne

Kryteria weryfikacji

• Niedestrukcyjne żądanie z nowym kluczem kończy się sukcesem tylko dla zamierzonej integracji i autoryzowanych zakresów uprawnień.
• Po krótkim czasie propagacji, to samo bezpieczne sprawdzenie uwierzytelniania przy użyciu usuniętego klucza kończy się niepowodzeniem.

Kryteria eskalacji

• Eskaluj sprawę do działu bezpieczeństwa i wsparcia SendGrid, jeśli przegląd konta wykaże nieautoryzowane wysyłki, nieznanych członków zespołu, webhooki, subkonta, klucze API lub zmiany w ustawieniach.

Zapobieganie

• Wydawaj klucze API wyłącznie z zakresami uprawnień do punktów końcowych, które są wymagane przez daną integrację.
• Utrzymuj możliwe do sprawdzenia zestawienia ustawień konta, kluczy, członków zespołu, kontroli dostępu IP, webhooków i subkont.

Wpływ na biznes

• Nieautoryzowane użycie może doprowadzić do wysyłki phishingu, spoofingu lub spamu przez Twoje konto i zniszczyć reputację nadawcy.

Uwagi dostawcy

• Unieważniony klucz API w SendGrid v3 może wymagać krótkiego czasu na propagację, zanim proces uwierzytelniania przestanie działać.

Otwarte pytania

• Czas rozpoczęcia ujawnienia, repozytoria lub logi zawierające klucz oraz każda integracja, która z niego korzystała, nie są bezpośrednio dostępne.
• To, czy klucz został użyty do nieautoryzowanych wysyłek lub zmian na koncie, musi zostać ustalone na podstawie aktywności dzierżawcy i dowodów z samych wiadomości.

Pierwsze 15 minut

1. Zachowaj podejrzane nagłówki i porównaj domenę autora z uwierzytelnionymi identyfikatorami SPF i DKIM pod kątem zgodności z DMARC (DMARC alignment).
2. Sprawdź rejestrację domeny i dowody dotyczące konta, aby sklasyfikować problem jako błąd w dokładnej domenie, podszywanie się pod domenę łudząco podobną, manipulację nazwą wyświetlaną lub przejęcie konta.
3. Przejrzyj dostępne raporty zbiorcze DMARC (aggregate reports) w poszukiwaniu nieznanych, niezgodnych (unaligned) lub nieuwierzytelnionych źródeł korzystających z domeny autora.

Teraz

• Jeśli domena jest wciąż w trybie monitorowania DMARC, utrzymaj ten stan na czas identyfikowania i naprawiania legalnych niezgodnych lub nieuwierzytelnionych strumieni; nie łagodź istniejącej polityki egzekwowania na podstawie tych dowodów.

Najbliższe 24 godziny

• W przypadku licencjonowanych dzierżaw Microsoft Defender włącz odpowiednie detekcje podszywania się pod domenę lub użytkownika i wybierz stosowną akcję: przeniesienie do śmieci (junk), kwarantannę lub usunięcie (delete).

Najbliższe 7 dni

• Po sprawdzeniu obecnie obserwowanej polityki oraz ocenie legalnych bezpośrednich i pośrednich ścieżek, zdecyduj, czy domena będąca w trybie monitorowania powinna przejść do fazy egzekwowania polityki; zachowaj aktualny stan egzekwowania, o ile nie ma oddzielnego uzasadnienia do jego zmiany.

Kontrole techniczne

Kryteria weryfikacji

• Dostępne raporty zbiorcze DMARC obejmują oczekiwane źródła domeny autora i identyfikują ewentualne pozostałe, niezgodne lub nieuwierzytelnione strumienie, pamiętając, że nie każdy odbiorca (receiver) raportuje.
• W licencjonowanym, skonfigurowanym środowisku Microsoft Defender kontrolowany test podszywania się (impersonation test) skutkuje podjęciem wybranej akcji: przeniesieniem do śmieci, kwarantanną lub usunięciem.

Kryteria eskalacji

• Eskaluj do działu bezpieczeństwa, gdy dowody wskazują na kampanię wykorzystującą domenę łudząco podobną, a do administratora bezpieczeństwa Microsoft, gdy skonfigurowane akcje dla podszywania się nie działają w licencjonowanym środowisku (tenant).

Zapobieganie

• Napraw legalne, niezgodne źródła przed zaostrzeniem egzekwowania polityki DMARC i utrzymaj kontrole antyspoofingowe (impersonation controls) po stronie odbiorcy, tam gdzie są one licencjonowane i skonfigurowane.

Wpływ na biznes

• Odbiorcy mogą otrzymać zwodniczą wiadomość z domeny łudząco podobnej, która pozytywnie przechodzi weryfikację SPF, DKIM i DMARC dla własnej domeny atakującego.

Uwagi dostawcy

• Microsoft Defender dla Office 365 może uzupełnić uwierzytelnianie o wykrywanie podszywania się pod domenę lub użytkownika oraz podejmować akcje przenoszenia do śmieci, kwarantanny lub usuwania wiadomości (jeśli posiada licencję i odpowiednią konfigurację).

Otwarte pytania

• Nie dostarczono podejrzanych nagłówków wiadomości, danych rejestracyjnych wysyłającej domeny, logów z audytu konta ani próbek raportów zbiorczych DMARC, więc kategoria ataku pozostaje nierozstrzygnięta.
• Kontrole dotyczące podszywania się, licencjonowanie oraz egzekwowanie polityk różnią się w zależności od docelowego dostawcy poczty (receiving provider) i konfiguracji środowiska.

Pierwsze 15 minut

1. Przeprowadź inwentaryzację aplikacji zależnych od każdego ujawnionego klucza, wydaj i wdróż nowy klucz o ograniczonych uprawnieniach (permission-scoped), zweryfikuj każdą zależną aplikację, a następnie usuń ujawniony klucz; jeśli zaobserwujesz aktywne nadużycia, natychmiast unieważnij ujawniony klucz i dokończ migrację zależności w ramach ratunkowego odzyskiwania.
2. Przejrzyj ostatnie próby dostępu przez interfejs użytkownika (UI), API oraz SMTP, a następnie potwierdź, że każdy obecny członek zespołu (teammate) nadal potrzebuje przyznanych mu uprawnień.

Teraz

• Zrób inwentaryzację zależności, wydaj i wdróż nowy klucz o ograniczonych uprawnieniach, zweryfikuj zależne aplikacje, a następnie usuń każdy ujawniony klucz; jeśli zaobserwujesz aktywne nadużycia, natychmiast unieważnij ujawniony klucz i dokończ wymianę w ramach ratunkowego odzyskiwania.

Najbliższe 24 godziny

• Potwierdź, że każda zinwentaryzowana aplikacja używa nowego klucza o ograniczonych uprawnieniach, i zweryfikuj uwierzytelnianie dwuskładnikowe dla użytkowników.

Najbliższe 7 dni

• Zaostrz dostęp dla członków zespołu, aby każda osoba zachowała tylko funkcje niezbędne do pracy.

Kontrole techniczne

Kryteria weryfikacji

• Skompromitowany klucz nie istnieje na koncie, nowy klucz o ograniczonych uprawnieniach działa w każdej zinwentaryzowanej aplikacji, a zależne zmienne środowiskowe zostały zaktualizowane.
• Ostatnie logi prób dostępu zostały przejrzane, a uwierzytelnianie dwuskładnikowe jest wymuszane dla każdego użytkownika SendGrid.

Kryteria eskalacji

• Eskaluj do wsparcia SendGrid i zespołu bezpieczeństwa, gdy dane o próbach logowania lub historia wysyłki wskazują na przejęcie konta lub nadużywającą wysyłkę.

Zapobieganie

• Utrzymuj przetestowany proces reagowania, polegający na wymianie i usuwaniu każdego publicznie ujawnionego klucza API.
• Wymagaj uwierzytelniania dwuskładnikowego i regularnie weryfikuj uprawnienia członków zespołu.

Wpływ na biznes

• Nieautoryzowane użycie konta może narazić odbiorców na otrzymywanie nadużywającej zaufania poczty i zniszczyć reputację nadawcy, z której korzystają legalne wiadomości biznesowe.

Uwagi dostawcy

• IP Access Management w SendGrid obejmuje dostęp do UI, API i usługi SMTP relay, ale niewłaściwa lista dozwolonych adresów (allowlist) może zablokować legalnych użytkowników.

Otwarte pytania

• Nie udostępniono żadnego bieżącego powiadomienia od dostawcy, komunikatu na koncie ani listy dotkniętych zasobów, więc z samego pytania nie można wywnioskować specyficznego zakresu incydentu.
• To, czy klucze API, poświadczenia użytkowników, członkowie zespołu, domeny wysyłkowe, szablony, listy lub sekrety webhooków zostały ujawnione, wymaga weryfikacji powiadomienia od dostawcy oraz danych audytowych dzierżawcy.
• Wstrzymanie wysyłki jest warunkowe i zależy od dowodów nieautoryzowanego dostępu lub wysyłki; aktualna dokumentacja bezpieczeństwa SendGrid nie narzuca powszechnego wstrzymywania po każdym incydencie po stronie dostawcy.

Pierwsze 15 minut

1. Sprawdź każdą uwierzytelnioną domenę na koncie i ustal, czy jej konfiguracja z 2021 roku korzystała z zabezpieczeń automatycznych, czy ręcznych.
2. Zidentyfikuj, czy każda z dotkniętych domen korzystała z zabezpieczeń automatycznych czy ręcznych, i sprawdź wszystkie domeny na koncie.

Teraz

• Rozpocznij udokumentowaną sekwencję zamiennego uwierzytelnienia dla każdej dotkniętej domeny z ręczną konfiguracją.

Najbliższe 24 godziny

• Utwórz nowe uwierzytelnienie z wcześniej nieużywanym selektorem, opublikuj i zweryfikuj jego rekordy DNS, a następnie usuń oryginalne ręczne uwierzytelnienie.

Najbliższe 7 dni

• Odnotuj zakończenie procesu dopiero po tym, jak zamienne uwierzytelnienie pomyślnie przejdzie weryfikację i zachowana zostanie ciągłość podpisywania.

Kontrole techniczne

Kryteria weryfikacji

• Każda dotknięta domena z ręczną konfiguracją posiada zweryfikowane nowe uwierzytelnienie i zestaw rekordów DNS, zanim jej oryginalna konfiguracja zostanie usunięta.
• Każdy proces ręcznej wymiany korzysta z nowego selektora i przed usunięciem oryginalnej konfiguracji posiada zweryfikowane rekordy DNS.

Kryteria eskalacji

• Eskaluj do działu wsparcia SendGrid i bezpieczeństwa Twilio, gdy status powiadomionego klienta lub tryb bezpieczeństwa jakiejkolwiek uwierzytelnionej domeny nie mogą zostać uzgodnione.

Zapobieganie

• Utrzymuj kompletną inwentaryzację uwierzytelnionych domen, selektorów oraz informacji o automatycznych i ręcznych trybach bezpieczeństwa.
• Wymagaj weryfikacji zamiennej konfiguracji przed usunięciem istniejącego ręcznego uwierzytelnienia domeny.

Wpływ na biznes

• Nierozwiązane ujawnienie prywatnego klucza DKIM stawia pod znakiem zapytania zaufanie do uwierzytelnienia dotkniętej domeny, dopóki status rotacji specyficzny dla dzierżawcy nie zostanie zweryfikowany.

Uwagi dostawcy

• Twilio zaraportowało, że nieuwierzytelniona pamięć podręczna Redis zawierająca prywatne klucze DKIM niektórych klientów była publicznie dostępna przez cztery dni w czerwcu 2021 r.
• Dochodzenie Twilio nie wykazało śladów nieautoryzowanego dostępu, co jednak nie stanowi dowodu, że taki dostęp był niemożliwy.

Otwarte pytania

• Ostrzeżenie podaje, że klienci bezpośrednio dotknięci incydentem otrzymali wiadomości e-mail; pytanie nie rozstrzyga, czy ten konkretny dzierżawca otrzymał takie powiadomienie.
• Aktualna lista uwierzytelnionych domen na koncie i to, czy w 2021 r. używały one zabezpieczeń automatycznych czy ręcznych, nie są podane.
• Twilio na etapie dochodzenia nie wykazało dowodów na nieautoryzowany dostęp; nie można jednak ani potwierdzić, ani wykluczyć nadużyć specyficznych dla dzierżawcy bez logów historycznych i dowodów na użycie klucza.