Menu dostępności

Blokujesz PowerShell? Można wykonać komendy PowerShell w chronionym środowisku IT

Jak cyberprzestępcy radzą sobie w sytuacji, kiedy zabronione jest uruchamianie PowerShell na komputerze ofiary? Czy możliwe jest, aby pozostali oni niewykryci? Zgłębiliśmy temat do śrubek i poniżej prezentujemy nasze badania i wnioski.


Własny interpreter PowerShell?


Na temat możliwości wykorzystania PowerShell w świecie cyberprzestępczości i o możliwości obejścia jego blokad w systemie Windows pisaliśmy na Kapitanie Hacku tutaj. Opisywana w poprzednim artykule metoda polegała na uruchomieniu interpretera PowerShell poprzez podegranie na komputer specjalnej biblioteki *.dll i załadowanie jej funkcji do pamięci komputera. Czasami taka metoda może się okazać nie do końca skuteczna, bo np. specjalistyczne oprogramowanie do bezpieczeństwa w firmie może wykryć taki plik i zablokować jego transfer lub uruchomienie na komputerze w sieci. Czy istnieje zatem jakiś inny sposób/obejście? Oczywiście – skopiowanie surowego kodu na komputer i skompilowanie lokalnie. Dzięki temu cyberprzestępca może w sposób niezauważalny uruchomić na komputerze ofiary linię komend w PowerShell (interpreter). Co ciekawe w interpreterze możemy wykonywać komendy, które nie posiadają restrykcji takich jak ograniczenie komend języka PowerShell wprowadzonych w systemie Windows. Taki kod cyberprzestępca może skopiować na komputer wykorzystując różne metody (np. steganografię opisywaną tutaj). Wniosek jaki nam się nasuwa, to że cyberprzestępcy mają w rękach poważną broń przeciwko systemom bezpieczeństwa.


Zacznijmy od kodu


Do celów badawczych wykorzystaliśmy krótki kod programu napisanego w języku C# przez analityka bezpieczeństwa Casey Smith oraz metodę opisywaną przez Jareda Atkinsona i Justina Warnera.

Kod programu napisany w jezyku C# został wylistowany poniżej:

Powyższy kod programu wykorzystuje bibliotekę do automatyzacji PowerShell (System.Management.Automation.dll), która posiada zdefiniowane klasy PowerShell dla języka DotNet i umożliwia tworzenie środowiska PowerShell w kodzie języka C# w celu wykonania skryptów lub dowolnych komend PowerShell. W kodzie powyższego programu znajduje się także zdefiniowana klasa dla instalatora, której wywołanie przez program InstallUtil.exe uruchomi na komputerze interpreter PowerShell, a nawet gotowy skrypt.


Przeskanujmy kod przez oprogramowanie do bezpieczeństwa


Zapiszmy nasz powyższy kod do pliku „PsInterpreter.cs” i sprawdźmy, czy wykryje go jakiekolwiek oprogramowania antywirusowe. Użyliśmy w tym przypadku platformy VirusTotal. Cały kod programu zajmuje jedynie 2.03 KB! Wynik skanowania pliku „PSInterpreter.cs” przez VirusTotal:

Wskazania z platformy Virus Total

Nasz komentarz do wyniku jest zbędny. Cyberprzestępcy mogą czuć się bezkarnie.


Jak skompilować kod na komputerze?


Drugą, złą informacją dla nas jest to, że w celu kompilacji opisywanego powyżej kodu cyberprzestępca nie potrzebuje na komputerze ofiary wgrywania żadnych dodatkowych narzędzi. Jedyne co musi zrobić to go skopiować, lokalnie skompilować i wywołać w środowisku Windows. W dużym skrócie, opisywana przez nas metoda na wywołanie interpretera PowerShell wykorzystuje wbudowane w Windows możliwości kompilacji kodu napisanego w języku C# do bibloteki DLL (za pomocą programu csc.exe) oraz interesujący sposób na załadowanie funkcji DLL do pamięci poprzez wbudowane w system operacyjny narzędzie InstallUtil.exe.


Jakie warunki musi spełniać system Windows, aby można było uruchomić nasz własny interpreter PowerShell?


Warunek jest jeden – na komputerze ofiary musi być zainstalowane środowisko Microsoft .Net Framework od wersji 4.0. DotNet Framework jest wbudowaną w system Windows platformą programistyczną opracowaną przez Microsoft, obejmującą środowisko uruchomieniowe (Common Language Runtime – CLR) oraz biblioteki klas dostarczające standardowej funkcjonalności dla aplikacji. Ogólnie bez niego nie jest w stanie poprawnie działać większość programów napisanych pod Windows. A dlaczego wersja 4.0? Ponieważ w tej wersji w katalogu: “C:\Windows\Microsoft.NET\Framework\v4.0.30319\” znajduje się program CSC.EXE pozwalający skompilować nasz kod do biblioteki dll oraz w katalogu: „C:\Windows\Microsoft.NET\Framework64\v4.0.30319\” program InstallUtil.exe pozwalający uruchomić w pamięci komputera funkcje z biblioteki DLL i w konsekwencji interpretera PowerShell.

Poniżej przedstawiamy dwa kroki w celu uruchomienia interpretera PowerShell na Windows 10 w wersji 1809 oraz z uruchomioną i zaktualizowaną usługą Defender:


Krok 1. Kompilacja kodu C#

Kod w C# możemy skompilować przy użyciu 2 komend:

Lub

W wyniku powstanie nam plik PsInterpreter.dll


Krok 2. Uruchomienie interpretera PowerShell

W celu uruchomienia interpretera PowerShell posłużymy się programem InstallUtil.exe, który jest częścią składową Microsoft .Net Framework 4.0 i w parametrach podamy wywołanie wcześniej utworzonej biblioteki DLL. Wykonując poniższą komendę będziemy w stanie uruchomić konsolę z interpreterem PowerShell: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U PSInterpreter.dll

Uruchomienie interpretera PowerShell

Po jej wykonaniu zaobserwujemy pojawienie się interpretera zaczynającego się od „PS >” Od tej pory mamy własne środowisko PowerShell do wykonywania komend.


Jak to wygląda od strony systemu operacyjnego?


Sprawdziliśmy w narzędziu Process Hacker jak wygląda wywołanie naszego interpretera w procesach.

Drzewo procesów w narzędziu Process Hacker

Jak możemy się przekonać na ekranie poniżej na liście procesów nie widać procesu powershell.exe. Widać tylko uruchomiony proces InstallUtil.exe oraz załadowane biblioteki:

Biblioteki załadowane do procesu InstallUtil.exe

Logi Windows PowerShell


Uruchomienie prostej komendy Get-Host w naszym interpreterze generuje następujące zdarzenie w logu Windows PowerShell

Wykonanie w naszym interpreterze komendy „Get-Host”
Wpis z Event Log z wykonaną komendą Get-Host

Warto zwrócić uwagę na atrybut HostApplication wskazujący aplikację i jej parametry, która uruchamia komendę PowerShell Get-Host.


Jak możemy sobie pomóc?


Przede wszystkim stosując i implementując w systemach przykłady dobrych praktyk z PowerShell (i nie tylko). Należą do nich:

  • Monitorowanie logów Windows PowerShell oraz Operacyjnych (dodatkowy audyt) w systemie Windows pod kątem podejrzanych zapytań oraz źródeł, z których są uruchamiane skrypty (uwaga na pole ApplicationHost).
  • Monitorowanie wywołania z linii komend programów csc.exe i InstallUtil
  • Monitorowanie uruchamiania podejrzanych procesów w systemie i podejrzanych wywołań. Możemy do tego zastosować SysMON
  • Stosowanie się do porad z tego artykułu.

Warto też monitorować File System pod kątem pojawiających się na nim nowych plików DLL i innych dziwnych rozszerzeń.


Pozdrawiamy, Zespół Kapitan Hack

Popularne

Masowy wyciek danych PayPal – 15,8 miliona haseł w rękach cyberprzestępców

Masowy wyciek danych PayPal – 15,8 miliona haseł w rękach cyberprzestępców

16 sierpnia br. na forum cyberprzestępczym pojawiła się oferta sprzedaży ogromnej bazy danych, zawierającej ponad 15,8 miliona par adresów e-mail i haseł w formacie jawnego tekstu powiązanych z konta...
Groźna dziura w Microsoft IIS. Deserializacja usług może prowadzić do zdalnego wykonania kodu

Groźna dziura w Microsoft IIS. Deserializacja usług może prowadzić do zdalnego wykonania kodu

W połowie sierpnia 2025 roku ujawniono poważną lukę bezpieczeństwa w narzędziu Microsoft Web Deploy 4.0, używanym do publikacji aplikacji webowych na serwerach IIS. Luka – oznaczona jako CVE-2025-53772 – pozwal...
Co sprawia, że Deep Web jest cennym źródłem threat intelligence?

Co sprawia, że Deep Web jest cennym źródłem threat intelligence?

Deep Web, czyli warstwa Internetu niedostępna dla standardowych wyszukiwarek, często bywa pomijana w analizach bezpieczeństwa, mimo że stanowi niezwykle wartościowe źródło informacji o zagrożeniach. Jej tre...
Miliony laptopów Dell narażone na kompromitację

Miliony laptopów Dell narażone na kompromitację

Niedawno pisaliśmy o kłopotach Lenovo, dzisiaj czas na Dell. Okazuje się, że pięć luk w oprogramowaniu ControlVault3 i powiązanych interfejsach API systemu Windows naraża miliony laptopów na trwałe w...
WinRAR: krytyczna podatność zero-day CVE-2025-8088

WinRAR: krytyczna podatność zero-day CVE-2025-8088

W popularnym narzędziu do archiwizacji plików WinRAR wykryto poważną lukę bezpieczeństwa. Została oceniona na 8.8 w skali CVSS i otrzymała oznaczenie CVE-2025-8088. Błąd dotyczy wersji przeznaczonych dla syste...