Autor: admin

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.

https://chacker.pl/

Po uruchomieniu serwera WWW w katalogu PowerSharpBinaries, możemy załadować narzędzie Rubeus. Rubeus pozwala nam przeprowadzić rozpoznanie i eksploatację Kerberosa. Jest napisany w języku C#, ale w tym ćwiczeniu wykorzystamy wersję etapową programu PowerShell:

Kerberoasting wykorzystuje sposób, w jaki usługi obsługują bilety Kerberos w AD. Te bilety usług są żądane z serwera przyznającego bilety (TGS) i zawierają informacje o użytkowniku usługi, aby określić, czy użytkownik powinien mieć dostęp do usługi bez konieczności znajomości hasła użytkownika. Ten bilet usługi jest szyfrowany za pomocą poświadczeń właściciela usługi — konta komputera lub konta użytkownika. Każda usługa będzie identyfikowana za pomocą nazwy głównej usługi (SPN) w usłudze Active Directory, którą użytkownik może wyszukać, aby zidentyfikować usługę, a gdy użytkownik zażąda tego biletu, nie musi on komunikować się z usługą docelową. Zamiast tego, jeśli użytkownik wyeksportuje te bilety, można je wymusić w trybie offline za pomocą narzędzia do łamania haseł, zamieniając przykładowe hasło na skrót NTLM, a następnie próbując odszyfrować bilet. Jeśli bilet zostanie odszyfrowany, wiemy, że jest to prawidłowe hasło dla usługi. Ten proces jest znany jako Kerberoasting. Użyjmy Rubeusa do Kerberoastu domeny i wyszukajmy prawidłowe nazwy SPN powiązane z kontami użytkowników, które moglibyśmy wykorzystać w niewłaściwy sposób:

Hasze będą teraz w pliku h.txt i można je skopiować do Kali w celu złamania. Po skopiowaniu haszy możesz spróbować je złamać za pomocą John the Ripper i listy słów na komputerze Kali. Ponieważ te maszyny są lekkie, spróbujmy najpierw z bardzo małą listą słów:

Nie wiadomo, do którego użytkownika to trafia, więc sprawdźmy nasz plik John POT:

Widzimy, że użytkownik passwordadmin ma hasło Passw+ord127. Sprawdzimy to ponownie za chwilę, ale najpierw spróbujmy tego samego z użytkownikami AS-REProasted. AS-REP to wstępne negocjacje uwierzytelniające z serwerem udzielającym biletów, zanim użytkownik otrzyma bilet udzielający biletów (TGT). Po wykonaniu tego wstępnego uwierzytelnienia informacje zostaną zwrócone użytkownikowi zaszyfrowane za pomocą żądanego skrótu NTLM użytkownika, więc można je złamać w podobny sposób:

Plik zostanie zapisany podobnie jak atak Kerberoasting i może zostać skopiowany do skrzynki Kali w celu złamania. Teraz, gdy mamy poświadczenia z Kerberoasting, przeprowadźmy rekonesans i dowiedzmy się więcej o użytkowniku i tym, do czego ma dostęp.

https://chacker.pl/

Czasami konta usługowe zawierają hasła w swoim opisie. Ma to na celu to, aby konta, które mogą być używane do wyszukiwania informacji lub innych działań ogólnego przeznaczenia, nie musiały mieć centralnie skoordynowanych poświadczeń. Oczywiście nie jest to najlepsza praktyka, ale nie zmienia to faktu, że zdarza się to częściej niż powinno. Aby znaleźć takie przypadki, załadujemy moduł PowerView i wyszukamy użytkowników z poświadczeniami w opisie ich konta:

BadBlood utworzy losowe konta jako część konfiguracji AD dla tego laboratorium, więc Twoje dane uwierzytelniające mogą wyglądać inaczej i będą miały różne grupy. Niezależnie od różnic, powinno to dać Ci wiele danych uwierzytelniających, które użytkownicy mogą wykorzystać jako ścieżki eskalacji. Jeśli ci użytkownicy nie są wartościowi, istnieją inne sposoby zbierania danych uwierzytelniających. Przyjrzyjmy się Kerberoasting i ASREProasting.

https://chacker.pl/

Eskalacja uprawnień AD zawiera trochę sztuki i trochę narzędzi. Część znajdowania ścieżek do Administratora domeny można wykonać za pomocą narzędzi takich jak BloodHound. Niezależnie od tego, jakich narzędzi używasz do znajdowania ścieżek, często będzie musiała nastąpić seria eskalacji. Przyjrzyjmy się kilku sposobom znajdowania poświadczeń do eskalacji.

https://chacker.pl/

Ponieważ ten sam nasłuch jest nadal na miejscu, uruchommy Invoke-SharpUp.ps1, aby zobaczyć, co może znaleźć (zauważ, że używamy tego samego stagera iex/iwr, którego używaliśmy do tej pory):

Widzimy, że usługa „Vulnerable Software” ma modyfikowalny plik binarny usługi. Przyjrzyjmy się plikowi binarnemu z icacls.exe:

To pokazuje, że nie mamy żadnych uprawnień do tego pliku binarnego. Dlaczego więc SharpUp go wyróżnił? Został wyróżniony z powodu niezacytowanej ścieżki usługi. Kiedy system Windows szuka plików binarnych, zaczyna od próby wyszukania pliku binarnego przy każdej przerwie spacji. W tym przypadku będzie szukał c:\Software\Vulnerable.exe, zanim dojdzie do vulnagent.exe. Przyjrzyjmy się uprawnieniom w katalogu C:\Software:

Mamy tutaj możliwość dodawania plików i katalogów, więc możemy spróbować utworzyć vulnerable.exe. Stwórzmy aplikację C#, aby po prostu dodać siebie do lokalnej grupy Administrators. Utworzymy plik vulnerable.cc w c:\programdata, a następnie go skompilujemy. W przypadku zawartości użyj tego podstawowego skryptu C#:

Po zapisaniu pliku jako c:\ProgramData\vulnerable.cc możemy go skompilować za pomocą wbudowanego kompilatora C# w środowisku .NET:

Teraz, gdy wszystko jest już gotowe, spróbujmy ponownie uruchomić tę usługę:

Teraz jesteśmy członkami lokalnej grupy Administratorzy, ale użycie polecenia whoami /groups nie pokaże tego. Aby uzyskać uprawnienia, musimy się wylogować i zalogować ponownie lub rozpocząć nową sesję za pomocą runas lub innej metody. Tak czy inaczej, musimy utworzyć nową powłokę z uprawnieniami Administratora, więc zróbmy to i zbadajmy kilka taktyk eskalacji z Active Directory.

https://chacker.pl/

Narzędzie winPEAS (Privilege Escalation Awesome Script) to plik wsadowy lub C#, który tworzy profil systemu Windows i próbuje zidentyfikować luki w zabezpieczeniach, które mogą zostać wykorzystane. Użyjemy wersji PowerShell z repozytorium SharpPack, która została sklonowana do Kali. Za pomocą tego samego odbiornika HTTP, który został skonfigurowany w poprzednich laboratoriach, załadujemy skrypt InvokewinPEAS.ps1, a następnie sprawdzimy niektóre z naszych opcji:

Możemy zobaczyć wiele informacji o systemie, a także kilka exploitów, które mogą się przydać do eskalacji uprawnień. Większość z nich wymaga pobrania dodatkowych plików binarnych do systemu, co może oznaczać AV lub EDR. Skrypt dostarczył nam jednak niektórych dodatkowych informacji, które uzyskaliśmy od Seatbelt, więc byłaby to realna alternatywa dla zbierania danych. WinPEAS nie wykrył jednak żadnej z podatnych ścieżek przez usługę, a to jest jedna z mocnych stron SharpUp, więc przyjrzyjmy się temu.

https://chacker.pl/

Chociaż PowerSploit ma wiele modułów, które są przydatne do późniejszej eksploatacji, skupimy się na module PowerView w podkatalogu Recon. Z naszego pola Kali uruchommy serwer WWW w katalogu PowerSploit:

Następnie na naszym serwerze docelowym załadujmy moduł PowerView. Możemy to zrobić za pomocą stagera iex/iwr:

Następnie wypróbujmy niektóre z funkcji, które omówiliśmy wcześniej. Najpierw zdobądźmy informacje o naszej domenie:

To te same informacje, które widzieliśmy wcześniej, ale są o wiele prostsze. Ponadto możemy uzyskać listę OU, jak poprzednio:

Aby uzyskać listę kontroli dostępu (ACL) dla jednostki organizacyjnej administratora, możemy użyć polecenia cmdlet Get-DomainObjectAcl:

Niestety, SID użytkownika nie jest rozwiązany, a uprawnienia są nadal w formie GUID, podobnie jak w metodzie ADSI z wcześniejszego artykułu. PowerView może pomóc nam je przekonwertować, aby wyjaśnić dostęp każdego użytkownika. Użyjmy polecenia cmdlet ConvertFrom-SID i opcji -ResolveGuids do Get-DomainObjectAcl, aby to uporządkować:

Dzięki temu odczyt danych jest znacznie łatwiejszy. Ponadto możemy użyć PowerView do wyszukania użytkowników, którzy mają uprawnienia DCSync, pobierając ACL dla tych, którzy mają albo uprawnienia All privileges albo uprawnienia replication w DN domeny:

Teraz wiemy, których użytkowników należy wybrać, aby przeprowadzić atak DCSync. To tylko kilka elementów, których można szukać.  Możemy użyć tych informacji, aby taktycznie znaleźć informacje, których potrzebujemy w domenie, bez wydawania ogromnej liczby zapytań, ale jednym z ulubionych narzędzi jest BloodHound. BloodHound zbierze mnóstwo informacji AD, a następnie pozwoli przeszukać dane w przeglądarce baz danych grafów o nazwie Neo4j. Wadą tego jest to, że wydaje ogromne ilości zapytań, a bardziej dojrzałe organizacje szukają ich, aby zidentyfikować złośliwe intencje, więc nie jest to szczególnie bezpieczne pod kątem bezpieczeństwa operacyjnego.