Najświeższe trendy w atakach na konta Microsoft 365 i jak wykorzystać nowe mechanizmy ochrony

Dlaczego konta Microsoft 365 są dziś kluczowym celem ataków

Jedno konto jako brama do całej organizacji

Konto Microsoft 365 nie jest już „tylko pocztą”. Jeden zestaw poświadczeń otwiera dostęp do Exchange Online, Teams, SharePoint, OneDrive, Plannerów, aplikacji biznesowych opartych o Entra ID (dawniej Azure AD), a często także do krytycznych aplikacji SaaS podpiętych przez SSO. Dla atakującego to idealny scenariusz: jednym skutecznym atakiem może uzyskać wgląd w całą komunikację, dokumenty i procesy firmy.

Przejęte konto w Microsoft 365 umożliwia m.in.:

• wysyłanie wiarygodnych wiadomości w imieniu pracownika lub członka zarządu,
• dostęp do poufnych plików (np. umów, ofert, arkuszy finansowych),
• przeglądanie historii spotkań i czatów w Teams,
• wykorzystanie konta jako punktu wejścia do innych systemów logowanych przez Entra ID,
• eskalację uprawnień – zwłaszcza jeśli użytkownik ma rolę administracyjną lub uczestniczy w procesach finansowych.

W praktyce oznacza to, że ochrona pojedynczego konta użytkownika ma równie krytyczne znaczenie, jak dawniej ochrona serwera plików w zamkniętej serwerowni. Atak na tożsamość w chmurze stał się realnym odpowiednikiem „włamania przez drzwi wejściowe” do firmy.

Praca zdalna i hybrydowa a ekspozycja kont na Internet

Model pracy hybrydowej sprawił, że logowania do Microsoft 365 pochodzą z dziesiątek różnych lokalizacji, adresów IP i urządzeń – często prywatnych, słabo kontrolowanych. Z punktu widzenia atakującego uprościło to działanie: ruch sieciowy z domowych łączy i sieci mobilnych nie wyróżnia się niczym szczególnym, przez co trudniej odróżnić legalne logowanie od podejrzanego.

Do tego dochodzi fakt, że:

• wielu pracowników korzysta z tych samych urządzeń do prywatnych zakupów, mediów społecznościowych i pracy,
• przeglądarki synchronizują hasła i cookies między urządzeniami, co zwiększa powierzchnię ataku na sesje,
• dostawcy Internetu mobilnego i domowego stosują NAT oraz zmienne adresy IP, utrudniając statyczne reguły bezpieczeństwa.

Organizacja, która opiera się wyłącznie na założeniu „pracownik łączy się z zaufanej sieci biurowej”, funkcjonuje de facto w modelu sprzed kilku lat i nie jest przygotowana na obecny krajobraz ataków. Stąd rosnące znaczenie podejścia zero trust i polityk opartych o ryzyko logowania, a nie o sam adres IP.

Motywacje atakujących: od BEC po pivot do sieci lokalnej

Ataki na konta Microsoft 365 są napędzane kilkoma powtarzającymi się motywacjami. Najbardziej widocznym w praktyce scenariuszem jest Business Email Compromise (BEC) – przejęcie skrzynki lub jej imitacja w celu wyłudzenia środków finansowych. Atakujący śledzą korespondencję, uczą się stylu pisania, procesów zatwierdzania płatności i w odpowiednim momencie podszywają się pod kontrahenta lub przełożonego.

Inne bardzo częste cele to:

• kradzież danych – wyciągnięcie ofert, dokumentacji technicznej, danych klientów,
• pivot do sieci lokalnej – wykorzystanie uprawnień w Entra ID i usług typu Azure AD Connect do ataku na środowisko on-premises,
• szantaż i wyciek – pozyskanie danych, które można wykorzystać w próbach wymuszenia (np. wrażliwe dane biznesowe, poufna komunikacja zarządu),
• dalsza dystrybucja malware – użycie zaufanego konta do rozsyłania złośliwych linków lub plików do kolejnych ofiar.

W części organizacji zagrożenie jest bagatelizowane, bo użytkownicy traktują konto Microsoft 365 jak „zwykłą pocztę”. Tymczasem przejęta tożsamość w chmurze, szczególnie gdy użytkownik ma delegowane uprawnienia administracyjne, może stać się punktem startowym dla ataku na całą infrastrukturę IT.

Włamanie na skrzynkę vs pełne przejęcie tożsamości w Entra ID

Stare podejście zakładało rozróżnienie: „złamano skrzynkę e-mail” vs „złamano konto domenowe”. W Microsoft 365 ta granica jest znacznie cieńsza. Konto użytkownika w Entra ID jest tożsamością nadrzędną dla wielu usług. Przejęcie skrzynki pocztowej to często skutek szerszego przechwycenia sesji lub tokenów logowania.

Między „samą skrzynką” a pełną tożsamością w Entra ID istnieje kilka poziomów zagrożenia:

• dostęp tylko do Exchange Online (np. przez aplikację OAuth ze zbyt szerokim zakresem),
• dostęp do Exchange + SharePoint/OneDrive,
• dostęp do całej tożsamości użytkownika i możliwość uzyskania tokenów do dowolnej usługi przypisanej w Entra ID,
• przejęcie konta z rolą administracyjną (Global Administrator, Exchange Administrator, SharePoint Administrator itp.).

W praktyce, jeśli obrońcy wykryją tylko nietypową aktywność pocztową, mogą pominąć fakt, że atakujący uzyskali szerszy dostęp – np. do aplikacji rejestrowanych w Entra ID. Stąd tak duże znaczenie ma monitorowanie logowań i uprawnień na poziomie tożsamości, a nie tylko samej skrzynki.

Dlaczego antywirus i firewall nie wystarczają

Klasyczne podejście: „mamy dobry antywirus i firewall, więc jesteśmy bezpieczni”, w kontekście Microsoft 365 zwyczajnie nie działa. Nawet wzorcowo skonfigurowany firewall nie zobaczy logowania użytkownika do chmury z prywatnego laptopa czy telefonu komórkowego w domu. Antywirus na stacji roboczej również nie zablokuje ataku, w którym użytkownik sam świadomie wprowadza dane logowania na fałszywej stronie lub akceptuje złośliwą aplikację OAuth.

Ochrona tożsamości wymaga innego zestawu mechanizmów:

• kontroli, kto i skąd może się logować,
• wymuszania silnych metod uwierzytelniania (MFA, najlepiej phishing-resistant MFA),
• analizy ryzyka logowania (nietypowe lokalizacje, urządzenia, wzorce zachowania),
• kontroli nad aplikacjami i ich uprawnieniami w Entra ID,
• ścisłej segmentacji uprawnień (zero trust) i zasad najmniejszego uprzywilejowania.

Bez tych elementów nawet rozbudowana ochrona sieci lokalnej pozostawia ogromną lukę – tożsamości chmurowe, do których można dobrać się z dowolnego miejsca na świecie.

Najważniejsze trendy w atakach na konta Microsoft 365 (ostatnie 12–24 miesięcy)

Od prostego phishingu haseł do ataków na sesję i tokeny

Jeszcze kilka lat temu dominowały kampanie phishingowe nastawione na wyłudzenie samego hasła. Obecnie atakujący coraz częściej koncentrują się na przechwyceniu sesji i tokenów dostępowych Microsoft 365. Powód jest prosty: hasło można zmienić, tokeny sesyjne bywają ważne przez dłuższy czas i umożliwiają omijanie standardowego MFA, jeśli zostały już poprawnie wydane.

Typowy schemat wygląda tak:

• ofiarę kieruje się na fałszywą stronę logowania M365,
• strona działa jako proxy (adversary-in-the-middle) do prawdziwego portalu logowania Microsoft,
• użytkownik wpisuje login, hasło i przechodzi proces MFA,
• proxy przechwytuje tokeny sesyjne i cookies, które następnie są wykorzystywane przez atakującego.

W efekcie atakujący może „wejść do środka” bez konieczności znajomości hasła czy przechodzenia MFA, przynajmniej dopóki token jest ważny i nie został unieważniony. Ten trend powoduje, że ochrona oparta wyłącznie na „MFA + silne hasło” nie wystarcza w części scenariuszy wysokiego ryzyka.

Rozwój BEC: mniej malware, więcej socjotechniki

Business Email Compromise nadal rośnie, ale jego forma ewoluowała. Zamiast wysyłać masowo zainfekowane załączniki, atakujący coraz częściej stawiają na soczjotechnikę i bardzo wiarygodne wiadomości. W praktyce oznacza to m.in.:

• podszywanie się pod dostawców z prośbą o zmianę numeru konta bankowego,
• podmianę faktur lub danych do przelewu w trwającej korespondencji,
• wiadomości z kont zarządu typu „pilna płatność, nie informuj księgowości, to poufny zakup”,
• używanie przekierowań skrzynki, aby subtelnie modyfikować wiadomości przychodzące i wychodzące.

Największym problemem jest to, że takie wiadomości często nie zawierają złośliwych linków ani plików, które można łatwo wykryć automatycznie. Kluczowa staje się ochrona samego konta (żeby do przejęcia BEC nie doszło) oraz specjalistyczne funkcje analizy treści i anomalii w poczcie, jakie oferuje m.in. Defender for Office 365.

Wzrost wykorzystania password spray i wyciekłych haseł

Przestępcy korzystają masowo z danych z wycieków innych serwisów (portale społecznościowe, sklepy internetowe, fora). Ponieważ wiele osób używa tych samych lub bardzo podobnych haseł w różnych miejscach, ponowne użycie haseł staje się jedną z głównych dróg ataku na konta Microsoft 365.

Typowy scenariusz obejmuje połączenie dwóch technik:

• password spray – sprawdzanie kilku popularnych haseł (np. „Wiosna2024!”) przeciwko wielu kontom w danej domenie, aby nie wywołać blokady konta,
• credential stuffing – masowe testowanie kombinacji login/hasło z wycieków na portalach logowania Microsoft 365 lub innych usługach korzystających z Entra ID.

Takie działania są trudne do wychwycenia klasycznymi mechanizmami, bo przypominają błędne logowania popełniane przez prawdziwych użytkowników. Stąd nacisk Microsoftu na polityki blokowania słabych i skompromitowanych haseł oraz na analizę ryzyka logowania (sign-in risk).

Nadużywanie aplikacji OAuth i consent phishing

Coraz istotniejszym trendem jest consent phishing – atak, w którym użytkownik samodzielnie przyznaje złośliwej aplikacji dostęp do swojego konta. Zamiast kraść hasło, przestępca tworzy aplikację, która prosi o uprawnienia typu:

• „odczyt i wysyłanie wiadomości w Twoim imieniu”,
• „dostęp do plików w Twoim OneDrive i SharePoint”,
• „dostęp do kalendarza i kontaktów”.

Użytkownik widzi standardowy ekran z prośbą o zgodę Microsoft, często z opisem sugerującym, że to „dodatek do Teams” czy „integracja z SharePoint”. Po zatwierdzeniu aplikacja uzyskuje tokeny dostępu, które mogą działać nawet po zmianie hasła, a w niektórych przypadkach – także po włączeniu MFA.

To podejście jest szczególnie niebezpieczne, ponieważ:

• wielu użytkowników traktuje ekran zgody jako „kolejne okno, które trzeba kliknąć”,
• standardowe mechanizmy wykrywania phishingu mogą nie potraktować tego jako ataku,
• nawet wdrożone MFA nie zatrzymuje procesu, bo użytkownik sam inicjuje uprawnienie dla aplikacji.

Zautomatyzowane narzędzia skanujące konfiguracje Microsoft 365

Atakujący przestali działać ręcznie. Coraz szerzej używane są automatyczne skanery i frameworki, które:

• analizują publiczne informacje DNS (MX, SPF, DKIM, DMARC) pod kątem misconfigów,
• sprawdzają, czy w organizacji dozwolona jest legacy authentication,
• testują, czy logowanie wymaga MFA i w jakich przypadkach,
• wykrywają anonimowo współdzielone pliki w SharePoint/OneDrive (linki „Anyone with the link”).

Takie narzędzia nie są zarezerwowane dla „zaawansowanych grup APT” – wiele z nich jest publicznie dostępnych, a ich obsługa nie wymaga głębokiej wiedzy technicznej. To oznacza, że błędy konfiguracyjne w Microsoft 365 są wykrywane szybko i na masową skalę. Organizacje, które nadal mają włączone stare protokoły lub nieograniczone udostępnianie plików, są w praktyce „podświetlone” w oczach przestępców.

Techniki ataku na logowania: od password spray do omijania MFA

Password spray kontra klasyczny brute force

Klasyczny brute force (setki tysięcy prób logowania na jedno konto) jest dziś w środowisku Microsoft 365 mało praktyczny. Limity, blokady, mechanizmy ochronne i systemy wykrywania sprawiają, że taki atak szybko zwraca na siebie uwagę. W praktyce zdecydowanie częściej wykorzystywany jest password spray.

W password spray atakujący wybiera kilka haseł (czasem kilkanaście), często opartych o najpopularniejsze wzorce (NazwaFirmy2023!, Wiosna2024!, Qwerty!23 itd.) i próbuje je na dużej liczbie kont w domenie. Zaletą jest minimalizacja ryzyka blokady kont i brak jednoznacznych sygnałów typu „setki nieudanych logowań z jednego IP na konto X”. Z perspektywy logów wygląda to podobnie do rozproszonych, sporadycznych błędnych logowań użytkowników.

Stąd kluczowe znaczenie ma:

• blokowanie słabych i przewidywalnych haseł,

Polityki haseł i ochrona przed ponownym użyciem danych z wycieków

Sama złożoność hasła (długość, cyfry, znaki specjalne) ma dziś mniejsze znaczenie niż jego przewidywalność i powiązanie z użytkownikiem lub organizacją. Schematy typu NazwaFirmy2024! czy Imię123! przechodzą klasyczne reguły złożoności, ale w praktyce są trywialne do zgadnięcia w password spray.

Minimum techniczne w Microsoft 365 / Entra ID obejmuje:

• włączenie password protection z własną listą zabronionych haseł (nazwy firmy, produktów, miejscowości, domen itd.),
• blokowanie haseł uznanych przez Microsoft za skompromitowane (globalny feed),
• wycofanie lokalnych zasad typu „zmiana hasła co 30 dni” na rzecz stabilniejszych, ale realnie silnych fraz i MFA.

Osobną kwestią jest wymuszanie zmiany haseł po incydentach. Automatyczne kampanie „reset hasła po 90 dniach” nie rozwiązują problemu reuse – użytkownicy tworzą warianty poprzednich fraz. Skuteczniejsze są akcje targetowane: zmiana haseł wyłącznie dla kont, które zostały oznaczone jako potencjalnie skompromitowane na podstawie sygnałów z Entra ID Identity Protection lub zewnętrznych źródeł threat intelligence.

Omijanie MFA: zmęczenie powiadomieniami i social engineering przy logowaniu

Wiele organizacji po wdrożeniu MFA popada w złudne poczucie bezpieczeństwa. Tymczasem większość stosowanych metod (MFA oparte na SMS, połączenia telefoniczne, powiadomienia push „approve/deny”) jest podatna na techniki socjotechniczne i ataki na „zmęczenie użytkownika”.

Typowe scenariusze omijania MFA:

• MFA fatigue – atakujący próbuje logować się wiele razy na poprawne hasło, generując serię powiadomień push na telefonie. Przy wystarczającej uporczywości część użytkowników klika „Akceptuj”, żeby „mieć to z głowy”.
• Podszycie się pod IT – ofiara jest proszona (telefon/Teams/mail) o „potwierdzenie logowania serwisowego” lub „akceptację nowej polityki bezpieczeństwa”, co faktycznie autoryzuje atakującego.
• Phishing „MFA reset” – fałszywe portale lub formularze udające stronę Microsoft, które proszą o podanie jednorazowego kodu lub zatwierdzenie logowania.

Ryzyko znacznie rośnie, gdy używane są:

• SMS jako jedyna metoda MFA,
• połączenia głosowe („naciśnij #, aby zatwierdzić”),
• aplikacje push bez konfiguracji reguły „number matching” i bez wyświetlania kontekstu logowania (lokacja, aplikacja, adres).

Lepsze praktyki w tym obszarze:

• wymuszenie number matching w Microsoft Authenticator oraz wyświetlania szczegółów logowania,
• wyłączenie połączeń głosowych i, jeśli to możliwe, ograniczenie SMS tylko do awaryjnego odzyskiwania konta,
• jasna polityka: „nigdy nie akceptuj powiadomień MFA, jeśli samemu nie inicjowałeś logowania”, wzmocniona krótkimi szkoleniami i symulacjami.

Ataki kombinowane: password spray + socjotechnika + MFA bypass

W realnych incydentach rzadko spotyka się „czyste” scenariusze teoretyczne. Zwykle jest to miks kilku technik:

1. Atakujący zdobywa hasło (wyciek, password spray, phishing).
2. Sprawdza, czy konto ma włączone MFA i jakie metody są dostępne.
3. Jeśli aktywne są powiadomienia push/SMS, uruchamia kampanię MFA fatigue.
4. Równolegle może wysłać wiadomość podszywającą się pod IT lub Teams „od administratora”.
5. Po uzyskaniu jednorazowego zatwierdzenia logowania ustanawia trwałą sesję, dodaje metodę backupową albo rejestruje nową aplikację.

To połączenie powoduje, że samo wdrożenie MFA bez kontroli nad metodami i bez ochrony sesji jest środkiem niepełnym. Trzeba jednocześnie pilnować jakości haseł, typów MFA, polityk dostępu warunkowego oraz aktywnych sesji i urządzeń.

Ataki na tokeny i sesje: przejęcie „klucza do królestwa”

Jak działają tokeny w Microsoft 365 i dlaczego są łakomym kąskiem

Po poprawnym zalogowaniu do Microsoft 365 użytkownik otrzymuje kilka typów tokenów (m.in. tokeny dostępu i odświeżania). Dla atakującego cenniejszy bywa nie sam login/hasło, lecz właśnie gotowy token, bo:

• jest już powiązany z poprawnym uwierzytelnieniem, w tym z przejściem MFA,
• może być ważny przez dłuższy okres (w szczególności tokeny odświeżania),
• umożliwia dostęp z innego urządzenia, jeśli nie wymusza się silnej kontroli urządzeń i lokalizacji.

W praktyce przejęcie tokenu często wygląda dla systemu jak „normalna, kontynuowana sesja użytkownika”, a nie jak nowe logowanie. To sprawia, że klasyczne mechanizmy typu „wymagaj MFA przy każdym nowym logowaniu” nie mają zastosowania.

Phishing sesyjny i adversary-in-the-middle (AiTM)

Strony phishingowe pełniące rolę proxy znacząco komplikują detekcję. Użytkownik widzi prawdziwą stronę logowania Microsoft (wstrzykniętą w ramkę lub tunelowaną przez serwer pośredniczący), a przeglądarka odbiera poprawne odpowiedzi z chmury. Tymczasem po drodze serwer atakującego przechwytuje całą wymianę, w tym tokeny sesyjne.

Charakterystyczne cechy takich kampanii:

• adres URL nie należy do Microsoft, ale treść strony i certyfikat TLS wyglądają wiarygodnie (często użyte są domeny podobne lub „neutralne” typu sharepoint-secure[.]com),
• po zalogowaniu użytkownik trafia do prawdziwej skrzynki lub dokumentu, więc nie ma wrażenia, że „coś poszło nie tak”,
• atakujący często automatycznie eksportuje tokeny do narzędzi umożliwiających dalszą interakcję z kontem.

Skuteczna obrona wymaga połączenia kilku warstw:

• filtrowania i analizy reputacji adresów URL (Defender for Office 365, proxy z inspekcją ruchu HTTPS),
• kontroli nad metodami MFA (preferencja dla rozwiązań odpornych na phishing, jak FIDO2 / Windows Hello),
• monitorowania anomalii w użyciu tokenów (nietypowe lokalizacje, aplikacje klienckie, nagłe zmiany w adresach IP w czasie jednej sesji).

Pass-the-cookie i kradzież sesji przeglądarki

Drugą grupą technik są ataki na lokalne przeglądarki i przechowywane w nich ciasteczka sesyjne. Nawet jeśli logowanie było w pełni poprawne, z użyciem silnego MFA, to zainfekowana stacja robocza może „wyciągnąć” cookie i sprzedać je dalej.

Typowe źródła zagrożenia:

• malware kradnący przeglądarkowe cookies i dane autouzupełniania,
• pluginy/rozszerzenia przeglądarki o zbyt szerokich uprawnieniach,
• zdalne narzędzia administracyjne (RMM) używane bez odpowiedniego nadzoru, przejęte przez atakujących.

Obrona nie sprowadza się tu do „lepszego antywirusa”. Potrzebne są:

• Endpoint Detection & Response (Defender for Endpoint) z naciskiem na wykrywanie kradzieży przeglądarkowych artefaktów,
• regularne unieważnianie sesji po zmianie krytycznych parametrów konta (hasło, metody MFA, uprawnienia administracyjne),
• wymuszanie logowania interaktywnego przy działaniach o podwyższonym ryzyku (privileged access), nawet jeśli istnieje aktywna sesja.

Wymuszanie ponownego logowania i zarządzanie czasem życia sesji

Domyślne czasy życia sesji w Microsoft 365 są często zbyt długie dla środowisk o podwyższonym ryzyku. Jeśli token jest ważny kilka godzin lub dni, to okno czasowe dla atakującego jest bardzo szerokie.

Kontrola nad sesjami obejmuje m.in.:

• stosowanie Conditional Access Session Controls, np. skrócenie czasu bezczynności, wymuszanie ponownego logowania przy zmianie IP lub kraju,
• stosowanie sign-in frequency zamiast „pamiętaj mnie przez 30 dni” dla kont wrażliwych (finanse, HR, administratorzy),
• rutynowe „sign out” wymuszane po incydencie bezpieczeństwa lub wykryciu ryzyka wysokiego poziomu.

Nie ma jednego idealnego ustawienia – zbyt agresywne skrócenie sesji generuje frustrację użytkowników i może prowadzić do obchodzenia zasad (np. zapisywanie haseł w niebezpieczny sposób). Parametry warto kalibrować na podstawie faktycznych incydentów oraz profilu ryzyka poszczególnych grup.

Nadużywanie aplikacji, uprawnień i współdzielenia w Microsoft 365

Shadow IT w Entra ID: aplikacje, o których nikt nie pamięta

Niemal w każdej większej organizacji występuje zjawisko „shadow IT” na poziomie aplikacji chmurowych. Pracownicy testują dodatki do Outlooka, integracje CRM, narzędzia do zarządzania zadaniami – wszystkie one często rejestrują się jako aplikacje w Entra ID i proszą o różne uprawnienia.

Ryzyka wynikające z niekontrolowanego przyznawania zgód:

• aplikacje firm trzecich z szerokim zakresem dostępu (mail, pliki, kalendarze), których nikt nie recenzował pod kątem bezpieczeństwa,
• zdezaktualizowane lub porzucone integracje pozostające z pełnymi uprawnieniami,
• możliwość przejęcia kont deweloperskich twórców aplikacji i wykorzystania ich do ataków łańcucha dostaw.

Minimalne działania porządkowe:

• wyłączenie opcji „każdy użytkownik może udzielić zgody aplikacjom” i wprowadzenie centralnego procesu akceptacji,
• regularny przegląd listy zarejestrowanych aplikacji, szczególnie tych z rolami typu Mail.ReadWrite, Files.ReadWrite.All, Directory.Read.All,
• oznaczanie aplikacji „krytycznych” i monitorowanie ich zachowania w logach sign-in i audit.

Consent phishing na poziomie organizacyjnym

Jeśli aplikacja uzyska uprawnienia typu „read mail in all mailboxes” lub „read all files” w trybie aplikacyjnym (app-only), skutki wykraczają daleko poza jedno konto użytkownika. To już nie jest problem jednostkowego phishingu, ale potencjalne naruszenie całej organizacji.

Scenariusz bywa prosty:

1. Atakujący tworzy aplikację udającą popularne rozwiązanie (np. integracja z kalendarzem, automatyzacja raportów).
2. Użytkownik lub nawet administrator wyraża zgodę na poziomie „organizacyjnym”, nie do końca rozumiejąc zakres uprawnień.
3. Aplikacja uzyskuje tokeny z uprawnieniami szerokimi jak konto serwisowe.

Ograniczanie tego typu ryzyka to przede wszystkim:

• włączenie i egzekwowanie admin consent workflow – żadna aplikacja z uprawnieniami organizacyjnymi nie powinna być akceptowana ad hoc,
• używanie Entra ID Governance do okresowych kampanii przeglądu uprawnień aplikacji,
• monitorowanie alertów dotyczących nowych zgód administracyjnych (Defender for Cloud Apps / Entra ID).

Nadużycia współdzielenia w SharePoint i OneDrive

Microsoft 365 bardzo ułatwia współdzielenie plików – i to jest jednocześnie jego siła oraz słabość. Często spotykane błędy konfiguracyjne:

• domyślne linki typu „Anyone with the link” pozostawione bez limitu czasu i bez hasła,
• możliwość tworzenia takich linków dla zewnętrznych domen bez żadnej weryfikacji,
• brak widoczności, które pliki są aktualnie współdzielone i z kim.

Do tego dochodzą nadużycia wewnętrzne – pracownik, który ma pełne prawo do pliku, ale nie powinien móc wysłać go poza organizację, robi to „na skróty”, wysyłając publiczny link. W logach zdarzeń widać potem tylko „anonimowy dostęp”, bez jasnej informacji, kto finalnie czytał dokument.

Praktyczne kroki porządkowe:

• ograniczenie lub całkowite wyłączenie linków Anyone, przynajmniej dla wrażliwych site’ów,
• preferowanie linków typu „Specific people” oraz wymóg logowania dla odbiorców spoza organizacji,
• definiowanie etykiet wrażliwości i zasad DLP, które automatycznie uniemożliwiają udostępnianie na zewnątrz określonych typów danych.

Uprawnienia administratorów i ryzyko „za szerokich ról”

Konta administratorów Microsoft 365 bywają jednocześnie najcenniejszym i najsłabiej chronionym zasobem. Typowe problemy:

• użytkownicy z rolami global admin, którzy nie potrzebują ich na co dzień,
• brak rozdzielenia obowiązków (jeden admin robi wszystko: Exchange, SharePoint, Entra ID, licencje),

Delegowanie uprawnień i tymczasowy dostęp uprzywilejowany

Konta techniczne z permanentnymi rolami administracyjnymi to ulubiony cel atakujących. Dużo bezpieczniejszy jest model, w którym dostęp uprzywilejowany jest przyznawany na żądanie i tylko na czas wykonania konkretnego zadania.

Kluczowe elementy takiego podejścia:

• Entra Privileged Identity Management (PIM) – role administracyjne przypisane jako „eligible”, a nie „active”, z wymogiem uzasadnienia oraz akceptacji przez innego administratora,
• tymczasowe podnoszenie uprawnień przy incydentach lub zmianach konfiguracyjnych wysokiego ryzyka, zamiast stałych ról global admin lub security admin,
• logowanie i korelacja wszystkich aktywacji ról z późniejszymi zdarzeniami (np. zmiany zasad Conditional Access, modyfikacje aplikacji w Entra ID).

Przy wprowadzaniu PIM pojawia się zwykle opór: „utrudniacie nam pracę, wcześniej było szybciej”. W praktyce można zacząć od najmocniejszych ról (Global Administrator, Privileged Role Administrator, Security Administrator), a dopiero potem obejmować kolejne. Z czasem wychodzi też na jaw, które role były nadane „na wszelki wypadek” i nikt ich realnie nie potrzebuje.

Segmentacja ról i minimalizacja uprawnień

Drugim filarem bezpieczeństwa administracyjnego jest segmentacja – zarówno na poziomie ról Entra ID, jak i ról lokalnych w poszczególnych usługach (Exchange, SharePoint, Teams). Zbyt szeroka rola jednego administratora to ryzyko jednostkowego punktu porażki.

Przy tworzeniu podziału ról sprawdza się prosta zasada: każda osoba powinna mieć dostęp tylko do tego obszaru, za który faktycznie odpowiada. Przykładowo:

• zespół odpowiedzialny za pocztę – role typu Exchange Administrator, bez pełnego Global Admin,
• zespół od tożsamości – Entra ID Administrator / User Administrator, ale bez dostępu do zawartości skrzynek,
• zespół bezpieczeństwa – Security Reader / Security Administrator, ewentualnie zgodnie z modelem Just-In-Time przez PIM.

Pułapką bywa nadawanie ról na poziomie globalnym, gdy realna potrzeba jest węższa. Typowy przykład: przydzielenie roli SharePoint Administrator tylko po to, aby zarządzać kilkoma site’ami projektowymi. W takim scenariuszu często wystarczy rola na poziomie Site Collection Administrator lub dobrze zaprojektowane grupy właścicieli witryn.

Nowe i rozwijane mechanizmy ochrony w ekosystemie Microsoft 365

Od „legacy security” do natywnego Zero Trust

Ochrona w Microsoft 365 coraz mniej przypomina klasyczne podejście „firewall + antywirus”. Rdzeniem staje się model Zero Trust: brak zaufania do sieci, urządzeń i użytkowników bez ciągłej weryfikacji. W Microsoft 365 przekłada się to na połączenie kilku funkcji, które osobno dają ograniczony efekt, a razem pozwalają znacząco utrudnić przejęcie konta:

• Entra ID Conditional Access – wymusza MFA, ogranicza dostęp z określonych lokalizacji, wymaga zgodnych urządzeń,
• Defender for Cloud Apps – kontroluje użycie aplikacji SaaS, wykrywa nietypowe zachowania,
• Defender for Endpoint – dostarcza sygnały o stanie urządzeń (risk score) do decyzji dostępowych,
• Entra Identity Protection – ocenia ryzyko logowania i użytkownika na podstawie globalnej telemetrii.

Najczęstszy błąd: wdrożenie pojedynczej funkcji (np. wymuszenie MFA) bez spójnej polityki warunkowego dostępu i integracji z sygnałami ryzyka. Efekt – rośnie liczba promptów MFA, ale odporność na ataki AiTM czy kradzież tokenów wcale nie jest znacząco lepsza.

Conditional Access jako „centrum sterowania” logowaniami

Conditional Access (CA) jest dziś faktycznym punktem, w którym można egzekwować najważniejsze zasady bezpieczeństwa kont Microsoft 365. Dobrze zaprojektowane zasady CA potrafią znacząco zredukować skuteczność wielu klas ataków, ale wymaga to porzucenia domyślnej filozofii „pozwól, chyba że…”.

Podstawowe wzorce konfiguracji, które sprawdzają się w większości średnich i dużych organizacji:

• Blokada legacy authentication – wyłączenie protokołów nieobsługujących nowoczesnego uwierzytelniania (POP, IMAP, SMTP Auth tam, gdzie to możliwe),
• Wymuszenie MFA dla wszystkich użytkowników, ale z różnymi poziomami wymogów – silniejsze metody dla administratorów i kont uprzywilejowanych,
• Warunkowanie dostępu od stanu urządzenia – dostęp do kluczowych aplikacji tylko z urządzeń zgodnych (Intune compliant) lub przynajmniej zarządzanych,
• Osobne zasady dla administracji – np. dostęp administracyjny tylko z dedykowanych stacji roboczych (PAW) i bez możliwości logowania z Internetu ogólnego.

Przy wdrażaniu CA rozsądną ścieżką jest tryb Report-only – zasady są oceniane, ale jeszcze nie blokują dostępu. Na tej podstawie można ocenić liczbę potencjalnych blokad oraz zidentyfikować nietypowe aplikacje lub urządzenia, które wymagają wyjątków albo planu migracji.

Identity Protection i dynamiczne decyzje o dostępie

Identity Protection wykorzystuje globalną telemetrię i uczenie maszynowe do oceny ryzyka logowań i użytkowników. Nie jest to „magiczny radar”, który wyłapie każdy atak, ale przy poprawnej konfiguracji potrafi wychwycić wiele nietypowych zachowań, których nie da się odfiltrować prostymi regułami.

Typowe sygnały wykorzystywane przez Identity Protection:

• logowanie z nowych, nieznanych lokalizacji lub nietypowych kombinacji kraju i dostawcy Internetu,
• logowanie z adresów IP powiązanych z anonimizerami, botnetami lub serwerami atakującymi inne organizacje,
• charakterystyczne wzorce „password spray” lub prób logowania do wielu kont z jednego źródła.

Największą wartość daje kombinacja Identity Protection z Conditional Access. Zamiast uniwersalnego wymogu MFA dla wszystkich, można stosować bardziej elastyczne podejście: przy niskim ryzyku – standardowe logowanie, przy średnim – wymuś silną metodę MFA, przy wysokim – zablokuj dostęp i wymuś reset hasła lub interwencję SOC.

Defender for Office 365 i ochrona przed phishingiem ukierunkowanym

Ataki na konta Microsoft 365 w przeważającej części zaczynają się od wiadomości e-mail. Klasyczne filtry antyspamowe i reguły treściowe coraz częściej zawodzą, bo kampanie są krótkotrwałe, a domeny jednorazowe. Defender for Office 365 dodaje kilka mechanizmów, które bezpośrednio utrudniają przejęcie konta:

• Safe Links – przepisywanie adresów URL i ich analiza w momencie kliknięcia, co ogranicza skuteczność kampanii, w których „czysta” domena zostaje podmieniona na złośliwą dopiero po dostarczeniu maila,
• Safe Attachments – detonacja załączników w piaskownicy i blokowanie plików, które próbują wykradać tokeny, cookies lub instalować stealer’y przeglądarkowe,
• Impersonation protection – wykrywanie podszywania się pod domeny, dyrektorów lub zaufanych partnerów biznesowych.

Nadmiar zaufania do automatycznej klasyfikacji jest jednak ryzykowny. Sporo kampanii phishingowych wykorzystuje spreparowane konwersacje, przekazywane dalej w wąskich wątkach („forwarded conversation”), które wyglądają jak odpowiedź kolegi z zespołu. W takich przypadkach przydają się dodatkowe reguły, np. podnoszenie poziomu detekcji dla maili spoza organizacji, w których występują słowa-klucze związane z resetem hasła, podpisami elektronicznymi czy szablonami Microsoft 365.

Defender for Cloud Apps i kontrola nad aplikacjami SaaS

Defender for Cloud Apps (dawniej MCAS) jest często traktowany jako narzędzie „opcjonalne”, tymczasem przy atakach na konta Microsoft 365 pełni ważną rolę kontroli nad użyciem aplikacji i wychwytywaniem nietypowych zachowań.

Przykładowe zastosowania:

• identyfikacja aplikacji chmurowych, do których użytkownicy logują się firmowym kontem Microsoft 365, choć nie są one formalnie zatwierdzone,
• wykrywanie masowych pobrań plików z OneDrive/SharePoint, szczególnie z kont o podwyższonych uprawnieniach,
• monitorowanie nowych uprawnień przyznawanych aplikacjom (app consent) i korelacja z logowaniami z podejrzanych lokalizacji.

Nie chodzi o pełną blokadę wszystkiego, co jest „nieautoryzowane” – taki model zwykle kończy się przeniesieniem pracy użytkowników do prywatnych kont i kanałów. Skuteczniejsze jest stopniowe kategoryzowanie aplikacji (approved, monitored, unsanctioned) i egzekwowanie zasad wyłącznie tam, gdzie ryzyko faktycznie jest wysokie (np. aplikacje do anonimowego dzielenia się plikami, które używają firmowego loginu).

Entra ID Governance i porządkowanie cyklu życia uprawnień

Uprawnienia w Microsoft 365 mają tendencję do akumulacji. Projekty się kończą, ludzie zmieniają zespoły, integracje przestają być używane – prawa zostają. To jest wygodne dla użytkowników, ale sprzyja powolnemu rozszerzaniu powierzchni ataku. Entra ID Governance wprowadza mechanizmy, które pomagają ten proces odwrócić.

Najbardziej praktyczne elementy:

• Access Reviews – okresowe kampanie przeglądu uprawnień do grup, aplikacji i ról. Właściciele zasobów są zmuszeni odpowiedzieć na pytanie: „czy ten użytkownik nadal potrzebuje dostępu?”.
• Entitlement Management – pakiety uprawnień (access packages), które mają zdefiniowany czas życia oraz proces zatwierdzania, zamiast ręcznego dodawania do wielu grup i ról.
• Automatyzacja na podstawie atrybutów – przypisywanie i odbieranie dostępu w oparciu o dane HR (departament, stanowisko, lokalizacja) oraz zdarzenia typu „offboarding”.

W praktyce często wychodzi, że pierwsze kampanie Access Reviews ujawniają setki kont z dostępem do zespołów projektowych sprzed kilku lat, do których nikt już nie zagląda, ale które nadal mają prawo czytać wrażliwe dane. To nie jest pojedynczy „błąd”, tylko typowy efekt braku systemowego podejścia do cyklu życia uprawnień.

Secure Score i mierzenie postępu, a nie tylko listy „check-boxów”

Secure Score dla Microsoft 365 bywa traktowane jako marketingowy wskaźnik, ale dobrze użyte może pomóc w podejmowaniu decyzji, co poprawić w pierwszej kolejności. Problem pojawia się, gdy celem staje się „wykręcenie jak najwyższego wyniku”, zamiast realnego obniżenia ryzyka.

Rozsądne podejście do Secure Score obejmuje:

• fokus na kontrolach związanych z tożsamością i logowaniami – MFA, blokada legacy auth, Conditional Access, ochrona administratorów,
• świadomą decyzję o pominięciu części rekomendacji, które przynoszą mały zysk przy dużym koszcie operacyjnym (np. nadmiernie agresywne zasady haseł przy dobrze wdrożonym MFA),
• monitorowanie trendu w czasie – czy po wprowadzeniu nowych usług i integracji wynik utrzymuje się, czy systematycznie spada.

Zamiast „gonienia” za 100%, bardziej użyteczne jest zdefiniowanie minimalnego akceptowalnego poziomu dla organizacji o danym profilu (np. powyżej 60–70% dla firmy o umiarkowanym ryzyku, wyżej dla sektorów regulowanych) i skupienie się na utrzymaniu go bez nadmiernego obciążenia zespołu IT.

Phishing-resistant MFA i „silne” metody logowania w praktyce

Dlaczego klasyczne MFA przestaje wystarczać

Kody SMS, aplikacje generujące kody TOTP i powiadomienia „push, kliknij zatwierdź” przez długi czas uchodziły za złoty standard. Ataki AiTM i masowe kampanie „MFA fatigue” pokazały jednak, że technicznie poprawne wdrożenie MFA nie jest równoznaczne z odpornością na phishing.

Typowe problemy:

• użytkownik zatwierdza powiadomienie MFA, bo „i tak ciągle coś wyskakuje”,
• kody TOTP mogą zostać przechwycone w czasie rzeczywistym przez stronę phishingową-proxy,
• SMS są narażone na ataki na infrastrukturę telekomunikacyjną, SIM swap czy przekierowania numerów.

Silniejsze metody logowania koncentrują się na powiązaniu urządzenia z tożsamością użytkownika i kryptograficznym uwierzytelnieniu, zamiast na wpisywaniu czy przepisywaniu kodów.

FIDO2 i passkeys w środowiskach firmowych

FIDO2 / WebAuthn to jedna z głównych technologii uznawanych za odporne na phishing. Prymarnym nośnikiem mogą być zarówno fizyczne klucze sprzętowe (YubiKey, Feitian itp.), jak i wbudowane zabezpieczenia platformowe (Windows Hello, biometria w mobilnych systemach operacyjnych).

Najważniejsze korzyści z perspektywy ataków na konta Microsoft 365:

• brak haseł wpisywanych w formularz – podatność na klasyczne phishingowe strony logowania drastycznie spada,
• uwierzytelnienie powiązane z konkretną domeną – sklonowana strona w innej domenie nie może wykorzystać tych samych kluczy,
• silne powiązanie z urządzeniem – kradzież samego tokenu sesyjnego jest utrudniona przez dodatkowe zabezpieczenia na poziomie hardware’u.

Problematyczny bywa etap wdrożenia. Organizacje często zderzają się z pytaniami praktycznymi:

Co warto zapamiętać

• Jedno konto Microsoft 365 jest dziś bramą do większości zasobów firmy – przejęcie tożsamości użytkownika daje dostęp nie tylko do poczty, ale też do plików, czatów, spotkań i aplikacji biznesowych spiętych z Entra ID.
• Model pracy zdalnej i hybrydowej mocno zwiększa ekspozycję kont na Internet – logowania z prywatnych, współdzielonych urządzeń i zmiennych adresów IP utrudniają klasyczne podejście „zaufana sieć biurowa vs reszta świata”.
• Motywacje atakujących wykraczają daleko poza samą pocztę: od oszustw BEC i wyłudzeń płatności, przez kradzież danych, aż po pivot z chmury do sieci lokalnej i dalszą dystrybucję malware z wykorzystaniem zaufanego konta.
• Różnica między „włamaniem na skrzynkę” a pełnym przejęciem tożsamości w Entra ID jest w praktyce cienka – skupienie się tylko na anomaliach w poczcie może ukryć fakt, że atakujący mają już szersze uprawnienia w całym środowisku.
• Klasyczny zestaw: antywirus + firewall nie chroni skutecznie kont Microsoft 365, bo nie widzi logowań z prywatnych urządzeń ani decyzji użytkownika, który sam wpisuje hasło na fałszywej stronie lub akceptuje złośliwą aplikację OAuth.
• Skuteczna obrona musi opierać się na ochronie tożsamości: silnym i najlepiej odpornym na phishing MFA, kontroli dostępów według ryzyka logowania, monitorowaniu uprawnień i aplikacji w Entra ID oraz zasadzie najmniejszych uprawnień (zero trust).

Źródła

• Microsoft 365 security for identity and access. Microsoft – Oficjalne zalecenia ochrony tożsamości, MFA, ryzyka logowań w M365/Entra ID
• Defending against adversary-in-the-middle (AiTM) phishing attacks. Microsoft – Opis ataków proxy na logowanie, przechwytywanie sesji i tokenów M365
• Business Email Compromise: The $26 Billion Scam. Federal Bureau of Investigation (2019) – Charakterystyka BEC, wektory ataku, skala zjawiska globalnie
• Zero Trust Architecture. National Institute of Standards and Technology (2020) – Model zero trust, zasady najmniejszego uprzywilejowania i segmentacji dostępu
• Microsoft 365: Security best practices and recommendations. Center for Internet Security – Praktyki zabezpieczania kont, poczty, SharePoint i tożsamości w M365
• Microsoft 365 threat intelligence: Trends in identity attacks. Microsoft Defender Threat Intelligence – Trendy w atakach na konta M365, tokeny, MFA, BEC z danych telemetrycznych
• Guidance on defending Microsoft 365 from phishing attacks. Cybersecurity and Infrastructure Security Agency – Rekomendacje CISA dot. ochrony M365 przed phishingiem i przejęciem kont