Dzisiejszy artykuł jest kontynuacją artykułu z kampanii „Microsoft LAPS – atakowanie i ochrona”. Pokażemy, jak cyberprzestępcy kompromitują LAPS oraz na co należy zwracać uwagę przy monitorowaniu tego typu aktywności.
W celu przeprowadzenia próby ataku na rozwiązanie Microsoft LAPS osoby atakujące (cyberprzestępcy) muszą najpierw zdobyć przyczółek w infrastrukturze – przejść przez fazę exploitacji KILL CHAIN lub skompromitować konto użytkownika np. poprzez phishing. Celowo nie będziemy opisywać tej fazy ataku, ponieważ pisaliśmy o niej w innych artykułach na Hack’u (tutaj znajdziesz wiele przykładów i sposobów jak to można wykonać).
Dostanie się do środka infrastruktury w firmie (serwery i stacje robocze) umożliwia cyberprzestępcom wykonywanie z poziomu systemu operacyjnego poleceń, które pomogą sprawdzić, czy jest w niej wdrożony LAPS oraz czy posiadają wystarczające uprawnienia, żeby przejąć nad nią kontrolę. Zacznijmy wiec od pierwszego elementu ataku – fazy rozpoznania, czyli wykonania zestawu poleceń pozwalających „zbadać grunt”.
Rekonesans środowiska
Niewątpliwie pierwszym krokiem, który należy wykonać po zdobyciu dostępu do stacji roboczej lub serwera w infrastrukturze Active Directory jest przeprowadzenie rekonesansu, czyli sprawdzenia środowiska. Ten krok jest o tyle istotny, ponieważ pozwala poznać uprawnienia użytkownika, którego przejął cyberprzestępca oraz odpytać środowisko Active Directory o odpowiednie atrybuty sugerujące wykorzystanie w nim LAPS. Celem tego etapu jest również sprawdzenie, które komputery są chronione przez LAPS oraz przejęcia uprawnień administracyjnych w celu wykonania dalszej fazy ataku.
Każde konto użytkownika (lub komputera) należące do Active Directory posiada możliwość odpytywania po LDAP bazy danych Active Directory. Dlatego:
Przejmując konto zwykłego użytkownika jesteśmy w stanie sprawdzić kilka istotnych informacji, które pozwolą nam zorientować się, czy konto lokalnego administratora na komputerze, na którym się znajdujemy jest zarządzane przez LAPS.
W poprzednim artykule używaliśmy poleceń w PowerShell sprawdzających, czy na komputerze jest zainstalowany klient LAPS oraz jakie posiada skonfigurowane uprawnienia itp. Oczywiście z nich także mogą korzystać cyberprzestępcy do zebrania interesujących dla nich informacji.
Posiadając poświadczenia zwykłego, domenowego użytkownika o nazwie „kapitannhack.pl” w domenie „Kapitan.Hack” wykonujemy następujące polecenia w celu sprawdzenia czy na komputerze jest zainstalowany klient LAPS:
1) Sprawdzenie jakie uprawnienia posiada nasz użytkownik lokalnie na komputerze oraz w AD
Komenda: whoami /groups
2) Sprawdzenie czy komputer ma zainstalowanego klienta LAPS
Komenda w PowerShell: Get-ChildItem ‘c:\program files\LAPS\CSE\Admpwd.dll’
W odpowiedzi systemu na wykonaną przez nas komendę w PowerShell otrzymujemy w wynikach potwierdzenie znalezienia pliku „Admpwd.dll” w katalogu „C:\Program Files\LAPS\CSE”. O tej bibliotece napiszemy więcej w późniejszej części artykułu.
Na podstawie powyższych informacji widzimy już, że komputer, na który się zalogowaliśmy posiada zainstalowanego klienta LAPS. Nie oznacza to jeszcze, że zarządzane jest na nim hasło lokalnego konta administratora. Aby tak było pamiętajmy, że taki komputer musi być zarządzany poprzez odpowiednie GPO z ustawieniami dla LAPS oraz takie GPO musi się na nim poprawnie wykonywać (muszą być poprawnie aplikowane ustawienia z polityki).
Ważną informacją jest również fakt, że Active Directory musi być przygotowane pod LAPS (posiadać rozszerzony schemat o atrybuty LAPS oraz wdrożony odpowiedni model zarządzania).
Musimy zatem zdobyć szersze informacje – tym razem sięgniemy po nie do AD.
Kolejne polecenia jakie wykonujemy:
3) Upewnienie się, że Active Directory zawiera atrybuty LAPS ms-Mcs-AdmPwd oraz ms-Mcs-AdmPwdExpirationTime
Komenda PowerShell: Get-ADObject ‘CN=ms-Mcs-AdmPwd,CN=Schema, CN=Configuration,DC=KAPITAN,DC=HACK’
Zatem w naszym testowanym scenariuszu widzimy rozszerzony schemat Active Directory pod LAPS. Kolejnym krokiem, który warto sprawdzić to uprawnienia do tych atrybutów. Może się okazać, że przejęte wcześniej konto domenowe posiada odpowiednie uprawnienia do pobierania hasła- wtedy sytuacja jest oczywista. Jeśli mamy zainstalowane wbudowane w Windows narzędzie RSAT (narzędzia administracji zdalnej serwera) istnieje interesujący sposób identyfikacji użytkownika mającego dostęp do atrybutu ms-Mcs-AdmPwd. Aby to wykonać możemy użyć polecenia:
4) Sprawdzenie uprawnień do atrybutów LAPS
Komenda: dsacls.exe ‘ścieżka do OU z naszym komputerem’
W wynikach zwróconych przez powyższe polecenie możemy wyszukać uprawnień do atrybutu ms-Mcs-AdmPwd oraz ms-Mcs-AdmPwdExpirationTime
Oprócz narzędzia dsacls.exe istnieją też inne możliwości/metody na odpytanie o te uprawnienia chociażby napisanie własnego skryptu w VBScript lub PowerShell lub zastosowania narzędzia firmy trzeciej.
Tym razem nie mamy szczęścia z odpowiednimi uprawnieniami dla konta, gdyż nasz użytkownik „Kapitanhack.pl” nie przynależy do żadnych w wymienionych powyżej grup mających uprawnienia do atrybutu hasła LAPS.
Ale to nie koniec, jeśli chodzi o uprawnienia.
Backdoor w uprawnieniach LAPS
Pisaliśmy w poprzednim artykule o specjalnym uprawnieniu ACE w Active Directory – „All Extended Rights” – DS_CONTROL_ACCESS.
Jeśli jest ono przydzielone do obiektu „komputer” dla użytkownika bądź grupy, wówczas taki użytkownik/grupa może czytać wszystkie rozszerzone uprawnienia, w tym „poufne atrybuty” LAPS.
Jest to bardzo duże zagrożenie bezpieczeństwa, ponieważ możemy o tym nie wiedzieć.
Drugim ukrytym faktem, o którym mało kto wie jest:
Jeśli komputer został dodany do domeny przez zwykłego użytkownika (a może to wykonać i pisaliśmy o tym tutaj), wówczas automatycznie dla jego konta użytkownika dodawane są explicite na obiekcie komputera dodatkowe uprawnienia, w tym „All Extended Rights)”.
Oznacza to, że nasz użytkownik ‘kapitanhack.pl’ może z powodzeniem pobrać hasło na konto lokalnego administratora zarządzanego na tym komputerze przez LAPS.
Wykonać to można prostą komendą w PowerShell:
Get-ADComputer WIN10_20H2 -Properties ms-mcs-admpwd
Trzeci problem w uprawnieniach LAPS’a to możliwość odczytu przez zwykłego użytkownika atrybutu daty wygaśnięcia hasła konta administratora dla danego komputera – atrybut ms-Mcs-AdmPwdExpirationTime (wartość podawana w Integer). Co nam daje taka możliwość? Otóż za pomocą jednego zapytania cyberprzestępca może zobaczyć, które komputery w Active Directory są zarządzane przez LAPS oraz dla których zmienia się cyklicznie hasło przez AD.
Komenda w PowerShell:
Get-ADComputer -filter {ms-Mcs-AdmPwdExpirationTime -like ‘*’} -Properties ‘ms-Mcs-AdmPwd’, ‘ms-Mcs-AdmPwdExpirationTime’
Jeśli wartość atrybutu ms-Mcs-AdmPwdExpirationTime nie jest pusta, to najprawdopodobniej system Windows zmienił hasło na koncie lokalnego administratora i ustawił datę (wyrażoną liczbowo) kiedy hasło wygaśnie i ponownie zostanie zmienione. Zatem jeśli delegowanie uprawnień do atrybutu „ms-Mcs-AdmPwdExpirationTime” jest zbyt szerokie, przejęcie jednego z kont użytkowników mających odpowiednie uprawnienie zapisu/modyfikacji może zmienić wartość tego atrybutu na bardzo odległą w czasie datę / godzinę. Skutkować to będzie tym, że hasło lokalnego administratora nie zmieni się do tego czasu. Jest to przydatne dla atakującego, który zidentyfikował hasło(a) LAPS, a następnie może przedłużać ich użycie.
Weryfikacja uprawnienia „All Extended Rights” na komputerach w AD
Żeby sprawdzić takie konta użytkowników lub grupy w AD, czy mają możliwość czytania wszystkich atrybutów (All Extended Rights), w tym poufnych atrybutów LAPS na komputerze posłużymy się poleceniem również wymienianym w naszym poprzednim artykule – Find-AdmPwdExtendedRights z modułu AdmPwd.ps LAPS.
Komenda:
Find-AdmPwdExtendedRights -IncludeComputers -Identity WorkStations | fl
W wyniku otrzymaliśmy listę uprawnień AllExtended Rights przydzielonych dla kont użytkowników/grup na obiekcie OU ‘Workstations”, w którym znajdują się zarządzane przez LAPS komputery oraz listę uprawnień do tychże komputerów. Widzimy, że na kontach komputerów są dodatkowo przyznane uprawnienie dla grup „Accounts Operators” i „Domain Admins” oraz dla użytkownika „KapitanHack.pl” (ponieważ tym kontem posłużyliśmy się do dodania komputera do domeny).
Podmiana biblioteki AdmPwd.dll na komputerze
Ostatnią, ciekawą możliwością ataku na LAPS jaką opiszemy, to podmiana biblioteki klienta LAPS (plik AdmPwd.dll).
Nie wspominaliśmy wcześniej o tym, że LAPS został oparty na rozwiązaniu „open source” o nazwie „AdmPwd” opracowanym przez Jiri Formacek’a i stał się częścią portfolio produktów firmy Microsoft od maja 2015 roku. Interesującą informacją jest również fakt, że rozwiązanie LAPS nie posiada sprawdzania integralności ani weryfikacji podpisu dla pliku AdmPwd.dll (informacje jak to można ręcznie zweryfikować zamieściliśmy w poprzednim artykule).
Kolejną ciekawą informacją jest, że rozwiązanie AdmPwd jest zgodne z Microsoft’owym LAPS’em, więc istnieje możliwość pobrania źródeł z Internetu i modyfikacji (zatrucia złośliwym kodem). Wystarczy skompilować źródło projektu i zastąpić oryginalną bibliotekę dll od Microsoft własną, a będziemy mogli np. poznać hasło lokalnego administratora zmieniane przez LAPS bez potrzeby hackowania Active Directory.
Poniżej przedstawiamy przykład kodu jaki może posłużyć do rejestracji w pliku tekstowym na dysku hasła lokalnego konta administratora zarządzanego przez LAPS.
Wystarczy w źródle kodu (po wywołaniu „else”) pliku „AdmPwd.cpp”:
Dodać 4 poniższe linijki:
wofstream LAPS_backdoor;
LAPS_backdoor.open (“c:\\LAPS_password_backdoor.txt”);
LAPS_backdoor << newPwd;
LAPS_backdoor.close ();
Po kompilacji uzyskujemy bibliotekę „AdmPwd.dll” działającą z LAPS, którą możemy wgrać na komputer. Aby to wykonać oczywiście musimy posiadać odpowiednie uprawnienia do systemu (administracyjne), lecz na tym etapie zakładamy, że użytkownik uzyskał już uprawnienia administratora przez LPE lub w jakikolwiek inny sposób.
Dzięki temu sposobowi atakujący będzie mógł poznać wszystkie hasła zmieniane cyklicznie przez LAPS na komputerze, do którego uzyskał dostęp.
Podsumowanie
Pokazaliśmy możliwości ataku na LAPS, przeprowadzenia fazy rozpoznania oraz tworzenia backdoor w środowisku. Pomimo tego, że LAPS może mieć pewne niedociągnięcia (które rozwiązanie ich nie ma?), które należy odpowiednio skonfigurować i zarządzać/zabezpieczyć rekomendujemy jego użycie w środowisku informatycznym przede wszystkim z dwóch powodów: łatwości wdrożenia oraz korzyści zarówno biznesowych jak i bezpieczeństwa.
W celu zabezpieczenia i mitygacji powyższych sposobów ataku na LAPS należy zwrócić szczególną uwagę na takie aspekty jak:
- Sprawdzenie integralności/podpisu pliku admpwd.dll na komputerach
- Wdrożenie odpowiedniego mechanizmy monitorowania LDAP w AD w szczególności w zakresie odpytywania przez użytkowników o określone atrybuty LAPS ich zmianie oraz monitorowanie uprawnień do obiektów LAPS
- Zabezpieczenie mechanizmu pobierania hasła z LAPS w AD
- Zastosowanie białej listy aplikacji w celu wykrywania / zapobiegania podmiany pliku DLL na komputerach lub wdrożenie EDR
- Zwiększenie poziom rejestrowania aktywności LAPS, ustawiając poniższą wartość rejestrze systemowym na 2 (tryb pełny, rejestruje wszystko): HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}\ExtensionDebugLevel
Zachęcamy również do zapoznania się z sugestiami odnośnie zabezpieczeń wymienionymi w poprzednich dwóch artykułach LAPS. Zapraszamy do kontaktu z firmą APPEAL, w celu zabezpieczenia i usprawnienia zarządzania LAPS.