Blazalek.com

Bezpieczeństwo, spoofing i przejęcie konta: zdiagnozuj ścieżkę wysyłki objętą problemem

Na tej stronie

W incydentach bezpieczeństwa dotyczących wysyłki e-mail najpierw decydujesz, jak opanować sytuację, a dopiero potem wracasz do zwykłej pracy nad dostarczalnością. Odróżnij nieuprawnione użycie konta lub klucza API od podszywania się pod domenę, zachowaj dowody możliwe do audytu i cofaj albo rotuj dostęp wyłącznie kontrolowaną ścieżką odzyskiwania.

Widoczne objawy

  • Jak opanować incydent i odzyskać przejęte konto SendGrid
  • Jakie dowody pozwalają odróżnić spoofing od przejęcia konta nadawcy lub odbiorcy
  • Jak zbadać i powstrzymać trwający incydent podszywania się pod domenę (domain spoofing)
  • Co zrobić, gdy raport DMARC wykryje podszywanie się pod naszą domenę (spoofing)

Grupy przyczyn

Przejęcie konta i poświadczeń

  • Nieoczekiwana aktywność API, nowe poświadczenia, zmiany na kontach użytkowników albo zdarzenia audytowe dostawcy mogą wskazywać na dostęp do konta, a nie na samo podszywanie się pod nadawcę w wiadomości.
  • Ujawniony klucz API trzeba unieważnić i wymienić zgodnie ze zweryfikowanym spisem oraz ścieżką wdrożenia.

Podszywanie się pod domenę

  • Fałszywa domena widoczna w From nie dowodzi przejęcia konta nadawcy; ścieżkę wysyłki pokazują uwierzytelnienie wiadomości i raporty DMARC.

Działania po incydencie dostawcy

  • Zdarzenie bezpieczeństwa u dostawcy wymaga sprawdzenia jego opublikowanego zakresu oraz własnych poświadczeń, logów i integracji klienta.

Pierwsze bezpieczne kontrole

  1. Opanuj aktywny nieuprawniony dostęp mechanizmami dostawcy i zachowaj przy tym logi audytowe, próbki wiadomości, znaczniki czasu oraz tożsamości objęte incydentem.
  2. Ustal, czy dowody wskazują na użycie konta lub klucza API, przejęcie konta odbiorcy, czy zewnętrzne podszywanie się, zanim zaczniesz rotować niepowiązany z tym DNS albo poświadczenia.
  3. Zinwentaryzuj zależne aplikacje, zanim wymienisz unieważniony klucz, a potem potwierdź, że stary klucz jest odrzucany, a nowy ma minimalne uprawnienia.

Zasady rozwiązania

  • Odzyskaj dostęp przez kontrolowaną rotację poświadczeń, ograniczone uprawnienia i udokumentowaną kontrolę wysyłki, webhooków oraz zdarzeń audytowych.
  • Przy spoofingu popraw potwierdzony mechanizm uwierzytelniania lub DMARC i monitoruj to samo źródło raportów; pojedynczy raport nie dowodzi, że wszystkie nadużycia ustały.

Wybierz runbook

Wybierz sygnał incydentu: nadużycie konta lub klucza API, zewnętrzne podszywanie się, raport DMARC albo komunikat dostawcy. Ścieżki rozdzielają opanowanie sytuacji i granice dowodów.

Macierz diagnostyczna

ObjawObszarPierwsza kontrola
Jak opanować incydent i odzyskać przejęte konto SendGridOpanowanie konta i odzyskanie dostępuWyłącz podejrzany dostęp, zachowaj aktywność konta i zinwentaryzuj nadawców, klucze, integracje oraz ruch objęty incydentem.
Jakie dowody pozwalają odróżnić spoofing od przejęcia konta nadawcy lub odbiorcyDowody spoofingu i przejęciaZbierz nagłówki, wyniki uwierzytelnienia, zdarzenia audytowe konta, dowody od odbiorcy i właściwe okno czasu.
Jak zbadać i powstrzymać trwający incydent podszywania się pod domenę (domain spoofing)Opanowanie aktywnego spoofinguZachowaj reprezentatywne nagłówki i wyniki uwierzytelnienia, potem ustal nieautoryzowaną ścieżkę wysyłki i odbiorców.
Co zrobić, gdy raport DMARC wykryje podszywanie się pod naszą domenę (spoofing)Interpretacja raportu DMARCUstal źródło raportu, IP, wynik uwierzytelnienia i alignmentu, domenę objętą incydentem oraz zakres czasowy.
Jak ograniczyć skutki ujawnienia klucza API SendGrid, bezpiecznie go wymienić i zweryfikować, że usunięty klucz już nie działaOpanowanie ujawnionego klucza APIUnieważnij ujawniony klucz, zachowaj historię jego użycia i spisz integracje przed wydaniem ograniczonego zamiennika.
Jak powstrzymać spoofing, skoro SPF, DKIM i DMARC są już wdrożoneLuka w zasięgu uwierzytelnieniaPorównaj tożsamość i wyniki uwierzytelnienia zgłoszonej wiadomości z polityką domeny oraz metodą podszycia.
Co klienci SendGrid powinni sprawdzić po incydencie bezpieczeństwa u dostawcyWeryfikacja incydentu dostawcyPrzeczytaj komunikat dostawcy i porównaj jego zakres z aktywnością konta, poświadczeniami, integracjami i wysyłkami.
Co klienci Twilio powinni sprawdzić po wystawieniu Kubernetes NodePortZakres udokumentowanej ekspozycjiDopasuj opublikowaną granicę ekspozycji do zasobów konta, logów dostępu i aktywnych poświadczeń.

Zacznij od dokładnego objawu i dowodów, a naprawę potwierdź, zanim wznowisz ścieżkę wysyłki objętą problemem.

Jak opanować incydent i odzyskać przejęte konto SendGrid?

Poziom ważności: KrytycznyWstrzymanie wysyłki: Wstrzymaj wysyłkę

Potraktuj podejrzenie przejęcia konta SendGrid jak aktywny incydent bezpieczeństwa: atakujący może rozsyłać phishing, spoofing lub spam i zniszczyć reputację nadawcy. Natychmiast zmień dane logowania do konta, wymień i usuń ujawnione klucze API oraz skontaktuj się ze wsparciem SendGrid. Wstrzymaj wysyłkę, dopóki nie opanujesz ujawnionego dostępu i nie zajmiesz się oczekującą złośliwą pocztą.

Pierwsze 15 minut

  1. Natychmiast zmień nazwę użytkownika i hasło do konta SendGrid oraz zaktualizuj aplikację wysyłającą.
  2. Skontaktuj się ze wsparciem SendGrid, aby w razie potrzeby przeprowadziło dochodzenie, zaangażowało dział Compliance, tymczasowo dezaktywowało konto lub usunęło oczekujące wiadomości.
  3. Utwórz zamiennik każdego ujawnionego klucza API, zaktualizuj aplikacje i usuń skompromitowany klucz.

Teraz

  • Zmień dane logowania do konta, wymień ujawnione klucze API, usuń skompromitowane klucze i zaktualizuj aplikacje wysyłające.

Najbliższe 24 godziny

  • Współpracuj ze wsparciem SendGrid przy dochodzeniu, angażowaniu działu Compliance, tymczasowej dezaktywacji i usuwaniu wciąż oczekujących wiadomości.

Najbliższe 7 dni

  • Dokończ odzyskiwanie danych logowania i aplikacji, gdy dochodzenie wsparcia ustali stan konta objętego incydentem.

Kontrole techniczne

Bezpieczeństwo

  • Potwierdź, że ujawnione klucze API mają zamienniki, a skompromitowane klucze zostały usunięte.
  • Jeśli masz stałe, zatwierdzone adresy wychodzące, sprawdź zakres ochrony IP Access Management dla interfejsu, API i przekaźnika SMTP.
  • Przejrzyj dostęp w SendGrid Teammate i ogranicz każdemu członkowi zespołu funkcje do tych, których wymaga jego podstawowy zakres obowiązków.

Kryteria weryfikacji

  • Potwierdź, że SendGrid odrzuca wywołania API korzystające z każdego usuniętego, skompromitowanego klucza.
  • Tam, gdzie włączono IP Access Management, potwierdź, że prawidłowe, zatwierdzone adresy działają, a pozostałe próby dostępu są blokowane.

Kryteria eskalacji

  • Natychmiast eskaluj sprawę do wsparcia SendGrid: niech przeprowadzi dochodzenie, zaangażuje dział Compliance, tymczasowo dezaktywuje konto i usunie oczekujące wiadomości.

Zapobieganie

  • Korzystaj z IP Access Management tylko przy stabilnych, zatwierdzonych adresach wychodzących i ogranicz dostęp do UI, API oraz SMTP relay do dozwolonych adresów IP.
  • Regularnie przeglądaj dostęp członków zespołu i ogranicz każdemu funkcje do tych niezbędnych do podstawowych obowiązków.

Wpływ na biznes

  • Atakujący może wykorzystać przejęte konto SendGrid do phishingu, spoofingu lub spamu i zniszczyć reputację nadawcy.

Uwagi dostawcy

  • Wsparcie SendGrid może przeprowadzić dochodzenie w sprawie przejęcia, zaangażować dział Compliance, tymczasowo dezaktywować konto i usunąć wciąż oczekujące wiadomości.
  • Po usunięciu skompromitowanego klucza API SendGrid odrzuca każde późniejsze wywołanie API, które z niego korzysta.

Otwarte pytania

  • Ustalenie, które dane logowania, konta członków zespołu, subkonta (subusers), adresy IP, szablony i kontakty zostały objęte incydentem oraz jakie było okno nieautoryzowanej wysyłki, wymaga logów konta i dochodzenia po stronie Twilio.
  • To, czy w kolejce wciąż czekają złośliwe wiadomości i czy Twilio zawiesiło już konto, musi potwierdzić wsparcie.
  • Bez stabilnych, zatwierdzonych adresów wychodzących IP Access Management się nie sprawdzi, bo może odciąć dostęp uprawnionym operatorom.
  • Zarchiwizowana wersja strony „Secure your Twilio account” (snapshot) zaleca kwartalną rotację kluczy API i usuwanie nieużywanych kluczy, ale nie potwierdza, że Twilio wymaga 2FA od każdego użytkownika SendGrid.
Źródła (6)
  1. Secure your Twilio account — Introduction, lines 53-59Twilio SendGrid
  2. Compromised Account Recovery — Recovery procedure, lines 99-106Twilio SendGrid
  3. Compromised Account Recovery — Recovery procedure, lines 104-106Twilio SendGrid
  4. API Keys — Deleting an API key and replacing an old API keyTwilio SendGrid
  5. IP Access Management — What is IP access management, lines 116-127Twilio SendGrid
  6. Secure your Twilio account — Review Teammate access, lines 129-141Twilio SendGrid

Jakie dowody pozwalają odróżnić spoofing od przejęcia konta nadawcy lub odbiorcy?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Nie klasyfikuj incydentu wyłącznie na podstawie widocznego adresu From. Zaufane wyniki uwierzytelniania (authentication results) i zgodność identyfikatorów (identifier alignment) mówią, czy widoczna domena przeszła uwierzytelnianie. Logi audytu i logowań pokazują z kolei, czy dane konto rzeczywiście podjęło działanie. Dopóki oba zestawy dowodów nie są ze sobą zgodne, pozostaje nierozstrzygnięte, czy to spoofing, czy przejęcie konta.

Pierwsze 15 minut

  1. Zachowaj surowe nagłówki (raw headers) i zdobądź Message-ID, aby móc prześledzić wiadomość (message trace).
  2. Przejrzyj ujednolicone zdarzenia audytu (unified audit events) oraz kontekst źródłowych adresów IP logowań dla podejrzanego konta.
  3. Zawieś użytkownika Google Workspace podejrzanego o przejęcie konta, aby zresetować jego ciasteczka logowania i tokeny OAuth.

Teraz

  • Zawieś użytkownika Google Workspace podejrzanego o przejęcie konta, aby zresetować jego bieżące ciasteczka logowania i tokeny OAuth.

Najbliższe 24 godziny

  • Utrzymuj zawieszenie podejrzanego konta i traktuj jego zresetowane ciasteczka logowania oraz tokeny OAuth jako unieważnione poświadczenia.

Najbliższe 7 dni

  • Wpisz udokumentowany mechanizm zawieszania użytkownika do procedury reagowania na przyszłe podejrzenia przejęcia konta w Google Workspace.

Kontrole techniczne

Bezpieczeństwo

  • Ufaj wyłącznie nagłówkom Authentication-Results dodanym wewnątrz ocenianej granicy zaufania po stronie odbiorcy.
  • Sprawdź, czy uwierzytelniony identyfikator SPF lub DKIM jest zgodny z widoczną domeną From.
  • Porównaj aktywność w logach audytu i źródłowe adresy IP logowań z oczekiwanym zachowaniem użytkownika.

Wsparcie ESP

  • Użyj Message-ID z surowego nagłówka, aby w Microsoft 365 prześledzić pierwotne źródło i docelowych odbiorców.

Kryteria weryfikacji

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

Kryteria eskalacji

  • Eskaluj sprawę do zespołu bezpieczeństwa, gdy w zapisach audytu lub logowań pojawia się aktywność albo źródłowe adresy IP, których właściciel konta nie umie wyjaśnić.
  • Eskaluj sprawę do administratora Google Workspace, gdy trzeba zawiesić podejrzanego użytkownika, aby zresetować jego sesje i tokeny 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ń, dbając o to, byś miał wystarczające uprawnienia do prowadzenia dochodzeń w sprawach przejęć.

Wpływ na biznes

  • Podejrzenie przejęcia konta może wymagać zawieszenia użytkownika, a to resetuje jego aktywne ciasteczka logowania i tokeny OAuth.
  • Dowody z audytu i logowań mogą ujawnić działania użytkownika lub administratora, które wymagają reakcji zespołu bezpieczeństwa.

Uwagi dostawcy

  • Microsoft 365 udostępnia śledzenie wiadomości (message trace), ujednolicony audyt i dane logowań Entra tylko wtedy, gdy dostępne są odpowiednie rejestrowanie (logging), retencja i uprawnienia.

Otwarte pytania

  • Nie dostarczono surowych nagłówków, zaufanych nagłówków Authentication-Results, śledzenia wiadomości, zdarzeń audytu ani zdarzeń logowania, dlatego pozostaje nierozstrzygnięte, czy to spoofing, czy przejęcie konta.
  • Pomyślny wynik uwierzytelniania sam w sobie nie dowodzi, że w momencie wysyłki kontrolę nad kontem sprawował człowiek, który wysłał wiadomość.
  • Nazwy logów, okresy retencji i mechanizmy powstrzymywania ataków (containment controls) różnią się między operatorami pocztowymi (mailbox provider).
Źródła (5)
  1. RFC 8601 - Message Header Field for Indicating Message Authentication Status — Sections 1.1-1.3, Purpose and Trust BoundaryIETF RFC 8601
  2. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Section 4.4.1, DKIM-Authenticated IdentifiersIETF RFC 9989
  3. Phishing investigation — Prerequisites: Message traceMicrosoft 365
  4. Phishing investigation — Audit log search and managed sign-in scenarioMicrosoft 365
  5. Identify and secure compromised accounts — Step 1: Temporarily suspend the suspected compromised user accountGoogle Workspace

Jak zbadać i powstrzymać trwający incydent podszywania się pod domenę (domain spoofing)?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Aktywną kampanię spoofingową traktuj jako incydent, w którym priorytetem jest ochrona odbiorców, i równolegle sprawdzaj zgodność domen w DMARC (alignment). Nie przechodź od razu do szerokiego odrzucania wiadomości (rejection), dopóki legalni nadawcy się nie uwierzytelnią i nie osiągną zgodności domen. Gdy egzekwowanie polityki wprowadzasz etapami, dołóż ukierunkowane zabezpieczenia anti-spoofing na poziomie skrzynek.

Pierwsze 15 minut

  1. Pogrupuj podejrzane strumienie z raportów zbiorczych DMARC (aggregate reports) według wyniku uwierzytelniania, dyspozycji (disposition) i identyfikatora.
  2. Zabezpiecz surowe nagłówki i użyj funkcji message trace w Microsoft 365, aby dla podejrzanych przykładów ustalić źródło, odbiorców i Message-ID.

Teraz

  • Włącz zabezpieczenia Microsoft Defender przed spoofingiem i podszywaniem się pod domeny dla odbiorców lub domen objętych incydentem.

Najbliższe 24 godziny

  • Zinwentaryzuj legalnych nadawców i doprowadź ich do zgodności domen (align), zanim rozszerzysz egzekwowanie DMARC.

Najbliższe 7 dni

  • Zacznij od polityki p=none, przez tydzień przeglądaj raporty, a potem obejmij kwarantanną niewielki odsetek ruchu, zanim przejdziesz do szerszego egzekwowania.

Kontrole techniczne

IT / DNS

  • Potwierdź, czy SPF lub DKIM uwierzytelnia wiadomość i jest zgodny z widoczną domeną From.
  • Sklasyfikuj strumienie wysyłkowe zestawione w raportach zbiorczych DMARC.

Bezpieczeństwo

  • Prześledź podejrzane przykłady wstecz do ich pierwotnego źródła i docelowych odbiorców w Microsoft 365.

Kryteria weryfikacji

  • Raporty zbiorcze pokazują, że znane, legalne strumienie przechodzą DMARC dzięki zgodnemu (aligned) SPF lub DKIM.
  • Lokalne różnice w politykach serwerów odbiorczych (receivers) są odnotowane, a nie traktowane jako dowód jednolitego egzekwowania.

Kryteria eskalacji

  • Eskaluj sprawę do działu bezpieczeństwa, gdy message trace wykryje aktywne, podejrzane źródła lub odbiorców będących celem ataku.
  • Eskaluj sprawę do osoby odpowiedzialnej za bezpieczeństwo Microsoft 365, gdy odbiorcy objęci incydentem wymagają objęcia polityką anti-spoofing lub polityką przeciw podszywaniu się pod domeny.

Zapobieganie

  • Utrzymuj etapowe egzekwowanie DMARC: przeglądaj raporty i pilnuj, aby legalni nadawcy byli uwierzytelnieni i osiągali zgodność domen (aligned).
  • Utrzymuj zabezpieczenia anti-spoofing i przeciw podszywaniu się pod domeny przypisane do właściwych 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, natomiast opisane tu message trace i zabezpieczenia antyphishingowe to funkcje Microsoft 365.

Otwarte pytania

  • Nie podano obecnej polityki DMARC, operatorów pocztowych obsługujących odbiorców objętych incydentem, podejrzanych źródłowych adresów IP ani spisu autoryzowanych zewnętrznych nadawców.
  • Egzekwowanie po stronie serwerów odbiorczych i ich lokalne polityki bywają różne, więc opublikowanie p=reject nie zagwarantuje identycznego traktowania wszędzie.
  • Zabezpieczenia przed spoofingiem w obrębie tej samej domeny nie rozstrzygają, czy równolegle nie trwa kampania oparta na domenach łudząco podobnych (lookalike-domain) lub na przejętych kontach.
Źródła (6)
  1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Section 5.3.5, Determine DMARC Pass or FailIETF RFC 9989
  2. RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting — Sections 3.1 and 3.1.1.7-3.1.1.13IETF RFC 9990
  3. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Sections 5.3.6 and 5.4, Policy Enforcement ConsiderationsIETF RFC 9989
  4. Recommended DMARC rollout — Recommended DMARC rollout, steps 1-2Google Workspace
  5. Configure anti-phishing policies in Microsoft Defender for Office 365 — Overview and policy creation: impersonation settingsMicrosoft Defender for Office 365
  6. Phishing investigation — Message trace and raw-header investigationMicrosoft 365

Co zrobić, gdy raport DMARC wykryje podszywanie się pod naszą domenę (spoofing)?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Raport DMARC traktuj jako sygnał do segregacji (triage), a nie dowód, że każde źródło z błędem uwierzytelniania jest złośliwe. Zanim zmienisz poziom egzekwowania polityki, sklasyfikuj źródłowe adresy IP, identyfikatory, dyspozycje (disposition), przekazywanie (forwarding) i autoryzowanych nadawców zewnętrznych. Najpierw doprowadź legalnych nadawców do zgodności domen (alignment), a potem stopniowo zmieniaj politykę i przez cały czas monitoruj raporty.

Pierwsze 15 minut

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

Teraz

  • Utrzymuj politykę na obecnym etapie, dopóki codzienny przegląd raportów klasyfikuje legalne i nierozpoznane źródła.

Najbliższe 24 godziny

  • Popraw uwierzytelnianie i zgodność identyfikatorów (alignment) dla legalnych usług wysyłkowych, zanim rozszerzysz egzekwowanie polityki.

Najbliższe 7 dni

  • Przechodź stopniowo od p=none przez częściową kwarantannę w stronę szerszego egzekwowania, ale dopiero po tym, jak legalne usługi osiągną zgodność domen (align).

Kontrole techniczne

IT / DNS

  • Porównaj każde źródło z wykazem autoryzowanych nadawców oraz z polami uwierzytelniania i dyspozycji (disposition) w raporcie zbiorczym.
  • Potwierdź, że prawidłowy podpis DKIM zapewnia zgodność identyfikatora podpisującego z widoczną domeną autora.

Bezpieczeństwo

  • Nierozpoznanym źródłom nadaj priorytet dopiero po wykluczeniu przekazywania (forwarding) i autoryzowanych nadawców.

Kryteria weryfikacji

  • Raporty zbiorcze dostarczają sklasyfikowanych danych o uwierzytelnianiu, dyspozycjach (disposition), identyfikatorach i liczbie wiadomości dla sprawdzonych źródeł.
  • Raporty zbiorcze pokazują wyniki uwierzytelniania i dyspozycje (disposition) dla badanych legalnych strumieni.
  • Nadpisania polityki przez odbiorców (receiver overrides) są udokumentowane, dzięki czemu opublikowanie polityki nie jest mylone z jednolitym odrzucaniem wiadomości.

Kryteria eskalacji

  • Eskaluj sprawę do działu bezpieczeństwa, gdy po wykluczeniu przekazywania (forwarding) i autoryzowanych nadawców zewnętrznych raporty zbiorcze wciąż zawierają nierozpoznane źródła.
  • Eskaluj sprawę do właściciela danej wysyłki, gdy znana usługa nie przechodzi uwierzytelniania lub nie zachowuje zgodności identyfikatora (alignment).

Zapobieganie

  • Codziennie przeglądaj raporty zbiorcze DMARC, dopóki wdrażasz politykę etapami i doprowadzasz legalnych nadawców do zgodności domen (aligned).
  • Wymagaj, aby identyfikatory podpisujące DKIM były zgodne (alignment) z widoczną domeną autora na potrzeby uwierzytelniania DMARC.

Wpływ na biznes

  • Błąd DMARC nie przesądza, czy każda wiadomość, której to dotyczy, została odrzucona, ponieważ odbiorcy (receivers) mogą nadpisać opublikowaną politykę (override).

Uwagi dostawcy

  • Etapowe wytyczne Google przewidują przejście od p=none przez częściową kwarantannę w stronę szerszego egzekwowania, a p=reject nakazuje odbiorcom respektującym tę politykę odrzucać wiadomości z błędem DMARC.

Otwarte pytania

  • Nie podano źródłowych adresów IP z raportu, liczby wiadomości, domeny z nagłówka From, domen SPF/DKIM, dyspozycji wynikającej z polityki (disposition) ani wykazu autoryzowanych nadawców.
  • Błąd DMARC może oznaczać przekazywanie (forwarding) albo autoryzowanego nadawcę bez zgodności domen (misaligned), więc złośliwego spoofingu nie da się potwierdzić, dopóki nie sklasyfikujesz źródeł.
  • Udział odbiorców i egzekwowanie polityki przez nich bywają różne; raporty zbiorcze nie obejmują każdego odbiorcy i nie dowodzą jednolitego blokowania.
Źródła (6)
  1. RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting — Sections 1 and 3.1.1.7-3.1.1.13IETF RFC 9990
  2. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Sections 1, 7.3, and 7.4, Interoperability Issues and ConsiderationsIETF RFC 9989
  3. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Section 5.4, Policy Enforcement ConsiderationsIETF RFC 9989
  4. Recommended DMARC rollout — Recommended DMARC rolloutGoogle Workspace
  5. Set up DMARC — DMARC record tag definitions: pGoogle Workspace
  6. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Section 4.4.1, DKIM-Authenticated IdentifiersIETF RFC 9989

Jak ograniczyć skutki ujawnienia klucza API SendGrid, bezpiecznie go wymienić i zweryfikować, że usunięty klucz już nie działa?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Wymień i usuń każdy potencjalnie ujawniony klucz API SendGrid, nawet jeśli był odsłonięty tylko przez chwilę. Sprawny skradziony klucz może posłużyć do phishingu, spoofingu lub spamu i zniszczyć reputację nadawcy. Po krótkiej zwłoce związanej z unieważnieniem klucza zweryfikuj niedestrukcyjnymi testami, że nowy klucz obsługuje tylko przewidzianą dla niego integrację, a usunięty klucz nie może się już uwierzytelnić.

Pierwsze 15 minut

  1. Traktuj każde możliwe publiczne ujawnienie jako wystarczający powód, by rozpocząć wymianę i usunięcie klucza.
  2. Przejrzyj ustawienia konta, klucze API, członków zespołu, IP Access Management, webhooki i subużytkowników (subusers) pod kątem podejrzanych zmian.

Teraz

  • Wymień i usuń ujawniony klucz niezależnie od tego, jak krótko był odsłonięty.

Najbliższe 24 godziny

  • Ogranicz nowy klucz wyłącznie do zakresów (scopes) tych endpointów API, których potrzebuje jego integracja.

Najbliższe 7 dni

  • Przeprowadź audyt pozostałych kluczy API SendGrid i zawęź wszystkie uprawnienia wykraczające poza ich docelowe integracje.

Kontrole techniczne

Bezpieczeństwo

  • Skontroluj ustawienia konta, klucze API, członków zespołu, IP Access Management, webhooki i subużytkowników pod kątem nieautoryzowanej aktywności.

Inżynieria

  • Potwierdź, że nowy klucz jest ograniczony do zakresów API (scopes) wymaganych przez przewidzianą dla niego integrację.
  • Po krótkim czasie propagacji wyślij niedestrukcyjne żądanie i potwierdź, że unieważniony klucz nie przechodzi uwierzytelniania.

Kryteria weryfikacji

  • Niedestrukcyjne żądanie wysłane nowym kluczem przechodzi tylko dla przewidzianej dla niego integracji i dozwolonych zakresów (scopes).
  • Po krótkim czasie propagacji to samo bezpieczne sprawdzenie uwierzytelniania usuniętym kluczem kończy się niepowodzeniem.

Kryteria eskalacji

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

Zapobieganie

  • Wydawaj klucze API tylko z tymi zakresami (scopes) endpointów, których wymaga dana integracja.
  • Prowadź łatwe do przeglądu spisy ustawień konta, kluczy, członków zespołu, mechanizmów kontroli dostępu po IP, webhooków i subużytkowników.

Wpływ na biznes

  • Nieautoryzowane użycie może posłużyć do rozsyłania phishingu, spoofingu lub spamu przez Twoje konto i zniszczyć reputację nadawcy.

Uwagi dostawcy

  • Unieważniony klucz API SendGrid v3 może wymagać krótkiego czasu propagacji, zanim jego uwierzytelnianie przestanie przechodzić.

Otwarte pytania

  • Czas rozpoczęcia ujawnienia, repozytoria lub logi zawierające klucz oraz wszystkie integracje, które go używały, nie są dostępne.
  • To, czy klucza użyto do nieautoryzowanych wysyłek albo zmian na koncie, trzeba ustalić na podstawie aktywności w tenancie i dowodów z samych wiadomości.
Źródła (6)
  1. Secure your Twilio account — Rotate out exposed keysTwilio SendGrid
  2. Delete API keys — DELETE /v3/api_keys/{api_key_id}: operation overviewTwilio SendGrid
  3. Secure your Twilio account — Account takeover overviewTwilio SendGrid
  4. API Key permissions — API Key permissions overviewTwilio SendGrid
  5. Forced Password Reset FAQ — Where can I look for evidence of bad activity in my account?Twilio SendGrid
  6. Delete API keys — DELETE operation behavior and authentication responsesTwilio SendGrid

Jak powstrzymać spoofing, skoro SPF, DKIM i DMARC są już wdrożone?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

SPF, DKIM i DMARC nie dowodzą, że uwierzytelniona wiadomość lub domena jest nieszkodliwa. Łudząco podobna domena (lookalike domain) może przejść uwierzytelnianie dla własnej domeny, a mimo to podszywać się pod atakowaną markę. Najpierw odróżnij błąd uwierzytelniania w dokładnej domenie, podszywanie się pod domenę łudząco podobną, zwodniczą nazwę wyświetlaną (display-name deception) oraz przejęcie konta nadawcy, bo każdy z tych przypadków wymaga innego sposobu powstrzymania incydentu.

Pierwsze 15 minut

  1. Zachowaj podejrzane nagłówki i porównaj domenę autora z uwierzytelnionymi identyfikatorami SPF oraz DKIM pod kątem zgodności DMARC (alignment).
  2. Sprawdź dane rejestracyjne domeny oraz dowody z konta, aby zakwalifikować incydent jako błąd w dokładnej domenie, podszywanie się pod domenę łudząco podobną, zwodniczą 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 wciąż jest w trybie monitorowania DMARC, utrzymaj ten stan, dopóki identyfikujesz i naprawiasz legalne strumienie niezgodne (unaligned) lub nieuwierzytelnione. Nie łagodź istniejącej polityki egzekwowania na podstawie tych dowodów.

Najbliższe 24 godziny

  • W licencjonowanych środowiskach (tenant) Microsoft Defender włącz odpowiednie mechanizmy wykrywania podszywania się pod domenę lub użytkownika i wybierz właściwą akcję: przeniesienie do śmieci (junk), kwarantannę lub usunięcie (delete).

Najbliższe 7 dni

  • Gdy sprawdzisz obecnie obserwowaną politykę i ocenisz legalne ścieżki bezpośrednie oraz pośrednie, zdecyduj, czy domena wciąż w trybie monitorowania powinna przejść do egzekwowania. Zachowaj obecny stan egzekwowania, o ile nie ma osobnego uzasadnienia dla jego zmiany.

Kontrole techniczne

Bezpieczeństwo

  • Ustal, czy podejrzana domena to domena chroniona, domena łudząco podobna uwierzytelniająca się we własnym imieniu, czy przejęty autoryzowany nadawca.

IT / DNS

  • Dla wiadomości z dokładnej domeny sprawdź, czy domena autora jest zgodna z uwierzytelnionym identyfikatorem SPF lub DKIM.
  • Przeanalizuj źródła w raportach zbiorczych DMARC pod kątem ruchu niezgodnego (unaligned) lub nieuwierzytelnionego. Pamiętaj, że raporty nie obejmują każdego odbiorcy.

Kryteria weryfikacji

  • Dostępne raporty zbiorcze DMARC obejmują oczekiwane źródła z domeny autora i wskazują ewentualne pozostałe strumienie niezgodne (unaligned) lub nieuwierzytelnione — przy czym nie każdy odbiorca (receiver) raportuje.
  • W licencjonowanym i skonfigurowanym środowisku Microsoft Defender (tenant) kontrolowany test podszywania się (impersonation) kończy się wybraną akcją: przeniesieniem do śmieci (junk), kwarantanną lub usunięciem (delete).

Kryteria eskalacji

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

Zapobieganie

  • Napraw legalne, niezgodne źródła, zanim zaostrzysz egzekwowanie DMARC, i utrzymuj kontrole antyspoofingowe (impersonation controls) po stronie odbiorcy tam, gdzie są licencjonowane i skonfigurowane.

Wpływ na biznes

  • Odbiorcy mogą otrzymać zwodniczą wiadomość z domeny łudząco podobnej, która 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 o akcje przeniesienia do śmieci, kwarantanny lub usunięcia wiadomości — o ile masz licencję i odpowiednią konfigurację.

Otwarte pytania

  • Nie dostarczono podejrzanych nagłówków wiadomości, danych rejestracyjnych domeny wysyłającej, logów z audytu konta ani próbki raportu zbiorczego DMARC, więc klasa ataku pozostaje nierozstrzygnięta.
  • Kontrole podszywania się, licencjonowanie i sposób egzekwowania różnią się w zależności od dostawcy odbierającego pocztę (receiving provider) oraz konfiguracji środowiska (tenant).
Źródła (7)
  1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Section 3.2.10, Identifier AlignmentIETF RFC 9989
  2. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Section 5.4, Policy Enforcement ConsiderationsIETF RFC 9989
  3. Impersonation insight in Defender for Office 365 — Domain impersonation versus domain spoofingMicrosoft Defender for Office 365
  4. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Sections 5.1.3-5.1.6IETF RFC 9989
  5. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Sections 5.1.4-5.1.7, Domain Owner actionsIETF RFC 9989
  6. Anti-phishing policies in Microsoft 365 — Mailbox intelligence impersonation protection and actionsMicrosoft Defender for Office 365
  7. Impersonation insight in Defender for Office 365 — Impersonation types and distinction from spoofingMicrosoft Defender for Office 365

Co klienci SendGrid powinni sprawdzić po incydencie bezpieczeństwa u dostawcy?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Powiadomienie o bezpieczeństwie od dostawcy traktuj jako dochodzenie o ograniczonym zakresie, dotyczące poświadczeń i dostępu, a nie jako dowód, że to właśnie Twoje konto (tenant) zostało przejęte. Każdy ujawniony klucz API SendGrid wymień w sekwencji bezpiecznej dla zależności; jeśli zaobserwujesz aktywne nadużycia, natychmiast unieważnij ujawniony klucz, a wymianę dokończ w trybie awaryjnym. Wysyłkę wstrzymaj tylko wtedy, gdy dane z konta wskazują na nieautoryzowany dostęp lub wysyłkę, która mogłaby umożliwić nadużycia i zaszkodzić reputacji.

Pierwsze 15 minut

  1. Zinwentaryzuj aplikacje zależne od każdego ujawnionego klucza, wydaj i wdróż zamiennik o ograniczonych uprawnieniach (permission-scoped), a każdą zależną aplikację zweryfikuj. Dopiero potem usuń ujawniony klucz. Jeśli zaobserwujesz aktywne nadużycia, natychmiast go unieważnij, a migrację zależności dokończ w trybie awaryjnym.
  2. Przejrzyj ostatnie próby dostępu przez UI, API i SMTP, a następnie potwierdź, że każdy obecny członek zespołu (Teammate) nadal potrzebuje przyznanego dostępu.

Teraz

  • Zinwentaryzuj zależności, wydaj i wdróż zamiennik 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, a wymianę dokończ w trybie awaryjnym.

Najbliższe 24 godziny

  • Potwierdź, że każda zinwentaryzowana aplikacja korzysta z zamiennika o ograniczonych uprawnieniach, i zweryfikuj uwierzytelnianie dwuskładnikowe użytkowników.

Najbliższe 7 dni

  • Zaostrz dostęp Teammate, aby każda osoba zachowała tylko funkcje niezbędne do pracy.

Kontrole techniczne

Bezpieczeństwo

  • Przejrzyj ostatnie próby dostępu do SendGrid — ich znaczniki czasu i użyte metody — pod kątem niezatwierdzonej aktywności.
  • Potwierdź, że uwierzytelnianie dwuskładnikowe jest wymuszane dla każdego użytkownika SendGrid.

Inżynieria

  • Zinwentaryzuj aplikacje używające klucza objętego incydentem, wydaj i wdróż zamiennik o ograniczonym zakresie uprawnień, zaktualizuj zależne zmienne środowiskowe i zweryfikuj każdą aplikację. Dopiero potem usuń ujawniony klucz. Jeśli wykryjesz aktywne nadużycie, natychmiast go unieważnij, a wymianę dokończ w trybie awaryjnym.

Marketing / CRM

  • Przejrzyj dostęp Teammate i zostaw każdej osobie tylko te funkcje, których potrzebuje do pracy.

Kryteria weryfikacji

  • Skompromitowanego klucza nie ma już na koncie, zamiennik o ograniczonych uprawnieniach działa w każdej zinwentaryzowanej aplikacji, a zależne zmienne środowiskowe są zaktualizowane.
  • Zapisy ostatnich prób dostępu zostały przejrzane, a uwierzytelnianie dwuskładnikowe jest wymuszane dla każdego użytkownika SendGrid.

Kryteria eskalacji

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

Zapobieganie

  • Utrzymuj przetestowaną procedurę reagowania, która wymienia i usuwa każdy publicznie ujawniony klucz API.
  • Wymagaj uwierzytelniania dwuskładnikowego i regularnie przeglądaj uprawnienia Teammate.

Wpływ na biznes

  • Nieautoryzowane użycie konta może narazić odbiorców na wiadomości stanowiące nadużycie i nadszarpnąć reputację nadawcy, z której korzystają legalne wiadomości biznesowe.

Uwagi dostawcy

  • IP Access Management w SendGrid obejmuje dostęp przez UI, API i SMTP relay, ale błędna lista dozwolonych (allowlist) może odciąć legalnych użytkowników.

Otwarte pytania

  • Nie ma bieżącego komunikatu od dostawcy, powiadomienia na koncie ani listy zasobów objętych incydentem, więc z samego pytania nie da się wywnioskować konkretnego zakresu incydentu.
  • Ustalenie, czy ujawniono klucze API, poświadczenia użytkowników, członków zespołu (Teammate), domeny wysyłkowe, szablony, listy czy sekrety webhooków, wymaga komunikatu od dostawcy i danych audytowych z Twojego konta (tenant).
  • Wstrzymanie wysyłki jest warunkowe i zależy od dowodów nieautoryzowanego dostępu lub wysyłki; aktualna dokumentacja bezpieczeństwa SendGrid nie nakazuje globalnego wstrzymania wysyłki po każdym incydencie u dostawcy.
Źródła (6)
  1. Secure your Twilio account — IntroductionTwilio SendGrid
  2. Secure your Twilio account — Rotate out exposed keysTwilio SendGrid
  3. Authentication — API keyTwilio SendGrid
  4. IP Access Management — What is IP access management? and Enable IP access managementTwilio SendGrid
  5. Authentication — Two-factor authenticationTwilio SendGrid
  6. Secure your Twilio account — Review Teammate accessTwilio SendGrid

Co klienci Twilio powinni sprawdzić po wystawieniu Kubernetes NodePort?

Poziom ważności: WysokiWstrzymanie wysyłki: Kontynuuj wysyłkę

Najpierw ustal, czy Twój tenant znalazł się wśród klientów, których Twilio powiadomiło o wystawieniu SendGrid z czerwca 2021 r., a potem sprawdź każdą uwierzytelnioną domenę. Wystawienie miało charakter historyczny i nie dowodzi bieżącej kompromitacji. Dla objętej incydentem domeny z ręcznym trybem bezpieczeństwa (manual security) zweryfikuj nowe uwierzytelnienie i rekordy DNS, zanim usuniesz oryginalną konfigurację.

Pierwsze 15 minut

  1. Sprawdź każdą uwierzytelnioną domenę na koncie i ustal, czy jej konfiguracja z 2021 r. używała trybu automatycznego czy ręcznego.
  2. Ustal, czy każda domena objęta incydentem używała trybu automatycznego czy ręcznego, i sprawdź wszystkie domeny na koncie.

Teraz

  • Rozpocznij udokumentowaną procedurę wymiany uwierzytelnienia dla każdej objętej incydentem domeny z ręcznym trybem bezpieczeństwa.

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 dopiero po tym, jak nowe uwierzytelnienie przejdzie weryfikację i zachowana zostanie ciągłość podpisywania.

Kontrole techniczne

IT / DNS

  • Zinwentaryzuj każdą uwierzytelnioną domenę, jej tryb bezpieczeństwa i selektor DKIM, ponieważ jedno konto może łączyć konfiguracje automatyczne i ręczne.
  • Wskaż, które objęte incydentem domeny z ręcznym trybem bezpieczeństwa wymagają rotacji kontrolowanej przez klienta.

Bezpieczeństwo

  • Uzgodnij wykaz tenantów i domen z powiadomieniem dla klientów objętych incydentem. Sprawdź każdą domenę, a nie tylko próbkę z konta.

Kryteria weryfikacji

  • Każda objęta incydentem domena w trybie ręcznym ma zweryfikowane nowe uwierzytelnienie i komplet rekordów DNS, zanim usuniesz jej oryginalną konfigurację.
  • Każda ręczna wymiana używa nowego selektora i ma zweryfikowane rekordy DNS, zanim usuniesz oryginalną konfigurację.

Kryteria eskalacji

  • Eskaluj sprawę do Twilio SendGrid oraz do zespołu bezpieczeństwa, gdy nie da się uzgodnić statusu klienta objętego incydentem ani trybu bezpieczeństwa którejkolwiek uwierzytelnionej domeny.

Zapobieganie

  • Utrzymuj kompletny spis uwierzytelnionych domen, selektorów oraz trybów bezpieczeństwa — automatycznych i ręcznych.
  • Wymagaj weryfikacji nowego uwierzytelnienia, zanim usuniesz istniejące ręczne uwierzytelnienie domeny.

Wpływ na biznes

  • Nierozwiązane ujawnienie prywatnego klucza DKIM podważa zaufanie do uwierzytelnienia domeny objętej incydentem, dopóki nie zweryfikujesz statusu rotacji dla danego tenanta.

Uwagi dostawcy

  • Twilio poinformował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 dowodzi, że taki dostęp był niemożliwy.

Otwarte pytania

  • Ostrzeżenie podaje, że bezpośrednio dotknięci klienci otrzymali wiadomość e-mail. Pytanie nie rozstrzyga, czy ten konkretny tenant dostał takie powiadomienie.
  • Nie znamy aktualnej listy uwierzytelnionych domen na koncie ani tego, czy w 2021 r. używały trybu automatycznego czy ręcznego.
  • Twilio na etapie dochodzenia nie wykazało śladów nieautoryzowanego dostępu. Bez historycznych logów i dowodów na użycie klucza nie da się jednak ani potwierdzić, ani wykluczyć nadużyć po stronie konkretnego tenanta.
Źródła (6)
  1. Details on Misconfigured Kubernetes NodePorts — What happened?Twilio SendGrid
  2. Details on Misconfigured Kubernetes NodePorts — What happened?Twilio SendGrid
  3. Details on Misconfigured Kubernetes NodePorts — Determining if your keys will be automatically rotatedTwilio SendGrid
  4. Details on Misconfigured Kubernetes NodePorts — How to manually rotate manual security keysTwilio SendGrid
  5. Details on Misconfigured Kubernetes NodePorts — Determining if your keys will be automatically rotatedTwilio SendGrid
  6. Details on Misconfigured Kubernetes NodePorts — How to manually rotate manual security keysTwilio SendGrid

Powiązane zasoby

Wojtek BlazalekWojtek BlazalekEkspert ds. dostarczalności e-mail

Masz incydent z pocztą? Pomagam zespołom przywrócić dostarczanie, reputację i uwierzytelnianie do normy.

Praktyczna praca nad dostarczalnością dla firm wysyłających na dużą skalę

Umów bezpłatną rozmowę diagnostycznąZobacz usługi
Umów bezpłatną rozmowę diagnostyczną