Malware bez pliku: jak działa i jak się przed nim chronić na Windows

Malware bez pliku – co to jest i dlaczego jest tak groźny?

Definicja malware bez pliku (fileless malware)

Malware bez pliku (ang. fileless malware) to klasa złośliwego oprogramowania, która działa głównie w pamięci operacyjnej i nie zapisuje klasycznego pliku wykonywalnego na dysku. Tradycyjny wirus to zazwyczaj plik EXE, DLL lub skrypt zapisany na dysku, który antywirus może przeskanować. Fileless malware wykorzystuje natomiast legalne komponenty systemu Windows, takie jak PowerShell, WMI, rejestr Windows czy usługi systemowe, aby uruchomić złośliwy kod bez tworzenia łatwo wykrywalnego pliku.

W praktyce oznacza to, że typowe skanery plików (AV oparte głównie na sygnaturach) mogą mieć duży problem z wychwyceniem zagrożenia, bo na dysku nie ma nic, co wyglądałoby podejrzanie. Złośliwy kod może zostać wstrzyknięty bezpośrednio do pamięci innego procesu, działać wyłącznie jako skrypt lub być przechowywany w mniej oczywistych miejscach (np. w rejestrze) i ładowany dopiero w trakcie działania systemu.

Czym różni się malware bez pliku od klasycznych wirusów?

Różnica nie polega na „magii”, lecz na miejscu przechowywania i sposobie uruchomienia. Klasyczny malware:

• zostawia fizyczny plik na dysku (EXE, DLL, DOCM, JS, BAT itd.),
• jest stosunkowo łatwy do wykrycia za pomocą skanera plików,
• często wymaga ręcznego uruchomienia przez użytkownika (np. otwarcie załącznika).

Z kolei malware bez pliku najczęściej:

• wstrzykuje się w procesy systemowe (np. explorer.exe, powershell.exe, svchost.exe),
• wykorzystuje preinstalowane narzędzia Windows (PowerShell, WMI, rundll32, mshta, wscript),
• utrwala się w systemie bez obecności oczywistego pliku wykonywalnego, np. przez klucze rejestru, zadania Harmonogramu zadań, skrypty logowania.

Dlaczego fileless malware jest trudny do wykrycia?

Typowy antywirus od lat bazuje głównie na sygnaturach plików (choć dziś dochodzą do tego mechanizmy behawioralne i chmurowe). Gdy nie ma pliku – nie ma czego porównać z bazą sygnatur. Malware bez pliku korzysta z:

• pamięci RAM – proces istnieje, działa, ale po restarcie systemu jego ślad może zniknąć (chyba że utrwalenie następuje przez inne mechanizmy),
• podpisanych narzędzi Microsoftu – antywirus jest ostrożniejszy z blokowaniem np. PowerShella, bo to narzędzie administracyjne używane legalnie,
• szyfrowania i obfuskacji – polecenia PowerShell są zakodowane, tablice znaków mieszane, nazwy funkcji losowe, co utrudnia analizę.

Do tego wiele rozwiązań bezpieczeństwa w domyślnej konfiguracji nie loguje szczegółowo działań PowerShella czy WMI, zwłaszcza w systemach domowych. Dla atakującego to idealne środowisko – może wykonać złośliwe działania bez pozostawiania klasycznych śladów na dysku.

Jak działa malware bez pliku na Windows – przegląd technik

Etapy ataku z użyciem malware bez pliku

Pomimo innej techniki, scenariusz ataku da się rozbić na kilka typowych kroków. W uproszczeniu wygląda to tak:

1. Dostarczenie – phishingowy e-mail, zainfekowana strona, exploit w przeglądarce, złośliwa reklama, makro w dokumencie Office.
2. Wykonanie w pamięci – zamiast zapisywania pliku EXE na dysk, kod jest ładowany bezpośrednio do pamięci (np. przez PowerShell lub exploit).
3. Utrwalenie – atakujący dodaje klucze rejestru, zadania Harmonogramu, skrypty logowania czy WMI Event Consumers, które wznowią złośliwe działanie przy następnym uruchomieniu.
4. Realizacja celu – kradzież danych, ruch boczny po sieci, instalacja ransomware, keylogger, exfiltracja haseł z pamięci.

Kluczowe jest to, że główna logika ataku dzieje się w pamięci, a same mechanizmy utrwalenia mogą wyglądać jak zwykła konfiguracja systemu – bez wyraźnego, podejrzanego pliku.

Wykorzystanie PowerShella i WMI

PowerShell jest jednym z ulubionych narzędzi twórców malware bez pliku. To potężna powłoka skryptowa Windows, która:

• ma dostęp do .NET i API systemu,
• może pobierać dane z internetu (Invoke-WebRequest, System.Net.WebClient),
• może wstrzykiwać kod do innych procesów,
• jest domyślnie obecna w nowoczesnych wersjach Windows.

Przykładowy schemat działania:

• Użytkownik uruchamia „niewinny” plik .vbs, .js lub skrypt logowania.
• Skrypt w tle startuje powershell.exe z bardzo długą, zakodowaną komendą (np. Base64).
• PowerShell pobiera z serwera C2 (Command & Control) zaszyfrowany blok kodu, ładuje go do pamięci i wykonuje.
• W systemie nie pojawia się żaden nowy plik EXE, a wszystko działa w kontekście legalnego procesu PowerShell.

Podobnie działa WMI (Windows Management Instrumentation) – mechanizm do zdalnego zarządzania i monitorowania. Atakujący może:

• utworzyć WMI Event Consumer, który uruchomi złośliwy skrypt w odpowiedzi na określone zdarzenie (np. logowanie użytkownika),
• wykorzystać WMI do zbierania informacji o systemie i wysyłania ich na zewnątrz,
• sterować innymi komputerami w sieci, jeśli WMI jest tam włączone.

Ataki w oparciu o rejestr Windows

Rejestr Windows to częsty magazyn konfiguracji, ale dla atakującego staje się również schowkiem na złośliwy kod. Schemat wygląda często tak:

• Złośliwy kod (np. shellcode lub skrypt PowerShell) jest zaszyfrowany i zakodowany, a następnie zapisany w kluczu rejestru, np.:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
lub mniej oczywistym, głęboko ukrytym kluczu.

• Przy starcie systemu lub przy konkretnym zdarzeniu inny mechanizm (zadanie, skrypt, PowerShell) odczytuje dane z rejestru, deszyfruje i wykonuje w pamięci.
• Na dysku nie ma klasycznego pliku ze złośliwym kodem – jedynie niepozorny wpis w rejestrze.

To właśnie taki wzorzec działania sprawia, że wiele starszych narzędzi antywirusowych nie alarmuje, dopóki nie pojawi się wyraźna anomalia behawioralna.

Typowe wektory infekcji malware bez pliku

Phishing i złośliwe dokumenty Office

Najczęściej początek ataku jest bardzo „klasyczny” – e-mail phishingowy. Różnica leży w tym, co dzieje się po otwarciu załącznika. Popularny scenariusz:

1. Ofiara otrzymuje dokument Word lub Excel, rzekomo od znanej firmy, kuriera lub kontrahenta.
2. Po otwarciu pliku Office prosi o włączenie makr „aby zobaczyć poprawnie dokument”.
3. Makro uruchamia PowerShell, który pobiera z internetu zaszyfrowany fragment kodu.
4. Złośliwy kod ładowany jest bezpośrednio do pamięci, bez zapisywania na dysk – rozpoczyna się działanie malware bez pliku.

Jedno nieostrożne kliknięcie w „Włącz zawartość” wystarczy, żeby uruchomić cały łańcuch infekcji. Nawet jeśli antywirus zareaguje w którymś momencie, część szkodliwych działań mogła zostać już wykonana (np. kradzież haseł, założenie tylnej furtki).

Exploit kits i luki w przeglądarkach

Drugi popularny kanał to złośliwe strony WWW i reklamy (tzw. malvertising). Mechanizm działania:

• Użytkownik trafia na stronę, która zawiera skrypt sprawdzający wersję przeglądarki, wtyczek, systemu Windows.
• Jeśli wykryje podatną wersję (np. starego Internet Explorera lub niezałataną bibliotekę), wykorzystuje exploit do zdalnego wykonania kodu.
• Exploit z poziomu przeglądarki wstrzykuje złośliwy kod do pamięci procesu lub używa systemowych narzędzi do pobrania kolejnych elementów ataku.

Tutaj też złośliwe komponenty często nie trafiają na dysk jako klasyczny plik, a działają w pamięci. Bez aktualnego systemu i przeglądarki oraz bez ochrony typu exploit protection jest to scenariusz bardzo trudny do zauważenia dla laika.

Nadużycie narzędzi administracyjnych (Living off the Land)

Fileless malware wpisuje się w filozofię Living off the Land (LotL), czyli korzystania z tego, co już jest w systemie. Zamiast przywozić własne narzędzia, atakujący używa:

• powershell.exe
• wscript.exe / cscript.exe
• mshta.exe
• reg.exe / regsvr32.exe
• wmic.exe
• rundll32.exe

Te procesy są podpisane przez Microsoft i powszechnie używane, więc ich obecność nie budzi podejrzeń. Gdy działają nietypowo – np. PowerShell pobiera i uruchamia zaszyfrowany kod z dziwnego adresu URL – bez monitoringu zachowań trudno to zauważyć. Stąd rosnąca rola narzędzi typu EDR/XDR, które patrzą nie na sam proces, lecz na ciąg powiązanych zdarzeń (kto uruchomił PowerShell, z jakimi argumentami, jaki był dalszy łańcuch procesów).

Przykłady popularnych kampanii malware bez pliku

Ataki z użyciem PowerShell Empire, Cobalt Strike i podobnych frameworków

W środowiskach korporacyjnych często odnotowuje się kampanie, w których wykorzystywane są frameworki post-exploitation, takie jak PowerShell Empire czy Cobalt Strike (oryginalnie legalne narzędzia do testów penetracyjnych). Schemat bywa następujący:

• napastnik zdobywa początkowy dostęp (phishing, słabe hasło RDP, luka w serwerze),
• uruchamia script-stager w PowerShellu – mały kawałek kodu, który pobiera i odpala większy ładunek z serwera C2,
• agent Cobalt Strike działa w pamięci, komunikuje się szyfrowanymi kanałami z serwerem sterującym,
• nie ma nowego pliku EXE, a jedynie aktywny proces PowerShell / rundll32 z wstrzykniętym kodem.

Taki agent pozwala robić prawie wszystko: przechwytywać klawiaturę, zrzucać hasła z pamięci (np. z LSASS), poruszać się lateralnie po sieci, a na końcu zainstalować ransomware. Dopóki nikt nie monitoruje ruchu sieciowego i zachowań procesów, obecność takiego zagrożenia może pozostać niezauważona przez tygodnie.

Fileless ransomware – szyfrowanie bez widocznego pliku

Ransomware kojarzy się z dużym, widocznym procesem, który szyfruje pliki i zostawia notatkę o okupie. Istnieją jednak warianty, które korzystają z podejścia fileless. Przykładowy scenariusz:

1. Makro w dokumencie uruchamia PowerShell,
2. PowerShell pobiera zaszyfrowany moduł szyfrujący, ładuje go w pamięć,
3. kod w pamięci przy użyciu API systemu szyfruje pliki użytkownika,
4. jedynym „trwałym” śladem na dysku jest tekstowy plik z żądaniem okupu.

Nawet jeśli uda się usunąć wpisy rejestru lub zadania, które umożliwiają powtórne wykonanie, szkody w postaci zaszyfrowanych danych pozostaną. Dlatego ochrona przed fileless malware jest tak istotna w kontekście backupów i segmentacji uprawnień.

Malware w pamięci przeglądarki i iniekcja w procesy systemowe

Niektóre kampanie złośliwego oprogramowania celują bezpośrednio w przeglądarki (Chrome, Edge, Firefox), wykonując kod w ich kontekście. Ten kod może:

• podmieniać treść stron (np. panelu bankowego),
• przechwytywać formularze logowania,
• podsyłać własne skrypty JavaScript.

Jak rozpoznać, że coś jest nie tak? Symptomy infekcji fileless

Fileless malware rzadko zostawia oczywiste ślady. Da się jednak wychwycić sygnały ostrzegawcze, zwłaszcza jeśli zna się typowe objawy na poziomie użytkownika i administratora.

• Nietypowe okna PowerShell / wiersza poleceń otwierające się na ułamek sekundy lub migające przy starcie systemu.
• Spadki wydajności przy braku widocznego obciążenia – procesor „buzuje”, a w Menedżerze zadań widać głównie systemowe procesy.
• Nienaturalne połączenia sieciowe z PowerShell, wscript, rundll32 czy przeglądarki do nietypowych domen lub adresów IP.
• Zmiany w ustawieniach systemu: wyłączony Defender, wyłączone aktualizacje, zmodyfikowane zasady grup (GPO), dodane dziwne wyjątki w firewallu.
• Nowe zadania w Harmonogramie zadań, których nikt w firmie nie tworzył – często z niejasnymi nazwami lub wywołujące skrypty PowerShell.

W praktyce wiele incydentów zaczyna się od sygnału: „komputer nagle działa wolniej” albo „antywirus coś zgłosił i zamilkł”. Jeśli po takim epizodzie użytkownik widzi nietypowe alerty logowania, błędy certyfikatów w przeglądarce lub blokady konta domenowego – to są momenty, w których trzeba założyć najgorsze i zacząć diagnostykę.

Ochrona przed malware bez pliku na poziomie użytkownika

Bezpieczna obsługa poczty i dokumentów

Znaczna część ataków fileless startuje od naiwnego kliknięcia. Kilka prostych zasad mocno podnosi poziom bezpieczeństwa:

• Nie włączaj makr w Office „bo dokument tego wymaga”. Jeśli plik pochodzi spoza organizacji, makra powinny być domyślnie zablokowane. Gdy dokument jest rzekomo „z banku” lub „od kuriera”, otwórz osobno stronę dostawcy, nie klikaj linków ani makr w załączniku.
• Sprawdzaj nadawcę i temat. Literówki w domenie (np. „micros0ft.com”), niepasujący język, presja czasu – to typowe sygnały phishingu.
• Otwieraj załączniki w trybie tylko do odczytu i bez uruchamiania aktywnej zawartości (makra, ActiveX). W środowiskach firmowych warto używać trybu Protected View.
• Nie uruchamiaj plików .vbs, .js, .ps1 z poczty lub komunikatora. W normalnej pracy biurowej prawie nigdy nie ma potrzeby wykonywania takich skryptów z maila.

Codzienne nawyki, które ograniczają ryzyko

Poza pocztą, znaczenie mają również drobiazgi związane z codziennym korzystaniem z komputera:

• Pracuj na koncie bez uprawnień administratora. Jeśli malware uruchomi się jako zwykły użytkownik, trudniej mu modyfikować system, instalować sterowniki czy hakować inne procesy.
• Używaj nowoczesnej przeglądarki (Edge, Chrome, Firefox) z aktualizacjami i włączonym sandboxem; nie korzystaj z przestarzałego Internet Explorera do codziennej pracy.
• Aktualizuj oprogramowanie: system, przeglądarki, pakiet Office, czytniki PDF. Fileless exploit często wykorzystuje pojedynczą łatkę, której „ktoś zapomniał” zainstalować.
• Nie wyłączaj Windows Defender / antywirusa „bo spowalnia”. Jeśli coś jest za ciężkie, szukaj lżejszego rozwiązania, a nie całkowitego wyłączenia ochrony.

Backup i minimalizacja szkód

Nawet najlepsza ochrona nie daje gwarancji. W razie ransomware działającego z pamięci jedynym ratunkiem bywają kopie zapasowe:

• Twórz regularne kopie offline – na dysku odłączanym od komputera lub w systemie backupowym, do którego malware nie ma bezpośredniego dostępu.
• Testuj odtwarzanie. Kopia, której nigdy nie sprawdzono, często okazuje się bezużyteczna w krytycznym momencie.
• Nie trzymaj jedynej kopii danych w chmurze synchronizowanej na żywo. Jeśli ransomware zaszyfruje pliki lokalnie, zsynchronizuje też zaszyfrowane wersje.

Ochrona przed malware bez pliku na poziomie systemu i sieci

Konfiguracja PowerShell i innych narzędzi systemowych

W korporacyjnym środowisku warto podejść do PowerShell, WMI i innych komponentów „jak do ognia” – potrzebne, ale wymagają barier. Kilka praktycznych kroków:

• Włącz Constrained Language Mode dla PowerShell tam, gdzie nie są potrzebne zaawansowane moduły. Ogranicza to dostęp do niektórych funkcji .NET wykorzystywanych w atakach.
• Stosuj PowerShell Script Block Logging i Module Logging. Dzięki temu polecenia PowerShell (w tym te zakodowane w Base64) zapisują się w logach Windows.
• Ogranicz zdalny PowerShell (WinRM) wyłącznie do hostów i kont administracyjnych, które faktycznie go używają.
• Monitoruj i loguj WMI – zapisywanie zdarzeń tworzenia WMI Event Consumer oraz nietypowych zapytań pozwala w porę wyłapać nadużycia.

Wiele firm po pierwszej poważnej infekcji wprowadza prostą zasadę: skrypty PowerShell w działach biznesowych są blokowane, a administracja korzysta z osobnych, ściśle kontrolowanych kont z dostępem do narzędzi automatyzacji.

EDR/XDR i analiza zachowań procesów

Klasyczny antywirus często nie radzi sobie z fileless malware, dlatego w środowiskach biznesowych rośnie rola rozwiązań EDR/XDR. Ich zadania to m.in.:

• Śledzenie łańcucha procesów – kto uruchomił PowerShell, z jakimi parametrami, co uruchomił dalej, jakie pliki i rejestr zmodyfikował.
• Wykrywanie nietypowych zachowań, np. PowerShell z konta zwykłego użytkownika, który nagle skanuje inne komputery w sieci lub odczytuje setki haseł zapisanych w przeglądarce.
• Blokowanie znanych technik iniekcji (np. process hollowing, reflective DLL loading) niezależnie od tego, jaki kod jest ładowany.
• Centralne alarmowanie i korelacja zdarzeń z wielu hostów, co pomaga zauważyć kampanię rozchodzącą się po całej sieci.

Nawet proste reguły, typu „blokuj PowerShell startowany przez Word/Excel z parametrem -EncodedCommand”, potrafią zamknąć znaczną część popularnych wektorów ataku.

Segmentacja sieci i zasada najmniejszych uprawnień

Fileless malware, które już znalazło się w organizacji, będzie próbowało rozprzestrzenić się dalej. Utrudniają to:

• Segmentacja sieci – podział na VLAN-y / strefy (biuro, serwery, systemy krytyczne, goście) i minimalne otwarcie portów między nimi.
• Ograniczone uprawnienia na stacjach roboczych – zwykły użytkownik nie powinien mieć możliwości logowania się na serwery RDP ani wykonywania zadań administracyjnych.
• Kontrola narzędzi zdalnych (RDP, TeamViewer, AnyDesk, itp.) – whitelistowanie i logowanie połączeń, zakaz „dzikich” narzędzi do zdalnego pulpitu.
• Blokady aplikacji (AppLocker, WDAC) – dopuszczanie tylko określonych aplikacji i skryptów w newralgicznych segmentach.

Dobrze zaprojektowana segmentacja często powoduje, że atak kończy się na jednej stacji roboczej zamiast paraliżować całą firmę.

Konfiguracja Windows Defender i wbudowanych mechanizmów ochrony

Włączenie i dostrojenie funkcji Exploit Protection

Windows 10/11 mają wbudowane mechanizmy utrudniające wykorzystanie luk i technik fileless:

• Exploit Protection – zabezpieczenia na poziomie procesu (DEP, ASLR, kontrola przepływu, itp.). Warto je włączyć co najmniej dla przeglądarek, pakietu Office i czytników PDF.
• Kontrola dostępu do folderów (Controlled Folder Access) – pozwala określić, które aplikacje mogą modyfikować kluczowe katalogi (Dokumenty, Pulpit, udziały sieciowe). Szyfrujący moduł, który wystartuje z PowerShell, powinien zostać zablokowany.
• Monitorowanie reputacji aplikacji (SmartScreen) – blokuje nieznane i niepodpisane aplikacje pobrane z internetu lub załączników.

Na stacjach roboczych użytkowników, którzy nie potrzebują skryptowania, sensowne bywa ustawienie default deny dla skryptów PowerShell i JavaScript, z wyjątkiem zatwierdzonych lokalizacji i podpisanych plików.

Atak powierzchniowy: ograniczanie makr Office i skryptów

Dobrze skonfigurowany pakiet Office i polityki grupowe eliminują większość prostych kampanii:

• Blokowanie makr w plikach pobranych z internetu (funkcja Office „Block macros from running in Office files from the Internet”).
• Wymóg podpisu cyfrowego dla makr pochodzących z wewnętrznej sieci.
• Polityki GPO, które:
  • blokują uruchamianie powershell.exe i wscript.exe z Word/Excel,
  • wyłączają wykonywanie skryptów PowerShell w trybie RemoteSigned lub surowszym tam, gdzie to możliwe,
  • uniemożliwiają uruchamianie JScript/VBScript spoza zaufanych lokalizacji.

Monitorowanie i diagnostyka w praktyce

Kluczowe logi Windows, które pomagają wykryć fileless malware

System Windows sam w sobie generuje sporo informacji wystarczających do wychwycenia wielu ataków – pod warunkiem, że ktoś na nie patrzy. W szczególności:

• Logi PowerShell:
  • Microsoft-Windows-PowerShell/Operational – uruchomienia skryptów, błędy, ostrzeżenia,
  • Script Block Logging – pełne treści wykonywanych bloków skryptów.
• Logi bezpieczeństwa (Security) – zdarzenia logowania, eskalacje uprawnień, zmiany zasad.
• Logi WMI – nietypowe obiekty zdarzeń, konsumentów i filtrów.
• Windows Defender / AV – wykrycia behawioralne, blokowanie exploitów, zdarzenia Controlled Folder Access.

W mniejszej firmie wystarczy nawet proste przekazywanie logów do centralnego serwera (np. syslog, SIEM w chmurze) i podstawowe reguły ostrzegające o:

• PowerShell uruchamianym z parametrem -EncodedCommand,
• Word/Excel/Outlook, które uruchamiają procesy skryptowe,
• nagłych falach nieudanych logowań lub nietypowych logowaniach w środku nocy.

Analiza pamięci (memory forensics)

Gdy podejrzenie pada na fileless malware, klasyczne „szybkie skanowanie antywirusem” bywa niewystarczające. Wtedy przydają się techniki analizy pamięci:

• Zrzut pamięci RAM z podejrzanego systemu (np. RamCapture, DumpIt, narzędzia EDR).
• Analiza zrzutu w narzędziach typu Volatility / Rekall, które pozwalają:
  • zobaczyć listę procesów i wstrzyknięte moduły,
  • odkryć ukryte procesy (unlinked),
  • zidentyfikować sekcje pamięci wykonawczej (RX) bez odpowiadającego im pliku na dysku.

Takie podejście jest już domeną zespołów bezpieczeństwa (SOC/CSIRT), ale świadomość, że „trzeba złapać pamięć, zanim wyłączymy komputer”, bywa kluczowa przy współpracy z zewnętrznym zespołem reagowania.

Procedury reagowania na incydent typu fileless

Pierwsze kroki po wykryciu podejrzanej aktywności

Gdy pojawia się podejrzenie, że na stacji działa malware bez pliku, liczy się kolejność działań:

• Odłącz komputer od sieci (kabel, Wi‑Fi), ale nie wyłączaj go od razu. W pamięci mogą znajdować się kluczowe ślady.
• Utwórz zrzut pamięci, jeśli masz narzędzia i procedury – to zlecenie można też przekazać działowi IT lub zewnętrznemu zespołowi bezpieczeństwa.
• Zabezpiecz logi – zgraj dzienniki zdarzeń, logi antywirusa, logi EDR z kilku ostatnich dni.
• Udokumentuj objawy – komunikaty błędów, alerty antywirusa, godziny, użytkownika zalogowanego w momencie wykrycia.

Ograniczona rekonstrukcja zdarzeń i decyzja: czyścić czy przeinstalować

Po wstępnym zabezpieczeniu dowodów trzeba podjąć decyzję, jak traktować zainfekowaną stację roboczą lub serwer. Fileless malware rzadko zostawia na dysku jasny ślad w postaci pojedynczego pliku EXE – pełna pewność, że system jest „czysty”, bywa więc trudna do osiągnięcia.

• Reinstalacja zaufanego obrazu – w środowiskach biznesowych najbezpieczniejszy scenariusz to przywrócenie systemu z przygotowanego wcześniej, aktualnego obrazu (golden image) oraz odtworzenie danych z backupu.
• Czyszczenie i dalsze monitorowanie – czasem (np. przy pojedynczej stacji z mało krytycznymi danymi) dział IT decyduje się na próbę usunięcia artefaktów, wyczyszczenie rejestru, harmonogramu zadań i WMI + podniesienie poziomu monitoringu na kilka tygodni.
• Ocena ryzyka – jeżeli z maszyny następowały logowania administracyjne do kontrolerów domeny lub systemów krytycznych, bezpieczniej jest przyjąć założenie, że kompromitacja mogła się rozszerzyć i odpowiednio poszerzyć zakres działań.

W praktyce, im ważniejsze dane przetwarza dany system i im bardziej rozbudowane ma uprawnienia, tym szybciej decyzja przechyla się w stronę pełnej reinstalacji i wymuszonej zmiany haseł.

Śledzenie lateral movement i kompromitowanych kont

Fileless malware bardzo często służy do pierwszego wejścia do sieci i przygotowania gruntu pod szerszy atak. Po zabezpieczeniu pierwszego hosta trzeba ustalić, czy napastnikowi udało się przejść dalej.

• Analiza logowań – przegląd zdarzeń logowania (Security) z kilku dni, ze szczególnym naciskiem na:
  • logowania interaktywne i sieciowe z kont użytkowników, które normalnie tego nie robią,
  • logowania administracyjne na nietypowe stacje,
  • logowania poza zwykłymi godzinami pracy.
• Sprawdzenie sesji RDP i narzędzi zdalnych – czy z podejrzanej maszyny nie zestawiano połączeń na inne hosty, zwłaszcza serwery plików, serwery aplikacyjne, kontrolery domeny.
• Przegląd logów EDR/XDR – łańcuchy procesów, nietypowe użycie narzędzi administracyjnych (PsExec, PowerShell Remoting, WMIC).
• Identyfikacja kont do resetu – w pierwszej kolejności konta, których poświadczenia mogły zostać wyeksportowane (np. z pamięci LSASS, z managerów haseł) lub użyte do logowań z podejrzanych hostów.

Krótki raport „co, gdzie, kiedy i na jakim koncie” często przydaje się później przy rozmowie z zarządem albo ubezpieczycielem cyber ryzyk.

Komunikacja wewnętrzna i zewnętrzna podczas incydentu

Aspekt techniczny to tylko połowa historii. Nawet dobrze opanowany incydent może spowodować chaos organizacyjny, jeśli nikt nie wie, co się dzieje.

• Jasne instrukcje dla użytkowników – kto ma odłączyć komputer, komu zgłaszać podejrzane objawy, czy wolno korzystać z poczty i VPN.
• Jeden kanał komunikacji – np. wewnętrzny komunikator lub mailing z konta bezpieczeństwa. Rozproszone, sprzeczne komunikaty powodują dodatkowe szkody.
• Kontakt z dostawcami IT – jeżeli fragment infrastruktury jest utrzymywany przez zewnętrznego integratora lub dostawcę chmurowego, warto ich szybko włączyć w działania.
• Ocena obowiązków notyfikacyjnych – przy wycieku danych osobowych dział prawny może mieć obowiązek zgłoszenia incydentu do regulatora (np. w kontekście RODO) i klientów.

Zespół techniczny działa wtedy spokojniej, gdy równolegle ktoś inny „ogarnia” komunikację i wymagania formalne.

Budowanie odporności organizacji na fileless malware

Szkolenia użytkowników i testy socjotechniczne

Zdecydowana większość kampanii fileless zaczyna się od użytkownika, który kliknął w link, otworzył załącznik lub podał dane logowania na fałszywej stronie. Technologia bez wsparcia ludzi ma ograniczony efekt.

• Krótka, cykliczna edukacja – realne przykłady maili phishingowych, pokazanie, jak wygląda okno z pytaniem o włączenie makr, jak rozpoznać nietypowe zachowanie Word/Excel (dziwne komunikaty, długie „myślenie” po otwarciu pliku).
• Symulowane kampanie phishingowe – legalnie przeprowadzane przez dział bezpieczeństwa lub zewnętrznego dostawcę, z jasną informacją zwrotną, bez „publicznego zawstydzania” osób, które dały się złapać.
• Standard zgłaszania incydentów – krótka instrukcja „jeśli coś wygląda podejrzanie, zrób X, Y, Z i nie rób A, B, C” powinna być równie oczywista jak procedura ewakuacji z budynku.

Prosty przykład z życia: w jednej z firm dopiero po pokazaniu na szkoleniu prawdziwego okna PowerShell, które czasem miga na sekundę przy otwarciu zainfekowanego dokumentu, użytkownicy zaczęli zgłaszać takie przypadki zamiast je ignorować.

Standardy konfiguracji (hardening) stacji i serwerów

Dobrze przygotowany „baseline” konfiguracyjny znacząco zawęża pole manewru dla fileless malware. Zamiast wymyślać zasady na nowo, można bazować na istniejących rekomendacjach.

• Wzorce CIS Benchmarks / Microsoft Security Baselines – gotowe listy ustawień dla Windows, Office, przeglądarek, które można zaimportować do GPO i dostosować do własnych realiów.
• Wyłączenie zbędnych funkcji – komponenty typu SMBv1, nieużywane usługi, stare wersje .NET lub Java, które bywają wykorzystywane jako „furtki”.
• Standaryzacja przeglądarek – ograniczenie liczby dopuszczonych przeglądarek, centralne zarządzanie rozszerzeniami i politykami zabezpieczeń.
• Profilowanie ról – inne zasady dla stacji użytkowników biurowych, inne dla komputerów działu IT, inne dla serwerów aplikacyjnych.

Im bardziej konsekwentnie wdrożony jest hardening, tym łatwiej wykryć odstępstwa – każdy niestandardowo otwarty port, nietypowa usługa czy dodatkowe narzędzie administracyjne od razu rzuca się w oczy.

Regularne testy bezpieczeństwa i „purple teaming”

Teoretyczne zabezpieczenia dobrze jest co jakiś czas skonfrontować z praktyką. Fileless malware korzysta dokładnie z tych samych technik, które wykorzystują zespoły red teamingowe i pentesterzy.

• Ćwiczenia z użyciem frameworków ataków – np. emulacja technik z MITRE ATT&CK (PowerShell, WMI, iniekcje w pamięci) w kontrolowanym środowisku, aby sprawdzić, które z nich zostają wykryte.
• Współpraca zespołów „red” i „blue” – po każdej próbie ataku omawiane są zarówno skuteczne techniki unikania wykrycia, jak i błędne alarmy po stronie SOC.
• Weryfikacja scenariuszy reagowania – czy dział IT wie, jak wykonać zrzut pamięci? Czy helpdesk potrafi szybko odłączyć maszynę od sieci? Czy procedury resetu haseł są przygotowane pod incydent na szeroką skalę?

Takie ćwiczenia często ujawniają nie tyle dziury techniczne, co organizacyjne – brak uprawnień do szybkiego wdrożenia reguły blokującej czy brak kontaktu do osoby decyzyjnej poza godzinami pracy.

Przykładowe scenariusze ataków fileless i ich blokowanie

Makro Office → PowerShell → szyfrowanie udziałów sieciowych

Jeden z najczęstszych scenariuszy w małych i średnich firmach wygląda następująco:

1. Użytkownik otwiera „fakturę” w formacie DOCM.
2. Makro, po uzyskaniu zgody na uruchomienie, startuje PowerShell z zakodowanym parametrem -EncodedCommand.
3. PowerShell pobiera z internetu zaszyfrowany moduł szyfrujący i ładuje go bezpośrednio do pamięci.
4. Kod zaczyna szyfrować pliki na lokalnym dysku i na podpiętych udziałach sieciowych, komunikując się z serwerem C2.

Taki scenariusz można przerwać w kilku miejscach:

• blokując makra w plikach z internetu i wymuszając podpis cyfrowy w dokumentach wewnętrznych,
• zakazując uruchamiania powershell.exe z procesów Office (GPO, AppLocker/WDAC),
• stosując reguły Defendera i EDR blokujące szyfrowanie chronionych folderów przez nieznane procesy,
• segmentując sieć i ograniczając uprawnienia do udziałów – użytkownik nie ma pełnych praw zapisu wszędzie.

Jeżeli każdy z tych elementów zadziała choć częściowo, szkody zwykle ograniczają się do niewielkiego wycinka danych.

Wykorzystanie WMI i harmonogramu zadań do utrzymania się w systemie

Bardziej zaawansowany napastnik, po uzyskaniu pierwszego dostępu, spróbuje zapewnić sobie trwałość, również bez zapisywania klasycznych plików malware na dysku.

• Trwałość przez WMI – tworzenie WMI Event Filter i Event Consumer, które reagują np. na logowanie użytkownika lub start systemu i wywołują skrypt PowerShell w pamięci.
• Zadania w Harmonogramie (Task Scheduler) – zadanie wywołujące komendę sieciową (np. pobranie i uruchomienie kodu z serwera HTTP) przy każdym logowaniu lub o określonej godzinie.

Obronę można oprzeć na:

• regularnym przeglądzie zadań harmonogramu (szczególnie uruchamianych przez konta administracyjne i SYSTEM),
• monitorowaniu tworzenia i modyfikacji obiektów WMI (logi, reguły EDR),
• ograniczeniu dostępu do narzędzi zarządzających WMI (np. wmic.exe, PowerShell z modułem WMI) tylko do wybranych administratorów.

Living off the Land: zaufane narzędzia w roli malware

Ataki fileless bardzo często nie wprowadzają żadnych „nowych” binariów. Zamiast tego korzystają z narzędzi już obecnych w systemie – tzw. Living off the Land.

Przykładowe narzędzia i mechanizmy wykorzystywane w takim stylu:

• powershell.exe, wscript.exe, mshta.exe – uruchamianie złośliwego kodu z argumentów, rejestru lub internetu,
• certutil.exe – pobieranie i dekodowanie plików z sieci,
• regsvr32.exe – ładowanie komponentów COM i DLL bez klasycznego „instalowania” aplikacji,
• narzędzia administracyjne (PsExec, wmic, PowerShell Remoting) – rozprzestrzenianie się po sieci i wykonywanie poleceń na innych hostach.

Skuteczna obrona wymaga zmapowania, które z tych narzędzi są faktycznie potrzebne w danej organizacji, i wprowadzenia:

• list dozwolonych aplikacji (AppLocker/WDAC) – blokowanie rzadko używanych binariów systemowych na stacjach użytkowników,
• reguł EDR powiązanych z kontekstem – np. „certutil.exe uruchomiony przez przeglądarkę => alarm”,
• dobrych praktyk po stronie administratorów – np. osobne konta do administracji z ograniczonym logowaniem interaktywnym.

Plan działania dla małej i średniej firmy

Minimalny zestaw kroków na najbliższe 3 miesiące

Nie każda organizacja ma własny SOC i budżet na rozbudowany EDR. Mimo to można podnieść bezpieczeństwo przed fileless malware kilkoma rozsądnymi krokami.

1. Przegląd i wzmocnienie konfiguracji Windows Defender – włączenie Exploit Protection, Controlled Folder Access, SmartScreen, blokad skryptów tam, gdzie nie są potrzebne.
2. Ustawienie polityk Office – blokada makr z internetu, wymaganie podpisu dla makr wewnętrznych, GPO zakazujące uruchamiania narzędzi skryptowych z pakietu Office.
3. Segmentacja podstawowa – choćby prosty podział: użytkownicy / serwery / goście, z ograniczonym ruchem pomiędzy.
4. Centralizacja logów – eksport najważniejszych logów (Security, PowerShell, Defender) na jeden serwer i proste reguły alertów.
5. Szkolenie użytkowników – krótkie, konkretne, powtarzalne: phishing, makra, zgłaszanie incydentów.

Dobrze jest z góry wyznaczyć osobę lub mały zespół odpowiedzialny za te działania, z jasnym mandatem do wprowadzania zmian w konfiguracji.

Rozwój dojrzałości bezpieczeństwa w perspektywie roku

Po wykonaniu podstaw warto przejść do bardziej zaawansowanych elementów:

• Wdrożenie EDR/XDR – choćby w podstawowej wersji chmurowej, która zapewni analizę zachowań procesów i lepszą widoczność.

Najczęściej zadawane pytania (FAQ)

Co to jest malware bez pliku (fileless malware) w systemie Windows?

Malware bez pliku to rodzaj złośliwego oprogramowania, który działa głównie w pamięci RAM i nie zapisuje klasycznego pliku wykonywalnego (EXE, DLL itp.) na dysku. Zamiast tego wykorzystuje legalne komponenty systemu Windows, takie jak PowerShell, WMI, rejestr czy Harmonogram zadań, aby uruchomić i utrwalić złośliwy kod.

Dzięki temu tradycyjne skanery antywirusowe, oparte przede wszystkim na analizie plików na dysku, mają znacznie trudniejsze zadanie, bo „widocznych” plików malware po prostu nie ma lub są one ukryte w mniej oczywistych miejscach (np. w rejestrze).

Czym malware bez pliku różni się od zwykłego wirusa lub trojana?

Klasyczny wirus lub trojan zostawia na dysku wyraźny plik (np. EXE, DOCM z makrem, skrypt JS), który można zeskanować i porównać z bazą sygnatur antywirusa. Często wymaga też od użytkownika ręcznego uruchomienia – np. otwarcia załącznika z e‑maila.

Malware bez pliku zazwyczaj nie tworzy takiego pliku. Wstrzykuje się w istniejące procesy systemowe (np. powershell.exe, svchost.exe), przechowuje zaszyfrowany kod w rejestrze lub konfiguracji systemu i uruchamia się przy określonych zdarzeniach (start systemu, logowanie użytkownika), przez co jest znacznie trudniejsze do namierzenia.

Dlaczego fileless malware jest tak trudny do wykrycia przez antywirusa?

Antywirusy tradycyjnie opierają się na skanowaniu plików i ich sygnatur. W przypadku malware bez pliku nie ma klasycznego pliku wykonywalnego do przeskanowania, a złośliwy kod działa głównie w pamięci, często pod „parasolem” zaufanych, podpisanych narzędzi Microsoftu, takich jak PowerShell czy WMI.

Dodatkowo atakujący stosują szyfrowanie i obfuskację komend (np. zakodowany Base64 PowerShell), co utrudnia analizę. W wielu systemach domowych nie są też domyślnie włączone szczegółowe logi dla PowerShella czy WMI, więc podejrzane działania mogą pozostać niewidoczne dla standardowych narzędzi ochronnych.

Jak można się zarazić malware bez pliku na Windows?

Najczęstsze wektory infekcji są podobne jak przy klasycznym malware, ale inny jest sposób dalszego działania po infekcji. Typowe scenariusze to:

• Phishingowe e‑maile z dokumentami Office zawierającymi makra, które po włączeniu uruchamiają PowerShell i ładują kod tylko do pamięci.
• Złośliwe strony WWW lub reklamy (malvertising), które wykorzystują luki w przeglądarce lub wtyczkach do zdalnego wykonania kodu w pamięci.
• Nadużycie narzędzi administracyjnych (PowerShell, WMI, Harmonogram zadań, rejestr), szczególnie w sieciach firmowych.

W każdym z tych przypadków kluczowe jest to, że zasadnicza część złośliwego kodu nie jest zapisywana na dysku jako osobny plik EXE, tylko wykonywana „w locie” w pamięci.

Jak sprawdzić, czy na moim komputerze działa fileless malware?

Wykrycie fileless malware przez zwykłego użytkownika jest trudne, bo rzadko zostawia ono oczywiste ślady. Warto jednak zwracać uwagę na nietypowe objawy, takie jak: nagłe wysokie zużycie CPU lub RAM przez procesy systemowe (np. powershell.exe, wmi, svchost), niespodziewane okna PowerShella czy dziwne zadania w Harmonogramie zadań.

Bardziej techniczni użytkownicy mogą dodatkowo:

• Przejrzeć uruchomione procesy i ich argumenty (np. bardzo długie, zakodowane parametry PowerShella).
• Sprawdzić podejrzane wpisy w rejestrze (klucze Run, RunOnce, nieznane skrypty logowania).
• Skorzystać z zaawansowanych narzędzi typu EDR lub skanerów analizujących zachowanie procesów, a nie tylko pliki.

Jak skutecznie chronić Windows przed malware bez pliku?

Ochrona przed malware bez pliku wymaga połączenia kilku technik, nie wystarczy sam „tradycyjny” antywirus. Podstawowe kroki to:

• Regularne aktualizacje systemu, przeglądarek i wtyczek, aby minimalizować ryzyko wykorzystania luk.
• Wyłączenie lub ograniczenie makr w dokumentach Office, zwłaszcza z internetu i e‑maili.
• Ograniczenie dostępu do PowerShella (np. wersja Constrained Language Mode, blokada dla zwykłych użytkowników, pełne logowanie poleceń).
• Używanie rozwiązania bezpieczeństwa, które analizuje zachowanie procesów (ochrona behawioralna, EDR), a nie tylko pliki na dysku.

W środowiskach firmowych ważne są też reguły AppLocker lub WDAC, segmentacja sieci i monitorowanie aktywności WMI oraz Harmonogramu zadań, aby szybciej wychwycić nietypowe działania.

Czy zwykły darmowy antywirus wystarczy przeciwko fileless malware?

Darmowy antywirus zapewnia podstawową ochronę, ale w przypadku malware bez pliku może być niewystarczający, jeśli opiera się głównie na sygnaturach plików. Wiele nowoczesnych silników ma już moduły behawioralne i ochronę w chmurze, jednak poziom ich zaawansowania różni się między produktami.

Dla użytkownika domowego ważniejsze od „marki” antywirusa bywa przestrzeganie dobrych praktyk (nie włączanie makr, ostrożność przy załącznikach, aktualizacje) oraz włączenie funkcji takich jak ochrona exploitów czy kontrola skryptów. W firmach warto rozważyć rozwiązania klasy EDR/XDR, które lepiej radzą sobie z atakami działającymi wyłącznie w pamięci.

Co warto zapamiętać

• Malware bez pliku działa głównie w pamięci RAM i nie zapisuje klasycznego pliku wykonywalnego na dysku, przez co omija tradycyjne skanery antywirusowe oparte na sygnaturach.
• Fileless malware intensywnie wykorzystuje legalne komponenty Windows (PowerShell, WMI, rejestr, harmonogram zadań), działając w kontekście zaufanych procesów systemowych.
• Różni się od klasycznych wirusów tym, że nie pozostawia oczywistych plików EXE/DLL, trudniej go przeskanować i często nie wymaga typowego „kliknięcia” pliku przez użytkownika.
• Atak składa się zwykle z etapów: dostarczenie (phishing, exploit, makro), wykonanie w pamięci (np. przez PowerShell), utrwalenie w systemie (rejestr, zadania, WMI) oraz realizacja celów takich jak kradzież danych czy ransomware.
• PowerShell i WMI są kluczowymi narzędziami atakujących, bo pozwalają pobierać i wykonywać zaszyfrowany kod z sieci, wstrzykiwać go w inne procesy i automatyzować złośliwe działania bez tworzenia nowych plików.
• Rejestr Windows może służyć jako „schowek” na zakodowany złośliwy kod, który jest później odczytywany i wykonywany w pamięci, co sprawia, że na dysku nie ma widocznego, podejrzanego pliku.
• Trudność wykrycia wynika także z domyślnie słabego logowania zdarzeń PowerShell/WMI oraz z wykorzystania szyfrowania i obfuskacji, które ukrywają prawdziwe działanie komend przed analizą.

Warte uwagi:

• 

  Jak używać PowerShell do codziennych zadań

• 

  Historia pierwszego wirusa komputerowego

• 

  Jak napisać prosty skrypt bash – poradnik dla…

• 

  Historia jednego wirusa – jak NotPetya sparaliżował świat

• 

  Monitorowanie zasobów systemowych z pomocą prostych skryptów

• 

  Najlepsze darmowe antywirusy 2025 – test i ranking