Phishing „z własnej domeny” w Microsoft 365: winne złożone trasowanie

6 stycznia 2026 roku Microsoft Threat Intelligence opisał kampanie phishingowe, w których wiadomość wyglądała jak wysłana z domeny organizacji do jej własnego pracownika. Wektor nie był nową luką w Microsoft 365 ani podatnością Direct Send. Powstawał w środowiskach ze złożonym trasowaniem poczty, gdzie rekord MX nie prowadził bezpośrednio do Exchange Online, a ochrona przed spoofingiem lub konektory stron trzecich były skonfigurowane zbyt łagodnie.

Microsoft obserwował większą widoczność tej techniki od maja 2025 roku. Przynęty dotyczyły poczty głosowej, dokumentów, HR i wygasających haseł; wiele kampanii prowadziło do Tycoon2FA i phishingu adversary-in-the-middle. Firma zaznaczyła, że opisywany wektor nie dotyczył tenantów, których MX wskazywał bezpośrednio na Office 365 i które korzystały z natywnych detekcji.

Dlaczego DMARC fail mógł nie wystarczyć

W poprawnym scenariuszu obcy serwer wysyłający wiadomość z domeną firmy powoduje SPF fail, brak prawidłowego DKIM i DMARC fail, po czym polityka p=reject albo p=quarantine wymusza działanie. Przy trasie przez bramę on-premises, filtr zewnętrzny lub archiwum Exchange Online musi jednak wiedzieć, który host jest zaufanym przekaźnikiem, a gdzie zaczyna się internet.

Zbyt szeroki konektor może oznaczyć wiadomość jako wewnętrzną mimo anonimowego uwierzytelnienia. Microsoft wskazał charakterystyczne zestawienie: InternalOrgSender=True, ale kierunek Incoming, AuthAs=Anonymous, a w Authentication-Results niepowodzenia SPF/DMARC bez skutecznej akcji. To dobry sygnał detekcyjny, lecz należy go korelować — sam nie dowodzi złośliwości.

Jak przeprowadzić audyt bez zakłócania poczty

Zacznij od narysowania rzeczywistej trasy dla przychodzących i wychodzących wiadomości. Porównaj MX z konfiguracją konektorów, reguł transportowych i listą publicznych adresów każdej bramy. Dla domeny ustaw SPF z twardym -all po usunięciu nieużywanych nadawców, włącz DKIM i przechodź do DMARC p=reject na podstawie raportów, zamiast pozostawiać bezterminowe p=none.

Każdy konektor powinien ufać konkretnemu certyfikatowi lub ograniczonemu zakresowi IP, a nie całemu partnerowi czy dowolnej wiadomości z nagłówkiem. Wyślij kontrolowane próbki z nieautoryzowanego źródła i sprawdź, czy zostają odrzucone, nie tylko oznaczone jako spam. Szczegółowy fundament opisujemy w przewodniku SPF, DKIM i DMARC.

Detekcja i odporność użytkownika

Alertuj na połączenie: nadawca i odbiorca w tej samej domenie, kierunek przychodzący, uwierzytelnienie anonimowe i DMARC fail/none. Sprawdź również adres IP pierwszego niezaufanego hopu, nowo utworzone reguły transportowe i wzrost wiadomości z kodami QR lub zewnętrznymi przekierowaniami.

Wygląd „wiadomości wewnętrznej” nie może wyłączać ostrożności. Żądanie płatności, zmiany rachunku lub resetu hasła wymaga osobnego kanału weryfikacji. MFA powinno być odporne na phishing; kody SMS i zatwierdzanie push nie chronią dobrze przed AiTM. Więcej warstw omawiamy w audycie bezpieczeństwa Microsoft 365.

Najważniejsza lekcja: SPF, DKIM i DMARC nie są trzema rekordami do jednorazowego dodania. To system zależny od całej trasy pocztowej. BreachRoad może zweryfikować konfigurację i bezpiecznie zasymulować spoofing.

Testy, które powinny znaleźć się w procedurze zmian

Każda modyfikacja bramy lub konektora powinna uruchamiać zestaw testów regresyjnych. Wiadomość podpisana przez autoryzowany system ma przejść i zachować wynik uwierzytelnienia. Wiadomość z domeną firmy, ale wysłana z nieautoryzowanego IP, ma zostać odrzucona. Forward z legalnej listy mailingowej trzeba obsłużyć bez wyłączenia ochrony dla całej domeny.

Testuj także drogę awaryjną. Organizacje często konfigurują zapasowy MX lub tymczasowy relay, który przez lata pozostaje najsłabszym wejściem. Inwentaryzacja musi objąć urządzenia wielofunkcyjne, systemy fakturowe i marketing automation, bo to one tworzą presję na szerokie wyjątki SPF.

Jak czytać nagłówki bez zgadywania

Zacznij od najniższego niezaufanego wpisu Received, następnie sprawdź Authentication-Results na zaufanej bramie. From widoczny dla użytkownika nie jest tym samym co envelope sender używany przez SPF. DKIM sprawdza podpis domeny d=, a DMARC wymaga alignmentu przynajmniej SPF albo DKIM z domeną widoczną.

Jeżeli filtr przepisał wiadomość lub dodał ARC, trzeba wiedzieć, któremu sealerowi ARC ufa organizacja. ARC nie „naprawia” złego nadawcy; przenosi wynik poprzedniego uwierzytelnienia przez pośrednika.

FAQ

Czy p=reject może zepsuć legalną pocztę? Tak, jeśli nie zinwentaryzowano nadawców. Właśnie dlatego migracja zaczyna się od raportów agregowanych i kontrolowanego zwiększania procentu polityki.

Czy baner „External” wystarczy? Nie. Pomaga użytkownikowi, lecz opisany wektor mógł klasyfikować wiadomość jako wewnętrzną. Kontrola musi działać na uwierzytelnieniu i trasie.

---

Źródła pierwotne: Microsoft Threat Intelligence — complex routing and domain spoofing, Microsoft Learn — enhanced filtering for connectors.