Jak skutecznie monitorować bezpieczeństwo Microsoft 365? Detekcja zagrożeń za pomocą platformy Wazuh.

Chmurowe środowisko do współpracy Microsoft 365 stało się sercem operacji wielu firm, gromadząc kluczowe dokumenty, dane użytkowników i komunikację firmową. Jako że jest to rozwiązanie chmurowe, dostęp do niego może odbywać się z dowolnego miejsca na świecie i z wielu typów urządzeń. Ta wszechstronność oraz ogromna wartość dla organizacji czyni z niego atrakcyjny cel dla cyberprzestępców. Choć Microsoft oferuje wbudowane narzędzia i mechanizmy ochronne, to samo zabezpieczenie środowiska bez ciągłego nadzoru nie wystarczy do wykrywania i zapobiegania incydentom.

Aby uzyskać pełną widoczność i natychmiast reagować na anomalie, kluczowa jest korelacja zdarzeń z wielu usług wchodzących w skład pakietu Microsoft 365 w jednym miejscu. W tym artykule przyjrzymy się, jak wykorzystać open-source’ową platformę Wazuh do zbudowania skutecznego systemu detekcji zagrożeń i stałego monitorowania Microsoft 365.

Dlaczego monitoring Microsoft 365 jest kluczowy dla Twojej organizacji?

Tak jak wspomniałem wcześniej, Microsoft 365 jest obecnie sercem operacyjnym wielu firm, przechowującym kluczowe dane, których wyciek lub utrata mogłyby spowodować nieodwracalne szkody.

Do przykładowych zagrożeń czyhających na dane w M365 należą:

Phishing i próby przejęcia kont (Account Takeover),
Podpięcie kont firmowych do nieautoryzowanych aplikacji SaaS (Shadow IT),
Nadmiarowe uprawnienia nadawane użytkownikom lub aplikacjom,
Niekontrolowane udostępnianie plików poza organizację,
Zapraszanie gości do tenanta przez nieuprawnione osoby,
Szyfrowanie plików w usługach OneDrive / SharePoint (np. przez złośliwe oprogramowanie typu ransomware).

Sama platforma działa w modelu współdzielonej odpowiedzialności (Shared Responsibility Model). Oznacza to, że Microsoft dba o dostępność i utrzymanie samej infrastruktury, jednak to my jako klienci odpowiadamy za właściwą konfigurację dostępów oraz bezpośrednie bezpieczeństwo przechowywanych w chmurze danych.

Dodatkowo Microsoft 365 generuje ogromną liczbę logów. Jak to jednak często bywa w ekosystemie Microsoftu, są one rozproszone po wielu osobnych panelach administracyjnych, co znacząco utrudnia szybką korelację zdarzeń oraz sprawną analizę zagrożeń.

Dlaczego Wazuh SIEM/XDR?

Wazuh to darmowa platforma bezpieczeństwa open-source, pełniąca funkcje systemu SIEM (Security Information and Event Management) oraz XDR (Extended Detection and Response). Rozwiązanie to umożliwia gromadzenie zdarzeń bezpieczeństwa z całej infrastruktury w jednym miejscu, ich wzajemną korelację oraz analizę pod kątem wykrywania incydentów.

Platforma oferuje również opcję automatycznego reagowania na zdarzenia i blokowania zagrożeń. Jest niezwykle wszechstronna – można ją łatwo dostosować do potrzeb konkretnej organizacji, a nawet tworzyć własne integracje przy pomocy języków skryptowych, takich jak Bash czy Python. Istotną zaletą Wazuha jest także ogromna społeczność, która codziennie dzieli się nowymi integracjami oraz gotowymi scenariuszami użycia (use-cases).

Microsoft oferuje oczywiście natywne narzędzia do monitorowania bezpieczeństwa Microsoft 365 i reagowania na incydenty: są nimi Microsoft Defender oraz Microsoft Sentinel. Usługi takie jak Microsoft Defender for Identity (ochrona tożsamości w Microsoft Entra ID) czy Microsoft Defender for Office 365 (ochrona aplikacji pakietu M365) to świetne rozwiązania, które bez problemu mogą działać w tandemie z Wazuhem. W takim zestawieniu Microsoft Defender odpowiada za natywne wykrywanie, alertowanie i ewentualne blokowanie zagrożeń, a sama informacja o incydencie trafia bezpośrednio do Wazuha, który przekazuje powiadomienie do administratorów lub analityków SOC. To podejście sam z powodzeniem stosuję w wielu organizacjach, zapewnia ono skuteczne, automatyczne blokowanie ataków od razu po wdrożeniu i świetnie integruje się z centralnym SIEM-em. Warto jednak pamiętać, że usługi z rodziny Microsoft Defender są dodatkowo płatne.

Z kolei Microsoft Sentinel to chmurowy system SIEM będący odpowiednikiem Wazuha w ekosystemie Microsoftu. Główną barierą bywają tu jednak koszty, w Sentinelu płaci się nie tylko za przechowywanie danych, ale przede wszystkim za sam proces ich zbierania i analizy (data ingestion). W dużych środowiskach koszty korzystania z tej platformy potrafią sięgać kilkuset tysięcy złotych miesięcznie, a nawet dla mniejszych firm bywa to wydatek nieproporcjonalnie wysoki. Dodatkowo Sentinel nie jest tak elastyczny jak Wazuh, choć posiada gotowe konektory do zewnętrznych rozwiązań, to wciąganie i parsowanie logów spoza ekosystemu Microsoftu bywa znacznie bardziej skomplikowane i generuje zauważalne, dodatkowe koszty.

Konfiguracja integracji

Microsoft Entra ID

Zanim przejdziemy do samej konfiguracji integracji, warto podsumować, co dokładnie Wazuh pozwala nam monitorować w środowisku Microsoft 365:

Aktywność użytkowników w SharePoint Online i OneDrive (operacje na plikach i folderach, udostępnianie zasobów),
Aktywność użytkowników w Exchange Online (działania na skrzynkach pocztowych),
Działania administracyjne w SharePoint Online,
Działania administracyjne w Microsoft Entra ID (zarządzanie tożsamościami, grupami i uprawnieniami),
Działania administracyjne w Exchange Online,
Operacje eDiscovery w Centrum Bezpieczeństwa i Zgodności (Microsoft Purview),
Aktywność użytkowników i administratorów w usługach dodatkowych pakietu M365 (m.in. Microsoft Teams, Power Apps, Power Automate),
Zdarzenia związane z etykietami poufności danych (Sensitivity Labels) w ekosystemie Microsoft Purview.

Sama integracja opiera się na Office 365 Management API (Office 365 to poprzednia nazwa usługi Microsoft 365, Microsoft często nie potrafi się zdecydować jak nazwać swoje produkty, przez co dla jednej usługi potrafi funkcjonować kilka różnych nazw). Wazuh łączy się z tym API i przy użyciu odpowiednich uprawnień (tylko do odczytu) pobiera logi audytowe do dalszej analizy.

Warto również pamiętać o zasadzie najmniejszych uprawnień (Least Privilege Principle) podczas konfiguracji dostępu do API. Nasza aplikacja (w tym przypadku Wazuh) powinna otrzymać wyłącznie te uprawnienia, które są niezbędne do realizacji powierzonego zadania (czyli w tym wypadku wyłącznie dostęp do odczytu konkretnych logów). Samo API musi oczywiście wymagać odpowiedniego uwierzytelniania, a nie być otwarte na dowolne żądania z sieci (u nas do tego celu posłuży wygenerowany sekret aplikacji).

Aby skonfigurować integrację, będziecie potrzebować uprawnień na poziomie Application Administrator w dzierżawie (tenancie) Microsoft Entra ID, która odpowiada za tożsamość w Waszym środowisku Microsoft 365. Rola ta jest niezbędna do zarejestrowania aplikacji dla systemu Wazuh oraz nadania jej odpowiednich uprawnień do wyżej wymienionego API.

Jeżeli macie już odpowiednie uprawnienia, możemy przejść do konfiguracji. Logujemy się do panelu administracyjnego Microsoft Entra ID, przechodzimy do zakładki Entra ID -> App registrations i klikamy + New registration.

Wpisujemy nazwę dla naszej aplikacji – w moim przypadku będzie to wazuh-test. Pozostałe ustawienia pozostawiamy domyślne i klikamy Register.

Przechodzimy do zakładki Overview i zapisujemy w notatniku wartości Application (client) ID oraz Directory (tenant) ID, będą nam potrzebne na dalszym etapie, podczas konfiguracji integracji po stronie Wazuha (na moim zrzucie ekranu zostały one zamazane, pamiętajcie, aby nigdzie publicznie nie udostępniać tych identyfikatorów!).

Nadajemy mu odpowiednią nazwę i ustalamy czas ważności. Warto w tym miejscu zastosować obowiązującą w Waszej organizacji politykę rotacji sekretów i uwzględnić w niej również ten klucz. Wiem, że kusi ustawienie 730 dni i zapomnienie o temacie, ale jest to jawne ryzyko bezpieczeństwa. W razie wycieku, osoba postronna mogłaby przez tak długi czas bez przeszkód pobierać pełne logi audytowe z Waszego środowiska Microsoft 365.

Kiedy już utworzycie sekret, skopiujcie jego wartość (Value) i zapiszcie w notatniku, przyda się podczas dalszej konfiguracji po stronie Wazuha. Pamiętajcie, że wartość ta jest widoczna tylko raz: po odświeżeniu lub opuszczeniu strony zostanie zamaskowana i w razie braku kopii konieczne będzie wygenerowanie nowego sekretu.

Gdy aplikacja dla Wazuha jest już zarejestrowana w Entra ID, musimy nadać jej odpowiednie uprawnienia do odczytywania logów z Office 365 Management API. W tym celu przechodzimy do zakładki API permissions i klikamy + Add a permission. Z listy dostępnych interfejsów wybieramy wcześniej wspomniane Office 365 Management APIs.

Jako typ uprawnień wybieramy Application permissions.

Czym różnią się te dwa warianty?

Application permissions – pozwalają aplikacji działać w tle w sposób samodzielny i korzystać z nadanych uprawnień bez udziału człowieka.
Delegated permissions – wymagają interakcji i zalogowania konkretnego użytkownika; aplikacja działa wtedy w jego imieniu i ma dostęp tylko do tego, do czego uprawniony jest ten użytkownik.

Ponieważ do Wazuha żaden użytkownik bezpośrednio się nie loguje, a sam system działa autonomicznie i cyklicznie pobiera logi z API, musimy wybrać właśnie Application permissions.

Następnie wybieramy dwa uprawnienia API:

ActivityFeed.Read – umożliwia pobieranie zdarzeń związanych z aktywnością użytkowników oraz administratorów w środowisku Microsoft 365.
ActivityFeed.ReadDlp – umożliwia pobieranie zdarzeń powiązanych z politykami ochrony przed wyciekiem danych (DLP) zdefiniowanymi w Microsoft Purview.

Po zaznaczeniu obu uprawnień klikamy Add permissions.

Jako że nadaliśmy szerokie uprawnienia typu Application permissions (gdzie zgodnie z dobrymi praktykami bezpieczeństwa Microsoft Entra ID dąży się do stosowania uprawnień delegowanych tam, gdzie to możliwe), wymagana będzie zgoda administratora globalnego dzierżawy.

Jeśli posiadacie rolę Global Administrator, możecie zatwierdzić je samodzielnie, klikając Grant admin consent for [Nazwa Waszej Organizacji]. W przeciwnym razie musicie zwrócić się do administratora swojego środowiska z prośbą o akceptację. Po udzieleniu zgody żółty trójkąt ostrzegawczy przy uprawnieniach zmieni się w zieloną ikonę statusu, oznacza to, że uprawnienia są aktywne i gotowe do użycia.

Po stronie Microsoft Entra ID cała konfiguracja jest gotowa, możemy teraz przejść do ustawień po stronie serwera Wazuh.

Serwer Wazuh

Logujemy się przez SSH do serwera Wazuh i otwieramy do edycji plik /var/ossec/etc/ossec.conf. Alternatywnie konfigurację możemy zmodyfikować z poziomu panelu webowego, przechodząc do zakładki Server management -> Settings -> Edit configuration.

Wewnątrz głównego bloku konfiguracyjnego <ossec_config> tworzymy nową sekcję <office365> i wklejamy do niej poniższą treść:

<ossec_config>
  <office365>
    <enabled>yes</enabled>
    <interval>1m</interval>
    <curl_max_size>1M</curl_max_size>
    <only_future_events>yes</only_future_events>
    <api_auth>
      <tenant_id><YOUR_TENANT_ID></tenant_id>
      <client_id><YOUR_CLIENT_ID></client_id>
      <client_secret><YOUR_CLIENT_SECRET></client_secret>
      <api_type>commercial</api_type>
    </api_auth>
    <subscriptions>
      <subscription>Audit.AzureActiveDirectory</subscription>
    </subscriptions>
  </office365>
</ossec_config>

W polach <tenant_id>, <client_id> oraz <client_secret> wklejamy wartości, które zapisaliśmy wcześniej podczas rejestracji aplikacji w Entra ID.

Częstotliwość pobierania logów z M365 definiujemy w polu <interval>, w naszym przykładzie operacja ta będzie wykonywana co minutę. Z kolei parametr <curl_max_size> pozwala określić maksymalną wielkość paczki danych, jaką Wazuh może pobrać w jednym zapytaniu (przydatne np. w sytuacji, gdy ruch przechodzi przez reverse proxy z ograniczeniem rozmiaru żądań). Warto również włączyć opcję <only_future_events>, dzięki której system zacznie gromadzić logi dopiero od momentu uruchomienia integracji, bez wstecznego pobierania archiwum. Pole <api_type> pozostawiamy ustawione jako commercial, wyjątkiem są specjalne dedykowane chmury (np. Azure Government dla amerykańskiego sektora rządowego), z których raczej nie będziecie korzystać.

Powyższa konfiguracja pobiera zdarzenia wyłącznie z logów audytowych Microsoft Entra ID. Do wyboru macie jednak następujące strumienie danych (dzienniki), do których możecie się zasubskrybować, aby rejestrować wybrane typy aktywności:

Audit.AzureActiveDirectory – zdarzenia związane z zarządzaniem użytkownikami i tożsamościami.
Audit.Exchange – logi usługi pocztowej Exchange.
Audit.SharePoint – zdarzenia związane z plikami przechowywanymi w SharePoint oraz OneDrive.
Audit.General – ogólne logi z pozostałych usług i aplikacji pakietu Microsoft 365.
DLP.All – zdarzenia powiązane z modułem ochrony przed wyciekiem danych (Data Loss Prevention) z Microsoft Purview.

Możecie pobierać dane tylko z wybranych dzienników lub ze wszystkich naraz. Konfiguruje się to poprzez dodanie odpowiednich znaczników <subscription> wewnątrz sekcji <subscriptions>, na przykład w następujący sposób:

<ossec_config>
  <office365>
    <enabled>yes</enabled>
    <interval>1m</interval>
    <curl_max_size>1M</curl_max_size>
    <only_future_events>yes</only_future_events>
    <api_auth>
      <tenant_id><YOUR_TENANT_ID></tenant_id>
      <client_id><YOUR_CLIENT_ID></client_id>
      <client_secret><YOUR_CLIENT_SECRET></client_secret>
      <api_type>commercial</api_type>
    </api_auth>
    <subscriptions>
      <subscription>Audit.AzureActiveDirectory</subscription>
      <subscription>Audit.Exchange</subscription>
      <subscription>Audit.SharePoint</subscription>
      <subscription>Audit.General</subscription>
      <subscription>DLP.All</subscription>
    </subscriptions>
  </office365>
</ossec_config>

Jeżeli Wasza firma posiada kilka dzierżaw (tenantów) Microsoft 365, możecie bez problemu wpiąć je wszystkie jednocześnie do systemu Wazuh i korelować z nich zdarzenia w ramach jednego panelu wizualizacji / systemu SIEM. Sam konfigurowałem integrację, w której podpinane były cztery różne tenanty M365, na których rozproszeni byli użytkownicy z jednej organizacji. Wynikać to może z wielu powodów, np. z fuzji spółek, trwających migracji czy po prostu specyficznego podziału organizacyjnego w firmie.

Aby podłączyć kilka tenantów do Wazuha, należy użyć poniższej konfiguracji (pamiętając, że każdy tenant musi posiadać własną rejestrację aplikacji dla Wazuha w swojej usłudze Entra ID):

<ossec_config>
  <office365>
    <enabled>yes</enabled>
    <interval>1m</interval>
    <curl_max_size>1M</curl_max_size>
    <only_future_events>yes</only_future_events>
    <api_auth>
      <tenant_id><YOUR_TENANT_ID_1></tenant_id>
      <client_id><YOUR_CLIENT_ID_1></client_id>
      <client_secret><YOUR_CLIENT_SECRET_1></client_secret>
      <api_type>commercial</api_type>
    </api_auth>
    <api_auth>
      <tenant_id><YOUR_TENANT_ID_2></tenant_id>
      <client_id><YOUR_CLIENT_ID_2></client_id>
      <client_secret><YOUR_CLIENT_SECRET_2></client_secret>
      <api_type>commercial</api_type>
    </api_auth>
    <subscriptions>
      <subscription>Audit.AzureActiveDirectory</subscription>
      <subscription>Audit.General</subscription>
    </subscriptions>
  </office365>
</ossec_config>

Warto również pamiętać, że choć możemy podpiąć kilka osobnych tenantów Microsoft 365, to w ramach jednej integracji wszystkie będą pobierały logi z tych samych, wspólnie zdefiniowanych dzienników.

Po zapisaniu konfiguracji musimy zrestartować usługę wazuh-manager. Możemy to zrobić w terminalu za pomocą polecenia:

sudo systemctl restart wazuh-manager

Alternatywnie (jeśli edytowaliśmy plik w panelu webowym) wystarczy kliknąć przycisk Restart Manager.

Gdy usługa uruchomi się ponownie, Wazuh zacznie odpytywać Office 365 Management API i automatycznie pobierać logi do analizy.

Praktyczne zastosowanie modułu monitoringu Microsoft 365 w SOC

Gdy logi audytowe z Microsoft 365 spływają już na serwer Wazuh, możemy przejść do codziennej analizy danych i detekcji zagrożeń. Wszystkie zaprezentowane poniżej zrzuty ekranu pochodzą z produkcyjnie działającego systemu SIEM, a nie z odizolowanego środowiska testowego. Aby jak najlepiej zaprezentować pracę na rzeczywistych danych, wykorzystałem instancję podpiętą do dużego tenanta M365 (z tego względu wszelkie wrażliwe informacje zostały odpowiednio zanonimizowane).

W tej części przedstawię codzienną analizę zdarzeń z M365 na przykładzie potencjalnych scenariuszy ataków oraz własnych reguł detekcji, zbudowanych na bazie natywnych reguł i dekoderów platformy Wazuh.

Ważne: Wszystkie przedstawione poniżej reguły możesz przetestować w własnym środowisku. Wystarczy dodać je na serwerze Wazuh do pliku /var/ossec/etc/rules/local_rules.xml (lub utworzyć osobny plik .xml w tym katalogu). Alternatywnie możesz wkleić je z poziomu panelu webowego Wazuha, przechodząc do: Server management -> Rules -> Manage rule files.

O czym warto pamiętać:

Przeładowanie usługi: Po dodaniu lub edycji reguł należy przeładować usługę Wazuh Managera (systemctl restart wazuh-manager lub przyciskiem Restart manager w interfejsie Web), aby zmiany weszły w życie.
Unikalne ID: Upewnij się, że identyfikatory reguł (id="...") są unikalne i nie kolidują z istniejącymi regułami w Twoim systemie (zakres 100000–119999 jest zarezerwowany na własne reguły użytkownika).

Wykrywanie złośliwych reguł przekierowania poczty (eksfiltracja danych)

Po udanym przejęciu konta (np. w wyniku phishingu) napastnicy bardzo często tworzą nowe reguły w skrzynce pocztowej. Ich celem jest automatyczne przekazywanie wybranych wiadomości (np. zawierających frazy „faktura”, „przelew” czy „dane finansowe”) na zewnętrzny adres e-mail w celu eksfiltracji danych. Innym popularnym zabiegiem jest natychmiastowe przenoszenie maili do kosza, co pozwala zmylić ofiarę i opóźnić wykrycie incydentu w infrastrukturze.

Log źródłowy z Office 365 Management API, generowany w momencie utworzenia nowej reguły pocztowej, wygląda następująco:

{"integration": "office365", "office365": {"Operation": "New-InboxRule", "Workload": "Exchange", "UserId": "victim.user@organization.com", "ClientIP": "198.51.100.45", "Parameters": [{"Name": "Name", "Value": "AutoForwardToExternal"}, {"Name": "ForwardTo", "Value": "attacker@external-domain.com"}]}}

Reguła, która przechwyci tę operację i wyzwoli alert o poziomie 12 (wysoki priorytet), wygląda następująco:

<group name="office365,exchange,bec,">
  <!-- Parent rule 91531: Office 365 operational event -->
  <rule id="108311" level="12">
    <if_sid>91531</if_sid>
    <field name="office365.Workload">^Exchange$</field>
    <field name="office365.Operation">^New-InboxRule$|^Set-InboxRule$</field>
    <field name="office365.Parameters">ForwardTo|RedirectTo</field>
    <description>M365 Exchange: External email forwarding inbox rule created (Possible BEC)</description>
    <mitre>
      <id>T1114.003</id>
    </mitre>
  </rule>
</group>

Tak wygląda wystąpienie alertu w panelu Wazuh:

Procedura triażu SOC dla tego zdarzenia:

Weryfikacja tożsamości: Sprawdź w parametrze office365.UserId czy użytkownik logował się ostatnio z nietypowych lokalizacji lub doszło do anomalii geograficznej (impossible travel, np. udane logowania z dwóch odległych miejsc w ciągu kilku minut)?
Analiza parametrów reguły: Przejrzyj sekcję Parameters w surowym logu i zweryfikuj wartości w polu ForwardTo.
Mitygacja zagrożenia: Jeśli domena, na którą przekierowywane są wiadomości, nie należy do Twojej organizacji, natychmiast zresetuj hasło użytkownika, unieważnij wszystkie aktywne sesje w Entra ID oraz usuń złośliwą regułę (możesz to zrobić z poziomu PowerShell za pomocą modułu ExchangeOnlineManagement).

Wykrywanie nadania uprawnień Administratora Globalnego w Entra ID (eskalacja uprawnień)

Microsoft Entra ID to dla atakującego „święty Graal”, przejęcie tej usługi daje mu pełną kontrolę nad całym środowiskiem chmurowym Microsoft 365 oraz Microsoft Azure.

Po przejęciu konta o wysokich uprawnieniach napastnicy często tworzą tzw. tylne furtki (backdoors), aby zapewnić sobie trwały i niezauważalny dostęp do infrastruktury ofiary. Bardzo często maskują je jako konta techniczne z przypisaną na stałe rolą Global Administrator, która pozwala na zarządzanie wszystkimi ustawieniami w Entra ID.

Log źródłowy z Azure Active Directory Audit Log, generowany w momencie przypisania roli Globalnego Admina do konta, wygląda następująco:

{"integration": "office365", "office365": {"Operation": "Add member to role", "Workload": "AzureActiveDirectory", "UserId": "admin.user@organization.com", "Target": [{"ID": "backdoor.account@organization.com", "Type": 1}], "ModifiedProperties": [{"Name": "Role.DisplayName", "NewValue": "Global Administrator"}]}}

Reguła wyzwalająca alert o poziomie 15 (krytyczny) w momencie wystąpienia takiego zdarzenia wygląda następująco:

<group name="office365,entra_id,privilege_escalation,">
  <!-- Parent rule 91531: Office 365 operational event -->
  <rule id="108312" level="15">
    <if_sid>91531</if_sid>
    <field name="office365.Workload">^AzureActiveDirectory$</field>
    <field name="office365.Operation">^Add member to role$</field>
    <field name="office365.ModifiedProperties">Global Administrator</field>
    <description>M365 Entra ID: Global Administrator role assigned to user</description>
    <mitre>
      <id>T1078.004</id>
      <id>T1098</id>
    </mitre>
  </rule>
</group>

Tak wygląda wystąpienie alertu w panelu Wazuh:

Procedura triażu SOC dla tego zdarzenia:

Weryfikacja zgłoszenia: Sprawdź w systemie zgłoszeniowym wykorzystywanym przez Twoje IT (np. Jira, ServiceNow), czy dla wskazanego konta zarejestrowano zatwierdzone żądanie nadania uprawnień administracyjnych (Change Request).
Korelacja z administratorem: Jeśli brakuje zatwierdzonego zgłoszenia, skontaktuj się z administratorem widniejącym w polu office365.UserId (osobą, która nadała rolę), aby natychmiast potwierdzić celowość wykonania tej operacji.
Mitygacja i czyszczenie (Incidence Response): W przypadku potwierdzenia incydentu:
- Zresetuj hasło i unieważnij wszystkie aktywne sesje przejętego konta administratora.
- Usuń konto techniczne utworzone jako tylna furtka (backdoor).
- Przejrzyj pozostałe logi w usłudze Entra ID, aby upewnić się, że atakujący nie wykonał w międzyczasie innych złośliwych operacji.

Wykrywanie masowego pobierania plików z SharePoint / OneDrive (eksfiltracja danych)

Pobranie pojedynczego pliku z platformy SharePoint lub OneDrive to standardowa operacja biznesowa. Problem pojawia się w momencie, gdy z jednego konta użytkownika następuje masowe, gwałtowne pobieranie dokumentów w krótkim przedziale czasu, co jest klasycznym objawem wycieku danych (Data Exfiltration) spowodowanego przejęciem tożsamości lub działaniem nielojalnego pracownika (Insider Threat).

Log źródłowy z Office 365 Management API, generowany przy pojedynczym pobraniu pliku, wygląda następująco:

{"integration": "office365", "office365": {"Operation": "FileDownloaded", "Workload": "SharePoint", "UserId": "employee@organization.com", "ClientIP": "203.0.113.10", "SourceFileName": "Confidential_Financial_Report.pdf", "SourceRelativeUrl": "Documents/Finance"}}

Reguła wyzwalająca alert o poziomie 15 (krytyczny) w momencie gdy ten sam użytkownik pobierze więcej niż 30 plików w ciągu 120 sekund będzie wyglądać następująco:

<group name="office365,sharepoint,data_exfiltration">

  <!-- Overriding rule 91531 to level 1 so events are ingested into the stateful memory accumulator -->
  <rule id="91531" level="1" overwrite="yes">
    <if_sid>91500</if_sid>
    <field name="office365.Workload">^SharePoint$</field>
    <description>Office 365: SharePoint operational event</description>
  </rule>
  
  <!-- Frequency detection for SharePoint mass file downloads -->
  <rule id="108314" level="15" frequency="30" timeframe="120">
    <if_matched_sid>91531</if_matched_sid>
    <field name="office365.Workload">^SharePoint$</field>
    <field name="office365.Operation">^FileDownloaded$|^FileAccessed$</field>
    <same_field>office365.UserId</same_field>
    <description>M365 SharePoint/OneDrive: Mass file download detected (Possible Data Exfiltration)</description>
    <mitre>
      <id>T1567.002</id>
    </mitre>
  </rule>
</group>

Dlaczego musimy nadpisać regułę 91531 i podnieść ją do poziomu 1?

Architektura Wazuha optymalizuje zużycie pamięci RAM poprzez odrzucanie zdarzeń o poziomie 0 – zdarzenia z level="0" nie trafiają do bufora pamięci stanowej (state accumulator). W efekcie reguła częstotliwościowa używająca <if_matched_sid> nie jest w stanie zliczać powtórzeń, ponieważ silnik „nie pamięta” poprzednich wystąpień logu.

Dodając parametr overwrite="yes" oraz podnosząc poziom bazowej reguły do level="1", wymuszamy zapisywanie zdarzeń w pamięci podręcznej managera. W ten sposób reguła 100314 śledzi atrybut <same_field>office365.UserId</same_field> i przy 31. pobraniu pliku w ciągu 120 sekund wygeneruje alert o poziomie 15.

Warto pamiętać, że w większych środowiskach Microsoft 365, gdzie generowane są tysiące logów na godzinę, może to zwiększyć zużycie pamięci RAM przez proces wazuh-analysisd.

Tak wygląda wystąpienie alertu w panelu Wazuh:

Procedura triażu SOC dla tego zdarzenia:

Weryfikacja kontekstu i tożsamości: Sprawdź tożsamość użytkownika (UserId), jego adres IP (ClientIP) oraz listę pobranych plików. Wyklucz konta serwisowe i planowane akcje (np. migracje danych lub skanowanie DLP).
Korelacja zdarzeń w Entra ID: Przejrzyj logowania użytkownika z ostatnich 24 godzin pod kątem logowań z nieznanych lokalizacji (Impossible Travel), nowych urządzeń lub nietypowych żądań czy rejestracji MFA.
Mitygacja (w przypadku potwierdzenia incydentu): Natychmiast unieważnij aktywne sesje w Entra ID (Revoke Sessions), zablokuj konto, odizoluj stację roboczą i sprawdź ile danych udało się atakującemu wyprowadzić na zewnątrz.

Przyznawanie uprawnień zewnętrznym aplikacjom SaaS (Consent Phishing)

Consent Phishing to obecnie jedna z najpopularniejszych i najbardziej podstępnych metod ataku wymierzonych w środowiska Microsoft 365. W tym scenariuszu atakujący nie musi znać hasła użytkownika ani przechwytywać sesji MFA, wystarczy, że skłoni go do kliknięcia w odnośnik i udzielenia zgody (consent) dla złośliwej, zewnętrznej aplikacji OAuth (np. wymagającej uprawnień do odczytu skrzynek pocztowych lub plików). Aplikacje te często podszywają się pod legalne narzędzia biznesowe, takie jak organizery spotkań, wtyczki PDF czy asystenci AI.

Choć możliwość samodzielnego wyrażania zgody przez użytkowników można zablokować z poziomu ustawień Entra ID (lub wymusić weryfikację przez administratora – Admin Consent Workflow), w praktyce wiele organizacji pozostawia tę opcję otwartą. Brak kontroli w tym obszarze daje użytkownikom wolną rękę, co bezpośrednio prowadzi do krytycznych incydentów bezpieczeństwa.

Gdy użytkownik wyrazi zgodę na dostęp aplikacji chmurowej do swoich zasobów, w usłudze Entra ID generowane jest następujące zdarzenie w formacie JSON:

{"integration": "office365", "office365": {"Operation": "Consent to application", "Workload": "AzureActiveDirectory", "UserId": "phished.user@organization.com", "Target": [{"ID": "Malicious OAuth App", "Type": 1}], "ModifiedProperties": [{"Name": "ConsentAction.Permissions", "NewValue": "[Mail.ReadWrite, Files.ReadWrite.All, Offline_access]"}]}}

Reguła, która przechwyci tę operację i wyzwoli alert o poziomie 12 (wysoki priorytet), wygląda następująco:

<group name="office365,consent_phishing">
  <rule id="108316" level="12">
    <if_sid>91531</if_sid>
    <field name="office365.Workload">^AzureActiveDirectory$</field>
    <field name="office365.Operation">^Consent to application$</field>
    <field name="office365.ModifiedProperties">Mail\.Read|Mail\.Send|Files\.Read|Directory\.ReadWrite</field>
    <description>M365 Entra ID: High-risk OAuth application consent granted (Possible Consent Phishing)</description>
    <mitre>
      <id>T1528</id>
    </mitre>
    </rule>
</group>

Tak wygląda wystąpienie alertu w panelu Wazuh:

Procedura triażu SOC dla tego zdarzenia:

Weryfikacja nazwy aplikacji i uprawnień: Sprawdź w zdarzeniu nazwę nadanej aplikacji oraz zakres przyznanych uprawnień (ModifiedProperties). Szukaj niebezpiecznych zakresów, takich jak Mail.Read, Mail.Send czy Files.ReadWrite.
Korelacja reputacji dostawcy: Przeanalizuj tożsamość aplikacji w konsoli Entra ID, sprawdź czy aplikacja posiada weryfikację wydawcy (Publisher Verification), czy może została utworzona niedawno na anonimowej domenie.
Mitygacja i unieważnienie dostępów: W przypadku potwierdzenia złośliwej aplikacji, natychmiast usuń udzieloną zgodę w panelu Entra ID -> Enterprise Applications, unieważnij tokeny dostępowe użytkownika (Revoke Sessions) oraz zablokuj identyfikator aplikacji (App ID) dla całej organizacji.

Wbudowane reguły detekcji

Tak jak wspomniałem wcześniej, Wazuh dostarcza wbudowany pakiet ponad 190 natywnych reguł przeznaczonych do analizy i klasyfikacji logów z Microsoft 365. Stanowią one cyfrowy fundament, który w codziennej pracy zespołu SOC wykorzystywany jest do:

Budowania złożonych detekcji behawioralnych: Podstawowe operacje na obiektach (takie jak FileDownloaded, FileAccessed, UserLoggedIn czy MailboxLogin) służą (jak pokazałem w powyższych scenariuszach) jako zdarzenia bazowe do budowania zaawansowanych reguł wykrywania anomalii w zachowaniu użytkowników M365.
Korelacji zdarzeń wzdłuż łańcucha ataku (Cyber Kill Chain): Dzięki regułom niższego poziomu analityk ma wgląd w chronologiczny ciąg zdarzeń poprzedzających wystąpienie krytycznego alertu, co pozwala dokładnie odtworzyć pełną ścieżkę działań intruza.
Audytu i zbierania materiału dowodowego (Digital Forensics): W przypadku wykrycia incydentu lub kompromitacji konta po czasie, zespół Incident Response / SOC może w kilka sekund przeszukać indeksy pod kątem pełnej historii aktywności danego UserId, adresów IP oraz modyfikowanych zasobów.
Monitorowania zmian konfiguracji (Compliance & Governance): Natywne detekcje rejestrują bieżące operacje administracyjne w Entra ID oraz Exchange Online, pozwalając na stałą weryfikację zgodności z wewnętrznymi politykami bezpieczeństwa i procedurami Change Managementu.

Wbudowany dashboard Microsoft 365

Wazuh dostarcza też dedykowany panel wizualizacyjny przeznaczony do analizy zdarzeń z Microsoft 365. Jest to idealne narzędzie dla analityków i administratorów szukających zagregowanego podsumowania aktywności w chmurze, przeglądanie czytelnych wykresów oraz zestawień statystycznych jest znacznie szybsze i efektywniejsze niż ręczna analiza surowych logów w formacie JSON.

Panel ten jest dostępny bezpośrednio w menu głównym interfejsu Wazuh (zakładka Office 365). Stanowi doskonały punkt startowy do codziennego monitoringu bezpieczeństwa:

Szybki triaż (Drill-down): Kliknięcie w dowolny element wykresu automatycznie filtruje pod spodem zdarzenia, umożliwiając natychmiastowe przejście od zagregowanego widoku do szczegółowej analizy incydentu.
Wizualizacja trendów i wolumenu logów: Pozwala wyłapać wzrokiem nagłe skoki aktywności (np. gwałtowny wzrost operacji pobierania plików lub błędy logowań).
Geolokalizacja i analiza adresów IP: Umożliwia identyfikację logowań i akcji z niestandardowych rejonów geograficznych lub adresów IP o wątpliwej reputacji.

Przydatne linki:

Wazuh SIEM/XDR – oficjalna strona produktu, tutaj znajdziesz specyfikację i pełną dokumentację systemu.
Program Ambasadorów Wazuh – dołącz do społeczności open-source i pomóż nam rozwijać system Wazuh.