Wprowadzenie do problemu / definicja
Omijanie systemów EDR pozostaje jednym z najważniejszych obszarów rozwoju technik ofensywnych w środowisku Windows. Najnowsze analizy opisują podejście określane jako process parameter poisoning, w którym złośliwy ładunek nie trafia do procesu z użyciem najbardziej monitorowanych mechanizmów wstrzykiwania kodu, lecz jest ukrywany w strukturach inicjalizacyjnych tworzonych podczas uruchamiania procesu.
To istotna zmiana z punktu widzenia obrony, ponieważ wiele narzędzi EDR nadal koncentruje się na wykrywaniu klasycznych wzorców process injection, takich jak zdalna alokacja pamięci, zapis do przestrzeni obcego procesu czy przejęcie wykonania za pomocą dobrze znanych interfejsów API.
W skrócie
Badacze opisali technikę evasji, która pozwala ukryć kod w standardowych strukturach startowych nowego procesu Windows. Dzięki temu atakujący może ograniczyć użycie wywołań API najczęściej kojarzonych z process injection, co utrudnia wykrycie aktywności przez rozwiązania ochronne oparte głównie na telemetrii z user mode.
W testach podstawowy wariant tej metody nie wywoływał alertów w analizowanym rozwiązaniu EDR. Po połączeniu go z dodatkowymi technikami, takimi jak DLL unhooking i ograniczanie ładowania bibliotek spoza ekosystemu Microsoft, skuteczność detekcji spadła jeszcze bardziej.
Kontekst / historia
Klasyczne process injection od lat opiera się na rozpoznawalnej sekwencji działań: utworzeniu procesu, zaalokowaniu pamięci, zapisaniu ładunku oraz przekazaniu sterowania do nowego kodu. Właśnie dlatego produkty EDR szczególnie uważnie monitorują funkcje takie jak alokacja pamięci w obcym procesie, zapis do jego przestrzeni adresowej czy mapowanie sekcji pamięci.
Opisywana technika wpisuje się w szerszy trend odchodzenia od dobrze znanych ścieżek API na rzecz mniej oczywistych prymitywów systemowych. Wcześniejsze badania wskazywały, że process parameter poisoning może omijać część popularnych produktów klasy EDR bez wzbudzania alarmów. Nowsze analizy rozwinęły ten kierunek o implementację w języku Rust oraz dodatkowe warstwy utrudniające inspekcję.
Analiza techniczna
Mechanizm wykorzystuje fakt, że podczas uruchamiania nowego procesu system Windows przekazuje mu zestaw struktur związanych z parametrami startowymi. Zamiast stosować klasyczny model wstrzyknięcia kodu do już działającego procesu, atakujący tworzy proces docelowy i osadza ładunek bezpośrednio w danych inicjalizacyjnych używanych na etapie startu.
Z perspektywy obrońcy kluczowe jest to, że taki schemat może znacząco ograniczać lub całkowicie eliminować użycie operacji uznawanych za silne wskaźniki compromise. Jeśli produkt EDR skupia się głównie na obserwacji najpopularniejszych funkcji odpowiedzialnych za alokację pamięci, zapis buforów lub mapowanie sekcji, może nie otrzymać wystarczająco czytelnych sygnałów do wygenerowania alertu.
W opisywanych testach badacze przygotowali implementację proof-of-concept w Rust i sprawdzili jej działanie przeciwko otwartej platformie EDR z komponentem XDR. Podstawowy wariant nie generował alertów po stronie EDR, choć komponent XDR zatrzymał późniejszą aktywność drugiego etapu. Następnie technikę rozszerzono o DLL unhooking, czyli przywracanie oryginalnych funkcji bibliotek systemowych zmodyfikowanych wcześniej przez oprogramowanie ochronne, oraz o politykę blokowania ładowania bibliotek DLL spoza ekosystemu Microsoft. W takim wariancie badacze nie zaobserwowali ani blokad, ani alertów w trakcie wykonania.
Technicznie pokazuje to ograniczenia detekcji opartej wyłącznie na user-mode hooks i monitorowaniu pojedynczych wywołań API. Jeśli przeciwnik potrafi przenieść aktywność do mniej obserwowanych elementów procesu, etapu inicjalizacji i pamięci wykonawczej, klasyczne reguły mogą okazać się niewystarczające.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tej techniki jest obniżenie skuteczności tradycyjnych mechanizmów wykrywania process injection. Dla zespołów blue team oznacza to ryzyko, że aktywność post-exploitation będzie przebiegać bez natychmiastowej sygnalizacji, zwłaszcza gdy ochrona opiera się głównie na liście znanych wywołań API.
Ryzyko rośnie szczególnie w środowiskach, które nie analizują szerzej zachowania procesu i jego pamięci.
- polegają głównie na telemetrii z user mode,
- nie korelują anomalii pamięci z zachowaniem wykonawczym procesu,
- nie analizują struktur startowych nowych procesów,
- nie monitorują zmian uprawnień pamięci do stanu wykonywalnego,
- nie wykrywają przejęcia wątków i niestandardowych punktów wejścia kodu.
Choć badacze podkreślają, że technika nie została jeszcze szeroko zaobserwowana w publicznie opisanych kampaniach malware, jej praktyczna użyteczność sugeruje wysoki potencjał adaptacji przez grupy APT, operatorów narzędzi red team oraz twórców loaderów malware. Szczególnie groźne może być jej łączenie z innymi metodami evasji, takimi jak unhooking, living-off-the-land czy wieloetapowe uruchamianie ładunków.
Rekomendacje
Organizacje powinny rozszerzyć strategię detekcji process injection poza standardowe reguły oparte na monitorowaniu popularnych API. W praktyce warto wdrożyć bardziej wielowarstwowe podejście obejmujące pamięć, zachowanie procesu i etap jego inicjalizacji.
- monitorować zawartość parametrów i struktur inicjalizacyjnych nowych procesów pod kątem anomalii,
- wykrywać wykonanie kodu z nietypowych obszarów pamięci,
- analizować zmiany ochrony pamięci, zwłaszcza przejścia do uprawnień wykonywalnych,
- obserwować przejęcia kontekstu wątku, thread hijacking oraz niestandardowe ścieżki startu procesu,
- ograniczać zależność od user-mode hooks i wzmacniać telemetrię na poziomie jądra, pamięci oraz zachowania procesu,
- testować produkty EDR i XDR pod kątem odporności na nowoczesne techniki evasji,
- prowadzić regularne ćwiczenia purple teamingowe obejmujące scenariusze bez użycia klasycznych wywołań process injection.
Dodatkowo warto rozwijać analitykę behawioralną skupioną na skutkach działania procesu, a nie wyłącznie na metodzie osiągnięcia celu. W praktyce ważniejsze staje się pytanie, czy proces wykonuje kod z nieoczekiwanego miejsca i w nietypowym kontekście, niż samo to, z jakiego API skorzystano.
Podsumowanie
Process parameter poisoning to kolejny przykład ewolucji technik omijania ochrony endpointów w systemie Windows. Jej siła nie wynika z całkowicie nowego modelu wykonania kodu, lecz z wykorzystania słabiej monitorowanego etapu inicjalizacji procesu i ograniczenia użycia łatwo wykrywalnych prymitywów API.
W połączeniu z DLL unhookingiem oraz dodatkowymi metodami ukrywania aktywności technika może znacząco utrudnić detekcję przez klasyczne rozwiązania EDR. Dla obrońców najważniejszy wniosek jest jasny: skuteczna ochrona musi opierać się na analizie zachowania procesu, pamięci i łańcucha wykonania, a nie wyłącznie na obserwacji znanych funkcji systemowych.
Źródła
- Dark Reading — EDR Evasion Stack Helps Process Injection Slip Past Defenses — https://www.darkreading.com/endpoint-security/edr-evasion-stack-helps-process-injection-slip-past-defenses
- Flashpoint — Process Parameter Poisoning in Rust — https://flashpoint.io/blog/process-parameter-poisoning-rust/
- SensePost — Process Parameter Injection: Evading EDR in 2026 — https://sensepost.com/blog/2026/process-parameter-injection/