W pracy z systemami Windows kluczowy jest dostęp do narzędzi umożliwiających zdalną administrację. Choć nowoczesne rozwiązania, takie jak PowerShell Remoting, dobrze spełniają te funkcje, ich wykorzystanie często jest ograniczone przez polityki bezpieczeństwa lub rozwiązania EDR (Endpoint Detection & Response – wykrywanie i reagowanie w punktach końcowych). W takich sytuacjach można sięgnąć po narzędzia Sysinternals PSTools, szczególnie po PsExec.

PSTools, wchodzące w skład Sysinternals, to zestaw kilkunastu narzędzi umożliwiających zdalne wykonywanie różnych operacji administracyjnych, bez konieczności instalowania dodatkowego oprogramowania na zdalnych systemach. 

Historia programów PSTools sięga czasów, gdy Windows nie miał jeszcze zaawansowanych mechanizmów zdalnego zarządzania. Do czasu upowszechnienia się PowerShella zdalne uruchamianie procesów, zarządzanie usługami czy przeglądanie dzienników zdarzeń wymagało niemałej gimnastyki. Mimo że współczesne systemy Windows mają dużo dopracowanych mechanizmów zdalnej administracji, narzędzia PSTools dalej sprawdzają się w codziennej pracy z systemami Microsoftu, wliczając w to testy penetracyjne. 

Narzędzia Sysinternals PSTools działają z poziomu wiersza poleceń i nie wymagają instalowania dodatkowego oprogramowania na komputerach docelowych. Działanie w trybie wiersza poleceń oraz ujednolicona, prosta składnia umożliwiają zarówno skuteczną, ręczną analizę, jak i tworzenie skryptów realizujących skomplikowane operacje, poczynając od zbierania informacji ze wskazanych systemów aż po eskalację uprawnień. Ze względu na te właściwości znajomość PSTools jest również nieoceniona w czasie reagowania na incydenty bezpieczeństwa (Incident Response), ponieważ narzędzia te bywają komponentami wykorzystywanymi przez złośliwe oprogramowanie.

W pakiecie Sysinternals PSTools znajdziemy 13 programów wiersza poleceń:

1. PsExec – umożliwia zdalne uruchamianie procesów na zdalnych systemach. Jest to szczególnie przydatne narzędzie dla pentesterów i administratorów, więc przyjrzymy się temu programowi szczegółowo w osobnym fragmencie niniejszego tekstu.
2. PsFile – wyświetla listę zdalnie otwartych plików i udziałów sieciowych na wskazanym komputerze. Narzędzie może być użyteczne w diagnostyce i monitorowaniu dostępu do współdzielonych zasobów.
3. PsGetSid – wyświetla identyfikator SID komputera lub użytkownika, co jest kluczowe w kontekście audytów bezpieczeństwa i zarządzania tożsamością.
4. PsInfo – dostarcza szczegółowych informacji o systemie, takich jak: zainstalowane oprogramowanie, woluminy dyskowe i inne zasoby. 
5. PsKill – pozwala na zdalne zakończenie procesów na komputerze docelowym, co jest przydatne w sytuacjach, gdy procesy blokują zasoby systemowe lub powodują problemy wydajnościowe.
6. PsList – wyświetla szczegółowe informacje o procesach działających na zdalnym komputerze, co pozwala na monitorowanie obciążenia i identyfikację problemów z wydajnością.
7. PsLoggedOn – wypisuje aktywne sesje użytkowników na danym komputerze, co umożliwia monitorowanie dostępu do systemów i aktywności użytkowników.
8. PsLogList – pobiera dzienniki zdarzeń zdalnych komputerów, co jest przydatne w analizie logów i diagnozowaniu problemów z systemem.
9. PsPasswd – umożliwia zdalną zmianę haseł użytkowników w sieci, co jest przydatne w zarządzaniu kontami w większych środowiskach IT.
10. PsPing – mierzy opóźnienia w komunikacji sieciowej, co pozwala na diagnostykę sieci i ocenę wydajności połączeń między komputerami. Dzięki temu programowi można sprawdzać system nie tylko przez ICMP, ale też TCP – i jest on dużo dokładniejszy niż systemowy ping, który w sieciach lokalnych okazuje się nieużyteczny przez swoją małą dokładność (1 ms). 
11. PsService – zarządza usługami systemowymi na zdalnych komputerach, pozwalając na ich uruchamianie, zatrzymywanie i restartowanie.
12. PsShutdown – umożliwia zdalne wyłączanie, restartowanie lub usypianie komputerów, co jest przydatne w zdalnym zarządzaniu dużymi sieciami.
13. PsSuspend – pozwala na wstrzymanie działania procesów na zdalnym komputerze, co może być użyteczne w przypadku konieczności tymczasowego zwolnienia zasobów systemowych.

Powyższe programy możemy uruchamiać lokalnie w kontekście swojego komputera lub wskazując zdalny system (czasem listę systemów). 

Na rysunku 1. pokazano podstawowy zestaw zbierający informacje o wskazanym komputerze. Najpierw wyświetlamy elementarne informacje o systemie (PsInfo) wraz z zainstalowanym na nim oprogramowaniem (-s), potem wypisujemy listę procesów (PsList) oraz usług systemowych (PsService).

Wszystkie narzędzia PsTools mają zbliżoną składnię i przełączniki. Dokładne informacje o tym, jak łączyć się do zdalnych systemów w kontekście konkretnego użytkownika i jak wykonywać na nich zaawansowane operacje, poznamy na przykładzie PsExec. Najpierw jednak dowiedzmy się, jakie warunki muszą zostać spełnione, aby narzędzia PsTools działały między komputerami w sieci.

Wymagania PsTools

Do działania PsTools potrzeba spełnienia określonych warunków, zależnych od scenariusza. Narzędzia wykorzystują natywne funkcje systemu Windows, dzięki czemu nie wymagają instalacji dodatkowego oprogramowania. W niektórych przypadkach konieczne będzie jednak otwarcie wybranych portów lub uruchomienie konkretnych usług w systemie. Poniżej przedstawiono wymagania, które warto sprawdzić, gdyby narzędzie nie działało zgodnie z oczekiwaniami.

Gdy uruchamiamy PsTools lokalnie, najlepiej jest korzystać z uprawnień administracyjnych. Wymagają tego narzędzia: PsFile, PsPasswd oraz PsShutdown. W zależności od użytych przełączników wysokie uprawnienia mogą być wymagane dodatkowo przez PsExec, PsKill, PsLogList, PsService oraz PsSuspend. Z niskimi uprawnieniami można lokalnie uruchomić wyłącznie PsGetSid, PsInfo, PsList oraz PsLoggedOn.

Jeśli zamierzamy łączyć się do zdalnych systemów, musimy przede wszystkim je wskazać. Można do tego zastosować adresy IP albo skorzystać z DNS. Jeśli DNS nie jest dostępny, rozwiązywanie nazw może być realizowane przez NetBIOS over TCP (NBT), ale w takim wypadku należy w zaporze sieciowej zdalnego systemu otworzyć porty: 137 TCP/UDP, 138 UDP oraz 139 TCP.

Część narzędzi do zdalnej komunikacji wykorzystuje udział administracyjny Admin$, który jest specjalnym udziałem sieciowym wskazującym na katalog systemowy C:\Windows. Aby te narzędzia mogły działać poprawnie, konieczne jest włączenie w systemie zdalnym usługi Udostępnianie plików i drukarek (ang. File and Printer Sharing) oraz otwarcie portu TCP 445 (SMB). Należy również wyłączyć Proste udostępnianie plików (ang. Simple File Sharing), aby umożliwić uwierzytelnianie się do usług zdalnych z użyciem nazw użytkowników oraz haseł. Gdy ta usługa jest włączona, dostęp do zasobów jest przyznawany za pomocą konta anonimowego, co uniemożliwia skorzystanie z wielu nowoczesnych metod zdalnej administracji. Dostęp do udziału Admin$ jest wymagany w czasie łączenia do zdalnych systemów przez: PsExec, PsGetSid, PsInfo, PsKill, PsList, PsLogList, PsShutdown oraz PsSuspend.

Kolejnym komponentem, o którym należy pamiętać, jest usługa Rejestr zdalny (ang. Remote Registry). Wymagają tego programy: PsInfo, PsList, PsLoggedOn oraz PsLogList. Warto zaznaczyć, że począwszy od systemu Windows 8, usługa ta nie jest domyślnie uruchamiana wraz ze startem systemu, a jej włączenie wymaga dodatkowo otwarcia portu TCP 445 (SMB) w zaporze sieciowej. 

Dobrze mieć również na uwadze fakt, że PsTools działa najlepiej w środowisku domenowym, gdzie większość powyższych wymagań jest już domyślnie spełniona. Praca poza domeną, przykładowo na komputerach w sieci domowej lub na maszynach wirtualnych nieprzyłączonych do domeny, może być znacznie bardziej problematyczna. Spowodowane jest to strategią Microsoftu, który od czasów Windows Vista wprowadzał coraz więcej ograniczeń dla grupy roboczej. Chroni to nietechnicznych użytkowników systemu, wpływając jednak na konfigurację administracji zdalnej, przykładowo wprowadzając LocalAccountTokenFilterPolicy, która ogranicza zdalny dostęp dla kont lokalnych (jest to jedna z przyczyn niedziałania PsExec w sieciach domowych).

PsExec

PsExec to jedno z najważniejszych narzędzi w arsenale Sysinternals, które nadal jest niezastąpione w wielu scenariuszach administracyjnych i ofensywnych. Za pomocą tego narzędzia możemy uruchamiać programy na komputerze zdalnym, lokalnym, a nawet na wielu komputerach jednocześnie. Tak jak wspomniano wcześniej, PsExec nie wymaga instalacji żadnego oprogramowania na wskazanych systemach, musimy jednak pamiętać o wskazywaniu konta, które ma dostęp do udziału Admin$.

Najczęściej będziemy uruchamiali PsExec z następującymi parametrami (rysunek 2).

Powyższe polecenie uruchomi na komputerze winpc interaktywny (-i) proces linii komend lub PowerShella. Jest to jeden z najłatwiejszych sposobów zarządzania zdalnym systemem, a więc też weryfikacji poświadczeń zdobytych podczas eksploitacji usług Windowsa. 

Jeżeli zależy nam tylko na uruchomieniu pewnego procesu z konkretnymi parametrami, a nie na interaktywnej sesji, możemy pominąć przełącznik -i. W taki sposób możemy przykładowo dodać konto nowego użytkownika w systemie za pomocą polecenia net user (rysunek 3).

Z perspektywy ofensywnej przydatne może okazać się użycie przełącznika -s, który powoduje uruchomienie wskazanego procesu w kontekście najwyższych uprawnień w systemie Windows, czyli z konta nt authority\system (rysunek 4). 

Innym przydatnym przełącznikiem jest -d (detached), który uruchamia polecenie w tle, bez potrzeby utrzymywania sesji PsExec między komputerami (rysunek 5).

Powyższe polecenie uruchomi PowerShella, który po minucie zapisze plik C:\windows\temp\test, my zaś nie będziemy musieli przez ten czas utrzymywać sesji PsExec w swoim terminalu. 

Warto zwrócić uwagę na najczęściej popełniany błąd w czasie eksperymentowania z różnymi przełącznikami (rysunek 6).

Powyższe polecenie nie uruchomi wiersza poleceń na uprawnieniach nt authority\system, ale wiersz poleceń z parametrem cmd -s, co nie będzie miało większego sensu. Trzeba więc pamiętać, aby zawsze umieszczać polecenia do wykonania oraz ich parametry na końcu komendy psexec.

PsExec domyślnie uruchamia procesy w kontekście sesji systemowej, która nie posiada interfejsu graficznego. Aby program taki jak Autoruns lub Process Explorer mógł zostać wyświetlony na ekranie zdalnego użytkownika, konieczne jest wskazanie numeru odpowiedniej sesji graficznej w parametrze -i. 

Jaki to numer? 

Od Windows Vista sesja o identyfikatorze 0 jest zarezerwowana wyłącznie dla usług systemowych (services), natomiast identyfikator 1 (console) jest przypisywany do pierwszej sesji zalogowanego użytkownika (mimo że nazwa „console” może sugerować wyłącznie tryb tekstowy, dotyczy też sesji graficznej). Numer ten może się różnić w zależności od liczby aktywnie zalogowanych użytkowników w systemie, ale jeżeli nie mamy pewności, numery sesji możemy sprawdzić za pomocą polecenia query session (w większości przypadków będziemy wskazywali sesję o numerze 1, co przedstawiono na rysunku 7). 

W jaki sposób uruchomić program, którego nie ma na zdalnym systemie? Aby to zrobić, wystarczy posłużyć się parametrem -c (copy), który spowoduje, że plik do wykonania przed uruchomieniem zostanie najpierw przekopiowany na zdalny komputer. Na rysunku 8. pokazano komendę kopiującą (-c) na zdalny system plik Autoruns64.exe, a następnie uruchamiającą go w graficznej sesji użytkownika Administrator (-i 1).

W jaki sposób PsExec potrafi wykonywać wszystkie te zadania? Jest to możliwe dzięki kreatywnemu połączeniu kilku mechanizmów. 

Najpierw PsExec łączy się przez SMB do udziału Admin$ (wskazującego na C:\Windows) i kopiuje swój plik wykonywalny na zdalny komputer. Następnie, z wykorzystaniem potoków nazwanych (ang. named pipes), udziału IPC$ oraz SVCManagera, w systemie zdalnym tworzona jest tymczasowa usługa PSEXESVC. Usługa ta działa w tle, realizując polecenia PsExec, co pozwala na uruchamianie długotrwałych operacji bez potrzeby utrzymywania stałego połączenia między komputerami. Po wykonaniu swojej pracy usługa PSEXESVC jest automatycznie usuwana. Dzięki temu utrzymujemy bardzo stabilny i funkcjonalny kanał komunikacyjny na potrzeby realizacji zadań wskazanych w parametrach wywołania PsExec.

Ćwiczenie: Uruchomienie PSRemoting oraz RDP przez PsExec 

Załóżmy, że w czasie testu penetracyjnego pozyskaliśmy poświadczenia do komputera winpc. 

Naszym celem będzie umożliwienie podłączenia się do tego komputera nie tylko przez PsExec, ale też przez PowerShella oraz RDP – po to, aby ułatwić sobie dalszą analizę systemu oraz aby mieć zapasowe kanały komunikacji z przejętym systemem. 

Uwaga: w podanym przykładzie system docelowy został zainstalowany w języku angielskim. W przypadku łączenia się do systemów Windows korzystających z innych języków należy odpowiednio dostosować nazwy usług i grup lokalnych.

Włączenie zdalnej administracji przez PowerShella można zrealizować, wykonując polecenie Enable-PSRemoting w samym PowerShellu (rysunek 9).

Domyślnie Enable-PSRemoting nie tworzy reguł zapory sieciowej. Problem zostanie rozwiązany, gdy całkowicie wyłączymy Windows Firewall (rysunek 10).

Jeśli komputer, na którym uruchamiamy PsExec, a także komputer zdalny nie są w tej samej domenie, musimy pamiętać o dodaniu zdalnego systemu do listy zaufanych hostów (w tym wypadku winpc). Polecenie należy wykonać na komputerze klienta PsExec (rysunek 11).

W tym momencie powinniśmy mieć już możliwość podłączenia się do winpc przez PowerShell (rysunek 12).

Uruchomienie RDP wymaga trochę więcej zachodu. Po pierwsze, musimy włączyć usługę TermService (warto od razu skonfigurować jej automatyczne uruchamianie przy starcie systemu). Jest to widoczne na rysunku 13.

Oprócz tego musimy pozwolić na podłączanie użytkowników przez Pulpit zdalny (Remote Desktop), ustawiając klucz rejestru HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server o nazwie fDenyTSConnections na wartość 0 (rysunek 14).

Ostatnią rzeczą, o którą trzeba zadbać, jest dodanie użytkownika do grupy Remote Desktop Users (Użytkownicy pulpitu zdalnego). Administratorzy domyślnie są członkami tej grupy, jednak gdybyśmy chcieli użyć wcześniej utworzonego konta, możemy to zrobić w sposób zaprezentowany na rysunku 15 (wersja dla komputera w domenie) oraz rysunku 16 (wersja dla komputera poza domeną).

Po wykonaniu powyższych kroków będziemy mogli podłączyć się do systemu zarówno przez PowerShell Remoting, jak i przez RDP. W kontekście testów penetracyjnych takie podejście zapewnia nam elastyczność i możliwość wykorzystania różnych metod uzyskania dostępu do systemu oraz persystencji – zarówno poprzez sesje terminalowe, jak i pulpit zdalny (rysunek 17).

impacket-psexec

Nie sposób rozmawiać o narzędziach PsTools w kontekście testów penetracyjnych bez wspomnienia o ich implementacji przygotowanej dla dystrybucji Kali Linux, czyli impacket-psexec wchodzących w skład pakietu impacket-scripts.

Skrypt impacket-psexec pozwala wykonywać większość funkcji oryginalnego PsExec bezpośrednio na Kali Linux. Narzędzie można ręcznie zainstalować za pomocą komendy apt install impacket-scripts.

Składnia parametrów impacket-psexec jest nieco inna niż w PsExec (rysunek 18).

Jak widać, impacket-psexec działa bardzo podobnie do wersji windowsowej, jednak bardziej uwidacznia procesy zachodzące „pod spodem” (co przydaje się też w debugowaniu połączenia).

Jedną z głównych zalet impacket-psexec jest możliwość uwierzytelniania za pomocą hashy NTLM, co jest szczególnie przydatne w scenariuszach ofensywnych, gdzie przeprowadzamy ataki pass-the-hash. Atak pass-the-hash polega na tym, że gdy pentester wyeksploituje usługę systemową, zamiast hasła do konta administratora może uzyskać jego hash NTLM. Ten hash może posłużyć do dalszego uwierzytelnienia się na zdalnym systemie, dzięki czemu nie ma potrzeby łamania takiego hasha, aby kontrolować kolejne usługi.

Implementacja impacket-psexec na Kali Linux ma tę zaletę względem windowsowego oryginału, że właśnie pozwala na łatwiejsze wykonywanie ataków pass-the-hash (rysunek 19).

Podsumowanie

PsExec oraz jego pythonowy odpowiednik impacket-psexec to narzędzia, które powinny znaleźć się w standardowym narzędziowniku pentestera. Dzięki nim możemy w prosty sposób zarządzać zdalnymi maszynami, omijając przy tym polityki blokujące PowerShella czy RDP. W połączeniu z resztą narzędzi pakietu PsTools dostajemy zestaw, który ułatwi nam poruszanie się po infrastrukturze sieciowej, jej rekonesansie, a także usprawni eskalację uprawnień.

Prostota, wszechstronność i możliwość integracji tych narzędzi z innymi programami czyni PsTools nieocenionym zestawem dla osób zajmujących się bezpieczeństwem systemów Windows.

~Adrian „Vizz” Michalczyk (vizzdoom@gmail.com)