W dzisiejszym artykule, kolejnym z serii Active Directory Persistance pokażemy, jak za pomocą modyfikacji odpowiednich wpisów na koncie użytkownika w Active Directory będziemy mogli odpalić plik binarny podczas zdalnej sesji (logowania się) do serwera terminali.
Zdalne wykonanie pliku binarnego (RCE) z poziomu Active Directory podczas zdalnego logowania się użytkowników do serwera terminali? Czemu nie?
Serwery terminali (Terminal Servers lub Remote Desktop Session Host (RDSH)) zdobyły dużą popularność w środowiskach informatycznych IT firm udostępniając dla pracowników możliwość zdalnego łączenie się wielu kont użytkowników do systemów i aplikacji. Używane są także przez administratorów do zdalnego łączenia się z serwerami docelowymi (zdalny pulpit) i zarządzania nimi. Co powiedziałbyś, gdyby podczas takiego logowania odpalał się payload na serwerze bez jakiejkolwiek ingerencji użytkownika? Jest to możliwe dzięki konfiguracji jednej z ciekawszych zakładek na użytkowniku w Active Directory o nazwie „Environment”. Metodę opisał na swoim blogu Justin Perdok w czerwcu 2020 i jej postanowiliśmy poświęcić poniższy artykuł.
Aby można było edytować ustawienia zakładki Environment wystarczy zdobyć odpowiednie uprawnienia w Active Directory do zapisu przynajmniej „GenericWrite” na koncie użytkownika, skonfigurować powyższe wpisy, a podczas logowania do terminal serwera uruchomi się payload.
Poniżej zamieszczamy skrypt, który pozwoli na wykonanie takich zmian:
W wyniku wykonania powyższego skryptu na użytkowniku Administrator zobaczymy poniższe wartości:
Po zalogowaniu się użytkownika Administrator na serwerze terminali z serwera o adresie IP 172.16.215.129 pobierze się lokalnie plik „payload.exe” i automatycznie wykona.
Diabeł tkwi w szczegółach
Oczywiście cała operacja ataku nie jest taka prosta do wykonania. Muszą być spełnione odpowiednie warunki:
- Server terminali, na który loguje się zdalnie użytkownik/administrator musi być serwerem w wersji nie nowszej niż Windows 2012 R2. W nowszych wersjach serwerów Microsoft ograniczył tę możliwość, ale poniżej wyjaśnimy, jak ją obejść.
- Konto użytkownika z uprawnieniami, które ustawi powyższe atrybuty dla użytkowników logujących się przez terminal server musi posiadać odpowiednie uprawnienia do ich zapisu na kontach użytkowników.
Istotna jest wersja Terminal Server
W systemie Windows Server 2012 R2 i starszych wersjach w momencie, gdy użytkownik loguje się na serwer z zainstalowaną rolą serwera terminali (TS) / hosta sesji usług pulpitu zdalnego (RDSH), proces Remote Connection Manager (RCM) kontaktuje się z kontrolerem domeny w celu wysłania zapytania o jego konfigurację konta i ustawień Pulpitu zdalnego. Ustawienia są następnie aplikowane są podczas procesu logowania użytkownika w celu dostosowania jego sesji (tzw. sesja terminalowa). Ustawienia te znajdziemy w zakładce „Remote Desktop Services Profile”.
Wiele nowoczesnych środowisk Active Directory odchodzi od konfiguracji tych atrybutów bezpośrednio na koncie użytkownika na rzecz ustawień poprzez GPO oraz kolekcji serwerów pulpitu zdalnego. Ustawienia te nie mogą być delegowane na poziome jednostki organizacyjnej (OU) lub grupy zabezpieczeń, lecz indywidualnie dla każdego obiektu. Dlatego Microsoft w nowych wersjach Windows (od 2016) prawdopodobnie zrezygnował z ich używania.
Oznacza to, że serwery z wersji Windows 2016 nie będą mogły korzystać z ustawień RCM.
RCM można jednak ponownie włączyć w systemie RDSH opartym na systemie Windows Server 2016 lub nowszym, tworząc następujące wpisy w rejestrze systemowym.
Klucz fQueryUserConfigFromDC o typie DWORD i watrości 1, w scieżcie HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\
oraz ten sam klucz w ścieżce:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\
Oczywiście w przypadku Windows 2016 dodanie powyższych wpisów do rejestru wymaga przejęcia uprawnień konta administratora na serwerze terminali. Plusem jest, że aby stały się aktywne nie wymagane jest ponowne uruchomienie serwera ani ponowne uruchomienie jego usług terminalowych. Oprócz skonfigurowania powyższych opcji musimy jeszcze wskazać (skonfigurować) jedną zakładkę „Environment”. To w niej wskażemy lokalizację, skąd ma być uruchomiony payload.
Podczas procesu logowania te wartości będą sprawdzane przez proces RCM i uruchamiane niezależnie od zdefiniowanego pliku wykonywalnego.
Wymagane uprawnienia do wykonania ataku
Może się zdarzyć sytuacja, w której znajdziemy użytkownika w Active Directory, który posiada uprawnienia zapisu atrybutów na atakowanych kontach. Takie uprawnienia może też przydzielić sobie atakujący w różny sposób np. opisywany w naszym poprzednim artykule Backdoor w Active Directory? Część 4 – przejęcie uprawnień poprzez AdminSDHolder
Jeśli nie mamy możliwości stworzenia backdoor’a z wymaganymi uprawnieniami, możemy przeszukać Active Directory w celu wystąpienia takich wpisów ACE, które pozwolą na zapis atrybutów na koncie użytkownika/lub administratora logującego się przez terminal serwer. Takie uprawnienia możemy wyszukać używając narzędzia PowerViewlub BloodHound. Jest jeszcze inna możliwość – napisanie własnego skryptu w VBScript lub PowerShell :).
Podsumowanie
Active Directory kryje w sobie wiele zagadek. Ich znajomość pozwala atakującym na bycie bezkarnym lub ułatwić sobie drogę do przeprowadzania ataku na środowisko. Powyższy artykuł pokazuje jeden z takich przykładów, w którym nieświadomy administrator w organizacji będzie mógł udostępnić tylną furtkę dla cyberprzestępcy i umożliwić proste przeprowadzenie ataku na środowisko.
Polecamy nasze inne części cyklu Active Directory Persistence:
- Backdoor w Active Directory? Część 1 – Utworzenie przyczółku
- Backdoor w Active Directory? Część 2 – ograniczone delegowanie uprawnień i przejęcie domeny
- Backdoor w Active Directory? Część 3 – dodanie komputera do domeny
- Backdoor w Active Directory? Część 4 – przejęcie uprawnień poprzez AdminSDHolder
Zachęcamy do udostępniania i komentowania artykułu na Facebook oraz na LinkedIn.