Zero-day w cyberbezpieczeństwie

Czym jest zero-day w cyberbezpieczeństwie?

Zero-day to luka bezpieczeństwa w oprogramowaniu nieznana jego producentowi, dla której nie wypracowano jeszcze oficjalnej poprawki. Atakujący mogą wykorzystać taką lukę, zanim twórca kodu przygotuje aktualizację, a rozwiązania bezpieczeństwa oparte na sygnaturach nie są w stanie wykryć  tego rodzaju ataku.

Luki tego typu pojawiają się w różnych warstwach technologii – w aplikacjach użytkowych, systemach operacyjnych, protokołach sieciowych, sprzęcie komputerowym czy oprogramowaniu układowym (firmware).

Termin zero-day obejmuje trzy odrębne zjawiska: podatność, exploit (kod wykorzystujący podatność) oraz sam atak. Mówimy więc o podatnościach zero-day, exploitach zero-day i atakach zero-day. 

Dlaczego to specyficzne zagrożenie określa się mianem „zero-day”?

Nazwa zero-day odnosi się do  liczby dni, jakie producent oprogramowania miał na reakcję: zero. Oznacza to, że luka została wykryta i potencjalnie wykorzystana przez osobę trzecią, zanim jej istnienie stało się znane twórcom oprogramowania. W takiej sytuacji producent  nie ma żadnego zapasu czasu na przygotowanie poprawki lub łatki.

Brak wiedzy o podatności znacząco utrudnia działania obronne.. Administrator nie może zainstalować aktualizacji, ponieważ producent jej nie wydał. Również skanery podatności często nie wykrywają problemu, ponieważ luka nie figuruje jeszcze w publicznych bazach ani rejestrach zagrożeń. W rezultacie podatność może pozostawać niewykryta przez wiele lat.  Przykładem jest robak Stuxnet, który wykorzystywał lukę związaną z obsługą  skrótów LNK, obecną w systemach Windows od wersji 2000.

Status zero-day kończy się w momencie publicznego ujawnienia podatności  oraz nadania jej identyfikatora w klasyfikacji CVE (Common Vulnerabilities and Exposures). Informacje o luce trafiają następnie do baz danych, takich jak National Vulnerability Database (NVD). Paradoksalnie liczba prób wykorzystania podatności często wzrasta po jej ujawnieniu, ponieważ szczegóły techniczne stają się dostępne dla szerokiego grona cyberprzestępców, w tym grup prowadzących zautomatyzowane ataki na dużą skalę.

Czym różni się podatność zero-day od exploitu i ataku?

Podatność zero-day to nieznany producentowi oprogramowania błąd lub słabość w kodzie, dla której nie istnieje jeszcze oficjalna poprawka. Exploit jest narzędziem lub techniką wykorzystującą tę podatność, natomiast atak oznacza praktyczne użycie exploitu przeciwko konkretnemu systemowi lub infrastrukturze. Rozróżnienie tych pojęć ma istotne znaczenie zarówno w analizie ryzyka, jak i przy projektowaniu mechanizmów wykrywania oraz reagowania na incydenty bezpieczeństwa.

Poniższa tabela przedstawia trzy podstawowe komponenty zagrożenia wraz z ich definicjami operacyjnymi i przykładami technicznymi.

Komponent	Definicja operacyjna	Przykład techniczny
Podatność (vulnerability) zero-day	Pasywna wada lub usterka w kodzie, nieznana producentowi oprogramowania	Brak walidacji danych wejściowych prowadzący do błędu deserializacji w serwerze SharePoint
Exploit zero-day	Aktywne narzędzie: program, skrypt lub specjalnie przygotowany zestaw danych wykorzystujący  podatność typu zero-day	Żądanie HTTP POST do zasobu ToolPane.aspx z ładunkiem uruchamiającym deserializację
Atak (attack) zero-day	Celowe wykorzystanie exploitu zero-day przeciwko konkretnemu systemowi lub infrastrukturze	Kampania wgrywająca web shell na serwery korporacyjne i wykradająca klucze kryptograficzne

Podatności zero-day najczęściej wynikają z błędów zarządzania pamięcią lub błędów logicznych w aplikacjach. Do najczęściej spotykanych kategorii należą m.in. przepełnienie bufora na stercie (heap-based buffer overflow), użycie pamięci po jej zwolnieniu (use-after-free), odczyt poza przydzielonym zakresem pamięci (out-of-bounds read), niezgodność typów danych (type confusion), deserializacja niezaufanych danych oraz podatności umożliwiające wstrzyknięcie kodu SQL (SQL injection).

Exploit zero-day jest zwykle projektowany w celu osiągnięcia określonego efektu taktycznego:: zdalnego wykonania kodu (Remote Code Execution, RCE), lokalnej eskalacji uprawnień (Local Privilege Escalation, LPE), obejścia uwierzytelniania lub ucieczki ze środowiska odizolowanego (sandbox escape). Opracowanie skutecznego  exploitu zwykle wymaga pokonania kliku dodatkowych zabezpieczeń systemowych , takich jak randomizacja przestrzeni adresowej (ASLR), mechanizm zapobiegania wykonywaniu danych (DEP), analiza heurystyczna czy filtry reputacyjne plików.

Atak zero-day może skutkować pełną kompromitacją systemu, nieuprawnionym dostępem do danych, ich eksfiltracją lub wdrożeniem złośliwego oprogramowania, w tym ransomware.Jego skuteczność wynika przede wszystkim z asymetrii informacyjnej między napastnikiem a obrońcą. Ponieważ szczegóły podatności nie są jeszcze publicznie znane, tradycyjne mechanizmy ochronne oparte na sygnaturach i bazach znanych zagrożeń często nie są w stanie wykryć ani zablokować takiego ataku.

Jakie są 5 etapów cyklu życia zagrożenia typu zero-day?

Cykl życia zagrożenia typu zero-day obejmuje 5 etapów następujących po sobie chronologicznie. W pierwszych trzech przewagę posiada atakujący, ponieważ podatność pozostaje nieznana producentowi oprogramowania i zespołom odpowiedzialnym za bezpieczeństwo.  Dopiero na dwóch ostatnich etapach obrońcy zyskują możliwość skutecznej reakcji dzięki identyfikacji zagrożenia, publikacji wskaźników kompromitacji oraz udostępnieniu oficjalnej poprawki.

Krok 1: Powstanie nieznanej luki w kodzie oprogramowania

Podatność pojawia się w momencie wprowadzenia błędu do kodu źródłowego, a nie w chwili jego odkrycia. Najczęstszymi przyczynami są błędy zarządzania pamięcią, nieprawidłowa walidacja danych wejściowych oraz niepoprawnie zaimplementowane mechanizmy uwierzytelniania i autoryzacji.Defekt przechodzi przez przegląd kodu i testy niezauważony, a wadliwa wersja oprogramowania trafia następnie do środowisk produkcyjnych i jest instalowana na urządzeniach.  Na tym etapie istnienie podatności nie jest znane żadnej ze stron — ani producentowi, ani obrońcom, ani potencjalnym napastnikom.

Krok 2: Odkrycie błędu i stworzenie działającego exploitu

Podatność może zostać odkryta przez badacza bezpieczeństwa, cyberprzestępcę lub grupę sponsorowaną przez państwo, określaną jako Advanced Persistent Threat (APT). Do najczęściej stosowanych metod identyfikacji luk należą analiza kodu źródłowego, inżynieria wsteczna plików binarnych oraz fuzzing, czyli automatyczne dostarczanie aplikacji nieprawidłowych danych wejściowych w celu wywołania błędów wykonania.

Coraz większą rolę w tym procesie odgrywają systemy wykorzystujące sztuczną inteligencję, które potrafią analizować obszerne repozytoria kodu i wskazywać potencjalne podatności na skalę trudną do osiągnięcia metodami manualnymi. Zjawisko to jest niekiedy określane mianem Frontier AI Vulnerability Burst.

Samo odkrycie błędu nie oznacza jeszcze możliwości jego wykorzystania. Ponieważ uzbrojenie (weaponization) stanowi osobny proces inżynieryjny. Konieczne jest opracowanie exploitu, czyli mechanizmu pozwalającego na niezawodne wywołanie błędu i osiągnięcie zamierzonego efektu. Proces ten obejmuje przygotowanie odpowiedniego scenariusza ataku, a często także obejście zabezpieczeń systemowych. W przypadku szczególnie złożonych środowisk, takich jak jądra systemów operacyjnych czy hipernadzorcy, opracowanie stabilnego exploitu może trwać od kilku dni do wielu miesięcy. 

Krok 3: Aktywny atak i eksploatacja podatności w infrastrukturze

Po przygotowaniu exploitu rozpoczyna się faza aktywnego wykorzystania podatności przeciwko wybranym celom. Sposób przeprowadzenia ataku zależy od rodzaju podatnego oprogramowania.

W przypadku urządzeń dostępnych z internetu, takich jak zapory sieciowe, routery czy koncentratory VPN, atak może zostać przeprowadzony zdalnie poprzez wysłanie odpowiednio spreparowanych pakietów sieciowych. Jeśli podatność występuje w aplikacji klienckiej, atakujący zwykle wykorzystuje techniki socjotechniczne, takie jak kampanie spear-phishingowe, złośliwe dokumenty, zainfekowane archiwa lub strony internetowe uruchamiające kod po odwiedzeniu.

Zaawansowane operacje często wykorzystują tzw. exploit chains — łańcuchy kilku podatności połączonych w jedną sekwencję działań. Przykładowo, atak może rozpoczynać się od błędu w przeglądarce internetowej, następnie wykorzystywać lukę umożliwiającą opuszczenie środowiska izolowanego (sandbox), a kończyć się lokalną eskalacją uprawnień.

Istotnym wskaźnikiem skuteczności tej fazy jest dwell time, czyli czas pozostawania napastnika w środowisku ofiary przed wykryciem. W przypadku nieznanych podatności okres ten może wynosić tygodnie lub miesiące, co umożliwia prowadzenie długotrwałych operacji szpiegowskich, sabotażowych lub finansowych.

Krok 4: Identyfikacja i ujawnienie zagrożenia

W większości przypadków wykrycie zagrożenia następuje nie poprzez rozpoznanie samego exploitu, lecz dzięki analizie skutków jego działania. . Zespoły Security Operations Center (SOC) zwracają uwagę m.in. na anomalie, takie jak  zachowanie procesów, podejrzaną komunikację sieciową, nieautoryzowane zmiany w systemie lub obecność ransomware. 

Po potwierdzeniu istnienia podatności uruchamiana jest procedura odpowiedzialnego ujawnienia (responsible disclosure). Jeżeli luka jest aktywnie wykorzystywana, producenci oraz organizacje odpowiedzialne za cyberbezpieczeństwo publikują ostrzeżenia i rekomendacje ograniczające ryzyko. Podatność otrzymuje identyfikator CVE (Common Vulnerabilities and Exposures), a tym samym przestaje być klasyfikowana jako zero-day.

Na tym etapie publikowane są również wskaźniki kompromitacji (Indicators of Compromise – IoC) oraz zalecenia tymczasowe, takie jak wyłączenie podatnych funkcji, segmentacja ruchu sieciowego czy wdrożenie dodatkowych reguł ochronnych na zaporach aplikacyjnych (Web Application Firewall – WAF). Informacje o aktywnie wykorzystywanych podatnościach trafiają także do specjalistycznych katalogów, takich jak CISA Known Exploited Vulnerabilities (KEV).

Krok 5: Opracowanie oraz masowa dystrybucja oficjalnej poprawki

Ostatni etap obejmuje przygotowanie, przetestowanie i dystrybucję oficjalnej poprawki bezpieczeństwa. W zależności od charakteru błędu proces ten może wymagać jedynie niewielkiej modyfikacji kodu lub głębokiej przebudowy mechanizmu odpowiedzialnego za podatność.

Paradoksalnie, okres bezpośrednio po publikacji poprawki często wiąże się ze wzrostem liczby prób ataku. Cyberprzestępcy analizują różnice między starą a nową wersją oprogramowania (patch diffing), aby zidentyfikować naprawiony fragment kodu i na tej podstawie opracować własny exploit. Następnie automatyczne narzędzia skanują internet w poszukiwaniu systemów, które nie zostały jeszcze zaktualizowane.

Zjawisko to bywa określane mianem patch-or-perish („załataj albo giń”), ponieważ organizacje zwlekające z instalacją aktualizacji stają się łatwym celem ataków. Dopiero powszechne wdrożenie poprawki oraz usunięcie podatnych wersji oprogramowania prowadzą do stopniowego ograniczenia ryzyka związanego z daną luką bezpieczeństwa.

Skalę zjawiska potwierdzają twarde dane. Google Threat Intelligence Group (GTIG) odnotował 90 podatności zero-day wykorzystanych w realnych atakach w 2025 roku, 78 w 2024 roku oraz 100 w rekordowym 2023 roku. Wartości z ostatnich czterech lat mieszczą się w przedziale 60–100 przypadków rocznie, co sugeruje względną stabilizację zjawiska.

Kto najczęściej odkrywa podatności zero-day zanim zrobią to  przestępcy?

Podatności zero-day odkrywają zwykle: badacze bezpieczeństwa uczestniczący w programach Bug Bounty, niezależne zespoły badawcze, wewnętrzne zespoły bezpieczeństwa producentów oraz uczestnicy konkursów bezpieczeństwa.

Legalny obieg informacji o podatnościach konkuruje pod względem ekonomicznym z rynkiem komercyjnych brokerów exploitów oraz nielegalnym obrotem prowadzonym przez grupy przestępcze. O tym, gdzie ostatecznie trafi informacja o podatności, często decydują wysokość potencjalnego wynagrodzenia, zasady ujawniania oraz ryzyko prawne związane z jej wykorzystaniem.

Jak badacze bezpieczeństwa poszukują podatności w ramach programów Bug Bounty?

Badacze bezpieczeństwa poszukują podatności w ramach programów Bug Bounty w czterech krokach:

1. Zapoznanie się z zakresem programu – producent określa aktywa objęte testami, takie jak aplikacje, domeny, interfejsy API czy urządzenia. Testowanie zdefiniowanego zakresu – badacz wykorzystuje m.in. analizę kodu, fuzzing oraz manualne testy funkcjonalności i logiki aplikacji. Dokumentacja podatności – raport powinien zawierać opis problemu, jego wpływ na bezpieczeństwo, kroki pozwalające odtworzyć błąd oraz, jeśli jest to wymagane, bezpieczny dowód jego występowania (proof of concept – PoC).Zgłoszenie przez kanał koordynujący – badacz przekazuje raport za pośrednictwem platformy pośredniczącej lub bezpośrednio do zespołu bezpieczeństwa producenta.

Wysokość wynagrodzenia zależy przede wszystkim od rodzaju podatności, jej wpływu oraz jakości zgłoszenia. Najpoważniejsze błędy mogą być wyceniane na dziesiątki lub setki tysięcy dolarów, natomiast szczególnie złożone łańcuchy exploitów dotyczące systemów mobilnych mogą osiągać na rynku komercyjnym znacznie wyższe wartości. 

Model Bug Bounty tworzy więc obopólną korzyść: badacz otrzymuje wynagrodzenie za odpowiedzialne ujawnienie podatności, a producent zyskuje możliwość naprawienia błędu, zanim szczegóły techniczne zostaną publicznie ujawnione lub wykorzystane w ataku.

O kierunku przepływu informacji w dużej mierze decydują jednak czynniki ekonomiczne. Jeżeli wartość podatności na rynku ofensywnym znacząco przewyższa nagrodę oferowaną w programie Bug Bounty, część badaczy może być skłonna sprzedać ją brokerowi zamiast zgłaszać ją producentowi. Z tego względu wysokość nagród, szybkość obsługi zgłoszeń oraz przejrzystość procesu ujawniania podatności są istotnymi elementami konkurencji między legalnym a komercyjnym obiegiem informacji o lukach.

Czym zajmują się niezależni badacze oraz uczestnicy konkursów typu Pwn2Own?

Niezależni badacze bezpieczeństwa oraz uczestnicy konkursów takich jak Pwn2Own wyszukują nieznane podatności, a następnie przekazują informacje o nich producentom w ramach skoordynowanego ujawniania (coordinated vulnerability disclosure). Ich działalność pozwala wykrywać luki, zanim zostaną wykorzystane przez cyberprzestępców, oraz daje producentom możliwość przygotowania i wdrożenia poprawek.

Program Zero Day Initiative (ZDI) działa od 2005 roku i skupia się na pozyskiwaniu informacji o podatnościach oraz koordynowaniu ich ujawniania producentom. Z kolei Google Project Zero stosuje określone terminy ujawniania informacji o wykrytych lukach. Standardowo producent otrzymuje 90 dni na przygotowanie poprawki, a po jej wydaniu szczegóły techniczne mogą zostać opublikowane po dodatkowym okresie 30 dni. W przypadku podatności wykorzystywanych już w rzeczywistych atakach termin na reakcję może zostać skrócony.

Pwn2Own to organizowany przez ZDI konkurs, podczas którego badacze demonstrują wykorzystanie wcześniej nieznanych podatności w aktualnych, odpowiednio skonfigurowanych systemach i urządzeniach. Konkurs obejmuje m.in. przeglądarki internetowe, systemy operacyjne, hipernadzorców oraz urządzenia wykorzystywane w środowiskach przemysłowych. Warunkiem uzyskania nagrody jest skuteczne wykorzystanie podatności, która nie była wcześniej znana producentowi. W praktyce producent otrzymuje więc nie tylko opis potencjalnego problemu, ale również działający dowód jego wykorzystania.

Skoordynowane ujawnienie nie kończy jednak cyklu życia podatności. Nawet po wydaniu poprawki może się okazać, że nie usuwa ona wszystkich elementów problemu albo że zastosowane zabezpieczenie można obejść. W takiej sytuacji pojawienie się nowego sposobu wykorzystania tej samej klasy błędu może doprowadzić do powstania kolejnej podatności zero-day. Dlatego skuteczne zarządzanie podatnościami wymaga nie tylko jednorazowego wydania poprawki, lecz także jej weryfikacji, monitorowania środowiska oraz reagowania na nowe techniki eksploatacji.

Jakie są najbardziej znane ataki typu zero-day?

Poniższa tabela zestawia kilka najbardziej znanych ataków typu zero-day, według roku eksploatacji, identyfikatora CVE oraz skutku operacyjnego.

Incydent (rok)	Identyfikator CVE	Skutek operacyjny
Stuxnet (2010)	CVE-2010-2568 i trzy kolejne luki Windows	Przeprogramowanie sterowników PLC, fizyczne zniszczenie wirówek
MOVEit Transfer (2023)	CVE-2023-34362	Web shell LEMURLOOT, masowa eksfiltracja danych
PAN-OS GlobalProtect (2024)	CVE-2024-3400	Wykonanie kodu z uprawnieniami root na firewallu
SharePoint ToolShell (2025)	CVE-2025-53770	Zdalne wykonanie kodu, instalacja web shellu i kradzież materiału kryptograficznego
Outlook (2022–2023)	CVE-2023-23397	Przekazanie skrótu NTLM bez interakcji użytkownika

Stuxnet pozostaje jednym z najbardziej znanych przykładów wykorzystania podatności zero-day do przeprowadzenia ataku o skutkach fizycznych. Atak wykorzystywał kilka nieznanych wówczas podatności systemu Windows oraz podatności związane z oprogramowaniem Siemens Step7. Po przedostaniu się do odizolowanej sieci przemysłowej umożliwiło to manipulowanie sterownikami PLC odpowiedzialnymi za pracę wirówek w zakładzie wzbogacania uranu w Natanz.

MOVEit Transfer stał się przykładem masowej eksploatacji podatności w platformie służącej do bezpiecznego transferu plików. Grupa CL0P wykorzystała podatność SQL injection oznaczoną jako CVE-2023-34362 do uzyskania dostępu do baz danych i instalacji web shellu LEMURLOOT. CISA potwierdziła wykorzystanie tej luki jako zero-day w maju 2023 roku. 

PAN-OS GlobalProtect pokazuje, jak atrakcyjnym celem dla atakujących są urządzenia brzegowe. Podatność CVE-2024-3400 umożliwiała nieuwierzytelnionemu napastnikowi wykonanie poleceń z uprawnieniami root na podatnej zaporze z włączonym GlobalProtect. CISA sklasyfikowała ją jako podatność aktywnie wykorzystywaną w rzeczywistych atakach i umieściła ją w katalogu Known Exploited Vulnerabilities (KEV). 

SharePoint ToolShell ilustruje ryzyko związane z aktywną eksploatacją podatności w systemach wystawionych bezpośrednio do internetu. W przypadku CVE-2025-53770 atakujący wykorzystywali podatność do zdalnego wykonania kodu na lokalnych serwerach SharePointa, a następnie instalowali web shelle i pozyskiwali dane MachineKey. Microsoft potwierdził aktywną eksploatację przez kilka grup powiązanych z Chinami i wydał aktualizacje bezpieczeństwa dla obsługiwanych wersji SharePoint Server. 

Outlook (CVE-2023-23397) jest przykładem ataku typu zero-click, czyli takiego, który może zostać przeprowadzony bez aktywnego działania użytkownika. Podatność pozwalała na wymuszenie połączenia SMB z infrastrukturą atakującego i przekazanie materiału uwierzytelniającego NTLM. Tego rodzaju luka była szczególnie niebezpieczna w środowiskach, w których stacja robocza miała dostęp do zasobów sieciowych i usług wykorzystujących uwierzytelnianie NTLM. 

Jakie metody obrony są najskuteczniejsze wobec zagrożeń zero-day?

Do najskuteczniejszych metod obrony przed zagrożeniami zero-day należą architektura Zero Trust, zaawansowana analiza behawioralna kodu oraz wirtualne instalowanie łatek (virtual patching). Metody te wpisują się w strategię wielowarstwowej ochrony (Defense in Depth) i zakładają, że pojedyncze zabezpieczenie może zostać przełamane. Celem nie jest więc wyłącznie zablokowanie nieznanego ataku na granicy sieci, lecz również ograniczenie jego skutków i zasięgu (blast radius). 

Warto przy tym rozróżnić ochronę przed samą podatnością od ochrony przed skutkami jej wykorzystania. W przypadku zero-day organizacja często nie może jeszcze usunąć źródła problemu, dlatego kluczowe stają się mechanizmy utrudniające wykorzystanie luki, wykrywające nietypowe zachowanie po jej wykorzystaniu oraz ograniczające możliwość dalszego przemieszczania się napastnika w środowisku.

Jak wdrożenie architektury Zero Trust ogranicza swobodę ruchów intruza?

Architektura Zero Trust ogranicza możliwości napastnika przede wszystkim poprzez ciągłą weryfikację dostępu, mikrosegmentację oraz zasadę najmniejszych uprawnień. Model ten nie zakłada, że ruch pochodzący z sieci wewnętrznej jest automatycznie zaufany. Każde żądanie dostępu jest oceniane na podstawie tożsamości, uprawnień, stanu urządzenia oraz kontekstu połączenia. 

Mikrosegmentacja pozwala dodatkowo ograniczyć komunikację pomiędzy systemami do niezbędnego minimum. Ma to szczególne znaczenie w przypadku nieużywanych lub zapomnianych zasobów, takich jak starsze maszyny wirtualne, usługi pozostawione po zakończeniu projektu czy nieprawidłowo zinwentaryzowane systemy. Takie zasoby mogą pozostawać poza standardowym procesem aktualizacji i stanowić dodatkowy punkt wejścia dla atakującego.

W przypadku zero-day kompromitacja pojedynczego systemu nie powinna automatycznie oznaczać dostępu do całej infrastruktury. Mikrosegmentacja ogranicza ruch lateralny, natomiast zasada najmniejszych uprawnień utrudnia wykorzystanie przejętego konta do uzyskania dostępu do kolejnych systemów i danych.

W jaki sposób zaawansowana analiza behawioralna kodu wykrywa nieznane anomalie?

Analiza behawioralna koncentruje się na tym, co robi proces lub użytkownik, a nie wyłącznie na tym, jaki plik został uruchomiony. Dzięki temu może wykryć również zagrożenia, dla których nie istnieje jeszcze sygnatura.

Systemy Endpoint Detection and Response (EDR) oraz Extended Detection and Response (XDR) analizują m.in. relacje między procesami, komunikację sieciową, operacje na plikach, dostęp do pamięci oraz działania użytkowników. Mechanizmy analityczne mogą wykrywać zachowania odbiegające od ustalonego profilu środowiska.

Przykładowe sygnały wskazujące na potencjalną aktywność po wykorzystaniu podatności to:

• Uruchomienie PowerShella przez proces, który zwykle nie korzysta z interpretera poleceń.Nawiązanie nietypowej komunikacji sieciowej z nową domeną, adresem IP lub infrastrukturą o podejrzanej reputacji.
• Wykorzystanie narzędzi Living-off-the-Land (LotL), czyli legalnych narzędzi systemowych do wykonywania działań typowych dla złośliwego oprogramowania.
• Nietypowy dostęp do pamięci innych procesów, mogący wskazywać na próbę pozyskania poświadczeń lub wykonania kodu.
• Nietypowe zapytania DNS lub wzorce komunikacji mogące wskazywać na kontakt z infrastrukturą Command and Control (C2).

XDR dodatkowo koreluje dane pochodzące z wielu źródeł — na przykład stacji roboczych, serwerów, poczty elektronicznej, urządzeń sieciowych i usług chmurowych. Dzięki temu pojedynczy sygnał, który sam w sobie może wyglądać niegroźnie, może zostać powiązany z innymi zdarzeniami i potraktowany jako element większego łańcucha ataku. 

Dlaczego systemy wirtualnego łatowania (virtual patching) zabezpieczają infrastrukturę?

Systemy wirtualnego łatowania zabezpieczają infrastrukturę, ponieważ blokują wektor ataku w warstwie pośredniczącej, bez konieczności modyfikacji kodu aplikacji. Metoda ta usuwa lukę czasową między publikacją informacji o podatności a wdrożeniem oficjalnej poprawki. Proces testów regresyjnych oraz konieczność wykorzystania zaplanowanych okien serwisowych mogą bowiem wydłużyć wdrożenie poprawki do kilku dni, a nawet tygodni.

Zespoły bezpieczeństwa sięgają po różne techniki wirtualnego patchowania , m.in. reguły na zaporach aplikacyjnych WAF, sygnatury w systemach IPS, wyłączenie podatnego modułu, ograniczenie dostępu do interfejsu zarządzania czy blokowanie makr i określonych typów plików.

Przebieg incydentu związanego z podatnością CVE-2024-3400 dobrze ilustruje zastosowanie tej metody. Palo Alto Networks poinformowało o podatności 12 kwietnia 2024 roku, a poprawki dla poszczególnych wersji PAN-OS były udostępniane w kolejnych dniach. Producent równolegle udostępnił sygnatury Threat Prevention oraz zalecenia dotyczące konfiguracji zabezpieczeń. Dzięki temu klienci mogli ograniczyć ryzyko eksploatacji podatności jeszcze przed przeprowadzeniem aktualizacji oprogramowania układowego.

Wirtualne patchowanie  chroni również systemy nieprzeznaczone do aktualizacji, czyli starsze aplikacje bez wsparcia producenta, urządzenia technologii operacyjnej (Operational Technology, OT) z certyfikowanym oprogramowaniem układowym oraz systemy o wymaganej ciągłości działania. Metoda uzupełnia zarządzanie podatnościami i obowiązuje do momentu wdrożenia właściwej poprawki dostawcy.

Słowniczek pojęć powiązanych z zagrożeniami zero-day