BEZPIECZEŃSTWO MICROSOFT 365 8 min czytania

Greatness atakuje Microsoft 365. Jak błędna lista zaufanych nadawców przepuściła phishing mimo DMARC?

Wiadomości Greatness nie przeszły SPF, DKIM ani DMARC, ale dotarły do skrzynek. Sprawdź, jak błędna lista zaufanych nadawców otworzyła drogę do phishingu.

Wiadomość wyglądała jak powiadomienie od RingCentral. Informowała o poczcie głosowej albo ocenie pracowniczej i prowadziła do strony logowania Microsoft 365. Nie pochodziła jednak z infrastruktury RingCentral, nie miała podpisu DKIM, a kontrole SPF i DMARC zakończyły się wynikiem FAIL. Polityka DMARC nadawcy nakazywała odrzucenie takiej wiadomości.

Mimo to e-mail trafił do skrzynki odbiorczej.

Nie dlatego, że napastnicy złamali SPF, DKIM lub DMARC. Mechanizmy prawidłowo rozpoznały fałszywą wiadomość. Zawiodła konfiguracja organizacji: domena podszywanego dostawcy znajdowała się na liście zaufanych nadawców, a wyjątek nadał wiadomości poziom SCL=-1, czyli polecenie pominięcia standardowego filtrowania spamu.

To najważniejsza lekcja z analizy kampanii Greatness opublikowanej przez ZeroBEC: dobre zabezpieczenia mogą wydać poprawny werdykt, a źle zaprojektowany wyjątek administracyjny może ten werdykt przesłonić.

Wiadomość, która nie powinna trafić do skrzynki

ZeroBEC opisał cztery wiadomości wysłane 22 lipca 2026 roku do jednej organizacji w odstępie zaledwie kilku sekund. Pole From wskazywało service@ringcentral.com, a nazwa nadawcy była dopasowana do domeny atakowanej firmy. Tematy wywoływały presję: pilna ocena pracownicza, gotowy przegląd wyników lub wiadomość głosowa wymagająca otwarcia.

Nagłówki mówiły coś zupełnie innego niż widoczny nadawca:

Mechanizm	Wynik	Co wynikało z nagłówków
SPF	FAIL	Serwer `212.227.146[.]181` nie był uprawniony do wysyłania poczty dla domeny RingCentral.
DKIM	NONE	Wiadomość nie zawierała podpisu kryptograficznego domeny.
DMARC	FAIL	Nadawca publikował politykę `p=reject`, więc nieuwierzytelniona wiadomość powinna zostać odrzucona.
SCL	-1	Konfiguracja odbiorcy nakazała pominąć filtrowanie spamu i potraktować wiadomość jako bezpieczną.

Wiadomość została wysłana z serwera IONOS/1&1 Mail, następnie przeszła przez pośredniczącą bramę i Microsoft 365 EOP. Organizacja była prawdziwym klientem RingCentral i wcześniej dodała domenę dostawcy do wyjątków. Atakujący nie musiał przejmować konta RingCentral. Wystarczyło, że wpisał jego adres w polu nadawcy.

Microsoft ostrzega, że szerokie wpisy na listach dozwolonych nadawców i domen są ryzykowne, ponieważ domenę można podrobić. Dokumentacja zaleca bardzo wąskie warunki wyjątków oraz sprawdzanie, co ustawiło wartość SCL. Warto przy tym zachować precyzję: SCL=-1 omija standardowe filtrowanie spamu, lecz nie oznacza automatycznego wyłączenia każdej warstwy. W typowej konfiguracji nadal działają m.in. skanowanie malware oraz ochrona przed phishingiem o wysokiej pewności. W badanym przypadku wiadomości nie otrzymały jednak takiego werdyktu i dotarły do skrzynki odbiorczej.

Fałszywa wiadomość przechodzi przez trzy zakończone niepowodzeniem kontrole, ponieważ zielony wyjątek administratora otwiera bramę do skrzynki

SPF, DKIM i DMARC mogą poprawnie wskazać problem, a zbyt szeroki wyjątek nadal skieruje wiadomość do skrzynki.

SPF, DKIM i DMARC zadziałały prawidłowo

W tym przypadku trzeba rozdzielić trzy decyzje, które łatwo wrzucić do jednego worka:

uwierzytelnianie nadawcy sprawdza, czy serwer i podpis wiadomości są powiązane z deklarowaną domeną;
ocena antyspamowa i antyphishingowa analizuje treść, reputację, linki oraz zachowanie wiadomości;
reguła administratora może zmienić sposób obsługi wiadomości, nawet gdy wcześniejsze sygnały są negatywne.

Najprostsza analogia brzmi: system alarmowy prawidłowo rozpoznał intruza, ale administrator wcześniej dodał deklarowaną przez niego nazwę do listy osób wpuszczanych bez standardowej kontroli.

DMARC nie jest samodzielnym filtrem treści. Łączy wynik SPF lub DKIM z domeną widoczną w polu From i przekazuje odbiorcy politykę postępowania. Tutaj wynik FAIL był prawidłowy. Problem pojawił się później, gdy lokalna decyzja o zaufaniu domenie okazała się ważniejsza dla ścieżki dostarczenia.

Dlaczego zaufana domena może stać się przepustką dla phishingu

Wpisanie całej domeny popularnej usługi do allowlisty w praktyce może oznaczać: „ogranicz kontrolę każdej wiadomości, która twierdzi, że pochodzi z tej domeny”. Sam adres widoczny w Outlooku nie dowodzi autentyczności, bo nadawca może go zadeklarować dowolnie.

Najczęściej problem tworzą:

całe domeny dostawców SaaS dodane do wyjątków po pojedynczym zgłoszeniu false positive;
reguły Exchange ustawiające SCL=-1 tylko na podstawie adresu lub domeny nadawcy;
pomijanie filtrów dla wiadomości przechodzących przez konektor lub szeroki zakres IP;
wyjątki dla systemów księgowych, CRM, fakturowania i newsletterów bez dodatkowej weryfikacji;
brak właściciela, uzasadnienia, daty wygaśnięcia i okresowego przeglądu wyjątku;
rozbudowane listy bezpiecznych nadawców tworzone samodzielnie przez użytkowników.

Wyjątek powinien być możliwie wąski i opierać się na sygnałach, których atakujący nie może łatwo zadeklarować. Zależnie od architektury poczty może to oznaczać połączenie konkretnego nadawcy z poprawnym uwierzytelnieniem, kontrolowanym konektorem, certyfikatem albo dokładnie określonym nagłówkiem z zaufanego systemu. Nie należy kopiować jednej reguły do każdego środowiska — sposób dostarczania trzeba najpierw potwierdzić z dostawcą.

Co dzieje się po kliknięciu — AiTM i device code phishing

Greatness to usługa PhaaS (Phishing-as-a-Service), czyli gotowy zestaw narzędzi sprzedawany innym przestępcom. Według ZeroBEC w sierpniu 2026 roku kosztował 289 dolarów miesięcznie, oferował jednodniowy okres próbny, panel statystyk, konfigurację domen oraz ponad 11 gotowych przynęt. Platforma łączy dwa warianty przejęcia kont Microsoft 365.

W pierwszym, AiTM (Adversary-in-the-Middle), strona phishingowa pośredniczy między ofiarą a prawdziwym logowaniem. Użytkownik podaje hasło i wykonuje prawdziwe wyzwanie MFA, ale pośrednik przechwytuje już uwierzytelniony token. Napastnik może go później odtworzyć z własnej infrastruktury i uzyskać dostęp bez ponownego wpisywania hasła.

W drugim wariancie, device code phishing, napastnik rozpoczyna legalny proces autoryzacji urządzenia. Ofiara otrzymuje kod i zostaje nakłoniona do wprowadzenia go na prawdziwej stronie Microsoftu. Po zalogowaniu i wykonaniu MFA użytkownik nie autoryzuje jednak własnego urządzenia, lecz sesję rozpoczętą przez napastnika. Greatness automatyzuje generowanie kodu i oczekiwanie na wydanie tokenów.

Dwie ścieżki prowadzące do przekierowania poprawnie uwierzytelnionego tokenu sesji: pośrednik AiTM i autoryzacja nieznanego urządzenia

AiTM pośredniczy w logowaniu, a device code phishing wykorzystuje prawdziwy proces autoryzacji. W obu przypadkach celem jest działający token, nie tylko hasło.

Po przejęciu sesji operatorzy obserwowani przez ZeroBEC sprawdzali Outlook, Teams, SharePoint, OneDrive, kalendarze, kontakty i aplikacje przez Microsoft Graph. Aktywność prowadzili przez komercyjne sieci VPN, a w jednym środowisku dostęp pozostawał aktywny ponad dwa tygodnie. Dlatego sam reset hasła może nie zakończyć incydentu.

Czy MFA chroni przed Greatness?

MFA nadal jest potrzebne, ale nie każda metoda MFA zatrzymuje każdy wariant phishingu.

W ataku AiTM ofiara sama kończy prawdziwe uwierzytelnienie wieloskładnikowe, a przestępca przejmuje wynik tej operacji w postaci tokenu. Powiadomienie push z dopasowaniem numeru ogranicza proste ataki typu MFA fatigue, ale nie rozwiązuje problemu pośrednika pokazującego użytkownikowi prawdziwe wyzwanie.

Metody odporne na phishing, takie jak passkeys/FIDO2 i Windows Hello for Business, są powiązane kryptograficznie z właściwą domeną logowania, dlatego znacznie utrudniają klasyczny AiTM. Microsoft zaleca wymaganie phishing-resistant MFA co najmniej dla kont administracyjnych i innych użytkowników wysokiego ryzyka.

Device code phishing wymaga oddzielnej kontroli. Microsoft rekomenduje dążenie do możliwie pełnej blokady device code flow, pozostawiając go wyłącznie w udokumentowanych i zabezpieczonych przypadkach. Politykę Conditional Access należy najpierw uruchomić w trybie report-only, sprawdzić legalne użycie — np. starsze narzędzia lub wybrane urządzenia — a następnie włączyć blokadę.

Checklista: co sprawdzić w Microsoft 365

Poniższa lista nadaje się jako zakres krótkiego audytu. Każdy wyjątek powinien mieć właściciela, biznesowe uzasadnienie, datę utworzenia i termin ponownej weryfikacji.

Konfiguracja poczty

dozwoleni nadawcy i domeny w politykach antyspamowych;
Tenant Allow/Block List oraz listy bezpiecznych nadawców użytkowników;
reguły Exchange ustawiające SCL=-1 lub „bypass spam filtering”;
IP Allow List, konektory i warunki omijania filtrów;
wyjątki dla księgowości, CRM, faktur, newsletterów i systemów powiadomień;
nagłówki Authentication-Results, X-Forefront-Antispam-Report i X-MS-Exchange-Organization-SCL w wiadomościach, które nieoczekiwanie trafiły do skrzynki odbiorczej;
wartości SFV:SKN, SFV:SKA i SFV:SFE, które pomagają ustalić, czy zadziałała reguła transportowa, lista administratora lub lista użytkownika.

Microsoft Entra ID

logowania wykorzystujące device code flow oraz ich uzasadnienie;
poprawnie działająca polityka Conditional Access blokująca niepotrzebne przepływy;
logowania z nietypowych lokalizacji, hostingu lub adresów VPN;
sesje z prawidłowym MFA, po których pojawia się aktywność z innego adresu IP;
nowe urządzenia, metody uwierzytelniania i zgody dla aplikacji OAuth;
możliwość wymagania phishing-resistant MFA dla administratorów, kierownictwa i osób pracujących z finansami.

Skrzynki użytkowników

ukryte i jawne reguły przenoszące, usuwające lub przekierowujące wiadomości;
forwarding na zewnętrzne adresy i nowe delegacje do skrzynek;
nietypowa aktywność w Outlooku, Teams, SharePoint i Microsoft Graph;
wiadomości wysłane po podejrzanym logowaniu, zwłaszcza prośby o płatność lub zmianę rachunku.

Co zrobić, jeśli użytkownik kliknął

Potraktuj zdarzenie jak możliwe przejęcie sesji, nawet jeśli użytkownik nie pamięta podania hasła.

Zablokuj konto na czas analizy i przerwij podejrzane logowania.
Unieważnij aktywne sesje oraz tokeny odświeżania w Microsoft Entra ID.
Zmień hasło z zaufanego, sprawdzonego urządzenia.
Usuń nieznane metody MFA, urządzenia oraz zgody aplikacji OAuth.
Sprawdź forwarding, delegacje i wszystkie reguły skrzynki, także ukryte.
Przeanalizuj logi Entra ID, Exchange, Microsoft Graph i aplikacji chmurowych od pierwszego podejrzanego zdarzenia.
Ustal, czy z konta wysłano kolejne wiadomości i kto otrzymał tę samą przynętę.
Zachowaj oryginalną wiadomość, pełne nagłówki i logi do dalszej analizy.

Procedura Microsoftu dla przejętego konta pocztowego obejmuje nie tylko zmianę hasła, lecz także unieważnienie sesji, przegląd metod MFA, zgód aplikacji, przekierowań i reguł skrzynki.

Dlaczego biura rachunkowe są szczególnie narażone

Biura rachunkowe codziennie otrzymują faktury, raporty i powiadomienia z wielu zewnętrznych systemów. Gdy ważna wiadomość trafia do spamu, naturalną reakcją bywa dodanie całej domeny do wyjątków „na zawsze”. To tworzy dokładnie ten rodzaj zaufania, który wykorzystano w kampanii Greatness.

Skutki przejęcia skrzynki biura są większe niż utrata pojedynczego hasła. Konto zawiera dokumenty finansowe, dane podatkowe i historię relacji z klientami. Napastnik może poznać prawdziwy obieg faktur, podmienić numer rachunku, ukryć odpowiedzi za pomocą reguł pocztowych, a następnie wysyłać wiarygodne wiadomości z autentycznego konta księgowego.

Najbezpieczniejsze podejście nie polega na zakazaniu wszystkich wyjątków. Polega na ich inwentaryzacji, zawężeniu, powiązaniu z uwierzytelnieniem i regularnym testowaniu.

Najważniejszy wniosek

Greatness nie musiał znaleźć podatności w Microsoft 365 ani „pokonać DMARC”. W opisanym przypadku SPF, DKIM i DMARC wykonały swoją pracę. To lokalna konfiguracja nakazała zaufać wiadomości podszywającej się pod znanego dostawcę.

Jeśli nie wiesz, jakie domeny, nadawcy i reguły omijają ochronę w Twoim środowisku, umów przegląd bezpieczeństwa Microsoft 365. Sprawdzimy filtry, wyjątki, uwierzytelnianie poczty, MFA, Conditional Access, logowania i ryzykowne reguły skrzynek. Otrzymasz listę problemów oraz konkretne zalecenia naprawcze — bez zakłócania działania poczty.