Ataki fileless coraz częściej omijają tradycyjną ochronę, działając wyłącznie w pamięci i wykorzystując legalne narzędzia systemowe. Skuteczne wykrywanie zagrożeń fileless wymaga podejścia skupionego na monitorowaniu pamięci oraz analizie zachowań, a nie tylko plików. Poznaj, jak wygląda ochrona przed nowoczesnymi zagrożeniami i jak rank_math_focus_keyword pozwala na skuteczną prewencję w środowiskach biznesowych.
Spis treści
- Czym są zagrożenia fileless i jak działają?
- Narzędzia systemowe wykorzystywane w atakach
- Techniki fileless stosowane przez hakerów
- Znaczenie monitoring pamięci w obronie
- Przykłady ataków fileless w praktyce
- Jak zabezpieczyć się przed atakami fileless?
Czym są zagrożenia fileless i jak działają?
Zagrożenia fileless to specyficzna klasa ataków cybernetycznych, w których złośliwy kod nie jest zapisywany na dysku jako tradycyjny plik wykonywalny, dokument lub archiwum, lecz działa głównie w pamięci operacyjnej (RAM) lub wykorzystuje legalne komponenty systemu operacyjnego. Dla klasycznych antywirusów, opierających się w dużej mierze na skanowaniu plików i porównywaniu ich z sygnaturami znanego malware, takie podejście jest wyjątkowo problematyczne – praktycznie „nie ma czego” przeskanować. Atak fileless może rozpocząć się na wiele sposobów: przez zainfekowany e‑mail phishingowy zawierający złośliwe makro w dokumencie Office, przez odwiedzenie strony wykorzystującej luki w przeglądarce (tzw. drive‑by download), poprzez zdalne wykonanie poleceń w wyniku podatności w usługach serwerowych, a nawet przez nadużycie legalnych narzędzi do zdalnego zarządzania IT. Kluczem jest to, że napastnik minimalizuje lub całkowicie eliminuje konieczność zapisu szkodliwego kodu na dysku – zamiast tego wstrzykuje go bezpośrednio do procesów w pamięci lub generuje instrukcje „w locie” przy użyciu interpretowanych języków skryptowych, takich jak PowerShell czy JavaScript. Tego typu ataki bardzo często określa się jako „living off the land”, ponieważ haker wykorzystuje to, co już jest w systemie: wbudowane narzędzia administracyjne, legalne biblioteki, zaufane procesy systemowe (np. powershell.exe, wscript.exe, mshta.exe) oraz istniejące mechanizmy autoryzacji i komunikacji sieciowej. Z perspektywy ofiary widoczna jest więc praca pozornie zwykłych komponentów systemu, podczas gdy w tle są one sterowane złośliwymi skryptami i komendami pobieranymi z serwerów atakującego lub generowanymi na podstawie zaszyfrowanych fragmentów kodu przechowywanych w rejestrze systemowym albo w pamięci procesów. Kolejnym wyróżnikiem zagrożeń fileless jest silne oparcie się na technikach „fileless persistence” – utrzymywania się w systemie bez pozostawiania klasycznych artefaktów. Może to obejmować dodawanie złośliwych wpisów w harmonogramie zadań, modyfikację kluczy Run/RunOnce w rejestrze, wykorzystanie mechanizmów WMI (Windows Management Instrumentation) do cyklicznego wywoływania skryptów czy nasłuchiwania na konkretne zdarzenia systemowe, a nawet ataki na pamięć firmware lub komponenty wirtualizacji. Wszystko po to, by po restarcie systemu złośliwy kod był ponownie załadowany do pamięci przy użyciu pozornie zaufanych mechanizmów, nie wzbudzając alarmu tradycyjnych narzędzi ochronnych. Co istotne, wiele współczesnych kampanii APT (Advanced Persistent Threat) stosuje hybrydowe podejście: etap początkowy jest w dużej mierze fileless, a dopiero po uzyskaniu trwałego dostępu i eskalacji uprawnień napastnicy mogą zdecydować się na pobranie dodatkowych modułów – często również silnie zaciemnionych i ładowanych bezpośrednio do pamięci z pominięciem zapisu na dysk.
Mechanizm działania zagrożeń fileless można przedstawić jako łańcuch kilku logicznych etapów, w którym na każdym kroku haker stara się maksymalnie wtopić w normalną aktywność systemu. Najpierw dochodzi do wektora wejścia – np. użytkownik otwiera dokument Word z makrem, które po cichu uruchamia PowerShell z odpowiednio przygotowanym skryptem, lub administrator pozostawia niezałatany serwer z podatnością RCE, pozwalającą atakującemu na zdalne wykonanie poleceń. Następnie uruchamiany jest tzw. downloader lub stager, często w formie krótkiego skryptu PowerShell/JavaScript, którego zadaniem jest pobranie z serwera C2 (Command & Control) właściwego payloadu i załadowanie go do pamięci, np. poprzez refleksyjne ładowanie bibliotek .NET, wstrzyknięcie kodu do istniejącego procesu (process injection) czy stworzenie nowego procesu w trybie suspended i nadpisanie jego pamięci (process hollowing). Payload – zamiast zostać zapisany na dysku jako .exe – istnieje tylko jako ciąg bajtów w RAM, co znacząco utrudnia jego wykrycie skanerom plikowym. Na tym etapie uruchamiane są właściwe funkcje złośliwego oprogramowania: kradzież danych uwierzytelniających z pamięci (np. z procesów przeglądarki czy z LSASS), skanowanie sieci wewnętrznej, rozprzestrzenianie się na kolejne hosty, a także instalacja mechanizmów persistence, najczęściej właśnie w oparciu o rejestr, WMI czy zadania harmonogramu. Atakujący, korzystając z kanału C2 ukrytego w pozornie typowym ruchu HTTP(S) lub DNS, może w czasie rzeczywistym wydawać polecenia systemowi ofiary, pobierać dodatkowe moduły w formie fragmentów skryptu, a nawet całych powłok (shelli) ładowanych tylko do pamięci, co dodatkowo redukuje ślad na poziomie dysku. Jednocześnie wiele kampanii fileless stosuje silne zaciemnianie (obfuscation) komend i skryptów – na przykład kod PowerShell jest dzielony na fragmenty, kodowany base64, a następnie dynamicznie składany i wykonywany, co utrudnia analizę zarówno narzędziom bezpieczeństwa, jak i analitykom. W połączeniu z nadużywaniem zaufanych narzędzi administracyjnych (Living off the Land Binaries – LOLBins) sprawia to, że klasyczne wskaźniki kompromitacji (IOC) – jak konkretne pliki złośliwe, nazwy procesów czy ścieżki w systemie plików – są w dużej mierze bezużyteczne. W przypadku zagrożeń fileless dużo ważniejsze stają się wskaźniki zachowań (IOB – Indicators of Behavior), takie jak nietypowe sekwencje wywołań PowerShell, anomalia w działaniach przeglądarki, nietypowe połączenia sieciowe z procesów systemowych czy niestandardowe wywołania WMI. Zrozumienie, że istotą zagrożeń fileless jest przeniesienie punktu ciężkości z trwałego kodu na dysku do efemerycznych, dynamicznie generowanych instrukcji w pamięci, jest kluczowe dla budowania skutecznych strategii detekcji i reagowania w nowoczesnych środowiskach IT.
Narzędzia systemowe wykorzystywane w atakach
W atakach fileless hakerzy świadomie rezygnują z klasycznych plików wykonywalnych i koncentrują się na nadużywaniu wbudowanych narzędzi systemowych, które są zaufane przez system operacyjny i administratorów. Najczęściej wykorzystywanym elementem ekosystemu Windows jest PowerShell – potężne środowisko skryptowe, stworzone z myślą o automatyzacji zadań administracyjnych. Cyberprzestępcy uruchamiają złośliwe polecenia bezpośrednio z pamięci, pobierając kod z internetu przy użyciu parametrów takich jak -ExecutionPolicy Bypass czy -EncodedCommand, które pozwalają ominąć polityki wykonywania skryptów oraz utrudniają analizę treści. Popularną techniką jest tzw. living off the land, w której PowerShell pobiera i odpala moduły w RAM, np. wstrzykujące shellcode do legalnych procesów jak explorer.exe czy svchost.exe. Umożliwia to przeprowadzenie eskalacji uprawnień, rekonesansu sieciowego, kradzieży poświadczeń oraz zdalne sterowanie stacją roboczą bez zapisania jakiegokolwiek złośliwego pliku na dysku. Kolejnym często nadużywanym narzędziem jest Windows Management Instrumentation (WMI), które w normalnych warunkach służy do zarządzania konfiguracją systemu i monitoringu. W ramach ataków fileless WMI pozwala tworzyć trwałe mechanizmy uruchamiania kodu w odpowiedzi na określone zdarzenia, np. start systemu czy logowanie użytkownika. Hakerzy definiują złośliwe subskrypcje zdarzeń i osadzają w nich skrypty PowerShell lub VBScript, które działają całkowicie w tle, bez tworzenia nowych plików. Tego typu persistence jest trudny do wykrycia, ponieważ wpisy WMI są traktowane jako standardowy element konfiguracji administracyjnej, a nie typowe autostarty. Nie mniej istotną rolę w fileless attack chain odgrywa usługa schtasks.exe, używana standardowo do planowania zadań w systemie Windows. Napastnicy tworzą zaplanowane zadania, które regularnie wywołują polecenia PowerShell, uruchamiają skrypty pobierane dynamicznie z sieci lub aktywują złośliwe makra aplikacji biurowych, przy czym sam złośliwy kod nadal pozostaje w pamięci lub w zaufanych lokalizacjach systemowych. Dzięki temu, nawet jeśli fragment złośliwej logiki zostanie wykryty i usunięty z RAM, harmonogram zadań zapewni jego ponowne uruchomienie przy kolejnym zdarzeniu, takim jak logowanie użytkownika, określona godzina czy restart komputera. Tradycyjnym, lecz wciąż skutecznie wykorzystywanym komponentem jest także cmd.exe – klasyczna powłoka konsolowa. Atakujący stosują ją do inicjalnej fazy uruchamiania skryptów, pobierania payloadów za pomocą narzędzi sieciowych wbudowanych w system lub do uruchamiania innych „zaufanych” binariów systemowych (tzw. LOLBins – Living Off The Land Binaries), które z kolei wykonują docelowy złośliwy kod. Dodatkowo coraz częściej pojawiają się scenariusze wykorzystania Windows Script Host (WSH) – mechanizmów obsługujących VBScript i JScript. Makra w dokumentach pakietu Office lub skrypty startujące z rejestru mogą wstrzykiwać kod do WSH, który funkcjonuje w pamięci jako zupełnie legalny proces, jednocześnie realizując funkcje typowe dla zaawansowanego malware, takie jak keylogging, exfiltracja danych czy komunikacja z serwerem C2.
Szczególnie groźne w kontekście ataków fileless jest kreatywne użycie narzędzi administrowania systemem oraz popularnych aplikacji biurowych, które w oczach klasycznych systemów bezpieczeństwa wyglądają jak zupełnie normalna aktywność użytkownika lub administratora. Przykładowo, narzędzie mshta.exe, przeznaczone do uruchamiania aplikacji HTML, bywa używane do wywoływania złośliwych skryptów hostowanych w sieci, przy czym kod JScript/ VBScript wykonywany jest w pamięci bez konieczności zapisu na dysku. Podobne nadużycia dotyczą regsvr32.exe, które normalnie rejestruje biblioteki DLL, lecz w rękach atakujących może ładować zdalne skrypty COM Scriptlet (pliki .sct) bez pozostawiania tradycyjnych artefaktów plikowych. Innym elementem łańcucha ataku jest rundll32.exe, pozwalające na uruchamianie funkcji z DLL – złośliwe biblioteki mogą być wstrzykiwane bezpośrednio w pamięci, czasem z użyciem technik refleksyjnego ładowania DLL, co całkowicie omija zapis na dysk. Równie ważną rolę odgrywają mechanizmy integracji z przeglądarkami i klientami poczty – hakerzy wykorzystują luki w wtyczkach, skrypty JavaScript oraz ActiveX do uruchamiania zaufanych binariów systemowych, które dopiero potem ściągają i wykonują właściwy payload w RAM. W środowiskach korporacyjnych fileless malware bardzo często łączy kilka narzędzi systemowych w jeden, spójny łańcuch: makro w dokumencie Word inicjuje PowerShell, ten poprzez WMI tworzy zadanie w harmonogramie, które następnie cyklicznie odpala mshta.exe do pobierania kolejnych porcji złośliwego kodu. Taka modularna konstrukcja jest trudna do uchwycenia przez detekcję opartą wyłącznie na sygnaturach, dlatego nowoczesne systemy EDR/XDR analizują korelację zdarzeń i niestandardowe kombinacje użycia narzędzi systemowych. Dla działów bezpieczeństwa kluczowe staje się monitorowanie sposobu i kontekstu użycia tych narzędzi: niestandardowych parametrów PowerShell, nietypowych subskrypcji WMI, anomalii w harmonogramie zadań czy nieoczekiwanych wywołań mshta.exe i regsvr32.exe. Właśnie te komponenty systemu Windows, stworzone z myślą o wygodzie i automatyzacji, stały się fundamentem nowoczesnych ataków fileless, w których tradycyjne skanowanie plików na dysku przestaje być wystarczającą metodą ochrony.
Techniki fileless stosowane przez hakerów
Ataki fileless bazują na kombinacji kilku klas technik, które łączy jeden wspólny mianownik: maksymalne wykorzystanie istniejącej infrastruktury systemowej i aplikacyjnej przy jednoczesnym ograniczeniu zapisu na dysk do absolutnego minimum. Jednym z głównych filarów jest tzw. script-based execution, czyli uruchamianie złośliwego kodu w postaci skryptów, najczęściej PowerShell, ale też JScript, VBScript czy makra VBA w dokumentach pakietu Office. Hakerzy stosują jednolinijkowe polecenia (one-liners) PowerShell, dostarczane np. w polu URL, w makrze lub w poleceniu zdalnym, które ściągają zakodowany w Base64 payload z serwera C2 (command and control) i od razu wykonują go w pamięci (In-Memory Execution). Popularna technika polega na wykorzystaniu parametrów takich jak -ExecutionPolicy Bypass czy -EncodedCommand, co pozwala ominąć polityki wykonania skryptów oraz ukryć prawdziwą treść polecenia. W środowiskach, gdzie PowerShell jest już monitorowany, cyberprzestępcy przenoszą się na inne interpretery, takie jak wscript.exe, cscript.exe, mshta.exe czy regsvr32.exe (tzw. “Squiblydoo”), aby „podpiąć się” pod zaufane procesy i uruchamiać skrypty JScript/HTML Application hostowane zdalnie lub wstrzykiwane bezpośrednio jako ciągi znaków. Kolejną grupą technik są ataki oparte na injekcji kodu do istniejących procesów (process injection), np. explorer.exe, svchost.exe czy przeglądarek internetowych. Po dostarczeniu pierwszego stopnia (stager) – np. za pomocą makra lub exploita przeglądarki – kod shellcode jest wstrzykiwany do procesu z podwyższonymi uprawnieniami z użyciem API systemowych, takich jak VirtualAllocEx, WriteProcessMemory czy CreateRemoteThread. Ponieważ właściwy złośliwy moduł nigdy nie jest zapisywany jako plik .exe, a jedynie istnieje jako blok pamięci przypisany do legalnego procesu, zwykłe skanowanie plików nie ma szans go wykryć. Wariantem tej techniki jest tzw. reflective DLL injection, gdzie biblioteka DLL jest ładowana bezpośrednio z pamięci, bez rejestracji na dysku oraz bez klasycznego mechanizmu LoadLibrary. Hakerzy łączą te metody z zaciemnianiem (obfuscation) – np. dynamicznym generowaniem części kodu, mieszaniem fragmentów skryptu w różnych zmiennych, szyfrowaniem parametrów czy korzystaniem z polimorficznych loaderów, które za każdym razem wyglądają inaczej, choć wykonują te same operacje.
Szalenie istotnym elementem krajobrazu fileless jest warstwa trwałości (fileless persistence) i nadużywanie komponentów takich jak Windows Management Instrumentation (WMI), rejestr systemowy oraz harmonogram zadań (schtasks.exe). Zamiast typowego wpisu w folderze Autostart, napastnik może utworzyć zdarzenie WMI, które nasłuchuje np. uruchomienia konkretnego procesu, logowania użytkownika czy zdarzenia systemowego, a następnie wyzwala skrypt PowerShell lub VBScript zdefiniowany w przestrzeni WMI lub w zaszyfrowanym kluczu rejestru. Ten skrypt znów pobiera właściwy payload z sieci lub rekonstruuje go w pamięci, co sprawia, że po restarcie systemu atak odradza się bez klasycznego „pliku startowego”. Innym wariantem jest przechowywanie zaszyfrowanego kodu w nietypowych gałęziach rejestru (np. w kluczach powiązanych z usługami, COM, przeglądarką) oraz dynamiczne jego odszyfrowanie przy starcie przy użyciu małego loadera działającego w pamięci. W obszarze lateral movement, czyli rozprzestrzeniania się wewnątrz sieci, hakerzy opierają się na mechanizmach takich jak WMI, PowerShell Remoting, PsExec, WinRM czy nawet narzędziach administracyjnych domeny (np. Group Policy), by uruchamiać złośliwe polecenia wyłącznie w pamięci na kolejnych hostach, bez kopiowania binariów. Do tego dochodzi living off the land, czyli intensywne korzystanie z wbudowanych narzędzi typu certutil.exe, bitsadmin.exe, msbuild.exe, powershell.exe, rundll32.exe czy regsvr32.exe, które służą jako „nośnik” złośliwych działań: pobierają, dekodują, odszyfrowują i uruchamiają payload in-memory. W bardziej zaawansowanych scenariuszach stosowane są techniki bezplikowego użycia przeglądarek – np. kradzież sesji poprzez iniekcję kodu JavaScript przez XSS lub zainfekowane rozszerzenia, a następnie użycie tych sesji do dalszych ataków, bez zapisywania dodatkowych plików malware na stacjach roboczych. Coraz częściej widać też połączenie fileless z technikami LOLBins (Living off the Land Binaries) oraz BYOI (Bring Your Own Interpreter), gdzie napastnik wykorzystuje np. wbudowane w aplikacje biznesowe interpretery skryptów lub środowiska jak Python/Node.js obecne na serwerach developerskich, uruchamiając w ich kontekście złośliwe fragmenty kodu utrzymywane wyłącznie w pamięci RAM. Wszystko to pokazuje, że nowoczesne techniki fileless nie są pojedynczą sztuczką, lecz złożonym ekosystemem metod wykorzystujących interpretery skryptów, iniekcję do procesów, trwałość opartą o WMI i rejestr oraz nadużywanie legalnych narzędzi systemowych, co radykalnie zmienia sposób myślenia o detekcji i analizie incydentów.
Znaczenie monitoring pamięci w obronie
W kontekście zagrożeń fileless, które w zdecydowanej większości działają wyłącznie w pamięci operacyjnej, monitoring pamięci staje się jednym z kluczowych filarów skutecznej obrony. Tradycyjne rozwiązania antywirusowe i systemy ochrony endpointów opierają się głównie na analizie plików – ich sum kontrolnych, sygnatur, reputacji czy zachowania w momencie uruchomienia pliku wykonywalnego. W przypadku ataków fileless ten model załamuje się, ponieważ złośliwy kod nigdy nie istnieje jako trwały plik na dysku lub pojawia się tam tylko w formie mocno zaszyfrowanej, tymczasowej struktury, która szybko znika. Obserwacja tego, co dzieje się bezpośrednio w pamięci RAM – jakie procesy są uruchamiane, jakie moduły są do nich wstrzykiwane, jak wygląda struktura stosu i sterty oraz jakie regiony pamięci zyskują prawa wykonywalności – pozwala zauważyć anomalie charakterystyczne dla technik fileless, na długo przed tym, zanim przełożą się one na widoczne skutki biznesowe, takie jak szyfrowanie danych czy exfiltracja poufnych informacji. Monitoring pamięci obejmuje m.in. wykrywanie nietypowych segmentów pamięci oznaczonych jako “read-write-execute” (RWX), które często służą jako przestrzeń dla shellcode’u, kontrolę niespodziewanych alokacji dużych bloków pamięci wykonywalnej oraz śledzenie, kiedy legalne procesy – np. powershell.exe, wmiprvse.exe czy mshta.exe – zaczynają wykonywać instrukcje, których profil znacząco odbiega od ich standardowego, biznesowego użycia. Z punktu widzenia obrony istotne jest także rozróżnienie między pamięcią należącą do samego procesu a pamięcią zdalnie modyfikowaną przez inne procesy, gdyż iniekcja kodu (np. za pomocą technik CreateRemoteThread lub APC injection) jest jednym z fundamentów ataków fileless. Analiza takich zjawisk w czasie rzeczywistym wymaga od narzędzi bezpieczeństwa głębokiej integracji z jądrem systemu oraz mechanizmami zarządzania pamięcią, aby mogły one przechwytywać zdarzenia niskopoziomowe, takie jak zmiany uprawnień stron pamięci, ładowanie bibliotek DLL z nietypowych lokalizacji pamięci czy dynamiczne kompilowanie i wykonywanie kodu JIT (np. w środowiskach .NET). Bez takiej widoczności organizacja jest w dużej mierze ślepa na kluczową fazę ataku fileless – moment, w którym złośliwy kod żyje wyłącznie w RAM i dopiero przygotowuje się do najbardziej destrukcyjnych działań.
Znaczenie monitoringu pamięci dla obrony rośnie także dlatego, że nowoczesne ataki fileless coraz lepiej ukrywają się w legalnym ruchu systemowym i biznesowym, instrumentalnie wykorzystując funkcje systemu operacyjnego oraz uzasadnione procesy aplikacyjne. W praktyce oznacza to konieczność przejścia z prostego modelu “wykryj znany wzorzec złośliwego kodu” do modelu behawioralnego, w którym narzędzie EDR/XDR lub wyspecjalizowany sensor pamięci buduje bazową linię (baseline) typowego użycia pamięci w danym środowisku, a następnie identyfikuje odstępstwa od tej normy. Przykładowo, instancja powershell.exe uruchamiana regularnie przez dział IT do automatyzacji zadań administracyjnych będzie miała inny profil zużycia pamięci, zestaw ładowanych modułów i wzorce instrukcji niż instancja uruchomiona przez makro w dokumencie Office, która pobiera dodatkowy payload z Internetu i wstrzykuje go w proces przeglądarki lub systemowy proces usługowy. Monitoring pamięci pozwala to odróżnić, analizując np. obecność dekoderów shellcode’u, typowych pętli skoków stosowanych w exploitach, niepodpisanych modułów DLL oraz nietypowych łańcuchów API, takich jak ciągłe wywołania VirtualAlloc/VirtualProtect, WriteProcessMemory i CreateThread w krótkim przedziale czasu. Podobnie wygląda sytuacja z mechanizmami trwałości (fileless persistence) – choć konfiguracja WMI, wpisów rejestru czy harmonogramu zadań może nie budzić od razu podejrzeń, to już analiza pamięci procesów wywołanych w odpowiedzi na te zdarzenia (np. procesów uruchamianych po restarcie systemu) pozwala wychwycić wstrzyknięty w nie kod, dodatkowe segmenty pamięci wykonywalnej czy nietypowe połączenia sieciowe inicjowane bezpośrednio z pamięci. Monitoring pamięci jest więc nie tylko narzędziem detekcji, ale także elementem forensyki i threat huntingu – umożliwia analitykom odtworzenie łańcucha ataku fileless, nawet jeśli na dysku nie zachowały się żadne artefakty lub napastnik starannie posprzątał ślady swojego działania. Kluczowe staje się tu połączenie danych z poziomu pamięci z telemetrycznymi informacjami z innych warstw (logi systemowe, zdarzenia sieciowe, informacje o tożsamości i uprawnieniach), co pozwala budować pełny obraz kampanii i identyfikować wspólne wzorce w różnych incydentach. Organizacje, które inwestują w takie rozwiązania – czy to w formie zaawansowanych platform EDR/XDR, czy dedykowanych sond do analizy pamięci – zyskują realną przewagę w walce z atakami fileless: są w stanie wykrywać je na wczesnym etapie, zawężać powierzchnię ataku poprzez szybką izolację podejrzanych procesów, a także lepiej rozumieć taktyki, techniki i procedury (TTPs) konkretnych grup atakujących, co przekłada się na dojrzalszy, proaktywny model cyberbezpieczeństwa.
Przykłady ataków fileless w praktyce
Ataki fileless od kilku lat stanowią istotny element krajobrazu zagrożeń i pojawiają się zarówno w kampaniach masowych, jak i wysoce ukierunkowanych operacjach APT. Jeden z najbardziej znanych przykładów to kampanie oparte na PowerShellu i frameworku PowerShell Empire, w których wektorem wejścia były spreparowane dokumenty Office z makrami lub osadzonymi łączami. Po otwarciu dokumentu uruchamiały się makra VBA, które nie zapisywały na dysku klasycznego pliku EXE, lecz bezpośrednio wywoływały PowerShell z zakodowanym w Base64 poleceniem. To polecenie pobierało kolejny etap ataku z Internetu (tzw. stager) i ładowało go bezpośrednio do pamięci, często wstrzykując w procesy takie jak powershell.exe, wscript.exe czy nawet w legalne procesy przeglądarki. W jednej z głośnych kampanii finansowych złośliwy PowerShell wykorzystywał API Windows do ładowania shellcode do pamięci i komunikacji z serwerem C2, zbierając dane o systemie, wykradając hasła z przeglądarek i klienta poczty, a następnie szyfrując ruch przy użyciu niestandardowych protokołów, aby utrudnić analizę sieciową. Kolejny charakterystyczny przykład dotyczy ataków, w których napastnicy w ogóle nie korzystali z makr, lecz z funkcji „DDE” (Dynamic Data Exchange) w dokumentach Word i Excel, co pozwalało na wywołanie poleceń systemowych z pominięciem części mechanizmów bezpieczeństwa. W takich scenariuszach złośliwe dokumenty inicjowały bezpośrednio cmd.exe lub powershell.exe z parametrami pobierającymi skrypty z odległych serwerów i wykonującymi je w pamięci. W praktyce po stronie ofiary widoczne były jedynie krótkotrwałe procesy wbudowanych narzędzi Windows, bez jakichkolwiek nowych plików binarnych, co sprawiało, że tradycyjne antywirusy oparte na sygnaturach plików pozostawały bezradne.
W środowiskach korporacyjnych istotną rolę odegrały też ataki fileless bazujące na Windows Management Instrumentation (WMI) oraz rejestrze systemowym. Przykładowo, jedna z analizowanych kampanii APT pokazała, jak napastnicy po uzyskaniu początkowego dostępu (np. przez spear phishing z załącznikiem Office) wykorzystywali WMI do utworzenia „permanent event subscription” – reguły reagującej na konkretne zdarzenia w systemie, takie jak uruchomienie procesu lub logowanie użytkownika. Reguła ta wskazywała na złośliwy skrypt PowerShell zapisany w rejestrze lub zaszyty bezpośrednio w konfiguracji WMI, dzięki czemu nie było konieczności utrzymywania widocznych plików na dysku. Po każdym logowaniu wywoływany był PowerShell z parametrem –EncodedCommand, który dekodował i wykonywał w pamięci właściwy payload, m.in. moduły do kradzieży danych uwierzytelniających z LSASS, skrypty do skanowania sieci wewnętrznej oraz narzędzia do ruchu lateralnego oparte na wbudowanym PsExec, WMI i PowerShell Remoting. Inny praktyczny przykład dotyczy grup cyberprzestępczych wykorzystujących „living off the land” do wdrażania ransomware bez klasycznych dropperów plikowych: napastnik po przejęciu konta administratora domeny wykorzystywał GPO i skrypty logowania logon scripts, które wykonywały w pamięci zakodowane w PowerShellu moduły szyfrujące. Często łączono to z nadużyciem narzędzi takich jak rundll32.exe czy regsvr32.exe (tzw. „Squiblydoo”), które pobierały skrypty z URL‑i i ładowały je w pamięci jako biblioteki lub komponenty COM, bez pozostawiania binariów na dysku. W kampaniach wymierzonych w instytucje finansowe spotykano również fileless keyloggery i backdoory oparte na .NET, wstrzykiwane przy użyciu refleksyjnego ładowania do procesów explorer.exe lub usług serwerowych; analiza powłamaniowa pokazała, że jedynymi śladami były podejrzane wpisy w harmonogramie zadań (schtasks.exe) wywołujące nietypowe komendy PowerShell oraz anomalie w zachowaniu pamięci procesów. W praktyce wszystkie te scenariusze łączy kilka cech: intensywne wykorzystanie legalnych narzędzi systemowych, brak trwałych plików malware na dysku, silne zaciemnianie kodu (obfuskacja) skryptów oraz oparcie detekcji bardziej na analizie zachowania i telemetrii pamięci niż na tradycyjnym skanowaniu plików.
Jak zabezpieczyć się przed atakami fileless?
Skuteczna obrona przed atakami fileless wymaga odejścia od myślenia wyłącznie w kategoriach „pliku z wirusem” i przejścia na model bezpieczeństwa oparty na zachowaniu, kontroli tożsamości oraz ścisłym nadzorze nad narzędziami wbudowanymi w system. Pierwszym filarem jest twarda konfiguracja środowiska (hardening). Obejmuje ona m.in. ograniczenie lub całkowite wyłączenie PowerShell, WMI, mshta.exe, regsvr32.exe czy rundll32.exe tam, gdzie nie są niezbędne biznesowo, a tam, gdzie są potrzebne – włączenie PowerShell Constrained Language Mode, weryfikacji podpisu skryptów oraz logowania wszystkich poleceń (Script Block Logging, Module Logging). Warto wdrożyć zasady AppLocker lub Windows Defender Application Control (WDAC), aby dopuszczać tylko zaufane skrypty i binaria, co znacząco utrudnia wykonywanie nieautoryzowanych komend w pamięci. Równolegle należy stosować zasady najmniejszych uprawnień (least privilege) – użytkownicy i konta usługowe nie powinni dysponować prawami administratora, a sesje uprzywilejowane powinny być skrupulatnie monitorowane i izolowane, np. poprzez dedykowane stacje administratorskie (PAW – Privileged Access Workstations). Krytycznym obszarem jest także zarządzanie aktualizacjami – ataki fileless bardzo często startują od wykorzystania luki w przeglądarce, pakiecie Office, sterowniku czy komponencie systemowym; kompleksowy system patch management oraz kontrola wersji oprogramowania na stacjach roboczych i serwerach znacząco zawężają powierzchnię ataku. Nie można pominąć konfiguracji makr w pakiecie Office – domyślne blokowanie makr z Internetu i niepodpisanych cyfrowo, stosowanie zasady „makra tylko z zaufanych lokalizacji” oraz edukacja użytkowników to jeden z najprostszych i najbardziej efektywnych sposobów przeciwdziałania scenariuszom, w których dokument inicjuje bezplikowy łańcuch infekcji.
Drugim kluczowym elementem obrony przed zagrożeniami fileless jest stałe monitorowanie zachowania systemu i pamięci, wsparte nowoczesnymi rozwiązaniami klasy EDR/XDR. Tradycyjny antywirus oparty na sygnaturach rzadko wychwyci złośliwy kod, który nie istnieje jako plik, dlatego organizacje powinny wdrożyć narzędzia analizujące aktywność procesów, nietypowe alokacje pamięci, sekwencje poleceń PowerShell, WMI oraz ruch sieciowy wychodzący z hostów. EDR powinien budować profil typowych zachowań w danym środowisku i generować alerty na podstawie odchyleń, np. gdy PowerShell jest uruchamiany przez proces pakietu Office, cmd.exe inicjuje połączenia HTTP(s) do nieznanych domen, WMI tworzy nowe zadania harmonogramu czy proces przeglądarki wstrzykuje kod do innego procesu. Warto skonfigurować zaawansowane logowanie w systemie Windows (m.in. zdarzenia Sysmon, szczegółowe logi PowerShell, rejestracja zdarzeń WMI) i centralizować je w systemie SIEM, który umożliwia korelację zdarzeń, budowę reguł detekcji opartych na MITRE ATT&CK oraz szybką analizę incydentów. Oprócz samych technologii niezbędne są procedury: regularne testy penetracyjne i ćwiczenia typu „purple team” pomagają odtworzyć ścieżki ataków fileless i dopasować reguły detekcji do specyfiki organizacji, a dobrze zdefiniowany plan reagowania na incydenty (IR playbook) określa, jak izolować hosty, jak wykonywać zrzuty pamięci (memory dump) do analizy oraz jak odtwarzać zdarzenia na podstawie logów. Uzupełnieniem jest warstwa zabezpieczeń tożsamości i sieci: silne uwierzytelnianie wieloskładnikowe (MFA) utrudnia przejęcie kont wykorzystywanych później do zdalnego wykonywania poleceń, segmentacja sieci ogranicza możliwości lateralnego ruchu napastnika, a filtrowanie DNS, inspekcja TLS i proxy webowe pozwalają wykrywać nietypowe, zaciemnione połączenia do serwerów C2, typowo używane w kampaniach fileless. Wreszcie, ciągłe szkolenia użytkowników w zakresie phishingu, rozpoznawania podejrzanych dokumentów oraz właściwych reakcji na alerty bezpieczeństwa zmniejszają szanse powodzenia pierwszej fazy ataku, która bardzo często zaczyna się od jednego kliknięcia – nawet jeśli dalszy etap infekcji ma już charakter całkowicie bezplikowy.
Podsumowanie
Ataki fileless stanowią poważne zagrożenie, ponieważ nie pozostawiają tradycyjnych śladów na dyskach twardych. Hakerzy wykorzystują narzędzia systemowe oraz inne techniki, by zainfekować systemy bez konieczności tworzenia nowych plików. Kluczowe w zabezpieczaniu się przed tego rodzaju zagrożeniami są: dokładny monitoring pamięci, regularne aktualizacje oraz stosowanie praktyk bezpieczeństwa, które utrudniają hakerom wykorzystanie legalnych narzędzi do nielegalnych celów. By zapewnić skuteczną ochronę, warto także edukować się na temat najnowszych metod i przykładów ataków fileless.
