Threat hunting w logach M365: 12 zapytań, które warto mieć gotowe (konto, poczta, SharePoint)

1. Wprowadzenie: czym jest threat hunting w Microsoft 365 i kiedy ma sens

Threat hunting w Microsoft 365 to proaktywne, hipotezowe poszukiwanie śladów kompromitacji w danych telemetrycznych z usług chmurowych: tożsamości (logowania i tokeny), poczty, plików oraz działań administracyjnych. W odróżnieniu od reakcji na alerty, hunting zaczyna się od pytania „co mogło się wydarzyć?” i sprawdzenia, czy w logach widać wzorce typowe dla nadużyć (np. nietypowe logowania, nagłe zmiany reguł poczty, masowe operacje na plikach czy działania uprzywilejowane).

W praktyce w M365 chodzi o wyłapywanie zdarzeń, które:

• nie generują alertów lub generują je z opóźnieniem,
• są zbyt „ciche”, by trafić w proste reguły detekcji (low-and-slow),
• na pierwszy rzut oka wyglądają jak legalna aktywność użytkownika lub administratora,
• wymagają korelacji między obszarami (konto ↔ poczta ↔ SharePoint/OneDrive), aby nabrały znaczenia.

Różnica między threat hunting a monitoringiem/alertingiem polega głównie na intencji i sposobie pracy:

• Monitoring i alerty próbują automatycznie wykrywać znane scenariusze na podstawie reguł, sygnatur i anomalii oraz szybko eskalować.
• Hunting jest sterowany hipotezą i kontekstem biznesowym, a wynikiem bywa zarówno znalezienie incydentu, jak i identyfikacja „dziur” w telemetryce, braków w audycie lub potrzeby nowych detekcji.

W środowisku Microsoft 365 hunting ma szczególną wartość, bo wiele ataków koncentruje się na tożsamości (phishing, token theft, MFA fatigue), a następnie na nadużyciu dostępu do poczty i danych w SharePoint/OneDrive. Z perspektywy obrońcy istotne jest więc nie tylko „czy ktoś się zalogował”, ale też „co zrobił potem” i „czy jego działania pasują do normalnego profilu”.

Kiedy threat hunting ma sens (i przynosi realny zwrot):

• Po sygnale o ryzyku: podejrzenie phishingu, nietypowe logowanie, zgłoszenie użytkownika, incydent na urządzeniu końcowym, informacje z threat intelligence.
• Po zmianach w środowisku: wdrożenie SSO, zmiany w MFA/Conditional Access, migracje skrzynek, integracje z aplikacjami SaaS, automatyzacje i konta serwisowe.
• W cyklu regularnym: okresowe przeglądy aktywności uprzywilejowanej, polowań na „ciche” nadużycia (np. podtrzymywanie dostępu), kontrola ekspozycji danych.
• Gdy organizacja ma priorytety ochrony danych: wrażliwe skrzynki, kierownictwo, działy finansowe/HR, zasoby SharePoint z danymi krytycznymi.

Kiedy hunting jest mniej efektywny: gdy brakuje spójnie włączonego audytu i retencji logów, gdy nie ma bazowej wiedzy o normalnych zachowaniach (baseline), lub gdy zespół nie ma czasu na analizę i wyciąganie wniosków (np. tworzenie nowych detekcji, zamykanie luk w konfiguracji). W takich przypadkach polowanie szybko zamienia się w przegląd przypadkowych zdarzeń bez możliwości rozstrzygnięcia, co jest realnym zagrożeniem.

Najważniejszą cechą dobrego threat hunt w M365 jest konkretna hipoteza oraz zestaw powtarzalnych zapytań, które można uruchomić na żądanie: podczas triage, po zgłoszeniu, po wykryciu anomalii lub w ramach cyklicznego przeglądu. Dzięki temu hunting staje się procesem, a nie jednorazową akcją.

2. Wymagane źródła logów i minimalna konfiguracja audytu

Skuteczny threat hunting w Microsoft 365 zaczyna się nie od zapytań, ale od kompletności i jakości telemetrii. Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity: jak upewnić się, że w ogóle masz dane, na których da się sensownie polować. W praktyce potrzebujesz kilku uzupełniających się strumieni zdarzeń: tożsamość i logowania (Entra ID), działania użytkowników i administratorów w usługach M365 (Unified Audit Log), zdarzenia typowo „pocztowe” (Exchange), aktywność na plikach i witrynach (SharePoint/OneDrive) oraz sygnały bezpieczeństwa z narzędzi ochronnych (Defender). Każde z tych źródeł odpowiada na inne pytania i ma inne ograniczenia, dlatego minimalna konfiguracja powinna zapewniać spójność identyfikatorów, retencję oraz możliwość korelacji w czasie.

Entra ID (tożsamość, logowania i ryzyko)

Logi z Entra ID są podstawą polowania na nadużycia kont: pokazują kto próbował się uwierzytelnić, skąd, jaką metodą oraz czy wystąpiły sygnały ryzyka. Najczęściej wykorzystywane są dwa typy danych: zdarzenia logowania oraz audyt zmian w konfiguracji i obiektach katalogowych.

• Włącz i utrzymuj logi logowań (interaktywne i nieinteraktywne), aby nie tracić aktywności związanej z tokenami, aplikacjami i dostępem w tle.
• Włącz logi audytowe katalogu, żeby widzieć zmiany w użytkownikach, grupach, rolach, aplikacjach, poświadczeniach i zasadach.
• Zadbaj o kontekst: informacje o urządzeniu, kliencie, stanie MFA/CA, IP, lokalizacji oraz identyfikatorach korelacyjnych. Bez tego wykrywanie anomalii (np. „niemożliwa podróż”, nietypowy klient, nadużycia sesji) będzie dużo mniej wiarygodne.
• Retencja i eksport: domyślne okno przechowywania bywa niewystarczające do polowań „wstecz”. Minimalnie zaplanuj centralizację do systemu analitycznego (np. Log Analytics/Sentinel lub SIEM) i ustaw retencję zgodną z procedurami reagowania.

Unified Audit Log (Ujednolicony dziennik audytu M365)

Unified Audit Log (UAL) spina aktywności z wielu usług Microsoft 365 w jeden strumień zdarzeń. Jest kluczowy, gdy chcesz odpowiadać na pytania typu: co użytkownik zrobił w usługach (plik, wiadomość, ustawienie), a nie tylko czy się zalogował. UAL jest też często „mostem” do korelacji działań między Exchange a SharePoint/OneDrive.

• Upewnij się, że audyt jest aktywny w dzierżawie i że nie ma wyjątków ograniczających rejestrowanie krytycznych działań.
• Zweryfikuj, czy zbierane są zdarzenia administracyjne i użytkownika (szczególnie operacje na skrzynkach, regułach, udostępnieniach plików, uprawnieniach, linkach).
• Zapewnij spójność identyfikatorów: UPN/ID użytkownika, identyfikatory obiektów oraz znaczniki czasu w tej samej strefie i formacie po stronie systemu, do którego eksportujesz logi.
• Określ docelową retencję i sposób wyszukiwania: do szybkich dochodzeń wystarczy portal, do huntingu i korelacji na większą skalę zwykle potrzebujesz agregacji w SIEM.

Exchange Online (poczta, uprawnienia i artefakty ataków)

W przypadku poczty polowanie często dotyczy przejętych skrzynek, reguł ukrywania śladów, nadużyć delegacji/pełnego dostępu i nietypowych operacji na wiadomościach. Minimalnie potrzebujesz telemetrii, która pokaże zarówno zmiany w konfiguracji skrzynki, jak i operacje na wiadomościach istotne z perspektywy ataków.

• Włącz audyt skrzynek pocztowych i upewnij się, że obejmuje działania właściciela, delegatów oraz administratorów.
• Zadbaj o rejestrowanie operacji na elementach (np. przenoszenie/usuwanie, dostęp do folderów, działania związane z regułami i przekazywaniem), bo to częsty sygnał „czyszczenia” po ataku.
• Utrzymuj widoczność zmian uprawnień (delegacje, pełny dostęp, wysyłanie jako/w imieniu). To nie zawsze jest „atak”, ale bez logów trudno odróżnić incydent od zwykłego procesu biznesowego.
• Spójność z UAL: wiele zdarzeń Exchange trafia do UAL; upewnij się, że w praktyce potrafisz odtworzyć chronologię działań w obu miejscach.

SharePoint Online i OneDrive (pliki, udostępnienia i eksfiltracja)

SharePoint i OneDrive są częstym celem, gdy atakujący szuka danych do kradzieży lub chce rozprzestrzenić złośliwe pliki. Tutaj kluczowe są logi pokazujące dostęp do plików, zmiany, udostępnienia i tworzenie linków, bo to one pozwalają polować na nietypowe pobrania masowe czy publiczne udostępnienia.

• Włącz audyt działań na plikach i witrynach (odczyt, pobranie, modyfikacja, usunięcie, przeniesienie/zmiana nazwy, synchronizacja).
• Rejestruj zdarzenia udostępniania: tworzenie linków, zmiany uprawnień, zaproszenia gości i udostępnienia „anyone link” (jeśli dopuszczone). To najważniejszy obszar w polowaniach na wyciek.
• Upewnij się, że widzisz operacje administracyjne na poziomie witryn (zmiany ustawień, polityk, właścicieli, zewnętrznego udostępniania), bo często poprzedzają one eksfiltrację.
• Rozważ centralizację tych zdarzeń do wspólnego miejsca analitycznego, ponieważ wolumen potrafi być wysoki, a polowania zwykle wymagają filtrowania po użytkownikach, lokalizacjach, typach operacji i „burstach” aktywności.

Microsoft Defender (sygnały bezpieczeństwa i korelacja)

Defender dostarcza „warstwy semantycznej” nad logami: alerty, incydenty, oceny ryzyka, a także sygnały z ochrony poczty, punktów końcowych i tożsamości (w zależności od posiadanych modułów). W threat huntingu to często najszybsza droga do zawężenia obszaru poszukiwań oraz do potwierdzania, czy obserwowane zachowanie ma już klasyfikację bezpieczeństwa.

• Włącz integrację i uprawnienia tak, aby analitycy mogli przeglądać alerty, incydenty i szczegóły zdarzeń (bez konieczności nadawania zbyt szerokich ról administracyjnych).
• Upewnij się, że kluczowe źródła są podpięte (poczta, tożsamość, aplikacje chmurowe, urządzenia – zgodnie z tym, co posiadasz). Bez tego polowania będą „ślepe” na część łańcucha ataku.
• Zadbaj o możliwość eksportu/korelacji alertów z logami operacyjnymi (Entra/UAL), aby z jednego sygnału przejść do szczegółowego śledztwa w aktywności użytkownika.

Minimalny „checklist” jakości danych do huntingu

• Retencja dopasowana do realnego czasu wykrycia incydentu (często tygodnie lub miesiące), a nie tylko do bieżącego monitoringu.
• Centralizacja logów w miejscu, gdzie da się je przeszukiwać przekrojowo (tożsamość + poczta + pliki + alerty) i korelować po czasie oraz użytkowniku.
• Spójny czas i strefa w zapisie zdarzeń oraz jednolity sposób identyfikacji kont (UPN, ObjectId) i aplikacji.
• Kontrola zmian konfiguracji: jeśli polityki audytu, udostępniania czy dostęp warunkowy mogą być zmieniane bez śladu lub bez procesu, polowania będą dawały niepełny obraz.
• Testy logowania: po włączeniu audytu wykonaj kilka kontrolowanych akcji (logowanie, utworzenie reguły w skrzynce, udostępnienie pliku) i sprawdź, czy faktycznie pojawiają się w odpowiednich źródłach.

3. Hunting: konta i logowania (Entra ID) — 4 przykładowe zapytania KQL/pseudo-KQL z omówieniem

Hunting w obszarze Entra ID (dawniej Azure AD) skupia się na tym, kto, skąd i w jaki sposób uzyskuje dostęp do zasobów chmurowych. W praktyce najczęściej poluje się na: nietypowe logowania, próby łamania haseł, obejścia MFA/Conditional Access oraz podejrzane działania na tożsamości (np. reset hasła, dodanie metody MFA). Poniższe cztery zapytania są celowo „gotowcami” do szybkiej weryfikacji hipotez — bez wchodzenia w dalsze szczegóły korelacji z pocztą czy SharePoint.

Najczęstsze źródła danych w tym polowaniu (w zależności od narzędzia):

• Sign-in logs (interaktywne i nieinteraktywne): zdarzenia logowania, CA, MFA, ryzyko.
• Audit logs: zmiany w tożsamościach i konfiguracji (użytkownicy, role, metody uwierzytelniania).
• Risk events (jeśli używasz Identity Protection): sygnały ryzyka i oceny.

Zapytanie 1: „Niemożliwa podróż” (impossible travel) / szybka zmiana kraju

Hipoteza: konto zostało przejęte, a atakujący loguje się z innej geolokalizacji niż użytkownik — w krótkim czasie, w sposób trudny do wyjaśnienia podróżą.

Co jest podejrzane: logowania z dwóch odległych krajów/regionów w oknie np. 30–120 minut (zwłaszcza gdy drugie logowanie jest udane).

// pseudo-KQL (Sign-in logs)
let window = 2h;
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0  // sukces
| project TimeGenerated, UserPrincipalName, IPAddress, Location = tostring(LocationDetails.countryOrRegion), AppDisplayName
| sort by UserPrincipalName asc, TimeGenerated asc
| serialize
| extend PrevTime = prev(TimeGenerated), PrevLoc = prev(Location), PrevIP = prev(IPAddress)
| extend Delta = TimeGenerated - PrevTime
| where UserPrincipalName == prev(UserPrincipalName)
| where Delta between (1m .. window)
| where Location != PrevLoc
| project UserPrincipalName, PrevTime, PrevLoc, PrevIP, TimeGenerated, Location, IPAddress, Delta, AppDisplayName

Jak czytać wynik: traktuj to jako listę par logowań. Najpierw sprawdź, czy oba logowania są realne (np. mobilna sieć/VPN potrafi „przeskakiwać” kraje). Następnie zweryfikuj, czy aplikacja jest typowa dla użytkownika oraz czy w czasie „drugiego” logowania pojawiły się inne anomalie (np. nowe urządzenie, nietypowy klient).

Szybkie doprecyzowania (opcjonalnie):

• Dodaj filtr na nietypowe aplikacje (np. admin portals) lub wyklucz znane firmowe VPN.
• Zmień warunek z kraju na ASN (operator) — często stabilniejsze od geolokalizacji.

Zapytanie 2: Password spraying — wiele kont, jedno źródło

Hipoteza: atakujący próbuje pojedynczych haseł na wielu kontach (niska liczba prób na konto), żeby ominąć blokady i nie wzbudzać alarmów.

Co jest podejrzane: duża liczba nieudanych logowań z jednego IP/ASN w krótkim czasie, rozproszona na wiele kont; czasem przeplatana pojedynczym sukcesem.

// pseudo-KQL (Sign-in logs)
let timeframe = 1h;
let minUsers = 15;
SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize
    FailedAttempts = countif(ResultType != 0),
    SuccessAttempts = countif(ResultType == 0),
    Users = dcount(UserPrincipalName),
    SampleUsers = make_set(UserPrincipalName, 10),
    Apps = make_set(AppDisplayName, 5)
  by IPAddress
| where Users >= minUsers and FailedAttempts > 0
| order by Users desc, FailedAttempts desc

Jak czytać wynik: najpierw patrz na Users (liczbę unikalnych kont) i FailedAttempts. Jeśli pojawia się też SuccessAttempts, potraktuj to jako priorytet (możliwe trafienie hasła). Dalsza analiza zwykle polega na zejściu poziom niżej: które konta miały sukces, jakie aplikacje i czy to nie jest np. błędna konfiguracja jakiegoś systemu.

Typowe źródła fałszywych trafień: testy SSO, błędne hasło zapisane w kliencie poczty, skrypty integracyjne lub błędnie skonfigurowane urządzenia.

Zapytanie 3: Podejrzane logowania do wrażliwych aplikacji (portale administracyjne / Graph) z nietypowych parametrów

Hipoteza: po przejęciu konta atakujący próbuje szybko wejść w panele administracyjne lub użyć API (Graph) do eskalacji lub eksfiltracji.

Co jest podejrzane: sukces do „wrażliwych” aplikacji z nowego IP/ASN, nietypowego klienta lub bez spodziewanej interakcji użytkownika.

// pseudo-KQL (Sign-in logs)
let sensitiveApps = dynamic([
  "Azure Portal",
  "Microsoft Admin Portal",
  "Microsoft Graph",
  "Exchange Online",
  "Office 365 SharePoint Online"
]);
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where AppDisplayName in (sensitiveApps)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
          ClientAppUsed, DeviceDetail, AuthenticationRequirement,
          ConditionalAccessStatus, Status
| order by TimeGenerated desc

Jak czytać wynik: to zapytanie jest „sitem” — nie mówi jeszcze, że to incydent, ale szybko pokazuje kto i kiedy dotyka wrażliwych obszarów. Szczególnie interesujące są logowania, które odbiegają od normy użytkownika (np. użytkownik nietechniczny nagle loguje się do portalu admina).

Wskazówka praktyczna: utrzymuj krótką listę aplikacji uznanych u Ciebie za „wrażliwe” i aktualizuj ją. W wielu środowiskach lepsze efekty daje lista 5–15 pozycji niż próba objęcia wszystkiego.

Zapytanie 4: Zmiany w tożsamości — dodanie/zmiana metod MFA, reset hasła, rejestracja urządzeń

Hipoteza: atakujący po uzyskaniu dostępu „utwardza” przejęcie: dodaje nową metodę MFA, resetuje hasło, dodaje urządzenie lub zmienia dane uwierzytelniające, by utrzymać dostęp.

Co jest podejrzane: nietypowe zdarzenia w audit logach dotyczące metod uwierzytelniania i danych konta, zwłaszcza gdy tuż przed nimi były anomalie logowania.

// pseudo-KQL (Entra ID Audit logs)
let ops = dynamic([
  "Add authentication method",
  "Update authentication method",
  "Delete authentication method",
  "Reset user password",
  "Register device",
  "Add user"
]);
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in (ops)
| project TimeGenerated, OperationName, Result, InitiatedBy,
          TargetResources, AdditionalDetails
| order by TimeGenerated desc

Jak czytać wynik: szukaj działań wykonywanych: (1) przez samych użytkowników w nietypowym czasie, (2) przez nietypowych administratorów/konta serwisowe, (3) seryjnie na wielu kontach. Jeśli widzisz zmianę metod MFA lub reset hasła, niemal zawsze warto sprawdzić, jakie logowanie poprzedziło tę zmianę (czas, IP, aplikacja, CA/MFA).

Minimalna praktyka hunt:

• Trzymaj osobną obserwację dla kont uprzywilejowanych (administratorzy, konta break-glass, konta serwisowe z szerokimi uprawnieniami).
• Ustal „normalne” okna czasowe dla operacji administracyjnych; poza nimi zdarzenia często są bardziej podejrzane.
• Notuj znane, planowane zmiany (np. rollout MFA), by nie zalać się szumem.

4. Hunting: poczta/Exchange Online — 4 przykładowe zapytania KQL/pseudo-KQL z omówieniem

Threat hunting w obszarze poczty w Microsoft 365 zwykle koncentruje się na czterech klasach zdarzeń: dostarczenie wiadomości (co weszło do organizacji), akcje użytkownika (co ktoś kliknął/uruchomił/zgłosił), zmiany konfiguracji (reguły, przekierowania, uprawnienia) oraz nietypowe operacje na skrzynce (masowe odczyty/eksport). Poniżej znajdziesz 4 praktyczne zapytania (KQL/pseudo-KQL), które dobrze sprawdzają się jako „gotowce” do szybkiej analizy incydentów i polowania na oznaki kompromitacji skrzynek. W Cognity omawiamy to zagadnienie zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

Zapytanie 1: Szybkie „campaign sweep” po IoC (URL/domena/nadawca)

Kiedy użyć: gdy masz choć jeden wskaźnik (URL z sandboxa, domenę nadawcy, temat, Message-ID) i chcesz szybko ustalić kogo dotknęło oraz jaką decyzję podjął system (dostarczono, zablokowano, kwarantanna).

// Pseudo-KQL (Defender for Office 365 / Advanced Hunting)
let iocDomains = dynamic(["example.bad", "phish.tld"]);
let iocUrlFragment = "login"; // opcjonalnie: fragment ścieżki/parametru
EmailUrlInfo
| where UrlDomain in (iocDomains) or Url has iocUrlFragment
| join kind=inner (
    EmailEvents
    | project NetworkMessageId, Timestamp, SenderFromAddress, RecipientEmailAddress,
              Subject, DeliveryAction, DeliveryLocation, ThreatTypes
) on NetworkMessageId
| summarize recipients=dcount(RecipientEmailAddress), sampleRecipients=make_set(RecipientEmailAddress, 10)
          by UrlDomain, Subject, SenderFromAddress, DeliveryAction, DeliveryLocation, ThreatTypes
| order by recipients desc

Na co patrzeć:

• DeliveryAction/DeliveryLocation — czy wiadomości realnie trafiły do Inbox, czy zostały zatrzymane.
• Recipient „rozlany” po działach — szeroki rozrzut odbiorców często wskazuje kampanię, a nie celowany atak.
• ThreatTypes — pomocne w priorytetyzacji (np. phishing vs malware), ale nie traktuj jako jedynego kryterium.

Warianty praktyczne: zamiast URL możesz filtrować po SenderFromDomain, Subject (ostrożnie, bo bywa powtarzalny w legalnych powiadomieniach) lub po AttachmentHash jeśli analizujesz kampanię z plikami.

Zapytanie 2: Nowe i podejrzane reguły skrzynki (Inbox Rules) pod kątem exfil/persistence

Kiedy użyć: gdy podejrzewasz przejęcie konta i szukasz mechanizmu ukrywania korespondencji (np. przenoszenie do RSS/Archiwum) albo automatycznego przesyłania na zewnątrz.

// Pseudo-KQL (Unified Audit Log / Microsoft Purview Audit)
AuditLogs
| where RecordType in ("ExchangeItem", "ExchangeAdmin")
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend User = tostring(UserId)
| extend RuleName = tostring(Parameters["Name"])
| extend RuleActions = tostring(Parameters)
| where RuleActions has_any ("RedirectTo", "ForwardTo", "DeleteMessage", "MoveToFolder")
| where RuleActions has "@" // heurystyka: adres w akcji
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Changes=count()
          by User, RuleName, RuleActions, ClientIP=tostring(ClientIP)
| order by LastSeen desc

Na co patrzeć:

• Akcje RedirectTo/ForwardTo — szczególnie gdy kierują do domen zewnętrznych lub rzadkich.
• MoveToFolder/DeleteMessage — reguły „ukrywające” odpowiedzi, reset hasła, alerty MFA, faktury, itp.
• ClientIP / AppId / UserAgent (jeśli dostępne w audycie) — nietypowy klient (np. automaty) albo geolokalizacja inna niż zwykle.

Wskazówka: wartości w Parameters i nazwy pól różnią się między eksportami (Graph API / portal). W polowaniu liczy się logika: kto, kiedy, co zmienił i czy reguła może wynosić/ukrywać pocztę.

Zapytanie 3: Przekierowania na zewnątrz (Forwarding SMTP / mailbox forwarding)

Kiedy użyć: gdy chcesz wykryć trwałe przekierowanie całej poczty (częsty mechanizm wycieku po kompromitacji) ustawione na poziomie skrzynki lub obiektu użytkownika.

// Pseudo-KQL (Unified Audit Log / Exchange admin changes)
AuditLogs
| where Operation in ("Set-Mailbox", "Set-MailboxPlan", "Set-TransportConfig", "New-Mailbox")
| extend Params = tostring(Parameters)
| where Params has_any ("ForwardingSmtpAddress", "DeliverToMailboxAndForward", "ForwardingAddress")
| summarize LastSeen=max(TimeGenerated), Ops=count() by UserId, TargetObject=tostring(ObjectId), Params, ClientIP=tostring(ClientIP)
| order by LastSeen desc

Na co patrzeć:

• ForwardingSmtpAddress ustawione na adres poza organizacją.
• DeliverToMailboxAndForward — scenariusz „niewidoczny dla użytkownika”, bo poczta nadal przychodzi do Inbox.
• Kto wykonał zmianę — sam użytkownik vs konto administracyjne; to pomaga rozróżnić kompromitację od działań IT.

Uwaga operacyjna: forwarding bywa legalny (np. procesy biznesowe). Najlepsze efekty daje porównanie z listą dozwolonych domen/skrzynek odbiorczych oraz szybka weryfikacja, czy forwarding pojawił się po podejrzanym logowaniu.

Zapytanie 4: Masowy dostęp do elementów skrzynki (MailItemsAccessed / nietypowe odczyty)

Kiedy użyć: gdy podejrzewasz wyciek danych ze skrzynki (np. napastnik przeszukuje i czyta wiele wiadomości) albo działanie automatu typu „eDiscovery-like” wykonywane niezgodnie z procesem.

// Pseudo-KQL (Audit: mailbox item access)
AuditLogs
| where Operation in ("MailItemsAccessed", "MessageBind")
| extend User = tostring(UserId)
| summarize ItemsAccessed=sum(tolong(AdditionalFields["ItemCount"])),
            Ops=count(),
            FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
          by User, ClientIP=tostring(ClientIP), App=tostring(AdditionalFields["App"])
| where ItemsAccessed > 200 or Ops > 500
| order by ItemsAccessed desc

Na co patrzeć:

• Skok wolumenu (ItemsAccessed/Ops) w krótkim czasie — sygnał przeglądania/eksfiltracji lub indeksowania.
• App/Client — nietypowa aplikacja (np. legacy protokół, nieznany klient) w zestawieniu z normalnym profilem użytkownika.
• ClientIP — nowe adresy lub adresy kojarzone z anonimizacją/proxy.

Jak tego używać w praktyce: to zapytanie jest dobrym „radarem” do wyłapania anomalii. Dopiero po trafieniu zwykle schodzi się niżej: do zakresu czasowego, folderów, konkretnych wiadomości/tematów oraz korelacji z logowaniami i zmianami konfiguracji skrzynki.

5. Hunting: SharePoint Online i OneDrive — 4 przykładowe zapytania KQL/pseudo-KQL z omówieniem

Hunting w SharePoint Online i OneDrive różni się od polowania na logowania czy pocztę: tutaj kluczowe są operacje na plikach (pobrania, udostępnienia, usunięcia, zmiany uprawnień) oraz kontekst zasobu (lokalizacja, typ linku, zewnętrzny odbiorca, wolumen zmian w krótkim czasie). W praktyce zapytania często celują w dwa scenariusze: eksfiltrację (masowe pobrania/udostępnienia) oraz impact (masowe usunięcia, niszczenie wersji, zmiany uprawnień).

Poniższe przykłady są zapisane jako KQL/pseudo-KQL (nazwy tabel/pól mogą się różnić w zależności od miejsca, w którym polujesz: Microsoft Sentinel, Advanced Hunting, eksport UAL). Warto traktować je jako wzorce do adaptacji.

5.1. Masowe pobrania plików z SharePoint/OneDrive (podejrzenie eksfiltracji)

Intencja: wykryć konto, które w krótkim oknie czasowym pobiera nietypowo dużo plików (lub danych) – szczególnie poza normalnymi godzinami, z nowego IP lub po świeżej zmianie urządzenia/przeglądarki.

// Pseudo-KQL: masowe pobrania w 30 min
SharePointActivity
| where TimeGenerated > ago(7d)
| where Operation in ("FileDownloaded", "DownloadFile", "FileSyncDownloadedFull")
| extend User = tostring(UserId), Ip = tostring(ClientIP), Site = tostring(SiteUrl)
| summarize Downloads=count(), DistinctSites=dcount(Site), First=min(TimeGenerated), Last=max(TimeGenerated)
          by User, Ip, bin(TimeGenerated, 30m)
| where Downloads > 200 or (Downloads > 80 and DistinctSites > 5)
| order by Downloads desc

• Na co patrzeć: czy wolumen jest wysoki w porównaniu do zwykłej aktywności użytkownika, czy pobrania dotyczą wielu witryn/bibliotek, czy pojawia się nowe IP lub nietypowy klient (np. nagły przeskok na synchronizację).
• Typowe legalne przyczyny: migracje danych, duża synchronizacja OneDrive po reinstalacji, praca z dużym projektem, pobranie paczki dokumentów do pracy offline.
• Sygnały podbijające priorytet: współwystępowanie z utworzeniem linków anonimowych, pobrania z wielu lokalizacji, pobrania z zasobów wrażliwych.

5.2. Tworzenie linków anonimowych lub „Anyone” (szybkie udostępnienie na zewnątrz)

Intencja: wychwycić przypadki, gdzie użytkownik tworzy link „dla każdego” (anonimowy) lub zmienia udostępnienie na bardziej otwarte, co może być prostą ścieżką eksfiltracji bez wysyłki plików mailem.

// Pseudo-KQL: linki anonimowe / Anyone + nietypowa skala
SharePointActivity
| where TimeGenerated > ago(14d)
| where Operation in ("AnonymousLinkCreated", "SharingLinkCreated", "SharingSet")
| extend User=tostring(UserId), Item=tostring(ObjectId), Site=tostring(SiteUrl)
| extend LinkType=tostring(SharingLinkType)   // np. Anyone/Anonymous/Organization/SpecificPeople
| where LinkType in ("Anyone", "Anonymous")
| summarize Links=count(), Items=dcount(Item), Sites=dcount(Site) by User, bin(TimeGenerated, 1h)
| where Links > 10 or Items > 10
| order by Links desc

• Na co patrzeć: czy link jest anonimowy, jaki ma poziom uprawnień (odczyt/edycja), jaki jest czas ważności, czy dotyczy wielu elementów w krótkim czasie.
• Typowe legalne przyczyny: szybkie udostępnianie materiałów dla wielu odbiorców, procesy biznesowe (np. publikacja plików do zewnętrznych interesariuszy).
• Sygnały podbijające priorytet: linki z uprawnieniami edycji, brak daty wygaśnięcia, tworzenie linków tuż po podejrzanym logowaniu lub masowych pobraniach.

5.3. Masowe usuwanie plików i czyszczenie kosza (impact/ransomware-like)

Intencja: namierzyć zdarzenia sugerujące niszczenie danych: masowe usuwanie, opróżnianie kosza lub usuwanie elementów z drugiego etapu kosza. Ten wzorzec bywa widoczny przy przejęciu konta lub automatycznych działaniach złośliwej aplikacji/klienta.

// Pseudo-KQL: masowe usunięcia + operacje na koszu
SharePointActivity
| where TimeGenerated > ago(7d)
| where Operation in ("FileDeleted", "FolderDeleted", "RecycleBinItemDeleted", "RecycleBinEmptied")
| extend User=tostring(UserId), Site=tostring(SiteUrl)
| summarize Deletes=count(), Sites=dcount(Site) by User, bin(TimeGenerated, 15m)
| where Deletes > 100
| order by Deletes desc

• Na co patrzeć: tempo usunięć, czy usuwane są foldery (większy impact), czy występuje opróżnianie kosza, czy zdarzenia obejmują wiele witryn.
• Typowe legalne przyczyny: porządkowanie dużych repozytoriów, automatyczne procesy archiwizacji/retencji (choć one często mają charakterystyczny „podpis”).
• Sygnały podbijające priorytet: usuwanie poza godzinami pracy, z nietypowego klienta, po świeżo utworzonych linkach udostępniania lub po eskalacji uprawnień.

5.4. Nietypowe zmiany uprawnień i udostępnianie: dodanie współwłaścicieli, nowe role, zewnętrzni goście

Intencja: wykryć ciche poszerzanie dostępu: dodawanie nowych osób do zasobów, podnoszenie uprawnień (np. Owner), zaproszenia gości lub zmiany polityki udostępniania na poziomie witryny/biblioteki. To często służy utrzymaniu dostępu nawet po zmianie hasła.

// Pseudo-KQL: zmiany uprawnień / role / zaproszenia
SharePointActivity
| where TimeGenerated > ago(30d)
| where Operation in ("SitePermissionChanged", "AddedToGroup", "RoleAssignmentAdded", "SharingInvitationCreated")
| extend Actor=tostring(UserId), Target=tostring(TargetUserOrGroup), Site=tostring(SiteUrl)
| summarize Changes=count(), Targets=dcount(Target) by Actor, Site, bin(TimeGenerated, 1d)
| where Changes > 20 or Targets > 10
| order by Changes desc

• Na co patrzeć: kto jest aktorem zmiany, czy pojawiają się konta zewnętrzne, czy zmiany dotyczą ról o wysokich uprawnieniach, czy są wykonywane seryjnie.
• Typowe legalne przyczyny: onboarding do projektu, reorganizacja zespołów, nadawanie dostępu serwisom/aplikacjom integracyjnym.
• Sygnały podbijające priorytet: dodanie nietypowych odbiorców (spoza domeny/organizacji), uprawnienia właścicielskie, zmiany tuż po anomaliach logowania lub w parze z tworzeniem linków anonimowych.

Wskazówka praktyczna: w SharePoint/OneDrive pojedyncze zdarzenie rzadko przesądza o incydencie. Najlepsze efekty daje szukanie sekwencji (np. utworzenie linku „Anyone” → masowe pobrania → usunięcia) oraz progów dopasowanych do profilu organizacji (dział, rola, typ witryn).

6. Interpretacja wyników: false positives, korelacja zdarzeń i wzbogacanie kontekstu

Same zapytania huntingowe rzadko dają „gotową odpowiedź”. Zwracają sygnały, które trzeba zinterpretować: odsiać fałszywe alarmy, połączyć zdarzenia w spójny ciąg oraz dołożyć kontekst (kto, skąd, na jakim urządzeniu i z jakim celem). Dobrze przeprowadzona interpretacja zmniejsza ryzyko pochopnej eskalacji i jednocześnie ogranicza przeoczenia.

False positives: skąd się biorą i jak je ograniczać

W M365 wiele zachowań wygląda „podejrzanie” tylko dlatego, że środowisko jest dynamiczne (praca zdalna, urządzenia mobilne, automatyzacje, integracje). Najczęstsze źródła false positives to:

• Legalne narzędzia i automatyzacje (aplikacje z uprawnieniami, PowerShell/Graph w admin automations, integracje DLP/CASB, systemy backupu).
• Zmiany lokalizacji i sieci (VPN, roaming, NAT operatorów, wyjścia przez chmury/VDI).
• Normalne wzorce biznesowe (masowe pobrania w czasie migracji, udostępnienia w projektach, duże wysyłki maili z systemów).
• Braki w telemetrii (np. tylko część aktywności jest widoczna, opóźnienia w logach, różne pola w różnych źródłach).

Praktyczne metody redukcji false positives (bez „przekręcania” detekcji na ślepo):

• Baselining: porównuj aktywność do typowego profilu użytkownika/zespołu (pory, wolumeny, lokalizacje, typy operacji).
• Allowlisty oparte o kontekst, nie o same IP: zaufane aplikacje (AppId/ServicePrincipal), znane narzędzia administracyjne, firmowe urządzenia zgodne (compliant).
• Progi i okna czasowe: np. „>N operacji w 10 min” zamiast pojedynczego zdarzenia.
• Weryfikacja artefaktów: czy działanie ma sens biznesowo (ticket/change), czy dotyczy zasobów wrażliwych, czy zostało potwierdzone innymi logami.
• Rozróżnienie tożsamości: użytkownik vs konto serwisowe; interaktywne logowanie vs token/aplikacja.

Korelacja zdarzeń: łączenie w „historię incydentu”

Pojedyncze zdarzenie rzadko jest rozstrzygające. Korelacja polega na zbudowaniu osi czasu i połączeniu sygnałów z różnych obszarów (konto, poczta, SharePoint). Najbardziej użyteczne wątki korelacyjne to:

• Tożsamość: UPN/userId, objectId, session id, token id (tam gdzie dostępne).
• Czas: bliskie okna (np. 5–30 min) wokół zdarzenia „wyzwalacza”.
• Źródło dostępu: IP, kraj/region, user agent, typ klienta (browser/mobile/legacy), aplikacja (AppId).
• Zasób: skrzynka (mailbox), witryna/plik (SiteUrl, FileId), rola/uprawnienie (role name).

W praktyce warto myśleć o korelacji jako o odpowiedzi na trzy pytania:

• Czy to ten sam aktor? (spójność urządzenia/IP/aplikacji i sekwencji zdarzeń).
• Jaki był cel? (próby utrzymania dostępu: reguły, uprawnienia, OAuth; oraz eksfiltracja: pobrania/udostępnienia/wysyłki).
• Jaki jest zasięg? (jedno konto czy wiele, jeden zasób czy wiele, czy dotyczy kont uprzywilejowanych).

Przykładowy schemat korelacji (bez przywiązania do konkretnego produktu SIEM) może wyglądać tak:

// Pseudo-KQL: korelacja logowania + zmiany w poczcie + aktywności w plikach
let seedUser = "<user@domain>";
let t0 = datetime(2026-03-20T10:00:00Z);
let window = 30m;

SigninLogs
| where UserPrincipalName == seedUser and TimeGenerated between (t0-window .. t0+window)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed, DeviceDetail
| join kind=leftouter (
    OfficeActivity
    | where UserId == seedUser and TimeGenerated between (t0-window .. t0+window)
    | where Workload in ("Exchange", "SharePoint")
    | project TimeGenerated, UserId, Workload, Operation, ItemName, SiteUrl, ClientIP
) on $left.UserPrincipalName == $right.UserId
| order by TimeGenerated asc

Wzbogacanie kontekstu: co dopinać do wyniku, żeby decyzja była szybsza

Wzbogacanie (enrichment) to dokładanie metadanych, które pomagają szybko ocenić ryzyko i priorytet. Najbardziej przydatne kategorie kontekstu w M365:

• Kontekst tożsamości: czy konto jest uprzywilejowane, czy jest chronione (MFA, Conditional Access), czy jest wysokiego ryzyka, czy to konto serwisowe.
• Kontekst urządzenia: zarządzane vs niezarządzane, compliant, znany fingerprint urządzenia, obecność sygnałów z EDR (jeśli dostępne).
• Kontekst aplikacji: czy dostęp był przez przeglądarkę, aplikację mobilną, legacy auth, czy przez aplikację OAuth; jakie ma uprawnienia i czy były niedawno nadane/zmienione.
• Kontekst danych: wrażliwość (etykiety, typy informacji), czy plik był udostępniony na zewnątrz, czy jest częścią krytycznej witryny.
• Kontekst organizacyjny: dział/rola użytkownika, czy jest na urlopie, czy działa poza typowymi godzinami, czy jest otwarty incydent/zmiana.

Dobry enrichment nie musi być rozbudowany — często wystarczy kilka pól, które „ważą” wynik. Przykładowa prosta punktacja (tylko jako idea interpretacyjna):

• +2 jeśli konto uprzywilejowane lub ma dostęp do wrażliwych zasobów
• +2 jeśli logowanie z nowego kraju/ASN i brak zgodnego urządzenia
• +2 jeśli w oknie czasu pojawia się mechanizm trwałości (reguła, OAuth, uprawnienia)
• +1 jeśli widać eksfiltrację (masowe pobrania/udostępnienia/wysyłki)
• -2 jeśli zdarzenie pokrywa się z udokumentowaną zmianą lub znaną automatyzacją

Jak czytać wyniki: sygnały silne vs słabe

Nie wszystkie trafienia są równe. W interpretacji pomocny jest podział na:

• Sygnały silne: wskazują na intencję lub trwałość (np. nowe przekierowanie na zewnętrzny adres, nadanie szerokich uprawnień, rejestracja podejrzanej aplikacji OAuth z wysokimi scopes, wyłączenie audytu/zmiana polityk bezpieczeństwa).
• Sygnały słabe: same w sobie często benign (np. pojedyncze nietypowe logowanie, wzrost liczby pobrań bez wrażliwych danych). Zyskują znaczenie dopiero po korelacji.

W praktyce celem sekcji interpretacji jest doprowadzenie wyniku hunt do krótkiej, decyzyjnej formy:

• Co się stało (1–2 zdania, oś czasu)
• Dlaczego to podejrzane (konkretne odstępstwo od normy + korelacja)
• Jaki jest potencjalny wpływ (konto/dane/zakres)
• Jakie informacje jeszcze brakuje (np. czy urządzenie było zarządzane, czy zasoby miały etykiety, czy była zmiana CA/MFA)

7. Działania po trafieniu: triage, containment, remediation oraz hardening

Wynik threat huntingu to zwykle sygnał, a nie gotowy werdykt. Kluczowe jest szybkie przejście od obserwacji do kontrolowanych działań: najpierw potwierdzenie istotności (triage), potem ograniczenie wpływu (containment), usunięcie przyczyny i skutków (remediation), a na końcu trwałe wzmocnienie środowiska (hardening). Poniżej znajduje się praktyczny, powtarzalny schemat postępowania dla incydentów związanych z kontem, pocztą oraz SharePoint/OneDrive w Microsoft 365.

Triage: co sprawdzić w pierwszych minutach

Celem triage jest odpowiedź na trzy pytania: czy to prawdziwe zagrożenie, jaki jest zakres oraz czy atak trwa. Na tym etapie ważniejsza jest szybkość i kompletność podstawowych ustaleń niż pełna analiza przyczyn.

• Ustal „co się stało” i „kiedy”: spisz identyfikatory zdarzeń, użytkownika, czas, adres IP, aplikację/klienta, typ operacji (logowanie, reguła skrzynki, udostępnienie pliku, masowe pobrania).
• Oceń prawdopodobieństwo kompromitacji konta: nietypowa geolokalizacja, nowe urządzenie, zmiana metody MFA, nieznana aplikacja OAuth, wiele nieudanych logowań przed sukcesem.
• Sprawdź „blast radius”: czy dotyczy jednego użytkownika czy wielu; czy operacje dotyczą wrażliwych lokalizacji (skrzynka, foldery SharePoint, OneDrive, grupy, role administracyjne).
• Zweryfikuj zmiany konfiguracji: nowo dodane metody uwierzytelniania, uprawnienia aplikacji, przekierowania poczty, delegacje, zasady udostępniania, linki anonimowe.
• Wykryj oznaki automatyzacji/masowości: krótkie odstępy czasowe, powtarzalny wzorzec operacji, wysokie wolumeny pobrań/usunięć/udostępnień.
• Zabezpiecz materiał dowodowy: zanotuj zakres czasu i kluczowe atrybuty; jeśli to możliwe, zachowaj kopię istotnych informacji o zdarzeniach do dalszej analizy i raportowania.

Wynikiem triage powinna być decyzja: zamykać jako fałszywy alarm, monitorować albo eskalować jako incydent z natychmiastowym containmentem.

Containment: szybkie ograniczenie wpływu (bez niszczenia dowodów)

Containment ma zatrzymać dalsze działania atakującego i ograniczyć rozprzestrzenianie się incydentu. W M365 często zaczyna się od konta (tożsamości), bo kompromitacja skrzynki lub SharePoint zwykle jest skutkiem przejęcia tożsamości.

• Konto i sesje: czasowe zablokowanie logowania lub wymuszenie wylogowania aktywnych sesji; odcięcie podejrzanych urządzeń lub aplikacji klienckich, jeśli to uzasadnione.
• Hasło i metody MFA: wymuszenie zmiany hasła i sprawdzenie/wyczyszczenie podejrzanych metod MFA (np. nowy numer telefonu, aplikacja uwierzytelniająca dodana w czasie incydentu).
• Aplikacje OAuth i zgody: cofnięcie podejrzanych zgód aplikacji i zablokowanie aplikacji, które mogły uzyskać trwały dostęp do poczty lub plików.
• Poczta: tymczasowe wyłączenie/zmiana podejrzanych reguł skrzynki, przekierowań i delegacji; w razie potrzeby blokada wysyłki z konta do czasu wyjaśnienia (ograniczenie kampanii BEC/phishing).
• SharePoint/OneDrive: ograniczenie udostępnień (zwłaszcza anonimowych), unieważnienie linków udostępniania, wstrzymanie synchronizacji na podejrzanych urządzeniach, jeśli ryzyko wycieku jest wysokie.
• Zmiany uprzywilejowane: jeśli incydent dotyczy konta z podwyższonymi uprawnieniami, priorytetem jest natychmiastowe ograniczenie ról i przejście na tryb awaryjny pracy administracyjnej.

Containment powinien być proporcjonalny: wystarczająco agresywny, by zatrzymać atak, ale nie tak szeroki, by niepotrzebnie sparaliżować organizację.

Remediation: usunięcie przyczyny i odwrócenie skutków

Remediation to etap „sprzątania”: usuwasz mechanizmy trwałości, cofnięte zostają niepożądane zmiany, a dostęp wraca do bezpiecznego stanu. W M365 najczęstsze przyczyny to wyłudzone poświadczenia, słabe zabezpieczenia tożsamości, niekontrolowane aplikacje oraz błędne ustawienia udostępnień.

• Tożsamość: pełna rotacja poświadczeń (hasło, klucze aplikacji, tokeny), weryfikacja urządzeń powiązanych z kontem, przegląd ostatnich zmian w profilu użytkownika i uprawnieniach.
• Usunięcie trwałości: trwałe usunięcie podejrzanych reguł skrzynki, przekierowań, delegacji, subskrypcji powiadomień, aplikacji z dostępem do danych oraz nadanych uprawnień.
• Przywrócenie poczty: identyfikacja i wycofanie złośliwych wiadomości (tam, gdzie to możliwe), sprawdzenie czy nie doszło do podszywania się, oraz korekta zmian w ustawieniach wysyłki.
• Pliki i udostępnienia: wycofanie publicznych lub zbyt szerokich udostępnień, przegląd ostatnio pobieranych/masowo modyfikowanych plików, odzyskanie danych w razie usunięć lub szyfrowania.
• Ocena ekspozycji danych: określenie, jakie dane mogły zostać ujawnione (poczta, załączniki, pliki, listy), i czy wymagane są działania formalne (np. zgłoszenia, powiadomienia).
• Weryfikacja czystości: potwierdzenie, że podejrzane aktywności nie występują po przywróceniu dostępu oraz że nie ma alternatywnych kanałów dostępu (np. inne konta, aplikacje, konta gościnne).

Hardening: jak zmniejszyć ryzyko powtórki

Hardening to zestaw zmian, które mają obniżyć prawdopodobieństwo podobnych incydentów i zwiększyć wykrywalność. Warto je traktować jak „lekcje z incydentu” i wdrażać w formie kontrolowanych zmian.

• Wzmocnienie logowania: konsekwentne MFA, preferowanie metod odpornych na phishing tam, gdzie to możliwe, oraz ograniczanie dostępu z ryzykownych lokalizacji/urządzeń.
• Kontrola aplikacji: ograniczenie zgód użytkowników na aplikacje, przegląd i cykliczna rekontrola aplikacji mających dostęp do poczty i plików, model „least privilege”.
• Ochrona poczty: redukcja ryzyka BEC i nadużyć reguł skrzynki poprzez polityki blokujące podejrzane przekierowania, monitoring nowych reguł oraz edukację użytkowników w zakresie anomalii w korespondencji.
• Higiena udostępnień: ograniczenie anonimowych linków, preferowanie udostępniania z uwierzytelnieniem, okresowe przeglądy uprawnień do witryn i bibliotek oraz kontrola dostępu gości.
• Segmentacja uprawnień: minimalizacja ról administracyjnych, rozdzielenie kont użytkownika od administracyjnego, okresowe przeglądy członkostw w grupach i ról.
• Detekcja i alertowanie: zamiana „ręcznego” discovery z huntów w stałe reguły/alerty dla najbardziej krytycznych wzorców, wraz z progami i wyjątkami ograniczającymi szum.
• Ćwiczenia i gotowość operacyjna: krótkie procedury postępowania dla helpdesku i zespołów IT/SOC, testy przywracania dostępu oraz regularne sprawdzanie, czy logowanie i audyt pokrywają kluczowe scenariusze.

Minimalne playbooki, które warto mieć przygotowane

Playbooki nie muszą być rozbudowane. Najlepiej sprawdzają się krótkie checklisty z kryteriami eskalacji i zestawem kroków „stop the bleeding”. W kontekście M365 najczęściej wystarczą poniższe scenariusze:

• Podejrzenie przejęcia konta: szybkie potwierdzenie sygnałów, blokada dostępu/sesji, reset poświadczeń, przegląd zmian MFA i aplikacji, potem bezpieczne przywrócenie.
• Persistence w skrzynce: wykrycie i usunięcie reguł/przekierowań/delegacji, kontrola wysyłki, weryfikacja czy nie doszło do dalszych nadużyć (np. BEC).
• Masowe pobrania/udostępnienia w SharePoint/OneDrive: odcięcie podejrzanego dostępu, unieważnienie linków, przegląd zakresu wycieku i uporządkowanie uprawnień.
• Podejrzana aplikacja OAuth: identyfikacja aplikacji i zakresu uprawnień, cofnięcie zgód, blokada aplikacji, przegląd aktywności wykonanych przez aplikację.
• Incydent na koncie uprzywilejowanym: natychmiastowe ograniczenie ról, przejście na administrację awaryjną, rotacja poświadczeń i pełny przegląd zmian w tenantcie.

Dobrą praktyką jest zakończenie każdego incydentu krótkim podsumowaniem: co było przyczyną, co zadziałało w detekcji, gdzie zabrakło telemetrii oraz jakie konkretne zmiany (techniczne i procesowe) zmniejszą ryzyko powtórki.

Szablon 5: Ransomware – detekcja, izolacja, odzyskiwanie, negocjacje i decyzje biznesowo-prawne oraz utrzymanie playbooków

Ransomware to scenariusz, w którym czas ma krytyczne znaczenie, a błędna decyzja w pierwszych godzinach potrafi eskalować straty wielokrotnie. Ten szablon playbooka porządkuje działania od wczesnej detekcji przez izolację, odzyskiwanie i komunikację kryzysową, aż po decyzje biznesowo-prawne (w tym temat negocjacji). W odróżnieniu od klasycznych incydentów phishingowych czy pojedynczego przejęcia konta, ransomware zwykle wymaga równoległego prowadzenia ścieżek: technicznej, operacyjnej, prawnej i zarządczej.

1) Detekcja: co odróżnia ransomware od „zwykłego” incydentu

Na wczesnym etapie kluczowe jest rozpoznanie wzorca: szybka, masowa zmiana lub utrata dostępu do danych, nietypowe operacje na plikach, nagłe ograniczenia dostępności systemów oraz próby obejścia kontroli. W środowisku M365 sygnały ostrzegawcze często dotyczą tożsamości (nadużycia kont), poczty (dalsze rozprzestrzenianie) oraz SharePoint/OneDrive (szyfrowanie/niszczenie danych w chmurze).

• Sygnał priorytetowy: oznaki równoległego nadużycia wielu kont, nietypowa automatyzacja i gwałtowny wzrost operacji na zasobach.
• Cel detekcji: jak najszybciej określić zasięg (kto, co, kiedy) i potencjalny wektor wejścia, aby izolacja nie była „na ślepo”.

2) Izolacja (containment): szybkość vs. ciągłość działania

Izolacja w ransomware różni się tym, że często trzeba przeciąć drogi propagacji szybciej niż w innych typach incydentów, nawet kosztem krótkotrwałego spadku dostępności. Kluczowe jest jednak, aby działania były kontrolowane i odtwarzalne: gwałtowne „wyłączanie wszystkiego” może utrudnić dochodzenie, odzyskiwanie i późniejszą odpowiedzialność prawną.

• Decyzje natychmiastowe: ograniczenie dostępu podejrzanych kont, zatrzymanie podejrzanych integracji/aplikacji, ograniczenie synchronizacji i dostępu do krytycznych repozytoriów.
• Priorytetyzacja: najpierw ochrona tożsamości i punktów o najszerszych uprawnieniach, potem obszary o największej wartości biznesowej.
• Minimalizacja szkód ubocznych: izolować segmentami i rolami, z jasnym kryterium „kiedy odkręcamy” oraz kto zatwierdza.

3) Odzyskiwanie: przywracanie usług i danych z zachowaniem kontroli ryzyka

Odzyskiwanie w ransomware to nie tylko „restore”, ale też kontrola, czy środowisko jest czyste i czy nie odtwarza się mechanizmu ponownej infekcji. W M365 ważne są decyzje dotyczące priorytetów przywracania: konta uprzywilejowane, poczta, repozytoria dokumentów, współdzielenie i integracje.

• Warianty odzyskiwania: przywrócenie danych (wersjonowanie/odzyskiwanie), odbudowa dostępu (reset poświadczeń i tokenów), odbudowa zaufania do konfiguracji (przegląd reguł, delegacji, aplikacji).
• Kolejność: najpierw zabezpieczenie tożsamości i mechanizmów dostępu, następnie zasoby biznesowo krytyczne, na końcu pełna dostępność i optymalizacja.
• Kryterium zakończenia: potwierdzony brak aktywnej propagacji, kontrolowany powrót usług, udokumentowane decyzje i dowody działań.

4) Negocjacje i komunikacja: ramy decyzyjne, nie improwizacja

Wątek negocjacji (lub decyzji o ich braku) jest szczególnie wrażliwy: to obszar, gdzie improwizacja zwiększa ryzyko prawne, reputacyjne i operacyjne. Playbook powinien opisywać kto może podejmować rozmowy, jak dokumentować ustalenia, oraz jakie są czerwone linie (np. brak kontaktu z atakującym bez zatwierdzenia).

• Jedno źródło prawdy: centralne miejsce do rejestrowania decyzji, osi czasu, kosztów i wpływu na biznes.
• Komunikacja: spójne komunikaty dla pracowników, klientów i partnerów oraz kontrola kanałów, aby nie wzmacniać paniki i nie ujawniać informacji operacyjnych.
• Wewnętrzne role: jasne rozdzielenie odpowiedzialności między IT/SecOps, prawnymi, PR i zarządem.

5) Decyzje biznesowo-prawne: minimalny zestaw pytań, które muszą paść

Ransomware zwykle uruchamia ścieżki formalne: obowiązki notyfikacyjne, ocenę ryzyka dla danych, wymogi kontraktowe i ewentualne wymogi ubezpieczyciela. Ten szablon zakłada, że decyzje muszą być udokumentowane i podejmowane w oparciu o wpływ na ciągłość działania, dane oraz ryzyko regulacyjne.

• Zakres i wpływ: jakie procesy biznesowe stoją, jakie dane są dotknięte, jak długo można tolerować niedostępność.
• Ryzyko danych: czy istnieją przesłanki wycieku, jakie są konsekwencje dla osób i organizacji.
• Wymogi formalne: kto zatwierdza komunikację, kiedy uruchamia się ścieżkę prawną, jakie są kryteria notyfikacji.
• Decyzje finansowe: koszty przestoju vs. koszty odzyskiwania, wpływ na reputację, zobowiązania umowne.

6) Utrzymanie playbooków: ćwiczenia, aktualizacje, właściciele i metryki

Playbook ransomware nie może być dokumentem „na półkę”. Skuteczność zależy od tego, czy organizacja potrafi go wykonać pod presją czasu. Dlatego szablon zawiera wymagania dotyczące utrzymania: właścicieli, cyklu przeglądów, testów i pomiaru gotowości. W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

• Właściciele: wskazanie odpowiedzialnych za część techniczną, komunikacyjną i decyzyjną oraz zastępstw na wypadek nieobecności.
• Ćwiczenia: regularne symulacje (tabletop i techniczne) z naciskiem na pierwsze 60–180 minut incydentu oraz na komunikację.
• Aktualizacje: przeglądy po zmianach w M365 (nowe funkcje, zmiany logowania/audytu, nowe integracje) i po każdym realnym incydencie.
• Metryki: czas do detekcji, czas do izolacji, czas do przywrócenia kluczowych usług, liczba kroków wykonywanych „poza procedurą”, jakość dokumentacji osi czasu.

Ten szablon ma prowadzić do dwóch rezultatów: ograniczenia strat w trakcie incydentu oraz zwiększenia odporności po jego zakończeniu, poprzez zamknięcie luk procesowych i technicznych ujawnionych w trakcie zdarzenia.

RStudio: reproducible reports — Quarto vs R Markdown w zespołach analitycznych 16 kwietnia 2026

Jak dobrać typ wykresu do pytania biznesowego: mapa decyzji (z przykładami ‘z życia’) 14 kwietnia 2026