Pentest Microsoft 365 - co sprawdzamy w Entra ID, poczcie i SharePoincie

W skrócie: w firmie, która pracuje na Microsoft 365, napastnik zwykle nie musi włamywać się na żaden serwer. Wystarczy mu jedno konto pracownika, a dalej decyduje konfiguracja: wyjątki od MFA, uprawnienia administratorów, zgody na aplikacje i ustawienia udostępniania.

Pentest Microsoft 365 sprawdza, jak daleko zajdzie ktoś z przejętym kontem i czy da się to konto w ogóle przejąć. Poniżej lista obszarów, w których najczęściej coś znajdujemy.

Poczta, pliki, Teams, kalendarze i logowanie do innych aplikacji przez konto Microsoft. W wielu firmach to jedno miejsce trzyma praktycznie wszystko, co ważne. Dlatego konto w Entra ID (dawniej Azure AD) jest dziś ważniejsze niż hasło do serwera, a błąd w konfiguracji tenanta potrafi otworzyć więcej niż podatność w aplikacji.

Domyślne ustawienia Microsoftu są coraz rozsądniejsze, ale każda firma z czasem dokłada wyjątki: dla drukarki skanującej do maila, dla prezesa, który nie lubi potwierdzeń w telefonie, dla aplikacji, którą ktoś podłączył trzy lata temu. Te wyjątki są tym, czego szukamy.

Logowanie i MFA

Samo włączenie MFA to dopiero początek. Sprawdzamy, czy da się je obejść:

Wyjątki w zasadach dostępu warunkowego. Konta serwisowe, grupy wyłączone „tymczasowo”, zaufane lokalizacje obejmujące całe zakresy adresów. Każde takie konto to miejsce, gdzie wystarczy samo hasło.
Stare protokoły. IMAP, POP czy SMTP z uwierzytelnianiem hasłem nie obsługują MFA. Jeśli są gdzieś dopuszczone, próba zgadywania haseł omija drugi składnik.
Rodzaj drugiego składnika. SMS i zwykłe zatwierdzanie powiadomienia nie chronią przed phishingiem, który przechwytuje sesję w locie (tzw. adversary-in-the-middle). Odporne na to są klucze FIDO2 i passkeys, przynajmniej dla administratorów.
Phishing kodem urządzenia. Napastnik prosi ofiarę o wpisanie kodu na prawdziwej stronie Microsoftu i dostaje token do jej konta. Sprawdzamy, czy ten sposób logowania jest w ogóle potrzebny i czy da się go ograniczyć.
Konta awaryjne. Czy istnieje konto „break-glass” na wypadek awarii MFA, czy jest monitorowane i czy jego hasło nie leży w arkuszu na SharePoincie.

Uprawnienia administracyjne

W małych i średnich firmach regularnie widzimy po kilka, czasem kilkanaście kont z rolą Global Administrator. Często są to codzienne konta pracowników, którymi czyta się też pocztę i klika w linki. Przejęcie takiego konta to przejęcie całej organizacji.

Sprawdzamy, kto ma jakie role, czy da się je zawęzić (osobne role do zarządzania użytkownikami, pocztą czy Teams), czy administratorzy mają osobne konta tylko do administracji i czy uprawnienia są przyznawane na stałe, czy na czas potrzebny do zadania. Patrzymy też na mniej oczywiste ścieżki: kto może resetować hasła administratorom, dodawać członków do grup z uprawnieniami albo zmieniać właściciela aplikacji.

Aplikacje i zgody

To obszar, o którym firmy wiedzą najmniej. Każda aplikacja podłączona do Microsoft 365 („Zaloguj przez Microsoft”, wtyczka do Outlooka, integracja z CRM) dostaje jakieś uprawnienia do danych. Sprawdzamy:

czy zwykły użytkownik może sam wyrazić zgodę na dostęp aplikacji do swojej poczty i plików. Jeśli tak, wystarczy przekonujący link, żeby obca aplikacja czytała jego skrzynkę bez znajomości hasła i mimo MFA,
które aplikacje mają szerokie uprawnienia do całego tenanta, np. odczyt wszystkich skrzynek, i czy ktoś je jeszcze używa,
czy sekrety i certyfikaty aplikacji nie są przeterminowane, nie leżą w repozytoriach kodu i kto może dodać nowe.

Udostępnianie i goście

SharePoint i OneDrive pozwalają udostępnić plik linkiem „każdy, kto ma link”. Wygodne, ale taki link nie wygasa, nie wymaga logowania i trafia do historii przeglądarek, maili i komunikatorów. Sprawdzamy, czy takie linki są dozwolone, ile ich istnieje i co jest pod nimi.

Druga strona to goście, czyli konta zewnętrzne zaproszone do Teams albo SharePointa. Po zakończeniu współpracy rzadko ktoś je usuwa. Sprawdzamy, ile ich jest, do czego mają dostęp i czy mogą przeglądać listę pracowników i grup.

Poczta

Reguły przekierowania na zewnątrz. Klasyczny ślad po przejętym koncie: reguła, która cicho kopiuje faktury na obcy adres. Sprawdzamy, czy automatyczne przekierowanie poza firmę jest zablokowane i czy takie reguły już istnieją.
SPF, DKIM i DMARC. Bez nich ktoś obcy może wysyłać maile „od firmy” do klientów i kontrahentów.
Zasady ochrony przed phishingiem i złośliwymi załącznikami oraz to, czy pracownik ma jak łatwo zgłosić podejrzaną wiadomość.

Środowisko hybrydowe i urządzenia

Jeśli firma ma też lokalne Active Directory synchronizowane z chmurą, serwer synchronizacji (Entra Connect) jest jednym z najcenniejszych celów w sieci. Kto go przejmie, często przejmuje też chmurę. Sprawdzamy, jak jest chroniony i jakie konta są synchronizowane, w tym czy uprzywilejowane konta lokalne nie mają odpowiedników z uprawnieniami w Microsoft 365.

Przy urządzeniach patrzymy, czy dostęp do danych firmowych wymaga urządzenia zarządzanego przez firmę, czy da się pobrać całą skrzynkę i OneDrive na prywatny laptop.

Logi, czyli czy w ogóle zauważycie atak

Ostatni obszar nie dotyczy blokowania, tylko wykrywania. Czy dziennik audytu jest włączony, jak długo przechowywane są logi logowań, czy ktoś dostaje alert o nowym administratorze, logowaniu z nietypowego kraju albo nowej regule przekierowania. Po incydencie to od logów zależy, czy da się ustalić, co wyciekło. Przy krótkiej retencji odpowiedź bywa po prostu niemożliwa.

Licencje mają znaczenie

Część zabezpieczeń, np. dostęp warunkowy czy czasowe nadawanie ról, wymaga konkretnych planów Microsoft 365 lub Entra ID. W raporcie zaznaczamy, co da się poprawić w obecnych licencjach, a co wymaga zmiany planu, żeby rekomendacje nie kończyły się na „kupcie wszystko”.

Jak wygląda taki test

Łączymy dwie perspektywy:

Przegląd konfiguracji. Dostajemy konto z rolą tylko do odczytu (Global Reader) i przechodzimy przez ustawienia tenanta, zasady dostępu, role, aplikacje i udostępnianie. To pokazuje pełny obraz, także rzeczy niewidoczne dla napastnika.
Test z perspektywy przejętego konta. Dostajemy zwykłe konto pracownika bez uprawnień i sprawdzamy, co da się z nim zrobić: co widać, do czego można się dostać, czy istnieje ścieżka do uprawnień administratora. Opcjonalnie dochodzi część z zewnątrz, np. czy da się ustalić adresy pracowników i czy logowanie odpiera zgadywanie haseł.

Testy w chmurze Microsoft nie wymagają zgłaszania ich Microsoftowi, ale obowiązują jego zasady testowania: tylko własny tenant, bez ataków na dostępność usług. Wszystko inne ustalamy z Wami w zakresie przed startem, łącznie z tym, kogo uprzedzić, żeby nietypowe logowania nie wywołały alarmu w środku tygodnia.

Wynik to raport z listą znalezisk od najpoważniejszych, z konkretną ścieżką w panelu administracyjnym do każdej poprawki. Więcej o tym, czym taki test różni się od audytu, piszemy we wpisie pentest a audyt bezpieczeństwa.

A Secure Score?

Microsoft Secure Score i podobne narzędzia automatyczne są dobrym punktem startu i warto je przejrzeć przed testem. Oceniają jednak pojedyncze ustawienia, a nie to, jak się łączą. Nie powiedzą, że konto serwisowe wyłączone z MFA jest właścicielem aplikacji z dostępem do wszystkich skrzynek. Takie łańcuchy są tym, czego szuka napastnik, i tym, co pokazuje pentest.

Jak się przygotować

przygotujcie konto Global Reader i jedno zwykłe konto testowe z MFA,
zbierzcie listę wyjątków, o których wiecie (konta serwisowe, urządzenia wysyłające maile, integracje),
ustalcie, kto po Waszej stronie jest kontaktem w trakcie testu i kogo uprzedzić,
sprawdźcie, jakie licencje macie, bo od nich zależy część rekomendacji.

Ogólną listę kroków przed każdym testem opisujemy we wpisie jak przygotować firmę do pentestu. Pentest Microsoft 365 jest częścią naszych testów penetracyjnych i dobrze uzupełnia szkolenie pracowników, bo większość ataków na Microsoft 365 zaczyna się od maila. Dlaczego samo szkolenie nie wystarczy, opisujemy we wpisie o szkoleniu z phishingu.