PsExec vs KNF vs ransomware – polemika spełnialności rekomendacji

Wydany przez KNF w maju 2024 dokument “Dobre praktyki w zakresie zapobiegania i reagowania na ataki typu ransomware” zawiera między innymi rekomendację 2.2 brzmiącą “Ograniczenie możliwości użycia narzędzia PsExec – zaleca się ograniczenie wykorzystania narzędzia PsExec poprzez wymaganie mechanizmu UAC, ograniczenie narzędzia tylko do wybranych kont administracyjnych, logowanie i weryfikacja każdego wywołania narzędzia PsExec”. Choć idea generalnie jest słuszna, to tak sformułowana rekomendacja jest niemal niespełnialna.

Aby móc wdrożyć ograniczenia, na początek warto przypomnieć, jak PsExec działa.

Dla jasności, w dalszej części dokumentu stosowana będzie nomenklatura “klient” dla komputera, na którym uruchamiany jest PsExec i “serwer” dla komputera, na którym tworzone są zdalne procesy lub zdalna konsola, nawet jeżeli faktycznie rola tych komputerów jest inna.

1. PsExec uruchomiony na kliencie, łączy się z udziałem ADMIN$ na serwerze i kopiuje tam plik wykonywalny (zwykle wyekstrahowany z własnego pliku exe). Domyślnie stosowana jest nazwa PSEXESVC.exe, jednak zastosowanie na kliencie parametru “-r” pozwala zastosować dowolną inną nazwę.
2. PsExec na kliencie łączy się do Named Pipe \pipe\svcctl na serwerze i komunikując się w ten sposób z Service Managerem tworzy nową usługę systemową PSEXESVC skonfigurowaną tak, aby jej plikiem wykonywalnym był plik exe skopiowany w poprzednim kroku. Nazwa usługi może być zmieniona dzięki zastosowaniu parametru -r.
3. PsExec nadal korzystając z mechanizmów zdalnej kontroli nad Service Managerem na serwerze uruchamia skonfigurowaną wcześniej usługę.
4. Uruchomiona na serwerze usługa otwiera swoje własne Named Pipe \pipe\psexesvc... z którymi komunikuje się PsExec uruchomiony na kliencie. Podobnie, jak we wcześniejszych punktach, nazwa ta może być zmodyfikowana przy użyciu parametru -r.

Należy tu zaznaczyć dwa istotne fakty:

• realizacja punktów 1, 2 i 3 w standardowej konfiguracji Windows wymaga praw lokalnego administratora na serwerze.
• kontrola wykonania PsExec na kliencie jest możliwa tylko w sytuacji, gdy w organizacji nie da się podłączyć do sieci niezarządzalnego komputera. W przeciwnym przypadku, użytkownik PsExec uruchomi aplikację na maszynie wirtualnej, prywatnym laptopie czy nawet służbowym komputerze, na którym udało się zdjąć nałożone ograniczenia na przykład dzięki prawom administratora.

W praktyce, działania ograniczające administratorom zastosowanie PsExec na serwerze możliwe są wyłącznie w przypadku, w którym wyłączone zostaną również inne podobne mechanizmy zdalnego zarządzania stosowane często w organizacjach. W szczególności, skuteczne będą:

1. Wyłączenie udziału ADMIN$ przy pomocy wpisów AutoShareServer / AutoShareWks w rejestrze.
2. Wyłączenie zdalnej komunikacji Service Managera przy pomocy wpisu DisableRemoteScmEndpoints w rejestrze.

Oba powyższe sposoby wymagają restartu systemu. Należy przy tym zwrócić uwagę, że metody te opierają się na rejestrze, czyli możliwe jest ich “odblokowanie” dzięki dostępnym standardowo dla administratorów mechanizmom zdalnego dostępu do rejestru i zdalnego wymuszenia restartu. Należy więc uznać je za tylko częściowo skuteczne, choć w znaczącym stopniu ograniczające ryzyko.

Możliwe jest również zastosowanie jednego z “trików” blokujących serwerową część PsExec w postaci:

1. Utworzenia na serwerze pustego pliku C:\Windows\PSEXESVC.exe i nadania mu atrybutu ReadOnly. W efekcie PsExec nie może skopiować na serwer swojego pliku wykonywalnego.
2. Utworzenia na serwerze usługi systemowej (na przykład poleceniem sc.exe) PSEXESVC i skonfigurowania jej jako “Disabled”. W efekcie PsExec nie może uruchomić usługi na serwerze.

Oba te triki blokują działanie PsExec pod warunkiem, że na kliencie nie został zastosowany parametr -r zmieniający nazwę pliku oraz nazwę usługi. Zastosowanie tego parametru sprawia, że nazwa pliku, usługi i Named Pipe zostają zmodyfikowane, co powoduje, że blokada jest nieskuteczna. Ponadto, podobnie, jak powyżej, oba te mechanizmy są możliwe do zdalnego rozbrojenia.

Niezależnie od mechanizmów opisanych powyżej, możliwa jest zmiana uprawnień do tworzenia nowych usług systemowych. (sc.exe sdset scmanager ...). Bieżące uprawnienia i dwuliterowe kody związane z poszczególnymi typami dostępu wyświetlić można poleceniem sc.exe sdshow scmanager showrights. W szczególności, teoretycznie możliwe jest takie ustawienie uprawnień, aby nawet administrator lokalny nie mógł zdalnie utworzyć nowej usługi (ani zmienić tych uprawnień), jednak złożoność scenariuszy, w których stosowany jest PsExec przekłada się na złożoność uprawnień, często przekraczającą racjonalne możliwości konfiguracji.

W efekcie, uznać należy, że ograniczenie działania PsExec polegać musi na jednym z opisanych wyżej sposobów:

1. Wyłączenie ADMIN$ ze świadomością, że może to zakłócić działanie innych niż PsExec mechanizmów zdalnego zarządzania,
2. Wyłączenie zdalnej komunikacji z Service Managerem, również potencjalnie zakłócające działanie innych mechanizmów,
3. Pełnej kontroli nad wszystkimi komputerami mogącymi się połączyć do serwera, na których klient PsExec będzie niedozwolony lub ograniczony.

Zastosowanie explicite rekomendacji KNF sugerującej ograniczenie zastosowania PsExec do “wybranych kont administracyjnych” nie jest praktycznie możliwe, jednak co do zasady wydaje się, że generalnie ograniczenie liczby takich kont jest zasadne. Każdy z mechanizmów stosowanych przez PsExec wymaga tych praw, poza tym, podejście takie adresuje równocześnie wiele innych ryzyk, również związanych z użyciem innych niż PsExec narzędzi stosowanych w atakach. W praktyce należy uznać, że podejście polegające na świadomym zarządzaniu uprawnieniami administratora jest najskuteczniejsze i przynoszące najwięcej korzyści. Równocześnie jest to zabezpieczenie na tyle typowe, że nie powinno powodować nieprzewidzianych skutków, które mogą wystąpić w przypadku użycia pozostałych wspomnianych wcześniej metod obrony.

Wśród metod obrony wymienić należy również mechanizmy Application Whitelisting lub zbliżone do nich mechanizmy blokowania plików wykonywalnych na podstawie ich funkcji skrótu lub metadanych. Jeżeli w organizacji takie rozwiązania są stosowane, ograniczenie użycia PsExec będzie stosunkowo proste, jednak wdrożenie tylko w celu ograniczenia działania jednego narzędzia wydaje się nieracjonalne. Należy przy tym zaznaczyć, że użycie standardowo zarządzanego AppLockera w tym konkretnym przypadku nie rozwiąże problemu, ponieważ proces związany z PsExec na serwerze posiada w swoim tokenie SID S-1-5-6 i jako taki wyłączony jest z kontroli (i monitorowania!) przez AppLocker.

Równolegle do omówionych wyżej technik prewencyjnych, należy skupić się na technikach detekcyjnych, pozwalających zauważyć, że PsExec został użyty. Ze względu na sposób działania PsExec, stwierdzić należy, że precyzyjna detekcja tylko tego narzędzia jest niezwykle trudna, a rekomendowana przez KNF metoda jest nieskuteczna w przypadku użycia na kliencie parametru -r. Metody wykrywania powinny skupić się na cennych, niezależnie od narzędzia, kierunkach takich jak:

1. Wykrywaniu tworzenia nowych plików wykonywalnych w folderze Windows,
2. Wykrywaniu zmian w HKLM\CurrentControlSet\Services,
3. Rejestrowaniu nowych procesów wraz z metadanymi pliku wykonywalnego.

Ciekawą cechą PsExec jest tworzenie plików exe (niezależnie od ich nazwy wynikającej z działania parametru -r) bezpośrednio w folderze Windows, a nie w jego podfolderach. Jest to zachowanie stosunkowo rzadko spotykane i może być wykorzystane w mechanizmach detekcyjnych, dając równocześnie stosunkowo niedużo fałszywie pozytywnych detekcji. W przypadku zastosowania narzędzia Sysmon, uruchomienie na serwerze procesu usługi związanej z PsExec, niezależnie od użycia parametru -r w logu zapisze metadane pliku, w szczególności “Description: PsExec Service“, “Product: Sysinternals PsExec” oraz “OriginalFileName: psexesvc.exe“. Detekcja tych metadanych z niemal stuprocentową pewnością świadczy o użyciu PsExec.

Podsumowując, stwierdzić należy, że zastosowanie rekomendacji KNF w jej oderwaniu od szerszego kontekstu jest niemal niemożliwe, ponieważ nie ma selektywnych mechanizmów prewencyjnych a sugerowany w rekomendacji artykuł opisujący detekcję nie uwzględnia scenariuszy wykorzystujących parametr -r. Rekomendacja jest jednak w naturalny sposób zrealizowana w sytuacji, kiedy lokalne prawa administratora nadawane są w sposób przemyślany. Równocześnie, ograniczenie nadawania lokalnych praw administratora adresuje inne, potencjalnie niebezpieczne scenariusze poszerzania uprawnień (lateral movements), nie tylko faktycznie często spotykany w atakach PsExec. W praktyce warto przyjąć, że ograniczenie nadawania praw administratora lokalnego jest działaniem lepszym, niż skupienie się na pojedynczym narzędziu, które tych praw używa.

~Grzegorz Tworek