Luka Ghost-Sender w Exchange Online: co sprawdzić poza DMARC
Nowo udokumentowana luka w Exchange Online przepuszcza sfałszowaną pocztę, mimo że nie przechodzi ona SPF, DKIM ani DMARC. Sprawdź to w swoim tenancie.
Ghost-Sender to nowo udokumentowana luka w sposobie, w jaki Microsoft Exchange Online przyjmuje pocztę przychodzącą. Pozwala atakującemu dostarczyć fałszywy email, który wygląda, jakby pochodził od współpracownika lub zaufanej marki, mimo że wiadomość nie przechodzi żadnej kontroli uwierzytelniania mającej wychwytywać sfałszowaną pocztę. Badacze bezpieczeństwa z InfoGuard opublikowali tę technikę 9 czerwca 2026 roku, a Microsoft zaklasyfikował ją jako znane ograniczenie architektoniczne, a nie błąd, który zamierza naprawić.
Luka dotyczy organizacji, które kierują pocztę przychodzącą przez zewnętrzny filtr antyspamowy, zanim trafi ona do Microsoft 365. Taka konfiguracja jest powszechna, zwłaszcza w firmach, których dział IT obsługuje agencja lub dostawca usług. Wymuszanie polityki DMARC to typowa obrona przed spoofingiem, ale nie zatrzymuje tego ataku, ponieważ sfałszowana poczta wchodzi ścieżką, na której werdykt DMARC nigdy nie jest egzekwowany. Poniższe sekcje wyjaśniają, jak działa ta technika, dlaczego samo uwierzytelnianie nie jest w stanie jej zatrzymać i które ustawienia Microsoft 365 zamykają tę lukę.
Co znajdziesz w tym przewodniku
- Czym jest luka Ghost-Sender?
- Jak atakujący omijają filtrowanie Exchange Online
- Dlaczego SPF, DKIM i DMARC tego nie wychwytują?
- Odpowiedź Microsoftu: „znane ograniczenie architektoniczne”
- Czy jesteś narażony? Jak sprawdzić swoją konfigurację Exchange Online
- Co robić teraz: praktyczne środki zaradcze
- Praktyczny wniosek
Czym jest luka Ghost-Sender?
Ghost-Sender to technika dostarczania sfałszowanych wiadomości do skrzynek Microsoft 365. Wiadomość podaje się za wysłaną przez zaufanego współpracownika lub znaną markę. Mechanizmy uwierzytelniania rozpoznają to twierdzenie jako fałszywe, a Exchange Online i tak dostarcza wiadomość.
Badacze z InfoGuard ujawnili tę technikę publicznie 9 czerwca 2026 roku. Podczas ich testów wiadomość podająca się za wysłaną z adresu noreply@microsoft.com dotarła do skrzynki z negatywnym wynikiem każdej kontroli: SPF nie przeszedł, brakowało DKIM, a DMARC zakończył się niepowodzeniem. Takie wyniki normalnie oznaczają, że wiadomość zostaje odrzucona albo trafia do folderu spam. Ta jednak została dostarczona.
Ta technika nie wymaga skradzionych haseł ani zmian w DNS ofiary. Wykorzystuje sposób, w jaki Exchange Online kieruje pocztą przychodzącą, więc działa nawet wobec domeny, której rekordy SPF, DKIM i DMARC są poprawnie skonfigurowane.
Jak atakujący omijają filtrowanie Exchange Online
Wiele organizacji nie kieruje rekordów pocztowych swojej domeny bezpośrednio do Microsoftu. Przed nim ustawiają zewnętrzną bramę bezpieczeństwa: filtr chroniący przed spamem i złośliwym oprogramowaniem, od dostawcy takiego jak Proofpoint, Mimecast czy Barracuda. Ich rekord MX (wpis DNS, który mówi światu, gdzie dostarczać pocztę) wskazuje na ten filtr, a nie na Microsoft. Poczta powinna płynąć w jednym kierunku: z internetu do filtra, z filtra do Microsoftu, z Microsoftu do skrzynki.
Problem w tym, że własny adres dostarczania Microsoftu pozostaje osiągalny przez cały czas. Każda organizacja Microsoft 365 (w terminologii Microsoftu „tenant”) ma bezpośredni adres dostarczania w postaci yourdomain.mail.protection.outlook.com, który przyjmuje pocztę od kogokolwiek w internecie. Atakujący, który wysyła na ten adres, trafia bezpośrednio do Exchange Online i całkowicie pomija zewnętrzny filtr. Filtr nigdy nie widzi wiadomości, więc żadna z jego reguł chroniących przed spoofingiem czy phishingiem się nie uruchamia.
Ponieważ wiadomość przychodzi przez własną infrastrukturę Microsoftu, Exchange Online traktuje ją z większym zaufaniem niż wiadomość przychodzącą z otwartego internetu. To błędnie ulokowane zaufanie jest sednem tej luki.
Dlaczego SPF, DKIM i DMARC tego nie wychwytują?
SPF, DKIM i DMARC to kontrole, które serwer poczty odbierającej wykonuje, aby zdecydować, czy wiadomość naprawdę pochodzi z domeny widniejącej w polu From. Są podstawową obroną przed spoofingiem domeny i zatrzymują zdecydowaną większość takich prób.
Ghost-Sender nie pokonuje tych kontroli. Omija ten moment w procesie dostarczania, w którym ich wynik jest brany pod uwagę. Sfałszowana wiadomość faktycznie nie przechodzi wszystkich trzech, dokładnie tak, jak pokazał test InfoGuard. Ale poczta została już przyjęta pod bezpośrednim adresem dostarczania Microsoftu, a Exchange Online nie stosuje tego samego wymuszania DMARC wobec poczty, którą traktuje jako wewnętrzną. Werdykt uwierzytelniania brzmi „fail”, a wiadomość i tak zostaje dostarczona.
Nic z tego nie oznacza, że DMARC jest opcjonalny. DMARC nadal pozostaje mechanizmem, który zatrzymuje codzienny spoofing: sfałszowane faktury od dostawców, fałszywe polecenia przelewów rzekomo od zarządu i phishing z domen łudząco podobnych, który nigdy nie dociera do twojego punktu końcowego Exchange. Ghost-Sender to wąski wyjątek architektoniczny i nie zmienia nic w tym, dlaczego potrzebujesz DMARC jako fundamentu.
Wiadomości sfałszowane w ten sposób trafiają na infrastrukturę, gdzie i tak trudno utrzymać czyste uwierzytelnianie. Według raportu branżowego DMARCeye za I kwartał 2026 poczta przypisana do infrastruktury Microsoftu wykazała 90,0% zgodności, przy czym SPF nie przechodził dla 26,6% wiadomości, a DKIM dla 19,6%. Znacząca część legalnej poczty pochodzącej z Microsoftu już teraz nie uwierzytelnia się czysto. Jak zauważa raport za I kwartał, niska zgodność u dużego dostawcy to niemal zawsze problem konfiguracji po stronie nadawcy, a nie wada samej platformy. Zwykłe przyczyny to klienci, którzy nie dodali właściwych kluczy DKIM do swojego DNS, albo których wolumen wysyłki przerósł ich rekord SPF.
Nie chodzi o to, że poczta Microsoftu jest słaba. Chodzi o to, że przepływ poczty w Microsoft 365 jest skomplikowany do poprawnego skonfigurowania, a Ghost-Sender wykorzystuje jedną konkretną lukę w sposobie, w jaki poprowadzone jest trasowanie poczty przychodzącej.
Pełny raport możesz pobrać tutaj:
Odpowiedź Microsoftu: „znane ograniczenie architektoniczne”
InfoGuard zgłosił problem Microsoftowi 21 kwietnia 2026 roku. Microsoft wdrożył wewnętrzny środek zaradczy następnego dnia, po czym wycofał go 27 kwietnia. 29 maja 2026 roku Microsoft zaklasyfikował Ghost-Sender jako znane ograniczenie architektoniczne, a nie podatność produktu, i na ten dzień nie istniała żadna poprawka na poziomie platformy.
W praktyce oznacza to, że odpowiedzialność za zamknięcie tej luki spoczywa na każdej organizacji, a nie na poprawce, która przychodzi automatycznie. Microsoft zaostrza powiązane ustawienia domyślne i nowe tenanty mają teraz Direct Send (funkcję, na której opiera się atak) domyślnie odrzucany, po zmianie, którą Microsoft zaczął wdrażać na początku 2026 roku. Istniejące tenanty zachowują obecną konfigurację, dopóki administrator jej nie zmieni.
Jeśli korzystasz z Microsoft 365 z zewnętrznym filtrem, nie możesz czekać na poprawkę. Musisz sam sprawdzić i dostosować konfigurację.
Czy jesteś narażony? Jak sprawdzić swoją konfigurację Exchange Online
Jesteś potencjalnie narażony, jeśli spełnione są dwa warunki: twoja organizacja korzysta z Microsoft 365 (lub Exchange w trybie hybrydowym), a rekord MX twojej domeny wskazuje na zewnętrzny filtr zamiast bezpośrednio na Microsoft. Dotyczy to dużej części zarządzanych tenantów, ponieważ umieszczenie dedykowanej bramy bezpieczeństwa przed Microsoftem to powszechne rozwiązanie.
Skanowanie przeprowadzone przez InfoGuard wykazało, że ponad 20% domen Exchange Online testowanych w ramach programów bug bounty wydawało się podatnych, a mniej niż połowa środowisk używających zewnętrznego rekordu MX miała wdrożone jakiekolwiek zabezpieczenie.
Aby sprawdzić tenant, przejdź przez trzy pytania:
- Gdzie wskazuje rekord MX? Jeśli wskazuje gdzieś indziej niż
*.mail.protection.outlook.com, poczta jest kierowana przez podmiot zewnętrzny, a bezpośredni punkt końcowy Microsoftu pozostaje odsłonięty. - Czy łącznik przychodzący jest ograniczony? W centrum administracyjnym Exchange przejrzyj swoje łączniki przychodzące. Łącznik, który ogranicza nadawców według zakresu adresów IP lub certyfikatu TLS, to mechanizm zamykający tę lukę. Jeśli takiego ograniczenia nie ma, tenant jest prawdopodobnie otwarty.
- Czy Direct Send jest włączony? Direct Send pozwala poczcie docierać do skrzynek bez uwierzytelniania. Jeśli jest włączony i żadna reguła transportu tego nie rekompensuje, sfałszowana poczta może się przedostać.
Co robić teraz: praktyczne środki zaradcze
Dwie konfiguracje niezawodnie blokują Ghost-Sender, a własny mechanizm kontroli Direct Send Microsoftu dodaje trzecią warstwę.
- Ogranicz łącznik przychodzący. Utwórz lub dostosuj łącznik przychodzący typu Partner Organization tak, aby obejmował pocztę z dowolnej domeny i przyjmował tylko wiadomości, które przechodzą walidację zakresu adresów IP lub certyfikatu TLS. To każe Exchange Online ufać poczcie przychodzącej z adresów twojego filtra, a nie od kogokolwiek, kto przypadkiem znajdzie bezpośredni adres dostarczania.
- Poddaj kwarantannie niezaufaną pocztę udającą wewnętrzną. Dodaj regułę przepływu poczty o najwyższym priorytecie (priorytet 0), która poddaje kwarantannie każdą wiadomość przychodzącą niezawierającą nagłówka
X-MS-Exchange-Organization-AuthAs: Internalz zatwierdzonego źródła lub niepochodzącą z twoich zatwierdzonych zakresów adresów IP. Mówiąc wprost, wychwytuje to pocztę, która podaje się za wewnętrzną, ale nie dotarła zaufaną ścieżką. - Wyłącz Direct Send. Direct Send to funkcja Microsoft 365, która pozwala urządzeniom i aplikacjom wysyłać pocztę przez tenant bez uwierzytelniania. Wyłączenie jej (ustawienie
RejectDirectSend) usuwa konkretną ścieżkę, którą wykorzystuje Ghost-Sender. Najpierw upewnij się, że twoje legalne drukarki, skanery i aplikacje biznesowe korzystają z uwierzytelnionego łącznika.
To nie jest problem DMARC, lecz problem konfiguracji Microsoft 365 z rozwiązaniem po stronie Microsoft 365. To, co dodaje monitoring DMARC, to widoczność. Gdy sfałszowana wiadomość nie przechodzi SPF, DKIM i DMARC, Microsoft i tak rejestruje to niepowodzenie i uwzględnia je w twoich zbiorczych raportach DMARC. Narzędzie, które czyta te raporty za ciebie, pokazuje sfałszowaną, nieuwierzytelniającą się pocztę wysyłaną jako twoja domena ze źródeł, których nie rozpoznajesz. To dokładnie ten sygnał, że technika taka jak Ghost-Sender jest używana przeciwko tobie. Darmowy plan DMARCeye obejmuje jedną domenę i zamienia surowe dane z raportów w zrozumiały obraz tego, kto wysyła jako ty i co zawodzi.
Jeśli chcesz zobaczyć, co twoja domena publikuje w tej chwili, zacznij od jej aktualnego rekordu DMARC:
Praktyczny wniosek
Bezpieczeństwo poczty działa warstwowo i żadna pojedyncza warstwa nie obejmuje wszystkiego. DMARC to niezbędny fundament: uwierzytelnia domenę w twoim polu From i zatrzymuje szeroką kategorię spoofingu, która stanowi większość oszustw e-mailowych. Ta luka go nie osłabia. To, co luka odsłania, to inna warstwa: zaufanie, jakim Microsoft 365 obdarza własny wewnętrzny przepływ poczty. DMARC nigdy nie był projektowany, by zarządzać tą warstwą, i tylko twoja konfiguracja Microsoft 365 może ją zabezpieczyć.
Dla agencji i dostawców IT komunikat do klienta łączy obie części naraz: utrzymaj wymuszanie DMARC, ponieważ zatrzymuje większość spoofingu, i zamknij lukę w Exchange Online, ponieważ DMARC nie jest w stanie do niej sięgnąć.
Ta dwuczęściowa odpowiedź to praca, którą uważamy za najważniejszą. DMARCeye istnieje po to, by dać ludziom jasny wgląd w to, kto wysyła jako ich domena, oraz by wyjaśniać spoofing, realne ryzyko, jakie ze sobą niesie, i rozwiązania, które działają, w tym te opisane tutaj, które wykraczają poza sam DMARC.