Miesiąc: styczeń 2025

https://chacker.pl/

SIDHistory to funkcja, która pomaga w migracji Active Directory. Gdy łączysz domeny lub lasy, podczas migracji, może być przydatna wiedza o tym, kim był użytkownik, aby zachować dostęp do poprzednich zasobów podczas migracji. Pole SIDHistory przechowuje identyfikatory SID poprzednich kont lub grup, do których należał użytkownik, aby mógł on nadal mieć dostęp jako poprzedni użytkownik w tych innych środowiskach. Niestety, dodawanie poprzednich identyfikatorów SID do użytkownika nie jest łatwym zadaniem. Jest to coś, co zwykle wykonuje się, gdy baza danych AD jest w trybie migracji. Z tego powodu PowerView nam nie pomoże. Zamiast tego będziemy musieli użyć naszych uprawnień, aby uzyskać bezpośredni dostęp do kontrolera domeny, a następnie możemy użyć modułu DSInternals PowerShell, aby dodać nasz identyfikator SID. Moduł wymaga od nas zatrzymania usługi NTDS, aby mogła ona uczynić usługę AD niedostępną, dopóki nie zostanie ona ponownie uruchomiona. Zacznijmy od końca  po wykonaniu Enter-PSSession w celu zalogowania się do DC. Teraz możemy uzyskać SID grupy Domain Admins:

Następnie instalujemy moduł dsinternals, jak pokazano poniżej. Pozwoli nam to na korzystanie z modułu po jego zainstalowaniu w systemie. Jeśli pojawią się jakieś monity o dodanie zależności, po prostu odpowiedz tak.

Po zaimportowaniu modułu musimy teraz zatrzymać usługę NTDS, a następnie użyć polecenia cmdlet ADD-ADDBSidHistory, aby dodać SID grupy Domain Admins do użytkownika docelowego. Musimy również określić lokalizację pliku bazy danych NTDS.dit. Usługa NTDS musi być offline, abyśmy mogli uzyskać dostęp do pliku; w przeciwnym razie zostanie on zablokowany.

Musimy odczekać kilka sekund, aż usługa zostanie ponownie uruchomiona; następnie możemy sprawdzić użytkownika docelowego i ustalić, czy ustawienia zostały wprowadzone:

Widzimy, że SIDHistory jest teraz obecne. Aby zastosować uprawnienia, użyjmy polecenia runas, aby uruchomić nowe okno poleceń i sprawdzić nasze uprawnienia:

Widzimy, że SIDHistory jest teraz obecne. Aby zastosować uprawnienia, użyjmy polecenia runas, aby uruchomić nowe okno poleceń i sprawdzić nasze uprawnienia:

Udało nam się nadać sobie uprawnienia Domain Admins bez bycia w grupie. Teraz mamy wiele sposobów, aby pozostać w domenie — albo korzystając z naszych uprawnień przyznanych przez SIDHistory, albo za pośrednictwem dostępu przyznanego przez nasze modyfikacje AdminSDHolder, które zostały rozpropagowane do uprzywilejowanych grup.

https://chacker.pl/

Na DerbyCon5 Sean Metcalf wygłosił wykład zatytułowany „Czerwony kontra niebieski: nowoczesne ataki i obrona usługi Active Directory”, w którym omówił specjalny obiekt w usłudze Active Directory, AdminSDHolder. Ten kontener jest wyjątkowy, ponieważ co godzinę uprawnienia, które się w nim znajdują, są propagowane do wszystkich elementów z admincount=1 w AD. Propagacja ta nazywa się SDProp, a gdy w kontenerze zostaną wprowadzone modyfikacje, w ciągu godziny zmiany będą obowiązywać we wszystkich obiektach administratora. I odwrotnie, jeśli zmienisz obiekt administratora, proces SDProp zastąpi Twoje zmiany w ciągu godziny. W laboratorium 17-12 wykonaliśmy DCSync, a następnie wstrzyknęliśmy bilet Kerberos do naszej sesji. W przypadku tego ataku potrzebujemy skrótów NTLM w naszej sesji. Aby to zrobić, ponownie załadujemy BetterSafetyKatz, wykonamy DCSync na koncie administratora, a następnie utworzymy nowy cmd.exe przy użyciu skrótów NTLM dla naszej sesji na naszym komputerze docelowym:

Powinno pojawić się nowe okno z wierszem poleceń. Teraz musimy załadować PowerView, abyśmy mogli łatwo sprawdzić, jakie są uprawnienia bieżącego obiektu AdminSDHolder, a następnie pracować nad dodaniem naszego backdoora:

Obecnie tylko konto Local System BUILTIN ma pełne uprawnienia do obiektu AdminSDHolder. Dodajmy użytkownika docelowego, aby móc wrócić. Aby to zrobić, użyjemy polecenia cmdlet Add-ObjectAcl w PowerView. Docelowo wybierzemy obiekt AdminSDHolder, a następnie dodamy uprawnienie GenericAll za pomocą opcji Rights:

Teraz, gdy sprawdzimy uprawnienia, powinniśmy zobaczyć użytkownika GHH\target na liście dostępu z uprawnieniami GenericAll:

Sukces! Uprawnienia są propagowane do innych grup co godzinę, więc musimy trochę poczekać, a następnie powinniśmy móc sprawdzić grupę Domain Admins i zobaczyć, że cel ma pełny dostęp do grupy:

Widzimy, że przy pierwszej próbie tylko System lokalny miał pełny dostęp, ale gdy odczekamy kilka minut, zobaczymy, że użytkownik docelowy jest również wymieniony. Jako nasz użytkownik docelowy możemy teraz dodawać członków do grupy według własnego uznania.

https://chacker.pl/

Teraz, gdy mamy dostęp Administratora domeny, chcemy się upewnić, że możemy go zachować. Aby to zrobić, mamy kilka opcji. Na przykład możemy utworzyć nowych użytkowników, których kontrolujemy, a następnie dodać ich do zaufanych grup, takich jak Administratorzy domeny. Jednak w bardziej dojrzałych organizacjach członkostwo w grupach krytycznych jest starannie monitorowane i możemy dać znać obrońcom, co spowoduje, że usuną nasz dostęp. Mamy jednak dodatkowe opcje. Przyjrzymy się dwóm metodom osiągnięcia trwałości: zatruwaniu obiektu AdminSDHolder i wstrzykiwaniu historii SID.

https://chacker.pl/

Na początek chcemy wiedzieć, jakie członkostwa w grupach ma ten użytkownik passwordadmin i co te grupy robią. Możemy w tym celu użyć PowerView:

Grupa użytkowników CloudSync znajduje się w jednostce organizacyjnej Administrative OU, więc wygląda to obiecująco. Sprawdźmy, czy znajdziemy jakieś interesujące listy kontroli dostępu w AD, do których dostęp ma nasz użytkownik passwordadmin lub grupa użytkowników CloudSync. Krok 1 to użycie polecenia cmdlet PowerView Find-InterestingDomainAcl, które wyszuka interesujące uprawnienia w obiektach AD. Chcemy zapisać to w zmiennej, aby nie musieć uruchamiać tego w kółko, ponieważ jest to dość czasochłonne, a im większa domena, tym większe będą wyniki. Określamy również opcję ResolveGUIDs, abyśmy mogli łatwo odczytać uprawnienia po zakończeniu wyszukiwania:

WSKAZÓWKA Może to zająć sporo czasu. To narzędzie przeszukuje wszystkie listy kontroli dostępu w domenie i rozwiązuje informacje dla każdego ze znalezionych wpisów.  

Następnie chcemy poszukać rzeczy, które mają naszego użytkownika i grupę jako część Identity ReferenceName. Możemy użyć programu PowerShell, aby to dla nas przefiltrować:

Wygląda na to, że grupa CloudSync Users ma możliwość DCSync z domeną. Możemy zalogować się jako ten użytkownik i wykonać te zadania lub możemy użyć Rubeusa, aby dodać dla nas TGT, który pozwoli nam wykonać atak DCSync bez ponownego uwierzytelniania. Następnie otwieramy okno cmd.exe jako Administrator, używając naszych nowych uprawnień i wchodzimy do wiersza poleceń programu PowerShell. Musimy ponownie zaimportować nasz moduł Rubeus, a następnie poprosić o TGT. Potrzebujemy tego podwyższonego dostępu, ponieważ normalnie nie można wstrzykiwać poświadczeń do sesji bez niego.

Teraz mamy TGT. Mając ten poziom poświadczeń, możemy spróbować wykonać DCSync z naszymi poświadczeniami PasswordAdmin. Aby to zrobić, użyjemy BetterSafetyKatz, aby wykonać atak DCSync dla użytkownika krbtgt. Pozwoli nam to użyć ataku golden ticket, aby uzyskać dostęp do dowolnego konta w domenie. Najpierw użyjmy stagera iex/iwr, aby załadować BetterSafetyKatz:

Po załadowaniu Mimikatz do pamięci możemy teraz wykonać ukierunkowaną synchronizację DC użytkownika krbtgt. Musimy określić moduł lsadump::dcsync i użytkownika docelowego dla opcji:

Potrzebujemy tutaj dwóch informacji: SID domeny (1), który jest całym SID do 502, oraz skrótu aes256_hmac (2). Potrzebujemy tych informacji, ponieważ wszelkie bilety, które utworzymy ze słabszym szyfrowaniem, mogą zdradzić, że są sfałszowane. Następnie chcemy utworzyć TGT dla administratora, używając ataku złotego biletu. Ten atak używa kluczy szyfrujących krbtgt, aby sfałszować TGT dla innego użytkownika, który następnie może zostać użyty do uwierzytelnienia w systemach w domenie. Umieszczamy wszystko w jednym poleceniu w wierszu poleceń:

WSKAZÓWKA Jeśli to nie działa, upewnij się, że aktualizujesz swój SID i inne istotne informacje, aby pasowały do ​​Twojej konkretnej instancji. W przyszłych krokach konieczne będą dodatkowe zmiany dla takich elementów, jak SID, nazwa hosta kontrolera domeny itd., więc upewnij się, że zaktualizowałeś każdą zmienną odpowiednio.

To pokaże nam, że nowy TGT został wygenerowany i wstrzyknięty do naszej sesji:

Widzimy, że bilet został pomyślnie utworzony i teraz możemy wyjść z Mimikatz. Mamy teraz prawidłowy token administratora i możemy go użyć, aby uzyskać dostęp do DC. Widzieliśmy na początku ataków Kerberos, że rozwiązał on nazwę DC na EC2AMAZ-TBKC0DJ.ghh.local. Możemy użyć programu PowerShell, aby uzyskać dostęp zdalny:

Teraz eskalujemy do użytkownika Administratora domeny i mamy pełną kontrolę nad lasem ghh.local.