CrowdStrike 2026: AI, Tożsamość I Nowe Ataki

Rok niewidzialnego przeciwnika: czego raport CrowdStrike 2026 uczy o AI, tożsamości i nowych ścieżkach ataku

Zobaczmy, co się dzieje, gdy napastnik nie wrzuca EXE na stację, nie zostawia klasycznego droppera i nie wygląda jak ktoś, kto właśnie „wszedł do środka”. Dzwoni na help desk. Resetuje hasło. Rejestruje urządzenie w chmurze. Przegląda SharePointa. Odpala tymczasową VM-kę w vCenter. A potem szyfruje dane z boku przez SMB albo wyciąga je przez legalny kanał SaaS. Właśnie dlatego raport CrowdStrike 2026 Global Threat Report warto czytać nie jako kolejną publikację „o AI”, tylko jako opis zmiany modelu ataku.

CrowdStrike pokazuje, że w 2025 roku średni eCrime breakout time spadł do 29 minut, najszybszy odnotowany przypadek trwał 27 sekund, 82% detekcji było malware-free, ataki prowadzone przez aktorów wykorzystujących AI wzrosły o 89% r/r, intruzje cloud-conscious wzrosły o 37%, a wykorzystanie zero-dayów przed publicznym disclosure wzrosło o 42%. To nie jest kosmetyka. To jest zmiana tempa i zmiana pola walki.

Raport o AI? Tak. Ale przede wszystkim o zaufaniu

Najłatwiej byłoby streścić ten raport jednym hasłem: „AI weszło do cyberataków”. Tyle że to byłoby spłycenie tematu.

W praktyce raport CrowdStrike mówi o czymś innym. O tym, że przeciwnik coraz rzadziej musi atakować „wbrew systemowi”. Coraz częściej działa przez system. Przez legalne konta, zaufane integracje, federację tożsamości, SaaS, edge devices, partner relationships i software supply chain. CrowdStrike nazywa 2025 rokiem evasive adversary i to jest dużo lepszy punkt wyjścia niż sam nagłówek o AI.

To ważna różnica. Bo jeśli obrońca myśli kategoriami „szukam malware”, a przeciwnik działa kategoriami „nadużywam zaufania”, to obie strony grają już w dwie różne gry.

Trzeba też uczciwie dodać jedną rzecz: to jest raport vendora. Bardzo wartościowy, bo oparty o dużą telemetrię i realne incydenty, ale nadal vendorowy. Czyli świetny do wyciągania trendów, trochę słabszy jako absolutna mapa całego internetu. Tę poprawkę warto mieć w głowie od pierwszego akapitu.

Od pliku na dysku do sesji w chmurze

Jeszcze kilka lat temu centrum ciężkości dyskusji o intruzji było proste: jaki malware, jaki hash, jaki loader, jaki beacon. Dziś dużo ważniejsze staje się pytanie: jakie konto, jaki token, jaki flow uwierzytelniania, jaka usługa i jaka ścieżka zaufania.

Na stronie 9 raportu CrowdStrike zbiera liczby, które dobrze oddają ten zwrot: 82% detekcji było malware-free, valid account abuse odpowiadał za 35% incydentów chmurowych, a 37% wzrost cloud-conscious intrusions pokazuje, że przeciwnik nie widzi już chmury jako dodatku do infrastruktury. On widzi ją jako naturalną drogę ruchu bocznego, eksfiltracji i utrzymania dostępu.

Ta zmiana świetnie wybrzmiewa w case study CHATTY SPIDER. W jednym z opisanych incydentów atakujący przekonał ofiarę do udzielenia dostępu przez Microsoft Quick Assist, pobrał WinSCP i w ciągu czterech minut od initial access rozpoczął próbę eksfiltracji danych. Gdy jedna ścieżka została zablokowana, szybko przeszedł na Google Drive. To nie był spektakularny exploit. To była bardzo sprawna, bardzo szybka operacja na legalnych narzędziach.

W realnym SOC takie zdarzenia często wyglądają niewinnie, dopóki ktoś nie sklei ich w jedną historię.

Przykład syntetycznego łańcucha zdarzeń z EDR/Sysmon:

2026-01-03T10:14:21Z HOST=WS-441 USER=j.kowalski PROC=QuickAssist.exe PARENT=explorer.exe
2026-01-03T10:16:45Z HOST=WS-441 USER=j.kowalski PROC=WinSCP.exe PARENT=QuickAssist.exe
2026-01-03T10:17:11Z HOST=WS-441 USER=j.kowalski DNS=drive.google.com PROC=chrome.exe
2026-01-03T10:17:39Z HOST=WS-441 USER=j.kowalski FILE_ACCESS=\\filesrv01\legal\*.pdf

Każda linia osobno może wyglądać jak „ktoś pracuje zdalnie”. Razem zaczynają wyglądać jak incydent.

I to jest jedna z najważniejszych lekcji z raportu: dzisiejszy przeciwnik nie musi być niewidzialny. Wystarczy, że przez kilka minut wygląda normalnie.

AI to akcelerator, nie cudowna nowa klasa ataku

Raport CrowdStrike mocno podkreśla wzrost aktywności aktorów wykorzystujących AI. Liczba takich ataków wzrosła o 89% rok do roku, a w cyberprzestępczych forach najczęściej przewijały się wzmianki o komercyjnych modelach, takich jak ChatGPT, Gemini, Claude czy Grok. Jednocześnie sam raport stawia ważną tezę: dziś AI przede wszystkim wzmacnia istniejące TTP, zamiast tworzyć całkowicie nowy model ataku.

To widać na trzech poziomach.

AI pomaga w socjotechnice

Tu zmiana jest najbardziej praktyczna. Lepsze lury. Lepsze tłumaczenia. Większa skala. Szybsze przygotowanie person i wiadomości. CrowdStrike opisuje choćby FAMOUS CHOLLIMA, które wykorzystywało wiele narzędzi AI do tworzenia fałszywych person, obsługi wielu kont i wspierania oszustw rekrutacyjnych, oraz RENAISSANCE SPIDER, które używało AI do tłumaczenia przynęt typu ClickFix na język ukraiński.

AI pomaga w pracy technicznej po kompromitacji

To już bardziej inżynierska warstwa. Pisanie skryptów, dostosowywanie malware, automatyzacja discovery, credential dumping, niszczenie artefaktów, praca na nietypowych formatach plików czy generowanie kodu do post-exploitation. Raport wskazuje tu m.in. PUNK SPIDER, ODYSSEY SPIDER oraz malware LAMEHUG używany przez FANCY BEAR, które integrowało LLM do prostych zadań rozpoznawczych i kolekcjonowania dokumentów.

AI samo staje się celem

To fragment raportu, który zasługuje na więcej uwagi niż zwykle dostaje. CrowdStrike opisuje m.in. nadużycia związane z platformami AI, prompt injection, złośliwe serwery MCP i wykorzystanie zaufania do narzędzi AI jako nowej powierzchni ataku. To ważne, bo pokazuje, że AI jest jednocześnie:

• narzędziem napastnika,
• celem napastnika,
• i przynętą na użytkownika.

W praktyce obrony to oznacza prostą rzecz: problemem nie jest już tylko „czy pracownik korzysta z AI”, ale jakie dane wkłada do modelu, jakie integracje ma ten model, jaki ma zakres uprawnień i czy ktoś nie próbuje manipulować jego inputem.

Przykład bezpiecznego testu dla zespołu bezpieczeństwa
Jeśli organizacja używa AI do triage wiadomości lub klasyfikacji zgłoszeń, warto sprawdzić, czy pipeline usuwa ukryty HTML, komentarze i nietekstowe artefakty zanim model podejmie decyzję. To nie jest temat futurystyczny. To zwykła higiena przetwarzania wejścia.

Tożsamość stała się główną powierzchnią ataku

W raporcie CrowdStrike tożsamość przewija się praktycznie wszędzie. W części cloudowej pada jeden z ważniejszych wskaźników: valid account abuse odpowiadał za 35% incydentów chmurowych. W praktyce to znaczy, że konto, token, federacja i mechanizmy logowania stają się ważniejsze niż sam host, na którym ktoś siedzi.

Tożsamość jest dziś nowym perimetrem, ale nie w marketingowym sensie tego zdania. Po prostu większość krytycznych ścieżek dostępu przechodzi właśnie tam:

• SSO,
• Entra ID,
• OAuth 2.0,
• device code flow,
• partner tenant trust,
• synchronizacja tożsamości hybrydowej,
• service principals,
• API keys,
• tokeny sesyjne.

CrowdStrike dobrze pokazuje kilka wariantów tego problemu. COZY BEAR nie musiało już prowadzić klasycznego phishingu z podejrzaną domeną. W opisanych przypadkach wykorzystywało legitymne strony logowania Microsoftu, wielodniową socjotechnikę, relacje interpersonalne i przepływy autoryzacyjne OAuth/device code. Z perspektywy użytkownika to wyglądało jak coś znajomego. Właśnie dlatego działało.

SCATTERED SPIDER i BLOCKADE SPIDER z kolei intensywnie nadużywały mechanizmów hybrydowej tożsamości: Entra ID, Entra Connect Sync, AD FS, rejestracji urządzeń, rejestracji nowych metod MFA i zmian w politykach conditional access. To jest bardzo ważny sygnał dla zespołów IAM: nie wystarczy chronić login page. Trzeba chronić cały ekosystem tożsamości.

Co to zostawia w logach

W wielu organizacjach pierwsze sygnały nie pojawią się w EDR. Pojawią się w audit logach tożsamości.

Przykład syntetycznego ciągu zdarzeń w Entra ID:

2026-01-08T13:25:00Z Operation=UserLogin User=anna.nowak@firma.pl App=Microsoft Device Registration Service IP=185.213.x.x
2026-01-08T13:28:00Z Operation=Consent to application User=anna.nowak@firma.pl App=Microsoft Intune Company Portal
2026-01-08T13:31:00Z Operation=Add registered device User=anna.nowak@firma.pl DeviceName=WIN-INTUNE-ENROLL-01
2026-01-08T13:34:00Z Operation=Update user MFA User=anna.nowak@firma.pl Method=PhoneAppNotification

Osobno? Może helpdesk, może wdrożenie, może onboarding. Razem? Bardzo dobra kandydatura na incydent.

Przykładowe zapytanie KQL do korelacji logowania, device registration i consentów

Dla środowisk Microsoft taki szybki hunting może wyglądać tak:

let identityWindow = 14d;
SigninLogs
| where TimeGenerated > ago(identityWindow)
| where AuthenticationProtocol =~ "deviceCode"
   or AppDisplayName in ("Microsoft Device Registration Service", "Microsoft Intune Company Portal")
| summarize firstSeen=min(TimeGenerated), lastSeen=max(TimeGenerated),
            ips=make_set(IPAddress), apps=make_set(AppDisplayName)
            by UserPrincipalName
| join kind=leftouter (
    AuditLogs
    | where TimeGenerated > ago(identityWindow)
    | where OperationName has_any ("Add registered device", "Consent to application", "Update user")
    | extend UserPrincipalName=tostring(InitiatedBy.user.userPrincipalName)
    | summarize ops=make_set(OperationName), opTimes=make_set(TimeGenerated) by UserPrincipalName
) on UserPrincipalName
| order by lastSeen desc

To nie zastępuje pełnego use case’u detekcyjnego. Ale dobrze pokazuje kierunek: szukaj historii, nie pojedynczych eventów.

Przykład prostego pobrania auditów z Microsoft Graph

curl -s -H "Authorization: Bearer $GRAPH_TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?\$filter=activityDisplayName eq 'Consent to application'" \
  | jq '.value[] | {time: .activityDateTime, user: .initiatedBy.user.userPrincipalName, target: .targetResources[0].displayName}'

Takie rzeczy warto mieć pod ręką nie tylko w czasie incydentu, ale też podczas regularnego review uprawnień i consentów.

Chmura i SaaS: przeciwnik nie musi dotknąć endpointu

Jedna z najmocniejszych obserwacji raportu dotyczy wzrostu intruzji cloud-conscious. CrowdStrike odnotował 37% wzrost takich intruzji, a wśród aktorów państwowych wzrost sięgnął 266%. Dodatkowo raport pokazuje, że celem coraz częściej są nie tylko skrzynki czy pliki, ale też CRM-y, aplikacje SaaS, tokeny OAuth i non-human identities.

To bardzo praktyczny trend. Kiedy przeciwnik wchodzi do Microsoft 365, SharePointa, Salesforce’a, Jira, ServiceNow czy innej aplikacji SaaS, często nie potrzebuje żadnego kodu na stacji końcowej. Wystarczy mu:

• poprawna sesja,
• ważny token,
• service account,
• dostęp do dokumentacji architektury,
• albo dostęp do danych klientów.

CrowdStrike opisuje kampanie, w których napastnicy wykorzystywali AiTM do przejęcia dostępu do Microsoft 365, a następnie szukali w SharePoincie dokumentacji prowadzącej do kolejnych systemów, np. CRM. To ruch bardzo „biznesowy”: zamiast eksplorować hosta, atakujący eksploruje procesy i repozytoria wiedzy.

Co warto monitorować w SaaS

W SaaS bardzo często nie ma klasycznego sygnału typu „process injection”. Są za to:

• masowe pobrania plików,
• nietypowe eksporty danych,
• consenty aplikacyjne,
• logowania z nowych ASN,
• ruch z tokenów, które dawno nie były używane,
• dostęp do aplikacji przez service account, który nagle zaczyna przeglądać dane HR, finanse albo CRM.

Przykład syntetycznego wpisu w logu SaaS:

2026-01-09T07:44:12Z Workload=SharePoint User=svc-sync@tenant.local
Operation=FileDownloaded Site=/sites/Finance Count=184
IPAddress=91.198.x.x ASN=Residential-ISP Country=NL
UserAgent=Mozilla/5.0

Nie każdy eksport danych jest zły. Ale jeśli service account nagle zachowuje się jak człowiek, a człowiek jak robot, to trzeba zacząć zadawać pytania.

Edge devices wróciły do gry

Najbardziej „niedoczytanym” fragmentem raportu może być część o edge devices. A szkoda, bo to tam widać jedną z najbardziej niebezpiecznych zmian.

CrowdStrike wskazuje, że aktywność aktorów China-nexus wzrosła o 38%, a przy exploitacji podatności przez te grupy 40% przypadków dotyczyło edge devices. Raport opisuje też bardzo szybkie weaponization świeżo ujawnionych podatności: w konkretnych przypadkach exploitacja następowała po 2, 3 lub 6 dniach od publicznego disclosure. W jednym długotrwałym przypadku utrzymano dostęp przez 22 miesiące.

To ma potężne znaczenie praktyczne. Edge device jest dla obrońcy niewygodne:

• często ma słabsze logowanie niż endpoint,
• często nie ma EDR,
• często jest patchowane wolniej,
• i zbyt często „należy do sieci”, a nie do SOC.

Dla napastnika to prawie idealny punkt wejścia. Internet-facing. Wysoka wartość operacyjna. Dobra pozycja do pivotu. Często słaba widoczność po stronie obrony.

Przykład syntetycznych logów z urządzenia brzegowego:

2026-01-10T02:14:11Z vpn01 mgmt user=websvc action=POST uri=/api/v1/license/keys src=185.177.x.x
2026-01-10T02:14:13Z vpn01 system process=websvc child=/bin/sh result=spawned
2026-01-10T02:14:45Z vpn01 config change=user-add username=audit-sync role=superadmin
2026-01-10T02:15:02Z vpn01 network outbound dst=198.51.100.44:443 note=new_tls_session

To nie musi wyglądać jak „eksploit”. Bardzo często wygląda jak „dziwna zmiana konfiguracyjna o 2:14 w nocy”.

Raport rekomenduje bardzo konkretną praktykę: priorytetowe patchowanie edge devices w ciągu 72 godzin od ujawnienia krytycznej podatności. To nie jest przesada. To jest realistyczna odpowiedź na tempo weaponization, które opisano w raporcie.

Ransomware po nowemu: mniej hałasu na stacji, więcej ruchu między domenami

Jeśli ktoś dalej myśli o ransomware jak o procesie encryptor.exe na stacji Windows, to raport CrowdStrike jest zimnym prysznicem.

Raport pokazuje trzy bardzo ważne rzeczy:

1. initial access coraz częściej idzie przez socjotechnikę i tożsamość,
2. ruch boczny coraz częściej omija dobrze monitorowane hosty,
3. szyfrowanie lub eksfiltracja coraz częściej dzieją się poza klasycznym endpointem.

SCATTERED SPIDER: help desk, SSO i niezarządzane VM

CrowdStrike opisuje, jak SCATTERED SPIDER używało socjotechniki wobec help desku do resetów haseł i przejmowania dostępu do kont chmurowych i SSO, a następnie wykorzystywało niezarządzane maszyny wirtualne w vCenter do montowania VMDK kontrolera domeny i kopiowania ntds.dit oraz hive SYSTEM. W jednym incydencie zrobiono to w trzy godziny od initial access, dotykając tylko jednego managed endpointu.

To jest bardzo ważna lekcja: możesz mieć świetne EDR na stacjach, a i tak przegrać, jeśli przeciwnik prowadzi operację przez identity, vCenter i unmanaged VM.

Przykład PowerCLI do przeglądu nietypowych zdarzeń w vCenter:

Get-VIEvent -Start (Get-Date).AddDays(-7) |
  Where-Object {
    $_.GetType().Name -match 'VmCreatedEvent|VmRegisteredEvent|VmReconfiguredEvent|VmPoweredOnEvent'
  } |
  Select-Object CreatedTime, UserName, FullFormattedMessage |
  Sort-Object CreatedTime -Descending

Takie zapytanie nie złapie całej operacji, ale bardzo szybko pokaże, czy ktoś nie tworzył lub nie uruchamiał „dziwnych” VM-ek poza typowym oknem zmian.

PUNK SPIDER: zdalne szyfrowanie przez SMB

PUNK SPIDER było według raportu najaktywniejszym BGH adversary w 2025 roku, z 198 intruzjami, co oznacza wzrost o 134% r/r. Jedną z kluczowych technik było remote encryption przez SMB shares, czyli szyfrowanie plików z hosta, który nie musi być tym samym hostem, na którym leżą dane. W praktyce pozwala to omijać monitoring na końcówkach i wykonywać najgłośniejszą część operacji „z boku”.

BLOCKADE SPIDER: edge + identity + SaaS + virtualization

Jeśli ktoś chce zrozumieć, czym jest dziś cross-domain intrusion, case BLOCKADE SPIDER nadaje się idealnie. Raport opisuje operacje łączące:

• initial access przez niezałatane edge devices,
• persistence przez mechanizmy identity,
• eksfiltrację przez SaaS,
• utrzymanie dostępu do vCenter,
• szyfrowanie na warstwie wirtualizacji.

To już nie jest „atak na serwer”. To jest atak na organizację jako system połączonych zależności.

Supply chain i zależności: cudzy pipeline, twój incident

Ta część raportu powinna zainteresować nie tylko zespoły bezpieczeństwa, ale też DevSecOps, AppSec i ludzi od platform engineering.

CrowdStrike opisuje kilka bardzo mocnych przypadków:

• kompromitację Safe{Wallet} i kradzież 1.46 mld USD przez PRESSURE CHOLLIMA,
• liczne kampanie złośliwych paczek npm,
• działania FAMOUS CHOLLIMA wobec developerów,
• malware ShaiHulud, które rozprzestrzeniało się przez ekosystem npm i w jednej iteracji kampanii obejmowało 690 pakietów.

Najważniejsza lekcja brzmi prosto: dzisiejszy supply chain attack nie polega tylko na tym, że ktoś „wstrzyknął złośliwy kod do biblioteki”. On polega na tym, że organizacja ufa:

• maintainerowi,
• build pipeline’owi,
• aktualizacji,
• CI/CD,
• dependency tree,
• i tokenom do repozytoriów.

A napastnik potrzebuje tylko jednego słabego miejsca w tym łańcuchu.

Co sprawdzać w praktyce

Szybki przegląd lifecycle scripts w package.json:

jq -r '.scripts // {} | to_entries[] | select(.key|test("preinstall|postinstall|prepare")) | "\(.key): \(.value)"' package.json

Przegląd zmian w zależnościach względem głównej gałęzi:

git diff origin/main...HEAD -- package.json package-lock.json

Sprawdzenie podstawowych metadanych paczki npm:

npm view <nazwa-pakietu> time maintainers dist.integrity

To nie rozwiązuje problemu supply chain. Ale pozwala złapać rzeczy, które zbyt często przechodzą „bo przecież to tylko dependency update”.

Warto też patrzeć na takie sygnały:

• nowy maintainer przy ważnym pakiecie,
• nietypowe lifecycle scripts,
• szybki przyrost wersji bez sensownego changelogu,
• pojawienie się nowych sekretów w pipeline,
• tokeny deweloperskie używane spoza typowych lokalizacji,
• pull requesty, które „przy okazji” dotykają skryptów builda, publikacji albo procesu release.

Zero-day: liczy się nie tylko CVSS, ale miejsce w ścieżce ataku

Raport CrowdStrike pokazuje 42% wzrost liczby zero-dayów wykorzystywanych przed publicznym disclosure. Ale równie ważne jak sama liczba jest to, jakie cele wybierają różne klasy przeciwników.

Aktorzy targeted intrusion wybierają zwykle edge devices, webmaile, VPN-y i internet-facing systems, bo dają:

• initial access,
• wysoką wartość operacyjną,
• niski poziom widoczności po stronie ofiary,
• i szansę na długą persistencję.

Aktorzy eCrime częściej patrzą na:

• niezawodność exploita,
• skalę,
• łatwość monetyzacji,
• i czas, w jakim da się przejść od exploitation do exfiltration lub szyfrowania.

To bardzo ważna lekcja dla vulnerability management. CVSS to za mało. Dziś priorytetyzacja musi brać pod uwagę:

• czy zasób jest internet-facing,
• czy prowadzi do identity plane,
• czy leży na ścieżce do SaaS lub vCenter,
• czy da się przez niego pójść dalej bez EDR,
• czy exploit jest już aktywnie weaponizowany.

Prosty model priorytetyzacji roboczej:

Priority = Exposure x IdentityReach x PatchGap x ExploitMaturity x BusinessCriticality

Nie chodzi o matematykę. Chodzi o mentalny model. Luka 8.8 na edge appliance z wejściem do SSO bywa groźniejsza niż luka 9.8 na systemie, który nie prowadzi nigdzie dalej.

Dlaczego to ma znaczenie?

To jest moment, w którym warto odłożyć raport i spojrzeć na własne środowisko.

Dla SOC

Jeśli średni breakout time spada do kilkudziesięciu minut, a w skrajnych przypadkach do sekund, to klasyczny model:

• alert,
• kolejka,
• triage rano,
• eskalacja po lunchu

po prostu nie domyka ryzyka. SOC musi korelować dane cross-domain: endpoint, identity, SaaS, cloud, edge, virtualization. Inaczej będzie widział pojedyncze kropki, ale nie zobaczy linii łączącej incydent.

Rekomendacja: zbuduj use case’y nie tylko na „złośliwy proces”, ale też na:

• device registration + MFA change,
• consent do aplikacji + nietypowe logowanie,
• szybkie pobranie dokumentacji architektury,
• utworzenie nowej VM w vCenter poza change window,
• nietypowe masowe operacje na SMB shares.

Dla IAM i Cloud Security

Tożsamość nie jest „tematem od administratora AD”. To jest dziś rdzeń bezpieczeństwa operacyjnego.

Rekomendacja:

• wdrażaj phishing-resistant MFA tam, gdzie to możliwe,
• przeglądaj regularnie app consents i service principals,
• ograniczaj delegated admin i relacje partner trust,
• monitoruj device code flow,
• oddziel break-glass accounts od zwykłej administracji,
• kontroluj rejestrację nowych urządzeń i nowych metod MFA.

Dla DevSecOps i AppSec

Software supply chain nie jest ryzykiem abstrakcyjnym. To jest droga do kompromitacji downstream.

Rekomendacja:

• weryfikuj provenance artefaktów,
• skanuj zależności i lifecycle scripts,
• izoluj pipeline’y publikacyjne,
• rotuj tokeny maintainerów,
• utrzymuj secrets hygiene,
• sprawdzaj, kto i skąd publikuje paczki.

Dla biznesu i kierownictwa

Największy problem nie polega już na tym, że „atak jest bardziej zaawansowany”. Problem polega na tym, że organizacje nadal mają blind spots między zespołami:

• IAM widzi swoje,
• SOC widzi swoje,
• sieć widzi swoje,
• zespół chmurowy widzi swoje,
• a platform engineering swoje.

Napastnik nie ma takiego podziału. On widzi jedną organizację.

Co sprawdzić dziś rano: techniczna checklista

Poniżej zestaw, który ma sens nawet bez wielkiego programu transformacji bezpieczeństwa.

Identity i M365

• sprawdź ostatnie 30 dni pod kątem Consent to application,
• przejrzyj nowe rejestracje urządzeń,
• wylistuj nowe metody MFA dodane do kont uprzywilejowanych,
• sprawdź logowania przez device code flow,
• przejrzyj aktywność service principals i stale używane tokeny.

Edge i warstwa zarządzająca

• policz, ile edge devices nie ma pełnego logowania bezpieczeństwa,
• sprawdź opóźnienie patchowania dla VPN, firewalli, gatewayów i vCenter,
• przejrzyj zmiany administracyjne wykonywane poza oknem zmian,
• sprawdź nowe lokalne konta adminów i import certyfikatów,
• potwierdź, że logi z edge trafiają do SIEM.

Virtualization

• przejrzyj tworzenie i uruchamianie VM w ostatnich 7–14 dniach,
• sprawdź VM-ki bez agenta bezpieczeństwa,
• potwierdź, kto ma dostęp do snapshotów, VMDK i datastore.

SaaS i cloud

• sprawdź masowe pobrania z SharePoint, OneDrive, CRM i repozytoriów dokumentów,
• przejrzyj logowania z nietypowych ASN i geolokalizacji,
• potwierdź, które integracje mają uprawnienia do czytania maili, plików i danych klientów.

Supply chain

• przejrzyj nowe dependencies dodane w ostatnich release’ach,
• sprawdź lifecycle scripts i paczki publikowane spoza standardowych hostów,
• potwierdź rotację tokenów repo i publikacji,
• uruchom secrets scanning na pipeline’ach i repozytoriach.

Detekcja i gotowość

• sprawdź, czy masz playbook na incident involving OAuth consent,
• sprawdź, czy masz playbook na podejrzane device registration,
• sprawdź, czy ktoś ćwiczył response dla kompromitacji edge device,
• przetestuj korelację identity + SaaS + virtualization w SIEM.

Podsumowanie

Raport CrowdStrike 2026 daje jedną bardzo cenną lekcję: współczesny przeciwnik nie musi łamać wszystkiego siłą. Wystarczy, że:

• zaloguje się poprawnie,
• wykorzysta zaufany flow,
• przejmie token,
• pójdzie przez SaaS,
• użyje edge device jako punktu wejścia,
• ominie monitorowane hosty,
• i zadziała szybciej, niż zespół zdąży skleić historię.

AI jest w tym modelu ważne, ale nie jako magiczna broń. Bardziej jako wzmacniacz skali, tempa i jakości operacji. Prawdziwy problem jest głębszy: organizacje nadal zbyt często bronią silosów, podczas gdy napastnik atakuje połączenia między nimi. Właśnie to pokazują case’y z raportu dotyczące identity abuse, cloud-conscious intrusions, edge exploitation, ransomware na niezarządzanych hostach i supply chain.

Na koniec nie zostawiajmy tego jako „ciekawego raportu”.

Sprawdź w logach ostatnie 30 dni:

1. nowe consenty OAuth,
2. nowe rejestracje urządzeń,
3. zmiany MFA dla kont uprzywilejowanych,
4. masowe pobrania z SharePoint lub CRM,
5. tworzenie VM poza oknem zmian,
6. zmiany konfiguracji na edge devices po godzinach.

Przetestuj na stagingu lub labie:

• scenariusz device code abuse,
• scenariusz podejrzanego app consent,
• scenariusz eksfiltracji przez legalny kanał SaaS,
• scenariusz utworzenia niezarządzanej VM w środowisku wirtualnym,
• scenariusz dependency poisoning wykrywanego w pipeline.

Bo właśnie tam dziś rozgrywa się większość naprawdę groźnych ścieżek ataku.