Lead

MFA znacząco utrudnia przejęcie konta Microsoft 365, ale nie eliminuje ryzyka phishingu. Współczesne ataki coraz częściej nie próbują „złamać” drugiego składnika logowania — nakłaniają pracownika do zatwierdzenia prawidłowego logowania lub autoryzacji urządzenia kontrolowanego przez atakującego.

Dla firmy skutkiem może być dostęp do poczty, plików SharePoint, Teams, kontaktów i korespondencji handlowej. Właśnie dlatego ochrona Microsoft 365 powinna obejmować nie tylko MFA, lecz także kontrolę przepływów logowania, zasad Conditional Access, tokenów sesyjnych i konfiguracji poczty.

Dlaczego samo MFA nie zawsze zatrzymuje atak?

MFA chroni przede wszystkim przed użyciem skradzionego hasła. Jeśli jednak pracownik sam potwierdzi logowanie na stronie pośredniczącej albo zatwierdzi kod urządzenia wygenerowany przez przestępcę, MFA może zostać wykonane poprawnie — ale z korzyścią dla atakującego.

W atakach na Microsoft 365 występują dwa szczególnie ważne scenariusze:

• Phishing AiTM (Adversary-in-the-Middle) — fałszywa strona logowania pośredniczy pomiędzy użytkownikiem a prawdziwym serwisem Microsoft, przechwytując dane logowania i token sesji.
• Device code phishing — ofiara wpisuje kod na prawdziwej stronie Microsoft i zatwierdza dostęp dla urządzenia lub sesji rozpoczętej przez napastnika.

Microsoft wskazuje device code flow jako przepływ wysokiego ryzyka, który może zostać wykorzystany w phishingu lub do dostępu do zasobów firmowych z niezarządzanych urządzeń. Microsoft rekomenduje blokowanie device code flow wszędzie tam, gdzie nie jest ono potrzebne biznesowo. Źródło: Microsoft Learn — przepływy uwierzytelniania w Conditional Access.

Jak działa phishing device code?

Device code flow to legalny mechanizm OAuth używany między innymi przez urządzenia z ograniczonym interfejsem wejściowym, takie jak wybrane urządzenia konferencyjne lub systemy bez wygodnej klawiatury. Użytkownik otwiera stronę logowania Microsoft, wpisuje krótki kod i potwierdza tożsamość.

W ataku przestępca uruchamia ten proces na swoim urządzeniu, a następnie nakłania pracownika do wpisania otrzymanego kodu i zalogowania się na prawdziwej stronie Microsoft. Ofiara nie musi zobaczyć fałszywego formularza logowania — dlatego klasyczne rozpoznawanie phishingu po podejrzanej domenie może nie wystarczyć.

Po udanej autoryzacji atakujący może otrzymać tokeny pozwalające działać w usługach Microsoft 365 w zakresie uprawnień użytkownika. Z tego powodu Microsoft zaleca wdrożenie kontroli device code flow w Conditional Access oraz ograniczanie go do niezbędnych przypadków. Źródła: przepływy uwierzytelniania oraz blokowanie przepływów uwierzytelniania.

Ważne doprecyzowanie

Device code phishing nie jest technicznym „złamaniem MFA”. Pracownik przechodzi uwierzytelnienie poprawnie, lecz zostaje socjotechnicznie nakłoniony do zatwierdzenia dostępu dla procesu uruchomionego przez atakującego.

To rozróżnienie ma znaczenie operacyjne: problemem nie jest wyłącznie słabe hasło, lecz kombinacja socjotechniki, zbyt szerokich ustawień dostępu i braku kontroli nietypowych zdarzeń logowania.

Jak działa przejęcie sesji AiTM?

W phishingu AiTM atakujący używa strony, która naśladuje proces logowania Microsoft 365 i przekazuje komunikację do prawdziwej usługi w czasie rzeczywistym. Użytkownik może wpisać hasło, przejść MFA i uzyskać normalny dostęp do swojego konta — równolegle atakujący przechwytuje rezultaty tej sesji.

Najcenniejszym celem nie zawsze jest hasło. Może nim być aktywny token lub cookie sesyjne, które potwierdza już zalogowaną tożsamość użytkownika. To pozwala przestępcy kontynuować dostęp bez potrzeby ponownego proszenia ofiary o kod MFA.

Przejęta skrzynka Microsoft 365 może następnie zostać użyta do:

• wysyłania phishingu z zaufanego firmowego adresu;
• podszywania się pod pracownika w rozmowach z klientami i dostawcami;
• przechwytywania faktur, danych kontrahentów i dokumentów;
• tworzenia reguł przekazywania poczty na zewnętrzne adresy;
• zmiany danych płatniczych lub inicjowania oszustw BEC;
• rozprzestrzeniania ataku wewnątrz organizacji i wśród partnerów biznesowych.

Co firma powinna wdrożyć w Microsoft 365?

Najskuteczniejsza ochrona nie jest pojedynczym ustawieniem. To zestaw kontroli technicznych, zasad operacyjnych oraz monitoringu zdarzeń tożsamości.

1. Ogranicz device code flow.
   Jeżeli firma nie korzysta z device code flow, należy rozważyć jego zablokowanie w Microsoft Entra ID Conditional Access. Microsoft opisuje konfigurację polityki obejmującej użytkowników, wszystkie zasoby oraz warunek Authentication Flows → Device code flow, z akcją Block access. Zalecane jest najpierw uruchomienie polityki w trybie raportowania, aby sprawdzić wpływ na środowisko. Źródło: blokowanie przepływów uwierzytelniania w Conditional Access. Jeżeli device code flow jest potrzebne konkretnym urządzeniom lub procesom, dostęp powinien być ograniczony do jasno określonych grup, lokalizacji sieciowych i przypadków użycia. Microsoft rekomenduje dopuszczanie tego przepływu wyłącznie tam, gdzie jest niezbędny.
2. Wdrażaj phishing-resistant MFA.
   Kod SMS, kod z aplikacji TOTP i zatwierdzenie push nadal pomagają, ale mogą być podatne na socjotechnikę lub pośredniczenie w procesie logowania. Dla kont uprzywilejowanych, finansów, administracji i osób mających dostęp do poufnych danych warto wdrożyć metody odporne na phishing, takie jak klucze FIDO2, passkeys lub Windows Hello for Business. Microsoft publikuje osobne wytyczne dotyczące wdrażania bezhasłowego, odpornego na phishing uwierzytelniania w Microsoft Entra ID.
3. Monitoruj nietypowe logowania i zgody OAuth.
   Zespół IT lub dostawca usług bezpieczeństwa powinien okresowo analizować:
   • logowania z nietypowych krajów, adresów IP lub urządzeń;
   • nieoczekiwane użycie device code flow;
   • nowe aplikacje OAuth oraz zgody nadane aplikacjom;
   • zmiany reguł skrzynki, przekierowania poczty i delegacje;
   • alerty dotyczące ryzyka użytkownika i ryzyka logowania;
   • aktywność kont uprzywilejowanych oraz dostęp do paneli administracyjnych.
   Microsoft wskazuje, że polityki oparte na ryzyku logowania mogą automatycznie wymuszać dodatkowe działania, takie jak blokada dostępu lub ponowne uwierzytelnienie. Źródło: konfiguracja zasad ryzyka w Microsoft Entra ID Protection.
4. Ogranicz uprawnienia i popraw higienę poczty.
   Firma powinna ograniczyć liczbę administratorów globalnych, stosować zasadę najmniejszych uprawnień oraz regularnie przeglądać role administracyjne. Należy także wyłączyć starsze mechanizmy uwierzytelniania tam, gdzie są zbędne, ponieważ nie wspierają nowoczesnych polityk MFA i Conditional Access. Źródło: Microsoft Learn — zasady ryzyka w ID Protection. Ochrona tożsamości musi iść w parze z higieną domeny oraz poczty: SPF, DKIM i polityka DMARC pomagają ograniczać podszywanie się pod markę, choć same nie zatrzymają phishingu wysłanego z już przejętej firmowej skrzynki.

Co zrobić po podejrzeniu przejęcia konta?

Sam reset hasła może nie wystarczyć. Reakcja zależy od charakteru incydentu, ustawień Microsoft Entra ID i rodzaju uzyskanej przez atakującego sesji lub tokenu.

W praktyce należy możliwie szybko:

1. Zablokować lub zabezpieczyć konto użytkownika zgodnie z procedurą incydentową.
2. Zresetować hasło i wymusić ponowne uwierzytelnienie.
3. Unieważnić aktywne sesje oraz przeanalizować tokeny i aplikacje OAuth.
4. Sprawdzić reguły skrzynki, automatyczne przekierowania i delegacje.
5. Zweryfikować historię logowań, lokalizacje, urządzenia oraz dostęp do plików.
6. Odwołać nieautoryzowane zgody aplikacyjne i usunąć podejrzane rejestracje urządzeń.
7. Sprawdzić, czy z konta wysłano phishing do pracowników, klientów lub dostawców.
8. Udokumentować incydent oraz wdrożyć kontrolę, która ograniczy powtórzenie scenariusza.

Perspektywa eksperta CHORS.NET

„W bezpieczeństwie Microsoft 365 najważniejsze jest nie tylko pytanie: czy firma ma MFA? Równie istotne jest: jakie przepływy logowania są dozwolone, kto może zatwierdzać aplikacje, gdzie trafiają tokeny sesyjne i czy organizacja potrafi szybko wykryć nietypową aktywność.”

— inż. Marcin Białczyk, Founder i Cybersecurity Operator CHORS.NET

Jak CHORS.NET pomaga ograniczyć ryzyko?

CHORS.NET pomaga firmom B2B uporządkować podstawy bezpieczeństwa: widoczną ekspozycję domeny, konfigurację poczty, ryzyka publicznie dostępnych usług oraz priorytety naprawy. Screening ekspozycji internetowej obejmuje między innymi domenę, DNS, pocztę, TLS, nagłówki i podstawowe błędy konfiguracyjne.

Jeżeli screening ujawnia szersze ryzyko lub firma potrzebuje głębszej analizy wybranej domeny, aplikacji albo strony, kolejnym krokiem jest Audyt Podatności za Zgodą. Usługa obejmuje autoryzowaną analizę techniczną, ocenę konfiguracji i raport z priorytetami naprawy.

Warto pamiętać, że zewnętrzny screening nie zastępuje analizy logów Microsoft Entra ID ani konfiguracji tenantów Microsoft 365. Może jednak wskazać ryzyka w obszarze domeny, poczty i publicznej powierzchni ataku, które zwiększają skuteczność kampanii phishingowych.

Najczęściej zadawane pytania

Czy MFA chroni przed phishingiem Microsoft 365?

MFA wyraźnie zmniejsza ryzyko przejęcia konta po kradzieży hasła, ale nie daje pełnej ochrony przed phishingiem AiTM ani device code phishing. W tych scenariuszach atakujący może skłonić użytkownika do wykonania poprawnego uwierzytelnienia lub przejąć rezultaty aktywnej sesji.

Czy należy wyłączyć device code flow w Microsoft 365?

Jeżeli organizacja nie ma uzasadnionej potrzeby korzystania z device code flow, należy rozważyć jego blokadę przez Conditional Access. Microsoft rekomenduje blokowanie tego przepływu wszędzie, gdzie jest to możliwe, oraz ograniczanie go do kontrolowanych wyjątków. Źródła: przepływy uwierzytelniania oraz blokowanie przepływów uwierzytelniania.

Czy reset hasła kończy incydent przejęcia skrzynki?

Nie zawsze. Po podejrzeniu przejęcia należy również sprawdzić aktywne sesje, tokeny, zgody OAuth, reguły skrzynki, przekierowania poczty i historię logowań. Zakres reakcji powinien wynikać z analizy konkretnego incydentu.

Jakie konta powinny dostać FIDO2 lub passkeys w pierwszej kolejności?

Priorytetowo należy zabezpieczyć konta administracyjne, osoby z dostępem do finansów, zarząd, HR, osoby obsługujące klientów strategicznych oraz użytkowników mających dostęp do wrażliwych danych lub paneli administracyjnych.

Czy DMARC zatrzyma phishing z przejętej skrzynki firmowej?

Nie. SPF, DKIM i DMARC pomagają ograniczać podszywanie się pod domenę, ale wiadomość wysłana z realnie przejętej skrzynki może przejść kontrolę jako prawidłowa. Dlatego potrzebne są również zabezpieczenia tożsamości, monitoring i procedura reakcji.

Sprawdź ekspozycję swojej firmy

Jeżeli chcesz ustalić, czy Twoja domena i poczta nie ułatwiają phishingu, zacznij od przeglądu publicznej ekspozycji. CHORS.NET realizuje Screening Ekspozycji Internetowej oraz Audyt Podatności za Zgodą, aby wskazać priorytety naprawy w języku zrozumiałym dla zarządu i IT.

Zamów Audyt Podatności za Zgodą →

Źródła

1. Microsoft Learn — przepływy uwierzytelniania w Conditional Access
2. Microsoft Learn — blokowanie przepływów uwierzytelniania
3. Microsoft Learn — wdrażanie uwierzytelniania bezhasłowego odpornego na phishing
4. Microsoft Learn — konfiguracja zasad ryzyka w Microsoft Entra ID Protection
5. CHORS.NET — Screening ekspozycji internetowej
6. CHORS.NET — Audyt Podatności za Zgodą