Atakowanie kont usługowych gMSA w Active Directory

Ważne atrybuty kont gMSA

Musimy zacząć od wymienienia ważnych dla nas atrybutów kont gMSA są to z pewnością:

• atrybut msDS-GroupMSAMembership – odpowiada za to, kto może uzyskać dostęp do hasła gMSA.
• atrybut msds-ManagedPassword zawiera BLOB z informacjami o hasłach dla kont usługowych zarządzanych grupowo.

Dodatkowo, aby uzyskać identyfikator klucza posłużymy się atrybutem msDS-ManagedPasswordId i na koniec msDS-ManagedPasswordInterval, który służy pobierania liczby dni przed automatyczną zmianą hasła

PS C:\> Get-ADServiceAccount -filter {name -eq 'KAPITANHACK_SVC’} -prop * | Select Name,DNSHostName,MemberOf,Created,LastLogonDate,PasswordLastSet,msDS-ManagedPasswordInterval,PrincipalsAllowedToDelegateToAccount,PrincipalsAllowedToRetrieveManagedPassword,msDS-ManagedPassword,ServicePrincipalNames

Powyższe informacje możemy pozyskać z Active Directory uruchamiając cmdlet PowerShell Get-ADServiceAccount. Przykład powyżej, gMSA jest członkiem grupy Administratorzy w domenie „Kapitan.hack”. Na zrzucie ekranu widać, że hasło zostało ostatnio zmienione i nie zmieni się przez 30 dni. Oznacza to, że jeśli uda się zdobyć hasło do tego konta, pozostanie miesiąc na wykorzystanie jego danych uwierzytelniających.

Atakujący wykona najprawdopodobniej dwa scenariusze, pierwszy, gdzie uzyskujemy dostęp do serwera z uprawnieniami administratora, aby za pomocą narzędzia Mimikatz wyciągnąć hash hasła NT. Drugi w przypadku braku dostępu do serwera wylistuje listę osób (i komputerów) z uprawnieniami do pozyskania hash’a aby użyć ich poświadczeń do wyciągnięcia hasła. Oba scenariusze mają taki sam cel, którym jest kompromitacja środowiska Active Directory.
W celu pokazania tych możliwości posłużyliśmy się scenariuszami opisanymi przez Sean Metcalf.

Scenariusz 1 – Pozyskiwanie dostępu do serwera z uruchomioną usługą gMSA

Po wejściu na serwer, na których działają usługi GMSA, mamy kilka opcji.

Jak widać serwer LCNSQL01 jest zarejestrowany jako Service Principal Name (SPN) w gMSA, widać też, że serwer znajduje się w Servers OU.

Wystarczy skompromitowanie konta z prawami do Servers OU lub delegowanymi prawami administratora poprzez GPO. Mając możliwość modyfikacji GPO, które łączy się z tym OU, uzyskujemy prawa administratora na serwerze LCN.

Po uzyskaniu praw administratora możemy zobaczyć, że w usługa gMSA została skonfigurowana tak aby uruchomić Windows License Manager.

Za pomocą Mimikatz i komendy sekurlsa::logonpasswords, możemy zobaczyć hash hasła natomiast nie jest to jeszcze forma, której możemy użyć do kompromitacji środowiska AD.

Nie jest to standardowe hasło (i nie jest to hasło przypisane do konta). Co więcej, ten hash hasła nie jest poprawny. Microsoft wczytuje dane uwierzytelniające GMSA do LSASS, ale nie wygląda, aby ich używał.

Aby uzyskać prawidłowy hash hasła NT, musimy użyć polecenia Mimikatz które jest używane do uzyskania biletów Kerberosa:

sekurlsa::ekeys

Scenariusz 2 – Brak dostępu do serwera

Mając informacje o tym, że istnieje grupa skonfigurowana z uprawnieniami do uzyskania hasła i wykorzystując to, że atrybut konta gMSA msDS-GroupMSAMembership zawiera grupę o nazwie „SVC-LAB-GMSA1 Group” możemy się dowiedzieć kto może żądać i otrzymywać hasło w postaci czystego tekstu.

Używając cmdlet Get-ADGroupMember jesteśmy w stanie określić członków danej grupy, widzimy, że występuję w niej komputery, użytkownicy i jeszcze jedna grupa „Server Admins”.

Teraz mamy listę wszystkich kont, które mogą uzyskać hasło gMSA w postaci czystego tekstu. Jest 11 kont użytkowników z taką możliwością, z czego 9 z nich wygląda jak zwykłe konta użytkowników.

Następnie kompromitujemy konto użytkownika lub komputera, który ma możliwość pozyskania hasła w postaci czystego tekstu. W tym celu możemy użyć cmdleta

Get-ADServiceAccount

Dane dotyczące hasła w postaci czystego tekstu które zawiera atrybut msds-ManagedPassword możemy uzyskać korzystając z modułu DSInternals który przekonwertuje blok haseł w postaci tekstu na hash NT.

Uwaga: Jeśli konto, które jesteśmy w stanie przejąć, jest kontem komputera, musimy uruchomić te polecenia jako SYSTEM na komputerze. Możemy do tego zastosować PSEXEC.

Załóżmy, że jesteśmy w stanie uzyskać prawa administratora/SYSTEM na serwerze z uprawnieniami do pozyskania hasła gMSA, ale usługa nie pracuje na tym hoście. W tym przypadku uruchomienie Mimikatz nie pomoże, ponieważ poświadczenia gMSA nie są przechowywane w pamięci.

Używając PSEXEC, jesteśmy w stanie wywołać polecenia jako lokalne konto SYSTEM. Po tym możemy wykonać te same czynności, które opisaliśmy powyżej.

Potwierdzenie hashy

Ostatnim krokiem jest potwierdzenie, że hash hasła NT uzyskany przez DSInternals odpowiada hasłu w Active Directory. Do tego możemy zastosować polecenie

DSInternals Get-ADReplAccount

Po potwierdzeniu, że hash konta gMSA zgadza się z hashem pobranym z AD możemy skompromitować środowisko AD.

Podsumowanie

Nieodpowiednio zabezpieczane konta gMSA szczególnie z wysokimi uprawnieniami potrafią w prosty sposób doprowadzić do kompromitacji całej domeny. Szczególnie ważne jest, aby weryfikować jakich uprawnień wymaga pracujące konto usługowe w naszym środowisku. Bądź czy istnieje możliwość nadania niższych uprawnień do prawidłowej pracy. Warto też zweryfikować ilość użytkowników którzy posiadają uprawnienia do pozyskania hasła z kont gMSA. W tym artykule między innymi opisywaliśmy, jak ograniczyć dostęp kont usługowych do poszczególnych serwerów, na których odpowiadają za obsługę. Nie ma potrzebny, aby były wystawione tam, gdzie nie wykonują żadnego zadania.