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 (brakquarantine/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 najmniejquarantinejako etap przejściowy) i upewnij się, że masz sensowneruado 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
-alli 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)
- Microsoft Security Blog — Phishing actors exploit complex routing and misconfigurations to spoof domains (6 stycznia 2026). (Microsoft)
- SecurityWeek — Complex Routing, Misconfigurations Exploited for Domain Spoofing in Phishing Attacks (7 stycznia 2026). (SecurityWeek)
- IETF RFC 7489 — DMARC. (IETF Datatracker)
- IETF RFC 7208 — SPF. (IETF Datatracker)
- Microsoft Learn — Enhanced filtering for connectors in Exchange Online (best practices dla złożonego mail flow). (Microsoft Learn)