Phishing Microsoft 365 mimo MFA: przejęcie sesji

Phishing Microsoft 365 wykorzystuje dziś znacznie więcej niż kiepskie wiadomości e-mail i fałszywe strony logowania. Ataki rozpoczynają się na przejętym koncie firmowym, prowadzą do łudząco podobnych lub prawdziwych stron Microsoft, a mimo MFA kończą się dostępem do skrzynki pocztowej, SharePoint lub Teams.

Raport półroczny 2026/1 szwajcarskiego Federalnego Urzędu ds. Cyberbezpieczeństwa dotyczy także szwajcarskich przedsiębiorstw. W pierwszym półroczu 2026 wzrosła liczba zgłoszeń przejętych kont Microsoft 365. Wykorzystywano je do phishingu i oszustw. Atakujący podszywali się pod wsparcie IT lub kadrę kierowniczą i obchodzili zabezpieczenia za pomocą tokenów sesji, Device Code Phishing albo Reverse Proxies.

MFA pozostaje niezbędne. Nie każda metoda jest odporna na phishing. Potwierdzona sesja może sama stać się celem ataku. Microsoft 365 należy zabezpieczać jako platformę tożsamości, a nie tylko usługę poczty elektronicznej.

Jak phishing Microsoft 365 działa mimo MFA

Po sprawdzeniu hasła, drugiego składnika, stanu urządzenia i obowiązujących warunków Entra ID wystawia tokeny lub pliki cookie sesji. Działają one podobnie jak przepustka dla gościa: po jej wydaniu liczy się przede wszystkim ważność. Jeśli przejmie ją inna osoba, nie zawsze musi ponownie przechodzić weryfikację.

Typy tokenów w Microsoft Entra ID różnią się przeznaczeniem i czasem ważności. Kluczowe jest to, że skradziony token lub token udostępniony atakującemu może reprezentować uwierzytelnioną sesję.

Adversary-in-the-Middle Phishing z Reverse Proxy

W ataku Adversary-in-the-Middle (AiTM) infrastruktura phishingowa znajduje się pomiędzy przeglądarką a Microsoft i przekazuje prawdziwe logowanie w czasie rzeczywistym:

1. Wiadomość e-mail odsyła na przykład do dokumentu SharePoint, poczty głosowej, faktury lub podpisu.
2. Łącze prowadzi przez Reverse Proxy atakującego do logowania Microsoft.
3. Nazwa użytkownika, hasło i odpowiedź MFA są przekazywane do Microsoft.
4. Microsoft akceptuje potwierdzone logowanie i ustanawia sesję.
5. Proxy przechwytuje plik cookie sesji lub tokeny. Dostęp kończy się dopiero po wygaśnięciu, unieważnieniu lub zablokowaniu.

MFA nie zostało złamane. Użytkownik potwierdził sesję obserwowaną przez atakującego. Kody TOTP i powiadomienia push zasadniczo nie uniemożliwiają takiego przekazania. Klucze FIDO2, Windows Hello for Business i prawidłowo wdrożone Passkeys wiążą natomiast logowanie kryptograficznie z właściwą usługą. Nie chronią jednak przed złośliwym oprogramowaniem na zalogowanym urządzeniu ani przed każdym rodzajem kradzieży sesji.

Device Code Phishing przez prawdziwą stronę Microsoft

Device Code Flow jest przeznaczony dla urządzeń bez wygodnej możliwości wprowadzania danych. Urządzenie w sali konferencyjnej lub program wiersza poleceń wyświetla kod, który potwierdza się na drugim urządzeniu za pośrednictwem Microsoft.

Atakujący sam rozpoczyna ten proces i pod pretekstem przekazuje kod ofierze. Po wpisaniu go na prawdziwej stronie Microsoft tokeny trafiają do sesji atakującego. Domena i certyfikat są prawidłowe, ale użytkownik autoryzuje cudze logowanie. Microsoft klasyfikuje ten przepływ jako ryzykowny i zaleca jego zablokowanie, jeśli nie istnieje udokumentowana potrzeba użycia.

Zalew wiadomości, fałszywe wsparcie IT i phishing łańcuchowy

Łańcuch ataku rozpoczyna się od setek wiadomości e-mail z newsletterami, potwierdzeniami rejestracji i powiadomieniami. Wywołują one stres i ukrywają prawdziwe ostrzeżenia. Następnie rzekomy pracownik wsparcia IT kontaktuje się przez Teams lub telefon i żąda użycia Quick Assist albo narzędzia zdalnego dostępu. Pozwala to wykonywać polecenia, instalować malware, odczytywać dane przeglądarki i kraść dane dostępowe. Przejmowana jest stacja robocza, a nie samo logowanie.

Po przejęciu atakujący wykorzystuje prawdziwą korespondencję, znanych dostawców i historię rozmów do wysyłania zmodyfikowanych faktur, dalszego phishingu oraz przejmowania kolejnych kont. SPF, DKIM i DMARC nie wystarczą, jeśli wiadomość pochodzi z prawdziwego tenanta Microsoft 365.

Co zapewnia MFA i gdzie leżą jego granice

MFA zapobiega wielu przejęciom kont, ponieważ samo hasło już nie wystarcza. Poszczególne metody różnią się poziomem ochrony:

• Hasło plus SMS, połączenie telefoniczne lub proste potwierdzenie push: lepsze niż samo hasło, ale podatne na Social Engineering, SIM-Swapping, MFA-Fatigue i phishing w czasie rzeczywistym.
• TOTP lub Authenticator z Number Matching: bardziej odporne na przypadkowe potwierdzenia, lecz kod można bezpośrednio przekazać przez stronę AiTM.
• Uwierzytelnianie odporne na phishing: FIDO2, Windows Hello for Business, uwierzytelnianie oparte na certyfikatach oraz Passkeys kryptograficznie sprawdzają właściwą usługę i wyraźnie ograniczają logowania AiTM.

Ryzyko pozostaje: zainfekowany Endpoint może odczytywać sesje, aplikacja OAuth może otrzymać trwałe uprawnienia, a użytkownik może potwierdzić cudzy kod urządzenia lub zdalny dostęp. MFA odporne na phishing jest kluczowe, ale nie stanowi kompletnego systemu bezpieczeństwa.

Rozsądne wzmacnianie Microsoft Entra ID

Conditional Access i Token Protection wymagają odpowiednich licencji Entra, a warunki dotyczące urządzeń wymagają zarządzanej floty. Zasady należy najpierw sprawdzić w trybie Report-only na grupie pilotażowej.

Priorytet dla logowania odpornego na phishing

Pierwszy etap wdrożenia powinien objąć administratorów, pracowników finansów, kadrę kierowniczą i Helpdesk. Conditional Access Authentication Strengths może wymagać w tych grupach Windows Hello for Business, kluczy FIDO2, Passkeys lub uwierzytelniania opartego na certyfikatach.

Potrzebny jest także proces Recovery obejmujący co najmniej dwie zarejestrowane metody, sprawdzone urządzenia zastępcze i oddzielnie monitorowane konta awaryjne. Utrata klucza nie może prowadzić ani do długiej przerwy, ani do łatwych do zmanipulowania wyjątków Helpdesk. Passkeys nadają się również do logowania w Sophos Central, przy czym trzeba także zaplanować Recovery i zmianę urządzenia.

Sprawdzenie i, jeśli to możliwe, blokada Device Code Flow

Użycie można zinwentaryzować w Entra Sign-in Logs przez Authentication protocol > Device code. Urządzenia w salach konferencyjnych, starsze narzędzia lub aplikacje wiersza poleceń mogą zależeć od tej funkcji. Bez uzasadnionej potrzeby w Entra ID > Conditional Access > Policies tworzy się następującą zasadę:

1. Wybrać zwykłych użytkowników lub grupy.
2. Wykluczyć konta awaryjne i uzasadnione wyjątki techniczne.
3. W Target resources wybrać w miarę możliwości All resources, a węższe cele tylko z uzasadnieniem.
4. W Conditions > Authentication flows aktywować Device code flow.
5. W Grant zablokować dostęp.
6. Najpierw użyć Report-only, sprawdzić logi, a dopiero potem aktywować zasadę.

Wyjątki powinny być ściśle ograniczone, udokumentowane i przypisane do konkretnych kont lub zasobów.

Powiązanie dostępu z zarządzanymi urządzeniami

Conditional Access może wymagać dla wrażliwych aplikacji urządzenia zgodnego lub przyłączonego do Microsoft Entra. Utrudnia to nadużycie tokena na nieznanych urządzeniach, ale wpływa również na BYOD, gości, urządzenia mobilne i klientów specjalistycznych. Dlatego trzeba znać zasób urządzeń, systemy operacyjne i aplikacje. Nieaktualne wpisy, słaby Enrollment lub zbyt szerokie wyjątki osłabiają kontrolę.

Ukierunkowane testowanie Token Protection

Token Protection wiąże obsługiwane Sign-in-Session-Tokens kryptograficznie z urządzeniem, które je otrzymało, i utrudnia Replay na innych systemach. Funkcja wymaga Entra ID P1 i obejmuje tylko określone platformy, aplikacje oraz zasoby. W systemie Windows chroni przede wszystkim obsługiwane natywne aplikacje Microsoft 365. Urządzenia Apple wymagają zarządzania i Microsoft Enterprise SSO Plug-in. Aplikacje Apple Mail i Kalendarz nie obsługują obecnie Token Protection.

Wdrożenie zaczyna się od ściśle ograniczonego trybu Report-only. Następnie w Sign-in Logs sprawdza się Token Protection Status Details, klienty i zasoby. Wymuszanie włącza się dopiero po potwierdzeniu zgodności. Przeglądarki, starsze oprogramowanie i urządzenia specjalne ocenia się osobno.

Kontrola Teams i zdalnego dostępu

Należy określić, które zewnętrzne domeny lub tenanty mogą kontaktować się z użytkownikami przez Teams oraz jak oznaczani są zewnętrzni uczestnicy. W przypadku wsparcia obowiązują następujące zasady:

• Zdalny dostęp rozpoczyna się wyłącznie na podstawie zgłoszenia lub zweryfikowanego oddzwonienia pod znany numer.
• Nie akceptuje się nieoczekiwanych sesji Quick Assist inicjowanych na czacie lub podczas rozmowy telefonicznej.
• Dozwolone narzędzia zdalnego dostępu są udokumentowane i monitorowane.
• Nieznane narzędzia RMM są blokowane lub generują alerty za pomocą Application Control, AppLocker, Windows Defender Application Control albo porównywalnych mechanizmów.
• Nietypowy zalew wiadomości e-mail zgłasza się do IT lub Security, zamiast traktować go wyłącznie jako spam.

Awareness musi odzwierciedlać te procesy. Sophos Phish Threat jest skuteczniejszy z jasnymi kanałami zgłaszania, scenariuszami Teams i realistycznym Helpdesk-Runbook.

Jakie ślady powinni sprawdzać administratorzy

Pomyślne zdarzenie MFA nie jest dowodem prawidłowego logowania. W przypadku AiTM lub Device Code użytkownik mógł sam potwierdzić składnik. Tożsamość, skrzynkę pocztową, Endpoint i komunikację należy analizować łącznie.

Microsoft Entra Sign-in Logs

Logi znajdują się w Entra ID > Monitoring & health > Sign-in logs i są dostępne od roli Reports Reader. W zależności od podejrzeń analiza powinna obejmować interaktywne i nieinteraktywne logowania, Service Principals oraz Managed Identities. Istotne są:

• nieznane lub niezgodne urządzenia oraz nietypowe adresy IP, regiony, aplikacje i klienty,
• Device code jako Authentication Protocol,
• nowe kombinacje przeglądarki lub urządzenia po normalnym logowaniu,
• nietypowy dostęp do Exchange Online, SharePoint lub Microsoft Graph,
• wynik Conditional Access, spełnione wymagania uwierzytelniania oraz
• udany dostęp bez oczekiwanej interakcji użytkownika przy użyciu istniejących tokenów.

Pojedynczy sygnał nie wystarcza. Szwajcarski adres IP może należeć do operatora komórkowego lub VPN, a logowanie z zagranicy może być związane z pracą. Znaczenie ma połączenie użytkownika, urządzenia, czasu, aplikacji i dalszej aktywności.

Exchange Online, Audit i Endpoint

Po przejęciu konta atakujący często szukają faktur i historii rozmów. Należy sprawdzić wewnętrzne i zewnętrzne przekierowania, widoczne i ukryte Inbox Rules, delegacje i uprawnienia Send-as, nietypowe operacje wyszukiwania, odczytu, pobierania oraz wysyłania, nowe zgody OAuth i Enterprise Applications, zmienione metody uwierzytelniania, a także wszystkie wiadomości wysłane w badanym przedziale czasu.

W przypadku fałszywego wsparcia IT ślady znajdują się na Endpoint: programy zdalnego dostępu, pobrane pliki, PowerShell, MSHTA, zaplanowane Tasks, dostęp do przeglądarki i podejrzane procesy. E-mail Security, Endpoint Protection oraz XDR lub MDR mogą je blokować i korelować, jeśli źródła danych są licencjonowane, zintegrowane i monitorowane. Strategia Sophos Fusion pomaga w tym zakresie, lecz nie zastępuje Conditional Access ani procesu Incident Response.

Okres przechowywania i szczegółowość danych Audit zależą od licencji oraz konfiguracji. Obie kwestie trzeba wyjaśnić z wyprzedzeniem, ponieważ logi włączone po incydencie nie zapewnią danych historycznych.

Plan awaryjny dla przejętego konta Microsoft 365

Sama zmiana hasła nie wystarczy. Sesje, obce metody MFA, zgody OAuth i reguły skrzynki pocztowej mogą pozostać aktywne.

1. Użycie czystego urządzenia administracyjnego

Jeśli istnieje podejrzenie przejęcia Endpoint, hasło zmienia się i przeprowadza działania administracyjne na innym urządzeniu. Dotknięty system należy odizolować bez pochopnego usuwania śladów. Podczas trwającego ataku lub w przypadku konta uprzywilejowanego sensowne może być tymczasowe wyłączenie konta.

2. Unieważnienie aktywnych sesji

Sesje można unieważnić w Entra Admin Center lub za pomocą Microsoft Graph PowerShell:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

User Principal Name należy odpowiednio zmienić. W zależności od aplikacji, typu tokena i Continuous Access Evaluation dostęp może przez krótki czas pozostać aktywny. Dlatego skuteczność działania trzeba sprawdzić w logach i aplikacjach.

3. Zmiana hasła i uporządkowanie uwierzytelniania

Hasło zmienia się w nadrzędnym źródle tożsamości, a w przypadku kont synchronizowanych lub federacyjnych w lokalnym Active Directory albo Identity Provider. Następnie należy sprawdzić metody MFA, Passkeys, numery telefonów, urządzenia i Temporary Access Passes oraz usunąć obce wpisy. W przypadku malware lub zdalnego dostępu Endpoint analizuje się równolegle, a w razie potrzeby tworzy od nowa.

4. Sprawdzenie zgód OAuth i ról

Zgody użytkowników, Enterprise Applications i podejrzane Service Principals mogą zapewniać trwały dostęp. W przypadku kont uprzywilejowanych należy również skontrolować role Entra, Azure i Microsoft 365.

5. Sprawdzenie przekierowań i Inbox Rules

Exchange Online PowerShell wyświetla kluczowe ustawienia skrzynki pocztowej:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Podejrzane reguły należy udokumentować i usunąć. Delegacje, uprawnienia Send-as i administracyjne reguły transportowe sprawdza się osobno.

6. Ustalenie i poinformowanie kolejnych ofiar

Message Trace i dane Audit pokazują wysłane wiadomości. Odbiorców wewnętrznych i zewnętrznych należy poinformować, zanim klikną łącza, wykonają płatności lub dojdzie do przejęcia kolejnych kont. Jeśli zmieniono dane płatności, trzeba skontaktować się z bankiem, księgowością i partnerami biznesowymi przez znane kanały. Dalsze kroki opisuje artykuł o natychmiastowych działaniach w przypadku phishingu i włamania.

7. Ustalenie przyczyny i zasięgu

Na koniec należy wyjaśnić, czy wykorzystano AiTM, Device Code, potwierdzone MFA lub zdalny dostęp, które pliki SharePoint lub OneDrive wyciekły, czy zarejestrowano kolejne konta, aplikacje lub urządzenia oraz czy incydent dotyczył danych osobowych bądź tajemnic handlowych. Bez analizy przyczyny luka pozostaje otwarta.

Praktyczna lista kontrolna dla administratorów Microsoft 365

• Nadać priorytet logowaniu odpornemu na phishing dla administratorów, finansów, kadry kierowniczej i Helpdesk.
• Oddzielić konta awaryjne, monitorować je i regularnie testować.
• Zinwentaryzować użycie Device Code, zablokować je lub wprowadzić uzasadnione wyjątki.
• Sprawdzić Conditional Access w trybie Report-only z grupą pilotażową.
• Dla wrażliwych zasobów wymagać zarządzanych urządzeń i wdrażać Token Protection tylko ze zgodnymi klientami.
• Ustalić wiążące zasady dla zewnętrznej komunikacji Teams, narzędzi zdalnego dostępu, oddzwaniania przez Helpdesk i weryfikacji tożsamości.
• Generować alerty dla zalewu wiadomości, nietypowych logowań, zgód OAuth i przekierowań.
• Testować unieważnianie sesji, czyszczenie MFA, Inbox Rules, ślady wysyłki i izolację Endpoint.
• Przed incydentem ustalić okres przechowywania danych Audit i zakres odpowiedzialności.

Moja rekomendacja

MFA pozostaje obowiązkowe, ale hasło połączone z aplikacją push w zbyt małym stopniu uwzględnia współczesne ataki. W pierwszej kolejności konta uprzywilejowane i istotne finansowo powinny otrzymać uwierzytelnianie odporne na phishing. Następnie należy wdrożyć kontrolę Device Code, zarządzane urządzenia i Conditional Access. Ze względu na ograniczenia Token Protection wymaga kontrolowanego wdrożenia. Równolegle Helpdesk potrzebuje bezpiecznych procesów obsługi nieoczekiwanych kontaktów przez Teams.

Decydujące znaczenie ma połączenie silnej tożsamości, zaufanego urządzenia, kontrolowanej sesji, monitorowanej komunikacji oraz planu awaryjnego obejmującego aktywne tokeny i ukryte mechanizmy Persistence.

FAQ