Active
En Windows easy-box där vi hittar inloggningsuppgifter för en användare och sedan använder dessa för enumeration av domänen. För privilegie-eskalering använder vi Kerberoasting.
Last updated
En Windows easy-box där vi hittar inloggningsuppgifter för en användare och sedan använder dessa för enumeration av domänen. För privilegie-eskalering använder vi Kerberoasting.
Last updated
Som vanligt så börjar jag med att köra en Nmap-scan av boxen.
Tänkte även passa på att visa hur snyggt format det blir om man väljer att skapa en HTML-rapport för Nmap-skanningen.
Då får man ett sådant här resultat. Snyggt, prydligt och lättöverskådligt.
Åter till resultatet. Onekligen ser det ut att vara en Windows-box, eventuellt Windows Server 2008 R2 SP1 och domänen heter "active.htb". Vi ser tjänster som DNS, Kerberos, SMB, RPC och LDAP.
Jag blir framförallt nyfiken på SMB och om det tillåter en NULL-session/Anonymous-login, alltså att det går att ansluta utan inloggningsuppgifter. Och det gör det!
Admin$, C$, IPC$, NETLOGON, SYSVOL och Users kan vi inte göra så mycket med. Replication kommer vi dock åt.
I Replication hittar vi en intressant fil:
Den ligger i Preferences-delen av en GPO. Detta är vad som benämns som en GPP (Group Policy Preferences). GPP är ett sätt att ytterligare konfigurera en klient i en domän. Denna maskinen ska enligt Nmap vara en Windows Server 2008R2 SP1. Dessa två bitar av information gör att jag misstänker att denna maskin är sårbar för MS14-025 som är en sårbarhet i Group Policy Preferences.
Denna sårbarhet gör att när man skapar en GPP där man sätter lösenordet på det lokala admin-kontot så skapas det en XML-fil som heter Groups.xml där användarnamn och lösenord lagras. Lösenorden är visserligen krypterade med en 32-bitars AES256-nyckel. Problemet var bara att Microsoft någon gång för länge sedan publicerade nyckeln som används på MSDN, vilket gör det till en trivial sak att dekryptera dessa strängar. Konstigt nog ligger den fortfarande kvar.
Eftersom denna maskin är en Windows Server 2008 och patchen släpptes i maj 2014 så är sannolikheten stor för att vi faktiskt kan extrahera giltigt användarnamn och lösenord ur denna Groups.xml-filen. Vi testar!
Mycket riktigt så ligger både användarnamn (active.htb\SVC_TGS) och lösenords-hash i filen. För att dekryptera lösenordet kan vi använda ett verktyg som heter "gpp-decrypt".
Nu har vi ett användarnamn och ett lösenord som vi kan använda för att försöka få in en fot på maskinen.
Nu har vi haft lite tur och hittat rätt på första försöket. Vi ser hur långt vi kommer med detta, annars får vi gå tillbaka och undersöka de andra tjänsterna som körs.
Vi försöker komma åt Users-share:en som vi stötte på tidigare.
Efter att ha angett lösenordet vi fick fram tidigare så har vi nu tillgång till Users-share:en! Här hittar vi även user-flaggan och hämtar den.
Inloggningsuppgifterna kan vi även använda för enumeration av domänen. VI börjar med att kolla vilka konton vi kan hitta. Det gör vi med följande skript:
VI får då följande svar:
Vi ser att det endast finns 4 konton på boxen.
Det finns även ett skript som heter GetUserSPN.py, med detta kan man få ut en lista på alla konton i domänen med ett Service Principal Name. Det kan vara bra att testa för att se om man får en träff.
-dc-ip är IP-adressen till domänkontrollanten
Därefter anger man bara domän/kontonamn
Vi får då fram ett konto som verkar har SPN satt och det är inget mindre än Administrator-kontot.
Vad är då Service Principal Name, eller SPN som det förkortas? För att förklara det så behöver vi gå igenom hur Kerberos fungerar lite snabbt.
Kerberos består av tre delar (därav namnet som anspelar på den trehövdade hunden Cerberus i den grekiska mytologin):
Klienten
Servern
KDC (Key Distribution Center)
När en klient vill nyttja en tjänst så måste den först autentisera sig och få en TGT (Ticket Granting Ticket) av KDC.
Därefter skickar den en begäran (TGS-REQ) om att få åtkomst till tjänsten/servern, klienten får då en Ticket Granting Service-biljett av KDC som den tar med sig.
Därefter går klienten till tjänsten och visar sin biljett, tjänsten i sin tur visar upp att den faktiskt är den specifika tjänsten (med hjälp av SPN). När de upprättat ett förtroende (båda autentiserat sig för varandra) så kan klienten börja nyttja tjänsten.
SPN definieras på följande sätt <tjänst>/<datorkonto>.domän. Det skulle kunna se ut så här: MSSQLSvc/SRVSQL01.CORP.LOCAL
Denna tjänsten körs i kontexten av t.ex. service account "SVC-MSSQL". SPN definieras då på detta service account. (Även användarkonton har ett sådant attribut, detta kallas User Principal Name, eller UPN.)
Om vi då återgår till resultatet ovan så är det en felkonfiguration när man sätter ett SPN på ett administratörs-konto då det har alldeles för mycket privilegier och dessutom brukar konton som är skapade av människor ha förutsägbara lösenord. När ett konto har ett SPN öppnar det upp för en attack som kallas "Kerberoasting".
Kerberoasting är en attack som Tim Medin uppfann och presenterade första gången 2014. Han upptäckte att när en klient begär en TGS (Ticket Granting Service) så tar Kerberos det efterfrågade service accounts lösenord, gör om det till en NTLM-hash och krypterar biljetten med denna hash för att endast den rätta tjänsten ska kunna dekryptera biljetten.
Det man då kan göra är att begära en TGS-biljett, i den får man ut NTLM-hash:en för tjänstens service account. Denna hash kan vi sedan försöka hitta ett matchande lösenord för med hjälp av t.ex. hashcat eller John The Ripper. Vi börjar med att begära en biljett.
Vi får då ut följande svar:
Vi sparar hash:en i en textfil som heter "hash.txt". Därefter använder vi hashcat för att försöka hitta lösenordet. Som ordlista använder vi rockyou.txt. Det hashcat gör i detta fallet är att den tar varje ord i ordlistan, gör om den till NTLM-hash och jämför hash:en med den vi har i textfilen. Om den matchar då vet vi att vi har hittat rätt lösenord.
Det tar inte lång tid innan vi får en träff, närmare bestämt 24 sekunder.
Nu kan vi testa att komma åt boxen med Administrator-kontot. För detta nyttjar vi python-varianten av PSExec.
Vi är nu NT AUTHORITY/SYSTEM och kan läsa root.txt!
Tack för att ni hängt med hela vägen, detta var en ganska enkel men rolig Windows-box som visade på risken med felkonfiguration av konton och varför man alltid bör jobba enligt least privilege-principen.
