Windows ma własne narzędzia do ataku. Jak hakerzy wykorzystują zaufane komponenty systemu

Najbardziej niebezpieczny proces w Windows nie zawsze wygląda jak malware.

Czasami ma podpis Microsoftu.

Czasami znajduje się dokładnie tam, gdzie powinien:

C:\Windows\System32\

Czasami uruchamia go legalna aplikacja.

A czasami jedyną rzeczą, która zdradza atak, jest to, kto uruchomił dany proces, z jakimi argumentami został uruchomiony i co zrobił kilka sekund później.

To fundament techniki Living off the Land, określanej również jako LOTL. Atakujący wykorzystuje narzędzia już obecne w systemie zamiast dostarczać własne programy. CISA i partnerzy określają LOLBins jako jeden z istotnych elementów takich operacji, ponieważ legalne komponenty są obecne w środowisku jeszcze przed rozpoczęciem ataku.

To zmienia filozofię obrony.

Nie wystarczy już zapytać:

Czy uruchomił się malware?

Trzeba zapytać:

Czy legalny proces właśnie został użyty w sposób, którego nie powinien wykonywać?

I tutaj zaczyna się prawdziwa zabawa.

Windows jest pełen binariów, które można wykorzystać przeciwko niemu

System Windows zawiera setki narzędzi administracyjnych, diagnostycznych i kompatybilnościowych.

Normalny administrator używa ich do:

• zarządzania systemem,
• instalowania komponentów,
• konfiguracji usług,
• obsługi certyfikatów,
• automatyzacji,
• diagnostyki,
• uruchamiania bibliotek,
• zarządzania aplikacjami.

Atakujący widzi dokładnie te same możliwości.

Różnica polega na celu.

Wśród często nadużywanych komponentów znajdują się m.in.:

MITRE ATT&CK klasyfikuje wiele takich przypadków w ramach System Binary Proxy Execution, T1218. Idea jest prosta: legalny komponent systemu staje się pośrednikiem w wykonaniu operacji, której normalnie nie kojarzylibyśmy z danym programem.

Najważniejsza rzecz: podpis Microsoftu nie oznacza bezpiecznego zachowania

To jedna z najbardziej niebezpiecznych mentalnych pułapek.

Administrator widzi:

C:\Windows\System32\rundll32.exe

Podpis:

Microsoft Windows

Status:

Verified

I kończy analizę.

To błąd.

Podpis odpowiada przede wszystkim na pytanie:

Czy ten plik pochodzi od zaufanego wydawcy i nie został zmodyfikowany?

Nie odpowiada natomiast:

Czy ktoś właśnie wykorzystuje ten legalny program do wykonania złośliwej operacji?

To ogromna różnica.

Wyobraźmy sobie:

explorer.exe
    ↓
rundll32.exe
    ↓
DLL
    ↓
połączenie sieciowe

Sam rundll32.exe może być całkowicie legalny.

Podejrzany może być kontekst jego uruchomienia.

Parent process często mówi więcej niż nazwa procesu

W analizie incydentu jednym z najważniejszych pytań jest:

Kto uruchomił ten proces?

Przykład:

explorer.exe
    └── rundll32.exe

może być normalnym zdarzeniem.

Ale:

winword.exe
    └── rundll32.exe

powinno już zwrócić uwagę.

Jeszcze ciekawiej:

outlook.exe
    └── mshta.exe
        └── powershell.exe

To nie jest automatycznie dowód kompromitacji.

Ale jest to łańcuch procesów wymagający analizy.

I właśnie tutaj tradycyjne podejście:

"czy plik jest malware?"

przegrywa.

Potrzebujemy:

Process
+
Parent
+
CommandLine
+
User
+
Integrity Level
+
Network
+
Loaded Modules
+
File Origin
+
Timing

rundll32.exe — zaufany pośrednik

rundll32.exe jest legalnym komponentem Windows przeznaczonym do uruchamiania określonych funkcji eksportowanych przez biblioteki DLL.

Problem polega na tym, że z punktu widzenia atakującego jest to już gotowy mechanizm uruchamiania kodu.

Nie trzeba więc tworzyć własnego loadera.

Można wykorzystać istniejący.

Schemat wygląda koncepcyjnie tak:

Attack infrastructure
        ↓
malicious DLL
        ↓
rundll32.exe
        ↓
DLL export
        ↓
payload

Dla systemu:

rundll32.exe

jest znanym komponentem.

Dla analityka liczy się natomiast:

• jaka DLL została wskazana,
• skąd pochodzi,
• czy znajduje się w standardowym katalogu,
• kto ją utworzył,
• jaki proces uruchomił rundll32,
• czy nastąpiło połączenie sieciowe.

Najciekawsze pytanie brzmi: skąd pochodzi DLL?

Jeżeli zobaczymy:

C:\Windows\System32\example.dll

sytuacja wygląda inaczej niż:

C:\Users\Public\example.dll

albo:

C:\Users\<user>\AppData\Local\Temp\example.dll

Nie oznacza to automatycznie malware.

Ale lokalizacja jest potężnym sygnałem kontekstowym.

Jeszcze lepszy jest czas:

DLL created
    ↓
2 seconds
    ↓
rundll32.exe
    ↓
network connection

To już znacznie ciekawszy wzorzec.

regsvr32.exe i problem zaufanego narzędzia

regsvr32.exe służy do rejestrowania komponentów COM/DLL.

Z punktu widzenia administratora jest to narzędzie systemowe.

Z punktu widzenia atakującego może być kolejnym sposobem na wykorzystanie zaufanego mechanizmu systemu.

MITRE klasyfikuje nadużywanie regsvr32.exe w ramach T1218.010.

Dlatego reguła:

if process == regsvr32.exe
then alert

jest bezwartościowa.

W środowisku produkcyjnym regsvr32.exe może być używany legalnie.

Znacznie lepszy model:

regsvr32.exe
+
nietypowy parent
+
nietypowa ścieżka DLL
+
nietypowy użytkownik
+
nietypowa pora
+
network activity

To właśnie jest detekcja behawioralna.

mshta.exe — mały proces, duży problem

mshta.exe jest szczególnie interesujący.

Microsoft sam wskazywał w swoich materiałach bezpieczeństwa na możliwość wykorzystania mshta.exe do wykonywania złośliwych skryptów oraz komunikacji z infrastrukturą C2. W 2026 r. Microsoft opisywał również możliwość blokowania wychodzących połączeń sieciowych tego procesu jako sposób ograniczania określonych łańcuchów ataku.

To dobry przykład szerszego problemu:

trusted executable
        ↓
unexpected capability
        ↓
malicious use

Samo istnienie mshta.exe nie jest problemem.

Problemem jest jego kontekst użycia.

Przykładowo:

Word
 ↓
mshta
 ↓
PowerShell
 ↓
network

powinien wyglądać zupełnie inaczej w systemie EDR niż:

legitimate installer
 ↓
mshta

LOLBin nie musi być malware

To bardzo ważne.

LOLBins nie są „złośliwymi programami”.

To legalne narzędzia.

Dlatego nie możemy po prostu usunąć:

rundll32.exe
regsvr32.exe
mshta.exe
msiexec.exe
powershell.exe

z systemu.

CISA wprost zwraca uwagę na problem blokowania LOTL bez odpowiedniego kontekstu. Te same narzędzia mogą być niezbędne w legalnych operacjach administracyjnych.

To tworzy jeden z trudniejszych problemów bezpieczeństwa Windows:

narzędzie potrzebne administratorowi może być jednocześnie narzędziem potrzebnym atakującemu.

Dlatego bezpieczeństwo powinno patrzeć na łańcuch

Nie:

mshta.exe = zły

ale:

Email client
    ↓
Office document
    ↓
mshta.exe
    ↓
PowerShell
    ↓
Internet
    ↓
new executable

To zupełnie inny poziom detekcji.

Przykładowy model analizy

               PROCESS TREE

explorer.exe
     │
     └── outlook.exe
           │
           └── winword.exe
                 │
                 └── mshta.exe
                       │
                       └── powershell.exe
                             │
                             └── network connection

Każdy element osobno może być legalny.

Cały łańcuch już nie wygląda normalnie.

Sysmon jest tutaj niezwykle użyteczny

Na Netbe istnieje już osobny materiał dotyczący wykorzystania Sysmon do zaawansowanego monitorowania Windows Server.

W kontekście LOLBins najważniejszy jest przede wszystkim telemetryczny kontekst procesu.

Szczególnie interesują nas zdarzenia dotyczące:

Process Create
Network Connection
Image Load
File Create
Registry activity

Przykładowo Sysmon Event ID 1 dostarcza informacji o utworzeniu procesu.

To pozwala budować zależności:

ParentImage
        ↓
Image
        ↓
CommandLine
        ↓
User

I właśnie tutaj zaczyna się prawdziwy threat hunting.

Przykładowe pytania dla analityka

Zamiast szukać „wirusa”, szukamy anomalii.

Pytanie 1

Czy rundll32.exe został uruchomiony przez nietypowego rodzica?

Pytanie 2

Czy DLL pochodzi z:

Temp
Downloads
AppData
Public
Network Share

?

Pytanie 3

Czy proces zaraz po uruchomieniu nawiązał połączenie sieciowe?

Pytanie 4

Czy użytkownik normalnie korzysta z tego programu?

Pytanie 5

Czy zdarzenie pojawiło się zaraz po otwarciu dokumentu?

Pytanie 6

Czy proces utworzył kolejny interpreter?

Na przykład:

mshta
 ↓
powershell

albo:

winword
 ↓
cmd

Takie relacje są często znacznie bardziej wartościowe niż klasyczny hash pliku.

Event ID 4688 też ma znaczenie

Windows Security Event 4688 – A new process has been created może dostarczyć informacji o uruchamianych procesach.

Problem?

Domyślne logowanie może być zbyt ubogie.

W praktyce warto zadbać o rejestrowanie command line, ponieważ:

process.exe

mówi niewiele.

Natomiast:

process.exe [argumenty]

może ujawnić zamiar.

To różnica między:

"uruchomił się PowerShell"

a:

"PowerShell został uruchomiony w konkretnym kontekście i wykonał określoną operację"

Najlepsze detekcje zaczynają się od procesu nadrzędnego

Przykładowa logika:

IF

    process = mshta.exe

AND

    parent = office application

THEN

    increase risk score

Jeszcze lepiej:

IF

    process = mshta.exe

AND

    parent = office application

AND

    child = powershell.exe

AND

    network_connection = true

THEN

    high confidence alert

To oczywiście uproszczony przykład.

W rzeczywistym EDR reguła powinna uwzględniać:

• użytkownika,
• urządzenie,
• reputację pliku,
• podpis,
• lokalizację,
• częstotliwość,
• historię procesu,
• adres docelowy,
• inne procesy,
• aktywność po wykonaniu.

AppLocker może ograniczyć powierzchnię ataku

Na Netbe znajduje się już szczegółowy poradnik konfiguracji AppLocker.

AppLocker pozwala kontrolować uruchamianie aplikacji między innymi według:

• ścieżki,
• wydawcy,
• hash,
• reguł dla określonych typów plików.

Ale LOLBins pokazują jego podstawowe ograniczenie:

jeżeli dopuszczasz legalny komponent, nie oznacza to automatycznie, że dopuściłeś tylko legalne zachowanie tego komponentu.

Dlatego sama kontrola aplikacji nie wystarczy.

Potrzebujemy połączenia:

Application Control
+
EDR
+
Logging
+
Behavior Analytics

WDAC idzie jeszcze dalej

W środowiskach wymagających mocniejszej kontroli Microsoft oferuje Windows Defender Application Control.

Na Netbe temat WDAC został już omówiony szerzej w artykule o zaawansowanym bezpieczeństwie Windows 11.

WDAC może znacząco ograniczyć możliwość uruchamiania nieautoryzowanego kodu.

Ale znowu:

trusted Microsoft binary

może pozostać dozwolony.

A jeżeli dozwolony proces posiada funkcję, którą można wykorzystać do proxy execution, sama allowlista nie rozwiązuje całego problemu.

Dlatego:

WDAC ≠ pełna ochrona przed LOLBins

WDAC jest warstwą kontroli.

EDR i telemetryka są kolejną.

Microsoft sam ostrzega przed aplikacjami omijającymi App Control

Microsoft publikuje listę aplikacji i komponentów, które mogą być wykorzystywane do obchodzenia polityk kontroli aplikacji. W aktualnych materiałach dotyczących App Control wskazuje konkretne programy, które w zależności od scenariusza mogą wymagać blokowania lub dodatkowych ograniczeń.

To pokazuje zmianę filozofii bezpieczeństwa.

Nie istnieje już prosty podział:

Microsoft binary = trusted
unknown binary = malware

Znacznie lepszy model to:

trusted binary
        +
trusted context
        =
normal

trusted binary
        +
abnormal context
        =
investigate

PowerShell jest tylko jednym elementem układanki

Na Netbe jest już osobny materiał poświęcony technikom PowerShell malware.

To ważne, ponieważ PowerShell jest często przedstawiany jako „narzędzie hakerów”.

To znowu prowadzi do złej obrony.

Nie można po prostu powiedzieć:

Zablokujmy PowerShell.

W wielu organizacjach PowerShell jest podstawowym narzędziem administracyjnym.

Lepsze pytanie:

KTO
 ↓
URUCHOMIŁ
 ↓
POWERSHELL
 ↓
Z JAKIMI ARGUMENTAMI
 ↓
Z JAKIEGO PROCESU
 ↓
I CO ZROBIŁ POTEM?

To samo dotyczy:

rundll32
regsvr32
mshta
msiexec
certutil
msbuild
wmic

Najgorszy scenariusz: zaufany łańcuch

Wyobraźmy sobie atak:

phishing
   ↓
Office
   ↓
trusted Windows binary
   ↓
script interpreter
   ↓
credential access
   ↓
discovery
   ↓
lateral movement
   ↓
ransomware

Nie musi istnieć jeden spektakularny plik:

malware.exe

który antywirus znajdzie po hash’u.

Atak może składać się z legalnych elementów.

To właśnie dlatego LOTL jest tak trudne do wykrycia. CISA, FBI, NSA i partnerzy międzynarodowi wskazują, że techniki te są używane m.in. przez zaawansowanych aktorów do omijania klasycznych mechanizmów bezpieczeństwa.

Jak administrator może zwiększyć odporność Windows?

Nie trzeba zaczynać od kupowania kolejnego produktu bezpieczeństwa.

Najpierw trzeba poprawić widoczność.

1. Logowanie procesów

Włącz:

Process Creation
Command Line Logging

2. Sysmon

Wdrożenie Sysmon pozwala znacząco zwiększyć ilość danych dostępnych do analizy.

Na Netbe znajduje się praktyczny przewodnik dotyczący jego konfiguracji.

3. Monitorowanie parent-child

Szczególnie:

Office → PowerShell
Office → cmd
Office → mshta
Office → rundll32
Browser → unusual binary
Service → unusual interpreter

4. Monitorowanie lokalizacji plików

Szczególnie:

Temp
AppData
Downloads
Public
UNC paths
user-writable directories

5. Monitorowanie sieci

Legalny komponent Windows wykonujący nietypowe połączenie z Internetem może być znacznie ciekawszym sygnałem niż sam fakt jego uruchomienia.

6. AppLocker / WDAC

Ograniczaj możliwość wykonywania nieautoryzowanego kodu tam, gdzie jest to operacyjnie możliwe.

7. Defender / EDR

Nie wyłączaj ochrony tylko dlatego, że atakujący może używać legalnych narzędzi.

Wręcz przeciwnie.

Wykorzystuj telemetrykę EDR do korelacji zachowań.

Co powinien zobaczyć SOC?

Dobrze skonfigurowany monitoring powinien umożliwić odpowiedź na kilka pytań:

WHO?

Kto wykonał proces?

WHAT?

Co uruchomił?

FROM WHERE?

Z jakiej lokalizacji?

BY WHOM?

Jaki proces był rodzicem?

WITH WHAT?

Jakie argumenty command line wykorzystano?

THEN WHAT?

Co proces zrobił później?

To ostatnie pytanie jest często najważniejsze.

Proces sam w sobie nie jest IOC

To bardzo ważna zmiana myślenia.

Nie:

rundll32.exe = IOC

ale:

rundll32.exe
+
nietypowy parent
+
DLL z katalogu użytkownika
+
network connection
+
podejrzany timing

To dopiero staje się interesujące.

W świecie LOTL kontekst jest IOC.

Dlaczego klasyczny antywirus może mieć problem?

Klasyczny model detekcji często zakłada:

plik
 ↓
sygnatura
 ↓
werdykt

LOTL próbuje ominąć ten model:

legalny plik
 ↓
legalny podpis
 ↓
legalny katalog
 ↓
nielegalne użycie

Nie trzeba więc koniecznie ukrywać malware.

Można ukryć intencję.

I to jest dużo trudniejszy problem.

Windows nie jest tutaj „zepsuty”

To również trzeba powiedzieć jasno.

Nie jest błędem, że Windows posiada:

PowerShell
rundll32
regsvr32
mshta
msiexec
certutil

Problem wynika z tego, że system operacyjny musi jednocześnie:

• umożliwiać administrację,
• obsługiwać kompatybilność,
• uruchamiać starsze aplikacje,
• pozwalać na automatyzację,
• obsługiwać komponenty COM/.NET,
• wykonywać operacje systemowe.

Atakujący korzysta z tych samych funkcji.

To klasyczny problem dual-use.

Funkcja potrzebna administratorowi może być jednocześnie funkcją potrzebną napastnikowi.

Nowoczesna obrona Windows powinna wyglądać inaczej

Najbardziej rozsądny model to warstwy:

                 USER
                   │
                   ▼
          Identity / MFA
                   │
                   ▼
          Application Control
          WDAC / AppLocker
                   │
                   ▼
             Defender / EDR
                   │
                   ▼
           Process Telemetry
                   │
                   ▼
              Sysmon
                   │
                   ▼
                 SIEM
                   │
                   ▼
          Behavioral Detection

Żadna warstwa nie jest idealna.

Ale razem tworzą znacznie trudniejszy cel.

Najważniejsza zasada dla administratora

Nie próbuj blokować każdego legalnego narzędzia, którego kiedyś użył atakujący.

To prowadzi do chaosu.

Zamiast tego ustal:

Co jest normalne?

Następnie:

Co jest rzadkie?

I na końcu:

Co jest niemożliwe?

Jeżeli użytkownik działu księgowości uruchamia rundll32.exe raz na pół roku, nie oznacza to jeszcze ataku.

Jeżeli ten sam użytkownik:

otwiera dokument
    ↓
uruchamia mshta
    ↓
mshta uruchamia PowerShell
    ↓
PowerShell łączy się z nową domeną
    ↓
pojawia się plik w AppData

to sytuacja wygląda już zupełnie inaczej.

Podsumowanie

Najgroźniejszą cechą LOLBins jest właśnie ich normalność.

Atakujący nie musi przynosić do systemu całego zestawu narzędzi.

Windows już go posiada.

Może wykorzystać:

rundll32
regsvr32
mshta
msiexec
PowerShell
certutil
msbuild
WMI

Nie dlatego, że te programy są złośliwe.

Dlatego, że mają funkcje, które można wykorzystać w nieprawidłowym kontekście.

Dlatego współczesne bezpieczeństwo Windows nie może opierać się wyłącznie na pytaniu:

„Czy ten plik jest zaufany?”

Musi pytać:

„Czy ten zaufany plik zachowuje się tak, jak powinien?”

To różnica między klasycznym antywirusem a współczesnym threat huntingiem.

I właśnie tutaj Sysmon, Defender, EDR, AppLocker, WDAC i centralna analiza logów zaczynają mieć sens jako system, a nie zbiór niezależnych checkboxów.

Jeżeli Windows ma być naprawdę odporny na ataki Living off the Land, administrator nie powinien próbować wyeliminować wszystkich LOLBins.

Powinien sprawić, żeby ich nadużycie pozostawiało ślad, który da się szybko zauważyć.

Źródła techniczne

• MITRE ATT&CK – System Binary Proxy Execution (T1218)
• CISA – Identifying and Mitigating Living Off the Land Techniques
• Microsoft – Applications that can bypass App Control
• Microsoft – Monthly Threat Protection News, April 2026
• Netbe – Sysmon na Windows Server
• Netbe – AppLocker
• Netbe – Windows 11: zaawansowane bezpieczeństwo

Polecane wpisy

Jak przeskanować komputer z wirusów cmd

Jak przeskanować komputer z wirusów cmd Komputery są narażone na różnego rodzaju zagrożenia, w tym wirusy, malware i inne złośliwe Czytaj dalej

Stałe 100 % zużycie dysku w Windows 11 – nawet przy niewielkiej aktywności systemu

🔄 Problem: Stałe 100 % zużycie dysku w Windows 11 – nawet przy niewielkiej aktywności systemu Wielu użytkowników Poland (i na Czytaj dalej