Złożone scenariusze routingu i błędne konfiguracje wykorzystywane do spoofingu domen w phishingu - Security Bez Tabu

Złożone scenariusze routingu i błędne konfiguracje wykorzystywane do spoofingu domen w phishingu

Wprowadzenie do problemu / definicja luki

Na początku stycznia 2026 Microsoft opisał kampanie phishingowe, w których atakujący podszywają się pod domenę ofiary, tak aby wiadomości wyglądały jak wysłane „z wewnątrz” organizacji. Kluczowy nie jest tu „0-day”, tylko kombinacja złożonego routingu poczty (MX nie wskazuje bezpośrednio na Microsoft 365/Exchange Online) oraz słabo egzekwowanych mechanizmów anty-spoofingowych.

W praktyce to problem klasy „security by configuration”: środowisko działa, poczta dochodzi, ale w pewnych ścieżkach dostarczania tworzy się luka pozwalająca wstrzyknąć e-mail z Internetu, który odbiorcy (i część filtrów) potraktują jak wewnętrzny.

W skrócie

  • Atakujący wykorzystują złożone scenariusze routingu (np. bramka zewnętrzna/urządzenie, hybryda, przekaźniki), gdy MX nie jest skierowany bezpośrednio do Office 365.
  • Skuteczność rośnie, bo e-mail wygląda jak internal spoof (często „To” i „From” są takie same), co zwiększa szanse kliknięcia.
  • Microsoft podkreśla, że to nie jest podatność funkcji Direct Send, tylko efekt routingu i polityk.
  • Remediacja sprowadza się do: DMARC na reject, SPF hard fail (-all), oraz poprawnego „domknięcia” ścieżek mail flow (connectory, dozwolone źródła, filtrowanie).

Kontekst / historia / powiązania

Według Microsoftu wektor nie jest nowy, ale zyskał na widoczności i skali od maja 2025. Kampanie są często oportunistyczne i korzystają z ekosystemu phishing-as-a-service (PhaaS) (m.in. Tycoon2FA), a przynęty obejmują pocztę głosową, dokumenty do podpisu/udostępnienia, HR, reset hasła czy faktury.

Warto też zanotować „sygnał skali”: Microsoft wskazuje, że w październiku 2025 Defender for Office 365 blokował >13 mln wiadomości powiązanych z Tycoon2FA (w tym wiele z podszyciem pod domeny wewnętrzne).

Analiza techniczna / szczegóły luki

1) Gdzie powstaje „dziura” – routing i punkty wejścia

Microsoft wyraźnie rozdziela dwie sytuacje:

  • MX wskazuje bezpośrednio na Office 365 → tenant jest objęty natywnymi mechanizmami anty-spoofing i ten wektor „nie dotyczy” takich klientów.
  • MX NIE wskazuje bezpośrednio na Office 365 (np. najpierw bramka/serwer pośredni/3rd party) + brak twardych polityk anty-spoofing → atakujący mogą dostarczyć e-mail, który „wygląda” jak wewnętrzny.

To klasyczny problem „wiele dróg do skrzynki”. Organizacja projektuje oficjalny tor dostarczania (np. Internet → gateway → M365), ale nie domyka alternatywnych ścieżek (Internet → bezpośrednio do M365) albo niewłaściwie konfiguruje connectory i reguły zaufania.

2) Dlaczego SPF/DKIM/DMARC nie zawsze ratują

Mechanizmy uwierzytelniania poczty opierają się o:

  • SPF: autoryzacja hostów wysyłających (sprawdzanie „MAIL FROM” / Return-Path)
  • DMARC: polityka i raportowanie oparte na wynikach SPF/DKIM, z kluczowym pojęciem alignment (dopasowanie domeny w „From” do domen użytych w SPF/DKIM)

W opisywanym scenariuszu problemem bywa nie tylko sam brak rekordów, ale zbyt łagodne decyzje:

  • SPF ustawiony „miękko” (softfail ~all) zamiast twardego odrzucenia (-all)
  • DMARC w trybie obserwacji (p=none) lub bez realnej egzekucji (brak quarantine/reject)
  • lub błędne założenia w mail flow, które powodują, że wiadomość przechodzi inną ścieżką niż przewidziana i kontrole są niespójne.

Microsoft wskazuje wprost: DMARC „reject” + SPF hard fail oraz poprawna konfiguracja connectorów stron trzecich mają zablokować ten typ spoofingu.

3) Jak to wygląda w wiadomości i nagłówkach

Warianty, które opisuje Microsoft, często mają charakter „internal-looking phish”:

  • adres odbiorcy pojawia się jednocześnie w polach „To” i „From” (albo „From” to inny poprawny adres wewnętrzny), co u użytkownika buduje fałszywe poczucie, że to komunikacja wewnętrzna
  • w nagłówkach można dostrzec zewnętrzny adres IP inicjujący wysyłkę, a wyniki uwierzytelnienia mogą wyglądać jak: SPF soft/hard fail, DMARC fail, DKIM = none (szczególnie gdy nadawca i odbiorca „wydają się” być w tej samej domenie).

4) Dlaczego connectory mają znaczenie

W środowiskach z bramkami i złożonym routowaniem częstym błędem jest „ufanie” ruchowi przychodzącemu bez wystarczającej walidacji źródła. Microsoft opisuje też, że dla scenariuszy z connectorami istnieją mechanizmy, które trzeba skonfigurować poprawnie (np. enhanced filtering for connectors), bo w przeciwnym razie sygnały reputacyjne/anty-spoofing mogą być mylone przez pośredników.

Praktyczne konsekwencje / ryzyko

Najgroźniejszy aspekt tego wektora jest psychologiczny i operacyjny: phishing „z wewnątrz” omija część heurystyk użytkownika („to od IT/HR, wygląda jak firmowe”) i bywa skuteczniejszy niż typowe spoofingi.

Skutki, które wymienia Microsoft, to m.in.:

  • przejęcie poświadczeń i dalsze nadużycia,
  • BEC (Business Email Compromise) i oszustwa finansowe,
  • kradzież danych oraz kosztowna remediacja (reset haseł, sesji, dochodzenie, czyszczenie reguł skrzynek, itp.).

Jeśli kampania korzysta z PhaaS i technik AiTM, może też ograniczać skuteczność samych mechanizmów MFA (np. przechwycenie tokenów sesji), co dodatkowo podnosi ryzyko incydentu tożsamościowego.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które wprost adresują opisany wektor (kolejność: od „najbardziej blokujących” po „diagnostyczne”).

1) Uporządkuj DMARC/SPF (twarda egzekucja)

  • DMARC: dąż do p=reject (co najmniej quarantine jako etap przejściowy) i upewnij się, że masz sensowne rua do raportów. DMARC definiuje też alignment — bez niego „pass” SPF/DKIM nie zawsze znaczy „wiarygodny From”.
  • SPF: jeśli to możliwe, stosuj hard fail -all i dbaj o to, by SPF nie był „przepełniony” lub rozjechany z realnymi nadawcami (aplikacje, CRM, marketing, helpdesk). SPF formalnie opisuje, jak domena autoryzuje hosty wysyłające.
  • Dopilnuj, aby „From” używany przez systemy wysyłające był zgodny z domenami, które umieszczasz w politykach (alignment i spójność nadawców).

2) Domknij ścieżki dostarczania (najczęstszy błąd)

Jeśli masz gateway/3rd party przed M365:

  • zidentyfikuj wszystkie możliwe drogi: Internet → gateway → M365, ale też Internet → M365 bezpośrednio,
  • skonfiguruj tak, by M365 akceptował pocztę tylko z przewidzianych źródeł (np. IP bramki / określone connectory), a nie „z całego Internetu”.

To jest sedno, bo sam fakt posiadania bramki nie chroni, jeśli atakujący może ominąć ją i dostarczyć e-mail inną ścieżką w Twoim mail flow.

3) Zweryfikuj connectory i filtrowanie w środowiskach z pośrednikami

W scenariuszach z connectorami sprawdź m.in. mechanizmy typu enhanced filtering for connectors, żeby systemy ochrony widziały właściwy „oryginalny” kontekst nadawcy, a nie tylko adresy pośredników.

4) Włącz i stroń mechanizmy anty-spoofing w M365/Defender

  • Skorzystaj z funkcji raportowania i analizy spoofingu (spoof intelligence / anti-spoofing), aby szybko identyfikować nietypowe źródła i podszycia.
  • Jeżeli masz Defender for Office 365, dopnij polityki anti-phishing/impersonation do poziomu Twojego ryzyka (szczególnie dla VIP, finansów, HR).

5) Threat hunting i detekcje (praktyczne sygnały)

Sygnały, które warto objąć regułami/alertami:

  • wiadomości, gdzie From = To albo „From” wskazuje wewnętrzny adres, a źródło (Received chain) jest zewnętrzne,
  • anomalie DMARC/SPF/DKIM (np. DMARC fail, DKIM none przy „wewnętrznym” From),
  • nagłe wzrosty tematyki „voicemail”, „password expiring”, „shared document”, „invoice” itp. (częste przynęty w opisie Microsoftu).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

To nie jest klasyczny:

  • „display name spoofing” (gdzie oszust liczy na nieuwagę w nazwie wyświetlanej),
  • „lookalike domain” (podobna domena, np. rn zamiast m),
  • ani „reply-to injection”.

W tym przypadku przewaga atakującego polega na tym, że e-mail wygląda jak realnie wewnętrzny (domena i adres nadawcy są „Twoje”), bo konfiguracja routingu i polityk dopuszcza taki scenariusz. Microsoft podkreśla też, że nie chodzi o podatność Direct Send, tylko o architekturę mail flow i egzekucję zasad.

Podsumowanie / kluczowe wnioski

  • „Internal domain spoofing” może wynikać z architektury routingu, nie z błędu w oprogramowaniu.
  • Najbardziej narażone są organizacje, które mają MX poza O365 i nie „domknęły” alternatywnych ścieżek oraz connectorów.
  • Minimalny zestaw naprawczy to: DMARC p=reject, SPF -all, poprawne reguły i connectory (w tym enhanced filtering), plus monitorowanie spoofingu.

Źródła / bibliografia (maks. 5)

  1. Microsoft Security Blog — Phishing actors exploit complex routing and misconfigurations to spoof domains (6 stycznia 2026). (Microsoft)
  2. SecurityWeek — Complex Routing, Misconfigurations Exploited for Domain Spoofing in Phishing Attacks (7 stycznia 2026). (SecurityWeek)
  3. IETF RFC 7489 — DMARC. (IETF Datatracker)
  4. IETF RFC 7208 — SPF. (IETF Datatracker)
  5. Microsoft Learn — Enhanced filtering for connectors in Exchange Online (best practices dla złożonego mail flow). (Microsoft Learn)