Kradzież ciasteczek i tokenów (session hijacking) zamiast haseł: jak to wykrywać w logach

Dlaczego kradzież cookies i tokenów sesyjnych wypiera kradzież haseł

Przez lata głównym celem atakujących były hasła, bo otwierały drzwi do konta. Dziś coraz częściej bardziej opłaca się przejąć stan zalogowania użytkownika: ciasteczka sesyjne, tokeny dostępu lub tokeny odświeżania. Taki materiał nie jest „sekretem logowania” w klasycznym sensie, tylko dowodem, że logowanie już się odbyło i zostało zaakceptowane przez usługę.

W praktyce przesunięcie to wynika z tego, że wiele organizacji znacząco wzmocniło ochronę haseł (MFA, polityki haseł, blokady, wykrywanie wycieków), natomiast sesja wciąż bywa traktowana jak zaufany kanał po uwierzytelnieniu. Jeśli atakujący przejmie tokeny/cookies, często może korzystać z aplikacji tak, jak legalny użytkownik — bez konieczności ponownego wpisywania hasła.

Hasło vs token/cookie: różnica w tym, co daje atakującemu

• Hasło to materiał do rozpoczęcia logowania. Trzeba je „przeprowadzić” przez mechanizmy kontroli: MFA, ryzyko logowania, reguły dostępu warunkowego, ograniczenia lokalizacji, ograniczenia urządzeń.
• Cookie lub token sesyjny to materiał do kontynuowania już uwierzytelnionej sesji. W wielu scenariuszach pozwala ominąć część kontroli wykonywanych przy samym logowaniu, bo usługa uznaje użytkownika za już zweryfikowanego.

Dlaczego obrona hasła przestała wystarczać

Nawet gdy hasło jest silne i unikalne, a MFA włączone, użytkownik nadal pracuje w przeglądarce lub aplikacji, które przechowują informacje o sesji. Atakujący nie musi więc „wygrać” z hasłem ani z MFA — wystarczy, że przejmie elementy podtrzymujące sesję. To zmienia model ryzyka z „czy ktoś zna mój sekret?” na „czy ktoś może wykorzystać mój aktywny kontekst logowania?”.

Co sprzyja popularności session hijackingu

• Powszechność logowania jednokrotnego (SSO) i federacji: jedna udana sesja daje dostęp do wielu usług, więc przejęcie tokenu jest bardziej opłacalne niż polowanie na kolejne hasła.
• Długotrwałe sesje i wygoda użytkownika: rzadsze ponowne logowania zwiększają okno czasowe, w którym skradzione tokeny mogą być użyteczne.
• Rozbudowane mechanizmy „pamiętaj mnie” i odświeżania sesji: użytkownik może być zalogowany dniami lub tygodniami, a to tworzy atrakcyjny cel.
• Lepsze zabezpieczenia anty-phishingowe dla haseł: menedżery haseł, wykrywanie wycieków, blokady podejrzanych logowań i MFA utrudniają kradzież haseł, więc atakujący wybierają ścieżkę najmniejszego oporu.
• Wartość „gotowej” tożsamości: token bywa przypięty do konkretnego kontekstu (sesji, aplikacji, urządzenia), co ułatwia atakującemu wejście w rolę użytkownika bez wzbudzania podejrzeń na etapie logowania.

Skutki dla wykrywania incydentów

Przy kradzieży hasła często widać klasyczny ślad w postaci nietypowego logowania (nowy adres IP, nowe urządzenie, nieudane próby, wyzwania MFA). Przy kradzieży tokenu/cookie obraz jest inny: atak może wyglądać jak normalna, już trwająca sesja. Dlatego coraz większe znaczenie ma analiza zachowania sesji i jej spójności w czasie — nie tylko samego momentu uwierzytelnienia.

2. Źródła przejętych tokenów: malware/infostealery, proxy phishing (AiTM), złośliwe rozszerzenia i wycieki z przeglądarki

Żeby doszło do przejęcia sesji, atakujący nie musi znać hasła. Wystarczy, że pozyska artefakt sesyjny (np. cookie sesyjne, refresh token, token OAuth, token aplikacyjny) albo możliwość jego „podglądania” w trakcie logowania. Źródła takich tokenów zwykle mieszczą się w czterech kategoriach, które różnią się tym, gdzie następuje kradzież (urządzenie użytkownika vs. kanał komunikacji) oraz jak trwały jest dostęp (jednorazowy zrzut danych vs. stała obserwacja/pośrednictwo). Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity.

Malware i infostealery (kradzież z endpointu)

Najczęstszy model to kradzież tokenów bezpośrednio z komputera użytkownika. Infostealery celują w dane, które przeglądarka i aplikacje przechowują lokalnie lub utrzymują w pamięci podczas aktywnej sesji.

• Co jest przejmowane: cookies sesyjne, tokeny aplikacji w pamięci, tokeny OAuth/SSO, dane z magazynów przeglądarki, czasem także konfiguracje profili i elementy pozwalające odtworzyć „kontekst” sesji.
• Dlaczego to działa: token jest już „po MFA” (użytkownik wcześniej przeszedł uwierzytelnienie), więc jego użycie często nie wymaga ponownego potwierdzenia.
• Charakterystyka ryzyka: infekcja na urządzeniu może dawać atakującemu nie tylko jednorazowy dostęp, ale też cykliczne zrzuty nowych tokenów wraz z ich odświeżaniem.

Proxy phishing / AiTM (kradzież w trakcie logowania)

W ataku typu Adversary-in-the-Middle użytkownik trafia na stronę, która wygląda jak prawdziwy ekran logowania, ale faktycznie działa jako pośrednik między ofiarą a legalnym serwisem. Użytkownik loguje się „naprawdę”, a atakujący przechwytuje rezultat logowania — w tym tokeny/cookies wystawione przez usługę.

• Co jest przejmowane: sesyjne cookies i/lub tokeny wynikowe po udanym logowaniu, czasem także kody jednorazowe (jeśli ofiara je wpisze), ale kluczowe są tokeny sesyjne.
• Dlaczego to omija MFA: MFA jest wykonywane poprawnie, tylko że sesja powstaje w obecności pośrednika, który „zabiera” to, co stanowi dowód uwierzytelnienia.
• Charakterystyka ryzyka: atak nie wymaga malware na urządzeniu; opiera się na nakłonieniu użytkownika do wejścia w kontrolowany przez atakującego przepływ logowania.

Złośliwe lub nadużywające uprawnień rozszerzenia przeglądarki

Rozszerzenia mają dostęp do przeglądarki w sposób, który bywa zbliżony do „legalnego malware” — mogą czytać i modyfikować strony, przechwytywać dane formularzy, a przy szerokich uprawnieniach również obserwować ruch lub dostęp do danych witryn.

• Co jest przejmowane: cookies i tokeny dostępne w kontekście stron, dane wpisywane w formularzach, czasem nagłówki/autoryzacje w żądaniach aplikacji webowych.
• Dlaczego to jest podstępne: rozszerzenie może działać długo i dyskretnie, a użytkownik postrzega je jako „funkcję” przeglądarki (np. tłumacz, menedżer narzędzi).
• Charakterystyka ryzyka: przejęcie może dotyczyć wielu aplikacji jednocześnie, jeśli rozszerzenie ma uprawnienia do „wszystkich witryn” lub wstrzykuje skrypty na wielu domenach.

Wycieki z przeglądarki i warstwy lokalnej (błędy, konfiguracje, kopie danych)

Nie zawsze potrzebny jest aktywny atak w postaci phishingu czy malware. Tokeny potrafią „wyciec” wskutek błędów w aplikacjach, niewłaściwych ustawień środowiska albo niezamierzonych ekspozycji danych lokalnych.

• Typowe źródła: kopie profilu przeglądarki, synchronizacja danych na wielu urządzeniach bez odpowiednich zabezpieczeń, pozostawione sesje na współdzielonych stacjach, przechwycenie plików cache/plików cookie przez inny proces z uprawnieniami, nieostrożne logowanie/diagnostyka po stronie aplikacji lub przeglądarki.
• Dlaczego to bywa niezauważone: nie ma wyraźnego „momentu ataku” (jak kliknięcie w link phishingowy); token zostaje skopiowany lub odczytany jako element danych użytkownika.
• Charakterystyka ryzyka: incydent może mieć charakter punktowy (jedno urządzenie) albo systemowy (błędna polityka, wspólne profile, niekontrolowane narzędzia do zdalnego wsparcia).

Jak odróżnić te źródła na poziomie ogólnej charakterystyki

Te cztery wektory różnią się przede wszystkim tym, czy token jest kradziony z urządzenia (infostealer, rozszerzenie, lokalny wyciek) czy w trakcie logowania i wymiany z usługą (AiTM). W praktyce ma to wpływ na to, czy atak jest jednorazowy czy długotrwały, i czy można go ograniczyć kontrolami na endpointach, politykami przeglądarki, czy mechanizmami ochrony logowania. W kolejnych częściach kluczowe będzie przełożenie tych źródeł na to, jak wyglądają ślady w telemetrii i jakie wzorce nadużyć można wykrywać.

3. Replay sesji krok po kroku: jak działa przejęcie i odtworzenie sesji oraz omijanie MFA

W przejęciu sesji atakujący nie „łamie” hasła ani nie musi przechodzić logowania. Zamiast tego przejmuje artefakty sesji (cookies sesyjne, tokeny dostępu/odświeżania, czasem tokeny urządzenia) i odtwarza je u siebie, by aplikacja uznała go za już uwierzytelnionego użytkownika. Z tego powodu MFA bywa omijane: jeśli MFA zostało spełnione podczas pierwotnej sesji, to replay często korzysta z efektu tej weryfikacji.

Co dokładnie jest „replayowane”

W praktyce spotyka się kilka typów „biletów” do sesji:

• Cookie sesyjne (np. identyfikator sesji) – serwer mapuje je na stan sesji po swojej stronie.
• Token dostępu (access token) – krótkotrwały token używany do wywołań API lub dostępu do zasobów.
• Token odświeżania (refresh token) – pozwala uzyskiwać nowe access tokeny bez ponownego logowania.
• Artefakty kontekstu (np. cookie „remember me”, tokeny „keep me signed in”, identyfikatory urządzenia) – utrwalają zaufanie do przeglądarki/urządzenia.

Replay krok po kroku (wysoki poziom)

• 1) Użytkownik uwierzytelnia się normalnie (hasło + MFA), a aplikacja/IdP wystawia cookies i/lub tokeny.
• 2) Atakujący pozyskuje token/cookie (niezależnie od metody) i utrzymuje go w formie nadającej się do użycia (np. surowy nagłówek Cookie, wyeksportowany zestaw cookies, skopiowany refresh token).
• 3) Import/odtworzenie po stronie atakującego: w przeglądarce, narzędziu automatyzacji lub kliencie API atakujący ustawia przejęte cookies/tokeny tak, by były wysyłane do właściwej domeny/endpointu.
• 4) Pierwsze żądanie „testowe”: atakujący wykonuje żądanie do aplikacji. Jeśli token jest ważny i kontekst jest akceptowalny, serwer uznaje sesję.
• 5) Utrwalenie dostępu: jeśli ma refresh token, może cyklicznie pobierać nowe access tokeny; jeśli ma tylko cookie, może polegać na czasie życia sesji i mechanizmach „sliding session”.
• 6) Działania w sesji: odczyt danych, zmiana ustawień, tworzenie reguł przekierowań, dodanie aplikacji OAuth, pobranie kolejnych danych – wszystko w ramach już „zaufanego” kontekstu.

Dlaczego MFA bywa omijane

MFA najczęściej chroni moment logowania. Replay sesji wykorzystuje fakt, że:

• Sesja jest już po MFA – serwer widzi „ważny token/cookie” i nie pyta ponownie o drugi składnik.
• „Pamiętanie urządzenia” – jeśli użytkownik zaznaczył „zaufaj temu urządzeniu”, część kontroli MFA może zostać pominięta przy odświeżaniu sesji.
• Refresh token potrafi umożliwić długotrwały dostęp bez interakcji użytkownika, dopóki nie zostanie unieważniony lub nie zajdą warunki wymuszające ponowną autoryzację.
• Brak silnego powiązania tokenu z urządzeniem – jeśli token nie jest kryptograficznie „przywiązany” do klienta, może zostać użyty z innej maszyny.

Warianty replay: przeglądarka vs API

Co może przerwać replay (ograniczenia atakującego)

Replay nie jest „magiczny” – bywa blokowany przez mechanizmy związane z kontekstem i czasem życia:

• Wygaśnięcie tokenu/cookie (krótkie lifetime, brak refresh tokenu).
• Unieważnienie sesji po zmianie hasła, wylogowaniu ze wszystkich urządzeń lub ręcznym revoke (zależnie od platformy).
• Weryfikacja kontekstu – silne powiązanie z urządzeniem, kontrola ryzyka, wymuszenie ponownej autoryzacji przy zmianie IP/geo/urządzenia.
• Token binding / proof-of-possession (gdy stosowane) – sam skradziony token nie wystarcza bez klucza po stronie klienta.

Minimalny przykład „replay” na poziomie HTTP (ilustracyjnie)

Poniżej uproszczony schemat użycia przejętego tokenu w wywołaniu API. To przykład pokazujący ideę, a nie konkretną usługę.

GET /api/me HTTP/1.1
Host: service.example
Authorization: Bearer <SKRADZIONY_ACCESS_TOKEN>

W wariancie cookies analogicznie kluczowy jest nagłówek Cookie z wartością skopiowaną z sesji użytkownika.

4. Objawy w logach i telemetrii

Przy session hijackingu napastnik nie musi „zgadnąć” hasła ani przełamywać MFA — korzysta z już uwierzytelnionego kontekstu (cookie sesyjnego, tokenu access/refresh). W logach często wygląda to inaczej niż klasyczne ataki na hasła: mniej nieudanych prób logowania, a więcej anomalii kontekstu sesji (skąd, czym i jak długo użytkownik korzysta). Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — szczególnie gdy pojedynczy sygnał (np. geolokacja) bywa mylący bez korelacji z UA, device_id i współbieżnością.

4.1. „Niemożliwa podróż” (impossible travel)

To wzorzec, w którym dwa zdarzenia dla tego samego konta zachodzą w odstępie czasu niewspółmiernym do fizycznej możliwości przemieszczenia się. W scenariuszu kradzieży tokenu typowe jest:

• Logowanie/aktywność użytkownika z lokalizacji A, a po kilku minutach aktywność z lokalizacji B (inny kraj/kontynent).
• Brak serii błędnych logowań poprzedzających zdarzenie — sesja jest „od razu” ważna.

Uwaga praktyczna: „niemożliwa podróż” bywa fałszywie dodatnia przy VPN, roamingu sieci komórkowej, węzłach egress dostawców chmurowych i środowiskach VDI. Dlatego traktuj ją jako sygnał do korelacji z innymi wskaźnikami (UA, device_id, współbieżność sesji).

4.2. Anomalie geolokacji i atrybutów sieci

Nawet bez „niemożliwej podróży” w przejęciu sesji często widać nietypowe cechy IP i geolokacji:

• Nowy kraj/region dla użytkownika lub nietypowa zmienność kraju w krótkim czasie.
• Nietypowy ASN/ISP (np. nagłe przejście z operatora mobilnego na dostawcę hostingu/centrum danych).
• IP o złej reputacji (w logach bezpieczeństwa jako „risky IP”, „anonymizer”, „proxy”, „TOR” – zależnie od platformy).
• Zmienność adresu IP w trakcie jednej sesji (jeśli system loguje zdarzenia per żądanie/odświeżenie tokenu).

W kontekście token theft kluczowe jest odróżnienie: zmiana IP przy tym samym urządzeniu (często normalne) vs zmiana IP wraz ze zmianą odcisku klienta (częściej podejrzane).

4.3. Zmiana UA/urządzenia (User-Agent, OS, przeglądarka)

Kradzione tokeny/cookies są często odtwarzane na innym kliencie niż oryginalny (inna przeglądarka, inny system). W logach może to wyglądać jak:

• Nagła zmiana przeglądarki (np. Chrome → nieznany/niestandardowy UA) bez logicznego powodu.
• Zmiana systemu (Windows → Linux) lub typu urządzenia (desktop → mobile) w krótkim czasie.
• UA „zbyt generyczny” albo typowy dla narzędzi automatyzacji/klientów bez UI (zależnie od aplikacji).

Niektóre aplikacje SaaS i IdP zapisują „device detail” lub „client app”; jeśli widzisz nową kombinację (OS+browser+device) równolegle z innymi anomaliami, to silny sygnał przejęcia sesji.

4.4. Nowe device_id / brak zgodności urządzenia

Wiele usług buduje trwały identyfikator urządzenia (cookie identyfikujące, device_id, fingerprint, „registered device”). Przy hijackingu token może działać nawet bez „znanego” urządzenia, co daje wzorce:

• Logowanie/aktywność z nowym device_id bez wcześniejszej sekwencji „device registration” lub bez typowej ścieżki dołączenia urządzenia.
• Brak zgodności między device_id a innymi atrybutami (np. ten sam device_id, ale kompletnie inny UA — sygnał, że identyfikacja jest niespójna lub omijana).
• Nagle „unmanaged/unknown device” u użytkownika, który zwykle pracuje z urządzeń zarządzanych.

Ten punkt jest szczególnie użyteczny tam, gdzie organizacja ma silną bazę „znanych urządzeń” — wtedy nowy identyfikator jest bardziej znaczący niż sama geolokacja.

4.5. Równoległe sesje i współbieżność

Odtworzenie przejętej sesji często nie kończy sesji ofiary. W logach warto szukać:

• Dwóch aktywnych sesji dla tego samego konta w tym samym czasie z różnych IP/UA/krajów.
• Nakładających się okien aktywności: ofiara pracuje normalnie, a obok pojawiają się działania administracyjne, eksport danych lub masowe odczyty.
• Nienaturalnych „burstów” aktywności (wiele operacji w krótkim czasie), gdy użytkownik jest równolegle aktywny w innym kontekście.

W odróżnieniu od zwykłego „logowania z telefonu i laptopa”, tu różnice w kontekście są ostre (inne kraje/UA/ASN) i pojawiają się bez przewidywalnego wzorca.

4.6. Nietypowe odświeżenia tokenów i zachowanie sesji

Jeśli platforma loguje zdarzenia związane z tokenami (np. refresh, re-issue, silent auth), można zauważyć subtelne sygnały:

• Odświeżenia tokenu z nowego IP/UA bez odpowiadającego im interaktywnego logowania.
• Zbyt częste odświeżenia (krótsze odstępy niż typowe dla aplikacji/użytkownika).
• Długie utrzymywanie sesji mimo braku normalnej aktywności użytkownika (tzw. „quiet persistence”).
• Nietypowe sekwencje: refresh połączony natychmiast z pobraniem dużej ilości danych albo zmianą ustawień bezpieczeństwa.

To odróżnia część ataków tokenowych od klasycznych prób logowania: widzisz kontynuację uprawnień bez „punktu wejścia” w postaci nowego logowania interaktywnego.

4.7. Szybka mapa sygnałów: co wskazuje na hijacking, a co bywa normalne

4.8. Minimalny wzorzec korelacji (praktyczny)

Najbardziej użyteczne są reguły, które łączą sygnały zamiast polegać na jednym. Przykładowo: „nowy kraj i nowy UA i współbieżność sesji” ma zwykle wyższą jakość niż sama geolokacja. Poniżej pseudowzorzec do myślenia o korelacji (niezależny od konkretnej platformy):

IF same_user AND time_window < 30m
  AND (geo_changed OR asn_changed)
  AND (ua_changed OR device_id_new)
  AND (concurrent_sessions OR token_refresh_without_interactive_signin)
THEN raise_high_confidence_session_hijack_alert

W kolejnych krokach (w zależności od stosu) dopiero dobiera się konkretne źródła logów i pola, które odpowiadają powyższym pojęciom.

5. Przykłady detekcji w M365/Azure AD (Entra): Sign-in logs, Audit logs, Conditional Access, Identity Protection i korelacja zdarzeń

W środowisku Microsoft 365/Entra kradzież tokenów i „replay” sesji rzadko daje w logach prosty sygnał w stylu „złe hasło”. Zamiast tego ślady są rozproszone: w Sign-in logs (kto i skąd uzyskał token), Audit logs (co zmieniono w konfiguracji i tożsamości), decyzjach Conditional Access (dlaczego dostęp był dozwolony/utrudniony) oraz w sygnałach Identity Protection (czy sesja wygląda na ryzykowną). Poniżej są praktyczne przykłady, co i gdzie obserwować oraz jak łączyć te źródła.

Gdzie szukać: rola poszczególnych źródeł

Przykłady obserwacji w Sign-in logs (Entra)

• Niespójność kontekstu logowania: w krótkim oknie czasu pojawiają się logowania tego samego użytkownika do tej samej aplikacji, ale z różnym IP/regionem lub inną charakterystyką klienta (np. inny typ klienta: browser vs. mobile/desktop).
• „Zbyt czyste” logowanie: sukces logowania bez wyzwania MFA w sytuacji, gdzie zwykle było wymagane (warto zestawić z politykami CA zastosowanymi do zdarzenia).
• Nietypowa aplikacja docelowa: po jednorazowym logowaniu następuje kaskada dostępów do wielu aplikacji (szczególnie administracyjnych) bez typowej sekwencji użytkownika.
• Anomalie w polach urządzenia: nagłe pojawienie się innego device detail (system/typ urządzenia), brak spodziewanych atrybutów urządzenia lub niespodziewana zmiana tego, jak klient jest identyfikowany.
• Wzorce „token-driven”: wiele zdarzeń dostępu bez błędów haseł i bez serii prób logowania — typowe dla sytuacji, gdy napastnik nie zgaduje hasła, tylko używa już ważnego tokenu/sesji.

Audit logs: detekcja „utrzymania dostępu” po przejęciu sesji

Przejęta sesja bywa używana nie tylko do odczytu danych, ale też do utrwalenia dostępu. Dlatego w Audit logs warto szukać zmian, które w normalnym procesie wymagają silnego uzasadnienia biznesowego.

• Zmiany w metodach uwierzytelniania: dodanie nowej metody MFA, zmiana numeru/urządzenia, rejestracja nowego urządzenia do uwierzytelniania.
• Zmiany w tożsamości: reset hasła, wyłączenie wymagań, zmiana właściwości użytkownika wpływających na dostęp.
• Zmiany uprawnień: przypisanie ról, dodanie do uprzywilejowanych grup, nadanie zgód aplikacjom.
• Zmiany w aplikacjach i zgodach: tworzenie/rejestracja aplikacji, modyfikacja uprawnień API, udzielenie admin consent (często używane do utrzymania dostępu poza sesją).
• Zmiany w Conditional Access: wyłączenie polityk, dodanie wyjątków (exclude), osłabienie wymagań urządzenia lub MFA.

Conditional Access: jak czytać decyzje polityk pod kątem przejętej sesji

Conditional Access nie jest tylko „barierą”, ale też źródłem sygnału diagnostycznego: pozwala zrozumieć, dlaczego dane logowanie przeszło. W kontekście session hijackingu szczególnie ważne są rozbieżności między tym, co organizacja uważa za standard, a tym, co widać w zastosowanych kontrolach.

• Polityki nie zastosowały się: zdarzenie ma status, że CA nie zadziałał (np. przez zakres aplikacji, wyjątki, warunki) — do weryfikacji, czy nie jest to błąd konfiguracji lub celowe osłabienie.
• Inne kontrole niż zwykle: np. brak wymogu „compliant device” lub brak MFA w scenariuszu, w którym zwykle występowały.
• Różnice zależne od aplikacji: logowanie do jednej aplikacji jest objęte restrykcjami, a do innej (równie wrażliwej) już nie — napastnicy często wybierają najsłabszy punkt wejścia.

Identity Protection: sygnały ryzyka i ich użyteczność

Identity Protection agreguje wykrycia ryzyka i jest praktycznym „filtem priorytetu” dla zdarzeń, które mogą wynikać z przejęcia sesji. W detekcji ważna jest nie tylko obecność ryzyka, ale też to, czy jest ono skorelowane czasowo z konkretnym logowaniem i późniejszą aktywnością w usługach M365.

• Sign-in risk / user risk: podwyższenie ryzyka w pobliżu czasowym podejrzanego logowania zwiększa prawdopodobieństwo, że to nie jest fałszywy alarm.
• Zdarzenia o nietypowych właściwościach: wykrycia wskazujące na anomalie kontekstu logowania (np. nietypowa lokalizacja, podejrzane cechy klienta).
• Ryzyko vs. CA: jeśli CA nie blokuje logowań podwyższonego ryzyka, jest to sygnał do przeglądu polityk oraz detekcji „policy gap”.

Korelacja: jak połączyć sign-in z działaniami w M365

Najbardziej użyteczna detekcja to taka, która łączy wejście (Sign-in) ze skutkiem (działania w poczcie, plikach, administracji). Korelacja nie musi być skomplikowana: często wystarczy spójność czasu, użytkownika oraz aplikacji/zasobu.

• Łańcuch „sign-in → aktywność”: podejrzane logowanie do Exchange/SharePoint/Graph, a następnie nietypowe akcje (np. masowe pobrania, eksporty, zmiany reguł poczty) w krótkim czasie.
• Łańcuch „sign-in → zmiana zabezpieczeń”: podejrzane logowanie, po którym pojawia się zdarzenie w Audit logs typu dodanie metody MFA, zmiana CA, nadanie roli.
• Łańcuch „ryzyko → dostęp”: Identity Protection podnosi ryzyko, ale logowania nadal są skuteczne — wskazuje to na potrzebę alertowania nawet bez błędów logowania.

Minimalny przykład zapytania (KQL) do wstępnej korelacji

Poniższy przykład pokazuje prostą korelację „podejrzane logowania z nowego IP” z następującą po nich aktywnością w M365 (na poziomie koncepcji). W praktyce nazwy tabel i dostępność zależą od tego, gdzie kierujesz logi (np. Microsoft Sentinel/Log Analytics) i jakie konektory są włączone.

// Koncepcyjny przykład: korelacja sign-in z późniejszą aktywnością
let window = 30m;
let SuspiciousSignIns = SigninLogs
| where ResultType == 0
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), IPs=make_set(IPAddress) by UserPrincipalName
| where array_length(IPs) > 1; // uproszczenie: wiele IP w krótkim okresie
SuspiciousSignIns
| join kind=inner (
    OfficeActivity
    | project TimeGenerated, UserId, Operation, Workload
) on $left.UserPrincipalName == $right.UserId
| where OfficeActivity.TimeGenerated between (FirstSeen .. LastSeen + window)
| project UserPrincipalName, FirstSeen, LastSeen, IPs, Operation, Workload, OfficeActivity.TimeGenerated
| order by OfficeActivity_TimeGenerated desc

W tej sekcji kluczowe jest rozróżnienie: Sign-in logs mówią „jak i skąd uzyskano dostęp”, Audit logs i Unified Audit Log mówią „co zrobiono”, a Conditional Access i Identity Protection odpowiadają „dlaczego to przeszło i czy wygląda ryzykownie”. Taki podział ułatwia budowę detekcji ukierunkowanych na przejęcie sesji, a nie na błędne hasła.

6. Przykłady detekcji w Google Workspace i typowych aplikacjach SaaS

W Google Workspace i większości SaaS przejęcie sesji rzadko wygląda jak „złe hasło”. Częściej przypomina poprawne logowanie i normalną pracę, tylko wykonywaną z nietypowego kontekstu (inne urządzenie, sieć, lokalizacja) albo przez token/OAuth zamiast interaktywnego sign-in. Dlatego detekcja opiera się na łączeniu kilku sygnałów: logów logowania, zdarzeń sesji, aktywności w aplikacji i zmian w konfiguracji.

Gdzie szukać śladów w Google Workspace

• Admin Console → Reports → Audit & Investigation: centralne miejsce do korelacji (logowania, aktywności, zdarzenia administracyjne).
• Login audit: zdarzenia logowania, metadane o kliencie (IP, user agent/typ klienta), wynik, wymuszenia zasad.
• Token/OAuth audit: nadania/odwołania dostępu aplikacjom, zgody OAuth, użycie tokenów w kontekście API.
• Drive/Gmail/Calendar audit: nietypowe operacje na danych po „pozornie prawidłowym” logowaniu (masowe pobrania, eksporty, przekierowania, reguły).
• Alert Center: wbudowane alerty (m.in. podejrzane logowania, podejrzane aplikacje, zmiany bezpieczeństwa) jako szybki punkt zaczepienia do dochodzenia.

Logi dostępu i sesji: na co patrzeć

W kontekście session hijacking kluczowe jest rozróżnienie „kto” (konto), „czym” (typ klienta: przeglądarka, aplikacja mobilna, IMAP/SMTP, API), „skąd” (IP/ASN/geo) i „jak długo/ciągle” (ciągłość sesji i jej odświeżenia).

• Nagłe przełączenie typu klienta (np. z przeglądarki na „less secure”/legacy protokoły lub odwrotnie) bez uzasadnienia biznesowego.
• Zmiana właściwości klienta w krótkim czasie: inny user agent, inna platforma/urządzenie, inna sieć (zwłaszcza nietypowe ASN lub hosting/VPN).
• Równoległe użycie: aktywność z dwóch różnych środowisk w tym samym oknie czasowym (np. interaktywne użycie Gmaila + równoległe masowe akcje przez API).
• Wzorce „cichej” aktywności: brak typowych kliknięć użytkownika, a pojawiają się akcje eksportu, udostępnień, zmian reguł, tworzenia filtrów, pobrań plików.

OAuth i tokeny: typowe wzorce nadużyć w SaaS

W wielu SaaS (w tym w ekosystemie Google) atakujący chętnie omijają klasyczne logowanie, przechodząc na OAuth i dostęp przez API. To nie zawsze jest kradzież „cookies” w sensie przeglądarkowym, ale efekt dla obrońcy bywa podobny: stały dostęp bez ponownego uwierzytelnienia.

• Nowa zgoda OAuth dla aplikacji z szerokimi zakresami (np. pełny dostęp do poczty/Drive) nadana nagle użytkownikowi, który zwykle nie integruje narzędzi.
• Nietypowa aplikacja OAuth: świeżo utworzony klient, nieoczekiwany wydawca, zgody nadawane wielu użytkownikom w krótkim czasie.
• Skoki w użyciu API: duża liczba wywołań, masowe „list/get/export”, działania hurtowe na plikach lub wiadomościach.
• Utrzymanie dostępu: rzadkie interaktywne logowania, ale stała aktywność przez tokeny (np. okresowe pobrania, odczyty, wysyłki).

Alerty bezpieczeństwa: co wykorzystać jako „trigger”

W praktyce warto traktować Alert Center jako mechanizm wyzwalający dochodzenie, a nie jedyne źródło prawdy. Najbardziej użyteczne są alerty, które wskazują anomalię kontekstu lub zmiany zwiększające utrzymanie dostępu.

• Podejrzane logowanie lub logowanie z nietypowej lokalizacji/IP.
• Alerty o aplikacjach: nietypowe zgody OAuth, ryzykowne aplikacje, wzrost użycia API.
• Alerty o poczcie: podejrzane reguły/filtry, przekierowania, zmiany ustawień, które sugerują utrzymanie dostępu lub eksfiltrację.
• Zmiany administracyjne dot. bezpieczeństwa (np. polityki dostępu, wyłączenia kontroli), jeśli model uprawnień pozwala użytkownikowi/atakującemu na takie operacje.

Przykładowe korelacje (Google Workspace + SaaS)

Najlepsze wyniki daje prosta korelacja „logowanie/zgoda” → „akcje na danych” w krótkim czasie. Poniższe przykłady są celowo ogólne, aby pasowały do różnych środowisk SaaS.

• Login anomaly (nowe IP/geo/UA) + masowe operacje w Drive/Gmail w ciągu 15–60 minut.
• Nowa zgoda OAuth + natychmiastowy wzrost użycia API (pobieranie/eksport/odczyt wielu zasobów).
• Interaktywne logowanie bez widocznej aktywności użytkownika + działania „konfiguracyjne” (filtry, forwarding, udostępnienia, delegacje).
• Zmiana kontekstu sesji (inna sieć/urządzenie) + równoległe działania z dotychczasowego środowiska (sygnał współdzielenia/kradzieży tokenu).

Tabela: szybkie mapowanie sygnałów do źródeł danych

Minimalny przykład zapytania/filtru (orientacyjnie)

W wielu systemach (w tym w narzędziach dochodzeniowych Google) praktyczny jest filtr: „anomalie logowania” połączone z „wysokim wolumenem działań”. Poniżej ogólny pseudofilter, który można przełożyć na UI/eksport do SIEM.

(event_type in [LOGIN, OAUTH_GRANT])
AND (ip_reputation = "suspicious" OR geo_change = true OR ua_change = true)
THEN
  correlate next 60m with (event_type in [DRIVE_DOWNLOAD, DRIVE_EXPORT, GMAIL_SETTINGS_CHANGE, API_CALL])
  where volume > baseline(user, 30d) * 3

Najważniejsze w Google Workspace i typowych SaaS jest to, że detekcja przejęcia sesji rzadko wynika z jednego wpisu w logach. Skuteczność rośnie, gdy traktujesz logowanie/OAuth jako punkt startowy, a potem sprawdzasz, czy następują po nim działania niepasujące do profilu użytkownika lub typowego sposobu użycia aplikacji.

7. Checklist prewencji: Conditional Access, FIDO2/passkeys, polityki sesji i token lifetime, Continuous Access Evaluation, hardening przeglądarek i EDR

Jeśli atakujący kradnie cookies lub tokeny sesyjne, „poprawne” hasło i nawet MFA mogą przestać mieć znaczenie, bo napastnik nie musi logować się od zera — może kontynuować istniejącą sesję. Prewencja powinna więc ograniczać wartość skradzionej sesji (krótszy czas życia, częstsza weryfikacja, wiązanie z urządzeniem), zmniejszać szanse kradzieży (hardening stacji roboczej i przeglądarki) oraz przyspieszać unieważnianie tokenów po wykryciu ryzyka.

Checklist działań (priorytetyzowany)

• Wymuś uwierzytelnianie odporne na phishing (FIDO2 / passkeys) wszędzie, gdzie to możliwe
  • Traktuj je jako domyślny standard dla kont uprzywilejowanych i użytkowników o podwyższonym ryzyku.
  • Cel: ograniczyć skuteczność klasycznego phishingu i części scenariuszy AiTM, które bazują na „przechwyceniu” interakcji użytkownika.
• Conditional Access / polityki dostępu: ogranicz „gdzie” i „z czego” wolno tworzyć oraz utrzymywać sesję
  • Wymagaj dostępu z urządzeń zarządzanych i zgodnych (MDM/EDR), a nie z dowolnej przeglądarki.
  • Stosuj warunki oparte o ryzyko (użytkownika/logowania), lokalizację, sieć, typ klienta oraz czułość aplikacji.
  • Blokuj lub ograniczaj logowania z nietypowych krajów/regionów i z anonimowych sieci, jeśli nie są biznesowo uzasadnione.
  • Cel: nawet jeśli token wycieknie, trudniej go użyć poza dozwolonym kontekstem.
• Polityki sesji i „token lifetime”: skróć okno nadużycia i wymuś częstsze „re-check”
  • Ustal krótsze czasy trwania sesji dla aplikacji wrażliwych, administracji oraz dostępu spoza sieci zaufanej.
  • Wymuszaj częstsze ponowne uwierzytelnienie dla operacji wysokiego ryzyka (np. zmiany ustawień bezpieczeństwa, eksport danych).
  • Unikaj zbyt długich „pamiętaj mnie”/persistent sessions tam, gdzie ryzyko przejęcia stacji roboczej jest realne.
  • Cel: skradziony token traci wartość szybciej, a atakujący ma mniej czasu na działania.
• Continuous Access Evaluation (CAE) i szybkie unieważnianie sesji
  • Włącz mechanizmy, które potrafią w trakcie trwania sesji wymusić ponowną weryfikację lub odciąć dostęp po zmianie poziomu ryzyka.
  • Zapewnij procedury „kill switch”: masowe wylogowanie, reset sesji, odwołanie refresh tokenów dla konta lub całej grupy.
  • Cel: ograniczyć skuteczność replay — nie czekać, aż token „sam wygaśnie”.
• Hardening przeglądarek: zmniejsz powierzchnię kradzieży cookies i tokenów
  • Standaryzuj przeglądarkę i konfigurację: aktualizacje, polityki bezpieczeństwa, kontrola funkcji ryzykownych.
  • Ogranicz rozszerzenia do listy dozwolonej; blokuj instalację nieautoryzowanych dodatków.
  • Izoluj profile przeglądarki używane do pracy (oddzielnie od prywatnych) i rozważ tryby/rozwiązania z izolacją (np. profile zarządzane).
  • Cel: utrudnić wyciek danych sesyjnych przez złośliwe dodatki, cache, niekontrolowane profile lub podatności.
• EDR i higiena stacji roboczej: minimalizuj ryzyko infostealerów
  • Utrzymuj EDR z aktywną ochroną przed kradzieżą danych przeglądarki, podejrzanymi procesami i exfiltracją.
  • Stosuj kontrolę aplikacji (allowlist), blokuj uruchamianie z nietypowych lokalizacji (np. katalogi profilu użytkownika) i ogranicz makra/skrypty tam, gdzie to możliwe.
  • Dbaj o szybkie aktualizacje systemu i aplikacji oraz podstawowe wzmocnienie (np. minimalne uprawnienia, separacja kont admin/user).
  • Cel: infostealer najczęściej kradnie sesje „u źródła” — z zainfekowanej stacji.
• Ochrona kont uprzywilejowanych
  • Oddziel konta administracyjne od użytkowych, ogranicz ich użycie do dedykowanych urządzeń i kontekstów.
  • Wymuś na nich najsilniejsze metody uwierzytelniania oraz najsurowsze polityki sesji.
  • Cel: przejęcie sesji admina ma nieproporcjonalnie duży wpływ — tu „pas bezpieczeństwa” musi być podwójny.
• Świadomość użytkowników ukierunkowana na sesje (nie tylko na hasła)
  • Ucz rozpoznawania proxy-phishingu i nietypowych promptów logowania, ale także ryzyk instalacji „przydatnych” rozszerzeń i uruchamiania plików z nieznanych źródeł.
  • Promuj zasady: osobny profil do pracy, aktualizacje, zgłaszanie podejrzanych zachowań przeglądarki.
  • Cel: wiele przejęć tokenów zaczyna się od prostych, „użytkowych” błędów na endpointach.

Minimalny zestaw na start: FIDO2/passkeys dla kluczowych ról, Conditional Access wymagający urządzeń zarządzanych, sensowne limity sesji, CAE/reakcja na ryzyko oraz twarde polityki przeglądarki i EDR. Ten zestaw nie eliminuje wszystkich ataków, ale znacząco zmniejsza opłacalność kradzieży cookies i tokenów oraz skraca czas, w którym przejęta sesja jest użyteczna.

8. Procedura triage incydentu: potwierdzenie, zakres, unieważnienie sesji/tokenów, odzyskanie kontroli i działania poincydentowe

Triage w incydencie przejęcia sesji (kradzieży cookies/tokenów) ma inny priorytet niż przy kradzieży hasła: kluczowe jest natychmiastowe przerwanie aktywnych sesji i odcięcie tokenów, a dopiero potem porządkowanie tożsamości i urządzeń. Poniżej znajduje się praktyczna sekwencja działań, która minimalizuje czas „okna nadużycia”, a jednocześnie pozwala zebrać dowody i zrozumieć zakres.

8.1. Potwierdzenie: czy to faktycznie przejęcie sesji?

• Zbierz minimalny zestaw faktów: który użytkownik, jakie aplikacje/SaaS, kiedy wystąpiły podejrzane logowania lub akcje, jakie objawy (np. równoległe sesje, nowe urządzenie, nietypowe odświeżenia sesji).
• Zweryfikuj spójność sygnałów: czy zdarzenia wskazują na użycie istniejącej sesji (ciągłość tokenu/sesji) zamiast klasycznego logowania hasłem. Szukaj sytuacji, gdzie „logowanie” wygląda normalnie, ale kontekst urządzenia/lokalizacji jest anomalią.
• Odróżnij od fałszywych alarmów: podróże służbowe, VPN, bramki bezpieczeństwa, automatyzacje API, zmiany przeglądarki po aktualizacji. Jeśli ryzyko jest wysokie, traktuj przypadek jako incydent i przejdź do izolacji.

8.2. Szybkie zabezpieczenie: przerwij dostęp zanim będziesz mieć pełny obraz

• Unieważnij aktywne sesje użytkownika w kluczowych aplikacjach (szczególnie tam, gdzie istnieją długie sesje przeglądarkowe). To najczęściej najszybszy sposób na zatrzymanie atakującego.
• Odetnij tokeny odświeżania / tokeny długoterminowe (jeśli używane): w praktyce to one utrzymują dostęp mimo zmiany hasła.
• Tymczasowo podnieś wymagania dostępu: wymuś ponowną weryfikację, włącz bardziej restrykcyjne warunki dostępu dla konta (np. blokada dostępu spoza zaufanych lokalizacji/urządzeń) na czas triage.
• W razie aktywnego nadużycia (np. masowe pobieranie danych, zmiany reguł poczty): rozważ krótkotrwałe zablokowanie konta do czasu zatrzymania eskalacji.

8.3. Ustalenie zakresu: gdzie i jak daleko sięga przejęcie

• Określ linię czasu: od pierwszego podejrzanego zdarzenia do momentu odcięcia sesji. To wyznacza zakres analizy i poszukiwania skutków.
• Sprawdź wszystkie kanały dostępu: przeglądarka, aplikacje mobilne, klienci poczty, integracje OAuth, aplikacje firm trzecich, tokeny API. Przejęcie sesji w jednym miejscu może umożliwić nadanie uprawnień gdzie indziej.
• Zidentyfikuj dotknięte zasoby: poczta (przekierowania, reguły), pliki (udostępnienia, pobrania), aplikacje (nowe integracje), katalog/tożsamość (zmiany metod MFA, dodane urządzenia, zmiany ról).
• Oceń ryzyko lateral movement: czy konto ma dostęp do danych wrażliwych, paneli administracyjnych, narzędzi DevOps, systemów finansowych. Im wyższe uprawnienia, tym większy priorytet forensyki i komunikacji.

8.4. Odzyskanie kontroli: nie tylko hasło

• Reset hasła traktuj jako element pomocniczy, a nie główne remedium; jeśli tokeny/sesje są ważne, samo hasło nie wystarczy.
• Wymuś ponowną rejestrację silnych metod uwierzytelniania (np. klucze sprzętowe/passkeys) oraz usuń podejrzane lub nieznane metody odzyskiwania dostępu.
• Usuń nieautoryzowane integracje: cofnięcie zgód aplikacji, odpięcie podejrzanych aplikacji firm trzecich, rotacja kluczy/sekretów aplikacji, jeśli były dostępne dla atakującego.
• Sprawdź i cofnij zmiany konfiguracji: reguły skrzynki, przekierowania, delegacje, uprawnienia do plików, nowe konta/urządzenia powiązane z tożsamością.

8.5. Weryfikacja punktu wejścia: token skądś się wziął

• Oceń stan urządzenia końcowego: jeśli token został skradziony z przeglądarki, najczęściej źródłem jest zainfekowane urządzenie lub złośliwy komponent (np. rozszerzenie). W razie podejrzeń priorytetem jest izolacja i analiza endpointu.
• Sprawdź, czy incydent jest powtarzalny: jeżeli po unieważnieniu sesji sytuacja szybko wraca, źródło (np. malware) nadal działa albo istnieje trwały mechanizm odzyskiwania dostępu.
• Zabezpiecz artefakty do analizy: informacje o urządzeniu, przeglądarce, rozszerzeniach, podejrzanych procesach, a także zdarzenia z systemów ochrony. Unikaj działań, które zacierają ślady zanim zostaną zebrane podstawowe dane.

8.6. Działania poincydentowe: zamknięcie luk i ograniczenie skutków

• Ocena wpływu na dane: ustal, czy doszło do nieautoryzowanego odczytu/eksfiltracji (w szczególności plików i poczty) oraz jakie informacje mogły zostać ujawnione.
• Komunikacja i obowiązki formalne: zgodnie z polityką organizacji ustal, kogo informować (IT, bezpieczeństwo, właściciele danych, prawny/RODO), i w jakim trybie prowadzić notyfikacje.
• Wzmocnienie kontroli dostępu: po incydencie zaktualizuj zasady sesji, wymagania urządzeń, ograniczenia geograficzne oraz zasady dla aplikacji firm trzecich tak, by podobne przejęcie było krótsze i mniej skuteczne.
• Retrospektywa detekcji: sprawdź, które sygnały były dostępne wcześniej i dlaczego nie zadziałały. Ustal minimalne alerty/monitoring, które przyspieszą wykrycie ponownego użycia sesji.
• Higiena tożsamości: uporządkuj uprawnienia, usuń zbędne role, potwierdź własność kluczowych kont i wprowadź wymagania dla kont uprzywilejowanych.

Najważniejsza zasada triage przy przejęciu sesji brzmi: najpierw przerwij sesje i odetnij tokeny, następnie cofnij skutki i usuń mechanizm pozyskania tokenu. Tylko takie podejście skraca czas nadużycia i zmniejsza ryzyko ponownego przejęcia.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

ThinkCell vs PowerPoint Add-ins 2026: 9 różnic, które widać dopiero w dużych deckach 24 marca 2026

Ataki na chain-of-trust w przeglądarce: fałszywe rozszerzenia, OAuth i przejęcia sesji (case’y 2025/26) 22 marca 2026