shellcode

Shellcode to krótki, samodzielny fragment kodu maszynowego, który exploit dostarcza do zaatakowanego procesu, by przejąć w nim sterowanie i uruchomić albo pobrać dalszy etap ataku. MITRE ATT&CK wymienia „position-independent shellcode”, czyli kod niezależny od adresu ładowania, jako jedną z form bezplikowego kodu wykonywanego wprost w pamięci procesu ^[2]. Shellcode jest więc rodzajem ładunku niskiego poziomu: nie jest plikiem programu, tylko ciągiem bajtów instrukcji procesora. Polskie opracowania podkreślają, że materiałów o pisaniu shellcode'ów na nowoczesne architektury jest niewiele ^[1].

Jak działa

Shellcode nie uruchamia się sam. Potrzebuje błędu, który pozwoli wpisać go do pamięci procesu i przekierować tam wykonanie. Klasycznym przykładem jest przepełnienie bufora na stosie. Według MITRE najważniejszą daną, którą atakujący może wtedy nadpisać, jest zapisany adres powrotu, czyli adres, od którego program ma kontynuować po zakończeniu funkcji ^[3]. Nadpisany adres może wskazać na wstrzyknięty kod albo na istniejące funkcje bibliotek ^[3].

Ogólny przebieg pokazuje schemat poniżej.

RYS. 1Od błędu pamięci do dalszego etapu

Ponieważ shellcode działa w cudzym procesie, dziedziczy jego uprawnienia. Jeśli zaatakowana usługa działa z wysokimi uprawnieniami, atakujący zyskuje je razem z nią. Dlatego skutkiem udanego wykonania bywa zdalne wykonanie kodu (RCE), a w dalszym kroku eskalacja uprawnień.

Rozmiar shellcode'u jest zwykle mały, bo miejsce w przepełnionym buforze jest ograniczone. Przykładowo opublikowany w 2017 roku samouczek opisuje shellcode dla Linuksa na architekturze x86_64, który w 136 bajtach daje wykonanie kodu, a przy tym wymaga podania hasła ^[1]. Samouczek prowadzi krok po kroku od prostego programu w C do gotowego shellcode'u ^[1].

Odmiany i zastosowania

Shellcode nie służy tylko do pierwszego wejścia. W nowoczesnym złośliwym oprogramowaniu pełni też rolę nośnika, który ładuje kolejne moduły bez zapisu na dysk. Najczęstsze role zestawia tabela.

Ładowanie w pamięci. Technika Reflective Code Loading polega na przydzieleniu pamięci w procesie i wykonaniu w niej kodu, bez tworzenia pliku na dysku ani osobnego procesu ^[2]. MITRE zaznacza, że pozwala to trzymać ładunek zaszyfrowany albo zaciemniony aż do chwili wykonania ^[2]. To wiąże shellcode z pojęciami złośliwego oprogramowania bezplikowego i zaciemniania kodu.

Wstrzyknięcie do innego procesu. Process injection to według MITRE wykonanie dowolnego kodu w przestrzeni adresowej innego, działającego procesu ^[5]. Celem jest ukrycie działania pod legalnym procesem i obejście zabezpieczeń opartych na procesach, a czasem także podniesienie uprawnień ^[5]. W systemie Windows typowo używa się do tego funkcji API takich jak VirtualAllocEx, WriteProcessMemory i CreateRemoteThread ^[5].

W WordPressie

WordPress jest napisany w PHP, a typowe ataki na strony WordPress nie potrzebują shellcode'u. Zamiast kodu maszynowego atakujący zwykle wgrywa kod PHP, na przykład webshell albo tylną furtkę we wtyczce. Dokumentacja WordPressa zauważa, że włamania rzadko wynikają z infrastruktury, a najczęściej z samej aplikacji ^[7], czyli z podatności we wtyczkach i motywach.

Shellcode pojawia się warstwę niżej: w natywnym oprogramowaniu serwera, na którym działa strona. Interpreter PHP, serwer WWW, biblioteki do przetwarzania obrazów i jądro systemu są pisane w językach, w których zdarzają się błędy pamięci. Dlatego dokumentacja WordPressa zaleca utrzymywać bezpieczne, stabilne wersje serwera WWW i działającego na nim oprogramowania ^[7]. Po stronie właściciela witryny oznacza to regularną aktualizację oprogramowania i niekorzystanie z wersji PHP po końcu wsparcia.

Ma to znaczenie zwłaszcza na hostingu współdzielonym. Dokumentacja ostrzega, że jeśli na serwerze współdzielonym zostanie przejęta inna witryna, zagrożona może być także twoja ^[7]. Kod wykonany w procesie serwera nie zna granic między katalogami klientów, jeśli nie wymusza ich system operacyjny.

Zagrożenia i skutki

Wykonanie shellcode'u oznacza, że atakujący steruje procesem ofiary. Najczęstsze skutki to:

• pobranie i uruchomienie dalszych modułów, na przykład RAT, keyloggera czy infostealera;
• nawiązanie łączności z serwerem C2 (command and control);
• ukrycie działania w legalnym procesie i obejście zabezpieczeń opartych na procesach ^[5];
• utrudnienie analizy powłamaniowej, bo przy ładowaniu w pamięci nie powstaje plik na dysku ^[2].

Ta ostatnia cecha sprawia, że shellcode jest trudny dla wykrywania sygnaturowego, które zwykle skanuje pliki. MITRE stwierdza wprost, że ładowania kodu w pamięci nie da się łatwo powstrzymać kontrolami prewencyjnymi, bo opiera się na nadużyciu funkcji systemu ^[2].

Jak się bronić

Obrona działa na dwóch poziomach: utrudnia wykonanie shellcode'u i wykrywa jego ślady w zachowaniu procesów.

Zabezpieczenia pamięci. Data Execution Prevention (DEP) w systemie Windows oznacza strony pamięci jako niewykonywalne, co utrudnia wykorzystanie przepełnień bufora ^[4]. DEP blokuje wykonanie kodu ze stron danych, takich jak domyślna sterta, stosy i pule pamięci ^[4]. Próba wykonania kodu z chronionej strony kończy się wyjątkiem naruszenia dostępu, a nieobsłużony wyjątek zamyka proces ^[4]. Microsoft zaznacza, że DEP nie jest pełną obroną przed wszystkimi exploitami, tylko jednym z narzędzi ^[4].

MITRE wymienia dla przepełnień stosu także rozszerzenia kompilatorów wykrywające przepełnienie oraz losowe rozmieszczanie programu i bibliotek w pamięci, które utrudnia przewidzenie adresów ^[3]. Żadna z tych metod nie jest kompletna, dlatego stosuje się je warstwowo ^[3].

Wykrywanie zachowania. Dla ładowania w pamięci MITRE zaleca obserwować łańcuch zdarzeń w jednym procesie: nietypowy przydział pamięci, zmianę jej uprawnień na wykonywalne i uruchomienie wątku ^[2]. W Linuksie sygnałem jest zmiana uprawnień obszaru z zapisywalnego na wykonywalny bez odpowiadającego mu pliku na dysku ^[2]. Takie reguły realizują systemy EDR (Endpoint Detection and Response).

Ograniczenie skutków. Przeciw wstrzykiwaniu do procesów MITRE wymienia ograniczenia ptrace w Linuksie oraz mechanizmy SELinux i AppArmor ^[5]. Usługi uruchamiane zgodnie z zasadą najmniejszych uprawnień dają shellcode'owi mniej możliwości. Podstawą pozostaje jednak usuwanie samych błędów: szybkie wgrywanie łatek do oprogramowania serwera.

Historia i przykłady

Przykładem współczesnego użycia jest kampania grupy APT APT28 opisana przez Sekuraka 25 września 2025 roku na podstawie badań Sekoia.io ^[6]. Shellcode został zaszyfrowany i ukryty w pliku WINDOWS.PNG metodą steganografii najmłodszych bitów, a po odszyfrowaniu był najprawdopodobniej ładowany bezpośrednio do pamięci ^[6]. Dalszy etap, tylna furtka BeardShell, pozwalał między innymi wykonywać polecenia PowerShell, a do komunikacji służyły legalne usługi chmurowe Koofr i Icedrive ^[6].

Schemat ataku z tej kampanii pokazuje, jak łączą się opisane wcześniej elementy.

RYS. 2Shellcode ukryty w obrazie