Co dzieje się po przejęciu konta Microsoft 365? Scenariusz ataku

Pracownik otrzymuje wiadomość z prośbą o ponowne zalogowanie do Microsoft 365. Strona wygląda znajomo, więc wpisuje login i hasło, a następnie zatwierdza żądanie MFA. Kilka minut później cyberprzestępca loguje się na jego konto. Użytkownik nadal odbiera pocztę i pracuje jak zwykle. Dla napastnika to jednak dopiero początek.

Ten modelowy scenariusz pokazuje, jak wygląda przejęcie konta Microsoft 365 z perspektywy organizacji: nie jako sam dostęp do skrzynki, lecz jako przejęcie cyfrowej tożsamości połączonej z Exchange Online, Teams, SharePoint, OneDrive, Entra ID i często również z zewnętrznymi aplikacjami SaaS. Dlatego jeden skuteczny phishing może rozpocząć Business Email Compromise, wyciek danych, oszustwo finansowe albo próbę przejęcia kolejnych kont.

Co warto wiedzieć

• Przejęte konto Microsoft 365 daje dostęp nie tylko do poczty, ale również do dokumentów, rozmów, aplikacji i kontekstu biznesowego.
• Pierwsze działania są często ciche: rozpoznanie skrzynki, procesów płatniczych i dostępnych uprawnień.
• MFA zmniejsza ryzyko, lecz nie chroni przed każdym scenariuszem, m.in. kradzieżą tokenu, MFA fatigue i consent phishing.
• Pojedynczy alert nie przesądza o incydencie. Znaczenie powstaje po korelacji tożsamości, urządzenia i aktywności w wielu usługach.
• Reakcja nie kończy się na zmianie hasła. Obejmuje sesje, MFA, aplikacje, mechanizmy trwałości i analizę zasięgu.
• SOC 24/7 skraca drogę od sygnału do decyzji, zanim konto zostanie użyte do wyłudzenia lub kradzieży danych.

Co naprawdę oznacza przejęcie konta Microsoft 365

W tradycyjnym ujęciu skrzynka e-mail była jednym z wielu narzędzi pracy. W środowisku Microsoft 365 konto reprezentuje użytkownika i pośredniczy w dostępie do usług, danych oraz procesów organizacji. Zakres ryzyka zależy od licencji, konfiguracji, uprawnień i integracji, ale typowe konto może umożliwiać dostęp do:

• korespondencji, kalendarza, kontaktów i książki adresowej w Exchange Online;
• rozmów, spotkań i plików udostępnianych przez Teams;
• dokumentów w SharePoint i OneDrive;
• aplikacji korzystających z logowania przez Microsoft Entra ID;
• danych projektowych, umów, faktur, danych klientów i komunikacji z dostawcami;
• zasobów dostępnych użytkownikowi przez SSO;
• funkcji administracyjnych, jeśli przejęte konto ma podwyższone uprawnienia.

Kradzież jednej tożsamości może być znacznie poważniejsza niż ujawnienie hasła. Napastnik może korzystać z legalnej sesji i przypisanych użytkownikowi uprawnień, więc część działań wygląda jak zwykła praca.

Etap

Działanie napastnika

Potencjalny cel

Ryzyko dla organizacji

Uzyskanie dostępu

Logowanie hasłem, tokenem lub przez zgodę OAuth

Wejście do środowiska

Utrata kontroli nad tożsamością

Rozpoznanie

Przeszukanie poczty, kontaktów i kalendarza

Poznanie relacji i procesów

Przygotowanie wiarygodnego oszustwa

Ukrycie aktywności

Reguły skrzynki, forwarding, usuwanie lub przenoszenie wiadomości

Opóźnienie wykrycia

Dłuższy czas obecności napastnika

Wykorzystanie zaufania

Wiadomości do pracowników, klientów lub dostawców

BEC, phishing wewnętrzny

Straty finansowe i kolejne przejęcia

Dostęp do danych

SharePoint, OneDrive, Teams i aplikacje SaaS

Kradzież informacji

Naruszenie poufności i obowiązki prawne

Utrzymanie dostępu

Nowa metoda MFA, zgoda OAuth, delegacja lub inne zmiany

Przetrwanie resetu hasła

Nawrót incydentu

Etap	Działanie napastnika	Potencjalny cel	Ryzyko dla organizacji
Uzyskanie dostępu	Logowanie hasłem, tokenem lub przez zgodę OAuth	Wejście do środowiska	Utrata kontroli nad tożsamością
Rozpoznanie	Przeszukanie poczty, kontaktów i kalendarza	Poznanie relacji i procesów	Przygotowanie wiarygodnego oszustwa
Ukrycie aktywności	Reguły skrzynki, forwarding, usuwanie lub przenoszenie wiadomości	Opóźnienie wykrycia	Dłuższy czas obecności napastnika
Wykorzystanie zaufania	Wiadomości do pracowników, klientów lub dostawców	BEC, phishing wewnętrzny	Straty finansowe i kolejne przejęcia
Dostęp do danych	SharePoint, OneDrive, Teams i aplikacje SaaS	Kradzież informacji	Naruszenie poufności i obowiązki prawne
Utrzymanie dostępu	Nowa metoda MFA, zgoda OAuth, delegacja lub inne zmiany	Przetrwanie resetu hasła	Nawrót incydentu

Jak dochodzi do przejęcia konta Microsoft 365

Nie istnieje jedna droga do Account Takeover. W praktyce spotyka się warianty, w których atakujący przejmuje dane logowania, aktywną sesję albo uprawnienie aplikacji.

• Phishing poświadczeń: użytkownik wpisuje dane na fałszywej stronie logowania, a napastnik wykorzystuje je przeciwko Microsoft 365.
• MFA fatigue i socjotechnika: ofiara zatwierdza żądanie uwierzytelnienia, którego sama nie rozpoczęła.
• Kradzież tokenu sesyjnego: przejęta, już uwierzytelniona sesja może zostać wykorzystana bez ponownego wpisywania hasła i nowego wyzwania MFA. Microsoft opisuje ten scenariusz w playbooku dotyczącym kradzieży tokenów.
• Consent phishing: użytkownik przyznaje aplikacji OAuth dostęp do danych. Zmiana hasła nie usuwa takiej zgody, więc trzeba ją oddzielnie zidentyfikować i cofnąć.
• Słabe lub ponownie używane hasło: dane ujawnione w innym serwisie mogą zostać wykorzystane w credential stuffing lub password spraying.

Ryzyko rośnie, gdy organizacja utrzymuje wyjątki od MFA, nieużywane konta, słabo chronione role uprzywilejowane albo starsze mechanizmy uwierzytelniania.

Pierwsze minuty po zalogowaniu

Pierwszym celem napastnika często nie jest wysłanie tysięcy wiadomości. Głośna aktywność szybko uruchomiłaby alerty i zwróciła uwagę użytkownika. Znacznie cenniejsze jest ciche rozpoznanie organizacji.

Atakujący wyszukuje faktury, umowy, nazwy klientów i informacje o płatnościach. Sprawdza styl komunikacji, trwające projekty, osoby decyzyjne oraz dostęp do Teams, SharePoint, OneDrive i aplikacji przez SSO. Ocenia też, czy konto ma podwyższone uprawnienia albo może udzielać zgód aplikacjom.

To faza, w której techniczny incydent zaczyna zamieniać się w plan oszustwa biznesowego.

„W przejęciu konta najgroźniejsze bywa nie samo logowanie, lecz czas, przez który napastnik może bez przeszkód poznawać organizację. Im dłuższy czas niewykrytej obecności, tym łatwiej zamienić dostęp techniczny w wiarygodne oszustwo, kradzież danych albo kolejne przejęcie.”

Co cyberprzestępca robi później

Po rozpoznaniu napastnik wybiera działania najlepiej dopasowane do roli ofiary i wartości dostępnych danych. Nie każdy incydent przebiega identycznie, ale powtarzają się cztery kierunki: ukrycie aktywności, wykorzystanie zaufania, dostęp do danych i utrzymanie obecności.

Ukrywa korespondencję Podszywa się pod użytkownika Sięga do Teams, SharePoint i OneDrive Próbuje utrzymać lub rozszerzyć dostęp Sprawdź, czy widzisz całą aktywność przejętej tożsamości

Ukrywa korespondencję

Tworzy reguły przenoszące lub usuwające wybrane wiadomości. Może też skonfigurować forwarding albo delegację, aby ukryć ostrzeżenia i zachować kontrolę nad rozmową.

Podszywa się pod użytkownika

Wysyła wiadomości z prawdziwego konta i istniejącego wątku. Prośba o pilną zmianę rachunku, przesłanie dokumentów albo wejście na stronę phishingową staje się wtedy bardziej wiarygodna. Tak powstaje Business Email Compromise.

Sięga do Teams, SharePoint i OneDrive

W Teams napastnik może podszywać się pod pracownika, a w SharePoint i OneDrive wyszukiwać umowy, dane osobowe lub pliki finansowe. Nietypowe pobieranie i udostępnianie danych wymaga oceny na tle normalnej aktywności użytkownika.

Próbuje utrzymać lub rozszerzyć dostęp

Atakujący może dodać metodę MFA, wykorzystać zgodę OAuth, zmienić uprawnienia albo zaatakować kolejnych użytkowników. Konto administracyjne radykalnie zwiększa potencjalny zakres incydentu.

Sprawdź, czy widzisz całą aktywność przejętej tożsamości

Jedno konto może otwierać dostęp do znacznej części środowiska. W podejściu VigilHorizon aktywność z Entra ID, Exchange Online, SharePoint, OneDrive i narzędzi bezpieczeństwa jest analizowana jako jeden kontekst, a potwierdzony incydent uruchamia uzgodniony playbook. Warto sprawdzić, czy taki sam ciąg od sygnału do decyzji działa również w Twojej organizacji.

Konsekwencje dla organizacji

Skutki przejęcia konta zależą od jego roli, uprawnień, czasu obecności napastnika i szybkości reakcji. Najważniejsze kategorie ryzyka to:

• straty finansowe — fałszywa zmiana rachunku, pilny przelew, oszustwo na dostawcę lub osobę decyzyjną;
• naruszenie poufności — dostęp do poczty, plików, danych klientów, dokumentacji pracowniczej lub umów;
• kolejne przejęcia — phishing wysłany z zaufanego konta ma większą wiarygodność;
• utrata reputacji — fałszywe wiadomości trafiają do klientów i partnerów z prawdziwego konta;
• zakłócenie operacji — blokada kont, wstrzymanie płatności i ręczna weryfikacja korespondencji;
• obowiązki prawne i kontraktowe — konieczność oceny naruszenia, zabezpieczenia dowodów i ewentualnych zgłoszeń;
• eskalacja techniczna — wykorzystanie konta jako punktu wejścia do innych aplikacji, zasobów lub uprzywilejowanych tożsamości.

Nie wolno traktować zdarzenia wyłącznie jako problemu jednego użytkownika. Trzeba ustalić, czy naruszono również pocztę, dane, aplikacje, relacje zewnętrzne i inne konta.

Dlaczego MFA i standardowe podejście nie wystarczają

MFA pozostaje jednym z najważniejszych zabezpieczeń, ale nie każda metoda daje ten sam poziom ochrony. Powiadomienie push albo kod jednorazowy może zostać wykorzystany w socjotechnice lub przechwycony w zaawansowanym phishingu. Token aktywnej sesji może z kolei pozwolić ominąć ponowne uwierzytelnienie.

Dlatego dojrzały model nie kończy się na zdaniu „mamy MFA”. Obejmuje metody odporne na phishing dla ról krytycznych, Conditional Access, kontrolę rejestracji metod MFA i zgód aplikacji oraz analizę nietypowych sesji również poza godzinami pracy.

Microsoft wskazuje passkeys/FIDO2, Windows Hello for Business i uwierzytelnianie certyfikatowe jako metody odporne na phishing. Ich wdrożenie powinno jednak wynikać z architektury, analizy ryzyka i przygotowanego procesu odzyskiwania dostępu, a nie z pojedynczej zmiany ustawienia.

Standardowe podejście zawodzi także wtedy, gdy logi są włączone, lecz nikt ich nie analizuje, alerty pozostają w osobnych konsolach, a uprawnienia do blokady konta są niejasne. To różnica między widocznością a zdolnością reakcji, opisana szerzej w materiale Czym jest SOC 24/7 i dlaczego monitoring nie wystarcza.

Jakie sygnały mogą wskazywać na przejęcie konta

Żaden pojedynczy sygnał nie musi oznaczać ataku. Logowanie z innego kraju może wynikać z podróży albo użycia VPN, a masowe pobranie plików — z legalnej migracji. Skuteczna detekcja polega na korelacji kilku zachowań i zestawieniu ich z profilem użytkownika oraz kontekstem biznesowym.

Sygnał

Gdzie szukać kontekstu

Co zwiększa ryzyko

Możliwa reakcja SOC

Nietypowa lokalizacja lub adres IP

Logi logowań Entra ID, reputacja IP, historia użytkownika

Nowe urządzenie, nietypowa aplikacja, ryzykowna sesja

Weryfikacja z użytkownikiem, ocena ryzyka i sesji

Impossible Travel

Entra ID / Defender for Cloud Apps, znane VPN i lokalizacje

Brak logicznego wyjaśnienia, kolejne anomalie

Korelacja, podniesienie priorytetu, containment

Nowa reguła skrzynki lub forwarding

Exchange Online, Microsoft Purview Audit

Reguła ukrywa wiadomości finansowe lub ostrzeżenia

Kontrola reguł, delegacji i wiadomości

Nowa aplikacja lub zgoda OAuth

Entra ID, aplikacje przedsiębiorstwa, logi zgód

Szerokie uprawnienia, nieznany wydawca

Analiza aplikacji i cofnięcie nielegalnej zgody

Nietypowe pobieranie lub udostępnianie plików

SharePoint, OneDrive, Defender, Purview

Duży wolumen, nowe urządzenie, zewnętrzni odbiorcy

Ograniczenie dostępu i ocena zakresu danych

Sygnał	Gdzie szukać kontekstu	Co zwiększa ryzyko	Możliwa reakcja SOC
Nietypowa lokalizacja lub adres IP	Logi logowań Entra ID, reputacja IP, historia użytkownika	Nowe urządzenie, nietypowa aplikacja, ryzykowna sesja	Weryfikacja z użytkownikiem, ocena ryzyka i sesji
Impossible Travel	Entra ID / Defender for Cloud Apps, znane VPN i lokalizacje	Brak logicznego wyjaśnienia, kolejne anomalie	Korelacja, podniesienie priorytetu, containment
Nowa reguła skrzynki lub forwarding	Exchange Online, Microsoft Purview Audit	Reguła ukrywa wiadomości finansowe lub ostrzeżenia	Kontrola reguł, delegacji i wiadomości
Nowa aplikacja lub zgoda OAuth	Entra ID, aplikacje przedsiębiorstwa, logi zgód	Szerokie uprawnienia, nieznany wydawca	Analiza aplikacji i cofnięcie nielegalnej zgody
Nietypowe pobieranie lub udostępnianie plików	SharePoint, OneDrive, Defender, Purview	Duży wolumen, nowe urządzenie, zewnętrzni odbiorcy	Ograniczenie dostępu i ocena zakresu danych

Dostępność detekcji, retencja i szczegółowość zdarzeń zależą od licencji oraz konfiguracji. Dlatego monitoring Microsoft 365 powinien zaczynać się od scenariuszy ryzyka i wymaganych źródeł danych, nie od samej listy produktów.

Jak SOC wykrywa przejęcie konta Microsoft 365

Skuteczny SOC Microsoft 365 nie powinien opierać się na jednej konsoli. Potrzebuje spójnego obrazu tożsamości, poczty, danych, aplikacji i endpointu. Przykładowy proces wygląda następująco:

1. Zebranie sygnału: alert ryzykownego logowania, nowa reguła skrzynki, nietypowy dostęp do pliku albo zgłoszenie użytkownika.
2. Wzbogacenie: reputacja IP, urządzenie, lokalizacja, metoda uwierzytelnienia, rola użytkownika i krytyczność danych.
3. Korelacja: sprawdzenie, co konto robiło przed i po logowaniu w Exchange, Teams, SharePoint, OneDrive i Entra ID.
4. Klasyfikacja: odróżnienie legalnej anomalii od podejrzanej aktywności oraz ocena potencjalnego wpływu.
5. Eskalacja: kontakt z użytkownikiem, IT, właścicielem procesu biznesowego lub Incident Response według playbooka.
6. Ograniczenie: blokada konta, unieważnienie sesji i inne działania w uzgodnionym zakresie.
7. Analiza zasięgu: ustalenie, czy podobne wskaźniki występują na innych kontach i czy doszło do BEC lub eksfiltracji.

Wartość SOC powstaje między alertem a działaniem. Narzędzie może wskazać „Impossible Travel”, ale analityk musi uwzględnić VPN, podróż, znane adresy i aktywność po logowaniu. Z kolei pozornie mniej krytyczna reguła skrzynki może stać się bardzo istotna, gdy pojawia się kilka minut po logowaniu z nowego urządzenia i dotyczy wiadomości o płatnościach.

Modelowy scenariusz: od phishingu do próby Business Email Compromise

Poniższy przebieg jest modelowym przykładem ilustrującym proces, a nie opisem rzeczywistego klienta ani gwarantowanym czasem detekcji. Pracownik działu zakupów otwiera fałszywą stronę logowania. Kilka minut później konto zaczyna przeszukiwać pocztę, tworzy regułę ukrywającą wiadomości finansowe i otwiera dokumenty w SharePoint oraz OneDrive.

Czas modelowy

Zdarzenie

Ocena pojedynczego sygnału

Znaczenie po korelacji

09:11

Logowanie z nowego środowiska

Możliwa legalna anomalia

Wymaga obserwacji kolejnych działań

09:16

Nietypowe wyszukiwanie w poczcie

Niejednoznaczne

Wzmacnia podejrzenie po ryzykownym logowaniu

09:21

Nowa reguła ukrywająca wiadomości

Wysokie ryzyko

Typowy mechanizm ukrywania BEC

09:24

Dostęp do wielu plików finansowych

Może wynikać z pracy

Nietypowy wzorzec i możliwość rozpoznania danych

09:28

Próba wysłania wiadomości o zmianie rachunku

Krytyczne

Potwierdzenie aktywnego wykorzystania konta

Czas modelowy	Zdarzenie	Ocena pojedynczego sygnału	Znaczenie po korelacji
09:11	Logowanie z nowego środowiska	Możliwa legalna anomalia	Wymaga obserwacji kolejnych działań
09:16	Nietypowe wyszukiwanie w poczcie	Niejednoznaczne	Wzmacnia podejrzenie po ryzykownym logowaniu
09:21	Nowa reguła ukrywająca wiadomości	Wysokie ryzyko	Typowy mechanizm ukrywania BEC
09:24	Dostęp do wielu plików finansowych	Może wynikać z pracy	Nietypowy wzorzec i możliwość rozpoznania danych
09:28	Próba wysłania wiadomości o zmianie rachunku	Krytyczne	Potwierdzenie aktywnego wykorzystania konta

SOC koreluje sekwencję i potwierdza z użytkownikiem innym kanałem, że nie inicjował działań. Konto zostaje zablokowane, sesje unieważnione, a analiza obejmuje skrzynkę, MFA, aplikacje, dane i inne konta z podobnymi wskaźnikami.

Najważniejszym efektem jest przerwanie łańcucha przed skutecznym wyłudzeniem. Wynika to z połączenia telemetrii, analityka, playbooka i kontekstu biznesowego — tak jak w podejściu VigilHorizon do obsługi przejętych kont.

Jak wygląda reakcja krok po kroku

Microsoft w przewodniku dotyczącym reakcji na przejęte konto Microsoft 365 wskazuje m.in. blokadę konta, unieważnienie dostępu oraz kontrolę MFA i aplikacji. Playbook powinien obejmować pięć warstw.

1. Ograniczenie dostępu 2. Usunięcie mechanizmów trwałości 3. Ustalenie zakresu incydentu 4. Komunikacja i bezpieczne przywrócenie 5. Lessons Learned

1. Ograniczenie dostępu

• zablokuj logowanie i unieważnij aktywne sesje;
• zmień hasło oraz uwzględnij lokalny katalog w środowisku hybrydowym;
• sprawdź inne sposoby dostępu, w tym hasła aplikacji i starsze protokoły, jeżeli są używane.

Samo ustawienie nowego hasła nie może zamknąć sprawy. Trzeba osobno przerwać istniejący dostęp i ocenić mechanizmy, które mogą działać niezależnie od hasła.

2. Usunięcie mechanizmów trwałości

• usuń nieznane metody MFA i urządzenia;
• cofnij nielegalne zgody OAuth, delegacje i zmiany uprawnień;
• sprawdź reguły skrzynki, forwarding oraz inne utworzone mechanizmy dostępu.

3. Ustalenie zakresu incydentu

• odtwórz aktywność od pierwszego podejrzanego logowania;
• sprawdź MailItemsAccessed, reguły, wiadomości, pliki i aplikacje;
• znajdź te same wskaźniki na innych kontach i oceń, czy doszło do BEC lub ujawnienia danych.

4. Komunikacja i bezpieczne przywrócenie

• poinformuj właścicieli procesów i odbiorców fałszywych wiadomości zweryfikowanym kanałem;
• wstrzymaj podejrzane płatności lub zmiany danych kontrahentów;
• przywróć konto dopiero po usunięciu trwałości, ponownej rejestracji MFA i potwierdzeniu kontroli.

5. Lessons Learned

Po incydencie trzeba ustalić, dlaczego atak się powiódł, których danych zabrakło i gdzie reakcja straciła czas. To część pełnego Incident Response.

Jak ograniczyć ryzyko przejęcia konta

Skuteczna ochrona łączy prewencję, detekcję i reakcję. Żadna pojedyncza kontrola nie pokrywa całego łańcucha ataku.

1. Wdrażaj MFA odporne na phishing, szczególnie dla administratorów i ról krytycznych.
2. Stosuj Conditional Access z uwzględnieniem ryzyka, urządzenia i wrażliwości zasobu.
3. Ograniczaj uprawnienia i wyjątki, rozdzielaj konta administracyjne i wyłączaj nieużywane tożsamości.
4. Kontroluj aplikacje OAuth, rejestrację metod MFA, delegacje i reguły skrzynek.
5. Zapewnij użyteczne logi z Entra ID, Exchange, SharePoint, OneDrive, Teams i aplikacji.
6. Koreluj tożsamość z pocztą, danymi i endpointem, zamiast analizować każdą konsolę osobno.
7. Przypisz właściciela alertów i eskalację 24/7, aby sygnał nie czekał do rana.
8. Zabezpiecz płatności weryfikacją drugim kanałem, niezależnym od poczty i Teams.
9. Ćwicz playbook przejętego konta, obejmujący BEC, tokeny, OAuth i komunikację.
10. Mierz czas wykrycia i reakcji, zgodnie z zasadami opisanymi w artykule MTTD i MTTR — dlaczego czas wykrycia decyduje o skali incydentu.

Jeżeli organizacja nie potrafi potwierdzić kilku z tych elementów, może posiadać zabezpieczenia techniczne, ale nadal nie mieć pełnej zdolności do obsługi przejęcia konta.

Podsumowanie

Przejęcie konta Microsoft 365 nie kończy się na dostępie do poczty. Jedna tożsamość może prowadzić do dokumentów, komunikatorów, aplikacji biznesowych i danych klientów. Napastnik wykorzystuje ją do rozpoznania, BEC, kradzieży danych i utrzymania obecności.

Skuteczna ochrona wymaga metod odpornych na phishing, Conditional Access, kontroli aplikacji, kompletnej telemetrii oraz zespołu zdolnego przełożyć sygnały na decyzję.

Jeżeli nie wiesz, czy Twoja organizacja wykryje taki scenariusz odpowiednio wcześnie, warto zweryfikować pokrycie logami, reguły detekcji, uprawnienia do reakcji i playbook dla przejętego konta. Pakiet SOC 24/7 VigilHorizon łączy monitoring, analizę zdarzeń, korelację i reakcję według uzgodnionych procedur — od pierwszej anomalii do opanowania incydentu.

Najczęściej zadawane pytania (FAQ)

Czy MFA chroni przed przejęciem konta Microsoft 365?

MFA znacząco ogranicza ryzyko, ale nie daje pełnej odporności na MFA fatigue, kradzież tokenu lub consent phishing. Dlatego powinno być wspierane przez metody odporne na phishing, Conditional Access, monitoring i proces reakcji.

Co to jest Business Email Compromise?

Business Email Compromise, czyli BEC, to oszustwo wykorzystujące zaufanie do komunikacji biznesowej. Przejęta prawdziwa skrzynka zwiększa wiarygodność próśb o pieniądze, dane lub kolejne poświadczenia.

Czy zmiana hasła wystarczy po przejęciu konta?

Nie. Trzeba również unieważnić sesje, zweryfikować MFA, aplikacje OAuth, reguły skrzynki i uprawnienia, a następnie ustalić zakres dostępu oraz sprawdzić inne konta.

Jak długo napastnik może mieć dostęp po zmianie hasła?

Zależy to od rodzaju sesji, aplikacji i mechanizmu przejęcia. Zmiana hasła nie zastępuje jawnego unieważnienia dostępu ani kontroli zgód i innych mechanizmów trwałości.

Co oznacza alert Impossible Travel?

Oznacza aktywność z dwóch lokalizacji w czasie krótszym niż realistyczna podróż. To wskaźnik ryzyka, a nie dowód włamania; analiza musi uwzględnić m.in. VPN, urządzenie i dalszą aktywność.

Jak wykryć złośliwą regułę w skrzynce Microsoft 365?

Należy sprawdzić bieżące reguły, forwarding i logi audytowe zmian. Szczególnie podejrzane są mechanizmy ukrywające wiadomości o płatnościach, ostrzeżeniach lub odpowiedziach partnerów.

Czy napastnik może uzyskać dostęp bez znajomości hasła?

Tak. Może wykorzystać skradziony token sesyjny albo uprawnienia aplikacji OAuth przyznane przez użytkownika. Właśnie dlatego analiza musi obejmować sesje, urządzenia i aplikacje, a nie tylko historię zmian hasła.

Jakie logi są potrzebne do zbadania incydentu?

Potrzebne są logi Entra ID, Exchange Online, SharePoint, OneDrive, Teams oraz aplikacji i zgód OAuth. Zależnie od scenariusza analizę uzupełniają dane z endpointu, proxy, VPN, DNS i innych usług SaaS.

Czy SOC może monitorować Microsoft 365 przez całą dobę?

Tak, jeżeli obejmuje właściwe dane, detekcje, dyżur analityków, playbooki i uprawnienia do eskalacji. Samo przekazywanie alertów nie jest pełną obsługą SOC.

Co zrobić, gdy z przejętego konta wysłano fałszywe wiadomości?

Trzeba zatrzymać kampanię, ostrzec odbiorców zweryfikowanym kanałem i sprawdzić kolejne przejęcia. Przy żądaniu przelewu należy natychmiast zaangażować finanse i bank.

Dowiedz się więcej

• Czym jest SOC 24/7? Jak działa Security Operations Center i dlaczego monitoring nie wystarcza
• Incident Response — jak wygląda reakcja na cyberatak krok po kroku
• EDR, XDR i MDR — czym się różnią i kiedy naprawdę chronią firmę
• MTTD i MTTR — dlaczego czas wykrycia decyduje o skali incydentu
• SIEM w firmie — dlaczego samo wdrożenie nie zwiększa bezpieczeństwa