Bloodhound – ett verktyg för angripare och försvarare

Denna veckas blogg kommer att diskutera verktyget Bloodhound. I artikeln så kommer vi att diskutera installation av verktyget, inhämtning av data till verktyget (ingest data) och upptäckt av verktyget för Blue Teams. Vi inleder med en kort beskrivning av BloodHound.

Bloodhound är ett verktyg för att identifiera svaga och missbrukbara konfigurationer i en Active Directory domän. Verktyget använder grafteori för att avslöja gömda och oavsiktliga relationer inom en domän. Detta visualiseras genom grafverktyget Neo4j genom vilken en angripare kan identifiera komplexa attacker som annars skulle vara nästintill omöjliga att upptäcka. För extrahering och enumrering av data från en domän till visualiseringsverktyget används s.k. ingestors.

Ansvarsfriskrivning: Genomgående i artikeln kommer det att blandas fritt mellan engelska och svenska och vissa ord kommer användas synonymt med varandra utan tidigare hänvisning. Artikelförfattaren ber om överseende med detta.

Installation

Bloodhound (visualiseringsverktyget)

För att installera visualiseringsverktyget behövs det att Neo4j och Bloodhound installeras. Detta kan utföras genom exempelvis i *unix:

Sudo apt install neo4j

Sudo apt install bloodhound *

*Artikelförfattaren har inte kunnat använda pakethanteraren apt för att installera Bloodhound i distributioner utanför Kali (troligen för att repot inte finns med som standard), och då kan de färdigkompilerade binärerna  användas istället, se här.

Ingestors (datainhämtning)

För att installera en ingestor så kan du ladda ned en av dessa:

• SharpHound (för användning på Windows-dator mot ett AD on-prem)
• AzureHound (för användning i Azure-miljöer)
• BloodHound.py (användning på både Linux och Windows-dator mot ett AD on-prem)

Artikeln kommer i huvudsak att fokusera på AD on-prem och AzureHound nämns endast, intresserade läsare hänvisas till länken för AzureHound.

Den sistnämnda ingestorn (bloodhound.py) kräver ldap3, impacket och dnspython för att fungera. För artikelförfattaren har det vid tillfällen uppstått problem med användning av pythoningestorn till följd av ldap3 (felen har troligen varit handhavandefel). Vid tidspressade uppdrag rekommenderas det därför att ha en färdiginstallerad virtuell maskin med SharpHound för att minimera tidsspill och felsökning.

Alla ingestors dumpar data i JSON-format och är således operativsystemagnostiska vid inläsning till BloodHound.

Skräddarsydda sökfrågor (Custom queries)

I Bloodhound är det möjligt att skriva skräddarsydda sökfrågor i sökspråket Cypher, men är man ovan i Cypher går det att ladda ned fullt dugliga sökfrågor från Github exempelvis dessa och dessa. Egenskrivna sökfrågor sparas i visualiseringsverktyget och nedladdade sökfrågor kan laddas in i BloodHound genom att lägga dessa under (på Linux):

~/.config/bloodhound/customqueries.json

Efter installation återfinns en fil på sökvägen ovan med samma namn och tom, och går således att skriva över eller döpa om med tillägg .bak eller liknande.

Starta Bloodhound

Innan BloodHound kan startas behöver grafverktyget neo4j startas. För att starta neo4j första gången så används följande kommando (fortfarande *unix):

sudo neo4j start

Surfa in på webbplatsen (http://localhost:7474) som anges. Där kommer en första gångs användare att bli uppmanad att logga in. Standardautentiseringsuppgifter är neo4j:neo4j.

Användaren kommer därefter bli uppmanad att ändra lösenordet, det rekommenderas att klicka i att neo4j automatgenererar ett lösenord och kopiera detta (för du kommer behöva använda det i nästa steg).

Nu kan du starta Bloodhound.

Fyll i autentiseringsuppgifterna för neo4j och ditt nysatta lösenord, för att slippa komma ihåg lösenordet till nästa gång – klicka i rutan kom ihåg mig.

Ingesta data

Beroende på vad som ska testas, vilka behörigheter som har erhållits i domänen och vilken dator som testet utförs ifrån och vilka behörigheter du har på datorn kommer valet av ingestor att variera. I valet av ingestor spelar även personliga preferenser in.

SharpHound

Om du har en Windows-dator så är SharpHound ett bra val som ingestor. För att skapa en session med en användare i domänen från en ej domänansluten dator kan du använda följande kommando:

runas /netonly /user:domain\user cmd.exe

Efter rätt lösenord har delgetts kommer då CMD att öppnas under den angivna använderens konto. I CMD letar du upp SharpHound-filen och använder följande kommando:

./SharpHound.exe --CollectionMethod All

Kommandot kommer samla in all data som den kan från domänkontrollanterna. En övergripande bild över vilken data som samlas in kan ses i Figur 3. Det finns flera olika flaggor som kan användas baserat på uppdragets mål, men detta går utanför omfattningen för artikeln och intresserade läsare hänvisas till denna länk.

Python bloodhound

Om du har däremot vill använda Kali eller annan distribution så är BloodHound.py ett bra val. Programmet kan installeras via pip eller installeras via setup.py som laddas ned från Githubsidan för BloodHound.py. Installation av verktyget:

pip install bloodhound

För att exekvera programmet och påbörja inhämtning av information från en domän används följande kommando:

bloodhound-python -u support -p '#00^BlackKnight' -ns 10.10.10.192 -d blackfield.local -c all

I det ovanstående kommandot betyder flaggorna:

• -u: Användare
• -p: Lösenord
• -ns: Nameserver (DNS), är oftast en av domänkontrollanterna
• -d: Domän
• -d: Collection Method

Det finns flera olika flaggor som kan användas baserade på uppdragets mål, men detta går utanför omfattningen för artikeln och intresserade läsare hänvisas till denna länk.

Det finns vissa begränsningar med BloodHound.py jämfört med SharpHound. BloodHound.py har inte stöd för GPO-relaterade funktioner som SharpHound har, samt är Kerberos-autentisering i beta för programmet. Detta är dock inget som hindrar vanliga användare från att nyttja pogrammet.

Ingesta data till BloodHound

Efter en körning med något av verktygen bör en ZIP-fil med JSON-filer ha erhållits.

ZIP-filen kan du släppa i BloodHounds grafiska gränssnitt så packar den upp filerna och laddar in dem. Alternativt kan de packas upp och laddas upp genom ”Upload data”.

Analysera importerat resultat med Bloodhound

Det som kan undersökas under ett test är bland annat:

• För tillåtande ACL:er
• ASREPRoast
• Constrained, Unconstrained och Resource-based Constrained delegation
• Privilegerade användare
• Kerberoast
• M.m

Det finns enormt mycket att titta på i BloodHound och under ett penetrationstest är det begränsat med tid och därmed begränsat hur mycket som är möjligt att identifiera. Blue Teams bör därför utföra periodiska körningar med BloodHound för att identifiera svaga konfigurationer i domänen. Nedanstående bilder är några exempel av vad som är möjligt att identifiera med BloodHound (bilder tagna från denna länk):

Figur 8 förklarar översiktligt hur BloodHound kan upptäcka vägar till att kompromettera en domän.

1. YMAHDI00284 är en användare i domänen och har ett medlemskap i gruppen IT00166
2. Medlemmar i gruppen IT00166 kan genom RDP ansluta till dator COMP00336
3. På COMP00336 har användaren TPRIDE000072 en session
4. Användaren TPRIDE000072 är domänadministratör

För att kunna utnyttja det ovanstående skulle vi behöva ansluta till COMP00336 och där dumpa autentiseringsuppgifter eller på annat sätt injicera kod i en process som körs under användaren TPRIDE000072. Det skulle ge oss tillgång till användarens token och vi skulle på så sätt kunna bli domänadministratörer.

Användaren TPRIDE000072 var inloggad på COMP00336 vid tillfället av körningen av BloodHound och när vi väl vill exploatera detta kan sessionen sedan länge vara nere. Det finns sätt att identifiera fler sessioner som kan leda till ett komprometterande av en domän, men det kommer inte denna artikeln att gå in på utan hänvisar till denna länk.

Vi ska använda Figur 8 som ett ett exempel, där vi letar upp användare för att Kerberoasta.

Kerberoast

Målet med Kerberoasting är att inhämta TGS biljetter för tjänster som körs under användarkonton i en domän och inte datorkonton. Detta gör att TGS biljetterna är krypterade med nycklar som är härledda från en användares/servicekontons lösenord. Genom inhämtning av TGS-biljetter kan därmed användares/servicekontons lösenord knäckas offline. För att identifiera ett användarkonton som används som en tjänst behöver man endast identifiera att attributet ”ServicePrincipalName (SPN)” inte är null.

För att kunna utföra Kerberoasting behöver du endast ett låg priviligerat konto i domänen då inga speciella privilegier behövs.

Exempel

Ponera att under körningen med BloodHound identifierades flertalet konton som hade SPN satt och därmed kunde Kerberoastas. En av dessa konton är medlemmar i gruppen Domain Admins i domänen.

Självfallet skulle du vilja utnyttja detta som angripare och använder ett verktyg för inhämtning av TGS-biljetter, exempelvis Rubeus (Windows-verktyg).

För användning av Rubeus om du inte sitter på en domänansluten dator men har ett konto i domänen du testar:

runas /netonly /user:domain\user cmd.exe

Starta Rubeus:

Rubues.exe kerberoast /outfile:hashes.txt

Med de erhållna hasharna kan du nu använda valfritt lösenordsknäckningsverktyg, exempelvis hashcat för att knäcka ett lösenord och elevera dina rättigheter inom domänen. För hashcat används mode 13100 för TGS-biljetter.

Upptäcka BloodHound och Kerberoast

Alla autentiserade användare i en domän kan ställa frågor till organisationens AD för kartläggning av domänen. Trafiken som genereras används av legitima tjänster och det kan därmed vara svårt att upptäcka nyttjandet av BloodHound och Kerberoasting. Vi kommer demonstrera två olika tillvägagångssätt för att upptäcka nyttjandet av BloodHound och Kerberoasting i en domän för Blue Teams.

Tillvägagångssätt 1

För att upptäcka BloodHound är det nödvändigt att aktivera en GPO för domänkontrollanterna. Det Event ID vi vill upptäcka är Event ID 5145 – ”A network share object was checked to see whether client can be granted desired access”.

Denna loggning aktiveras på domänkontrollanterna genom följande konfiguration:

Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Audit Policy >> Audit Object Access

Klicka i att försök för success ska loggas.

Event ID 5145 används legitimt i en domän och det är därför viktigt att inte överflöda sitt loggsystem med flertalet false positives. Det BloodHound gör vid användning av CollectionMethod ALL eller Default är att verktyget ansluter mot tjänsterna srvsvc, lsarpc och samr. Vid en körning med BloodHound är det oftast även samma användare och source IP-address och port. Följande pseudoalgoritm kan användas för att detektera BloodHound:

1. Händelseloggarna innehåller Event-ID 5145, och
2. Händelseloggarna innehåller Relative Target Name: srvsvc, lsarpc eller samr under 1 minuts intervall, och
3. Minst 3 händelser där samma Account Name, Source Address och Source Port (konto och IP-adress) under 1 minuts intervall, och
4. Account Name innehåller inte $ (maskinkonto)

Tillvgagångssätt 2

Det andra tillvägagångssättet är liknande som det första i det initala steget förutom att du klickar i Success på Audit directory access på domänkontrollanterna. Det event-ID som skapas då är event-ID 4662.

Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Audit Policy >> Audit directory access

Nu kommer tillvägagångssätten skilja sig ifrån varandra. För denna metodik kommer vi att skapa ”Honey Accounts”, dvs fejkade konton vars syfte är att upptäcka intrång i miljön. Vi vill skapa användarkonton, maskinkonton och grupper och göra dessa så realistiska och representativa för domänen som möjligt. Exempelvis bör det läggas till detaljer som jobbtitel, avdelning, namn etc. Försök även att logga in då och då så att tidsstämpeln för senaste inloggning inte är alltför gammal. Dessa konton bör inte ha några rättigheter i domänen och bör vara behäftade med långa lösenord (enligt overifierad källa ska hashcat få en buffer overflow om lösenordet är längre än 30 tecken som kan användas som riktmärke).

Följande pseudoalgoritm kan användas för tillvägagångssätt 2:

1. Händelseloggarna innehåller Event-ID 4662, och
2. Objekt GUID är detsamma som för ett av de uppsatta Honey Accounts, och
3. Account Name innehåller inte $ (maskinkonto)

Upptäcka Kerberoast

För att upptäcka Kerberoast i en domän är det möjligt att utnyttja liknande tillvägagångssätt som för BloodHound. Man kan välja mellan att fånga in allt på domänkontrollanterna för ett specifikt Event ID eller skapa ”Honey accounts” för att granska specifika konton. Det måste vid skapandet av fejkat konto för upptäckt av Kerberoasting sättas ett fejkat SPN för kontot. Detta för att kontot ska kunna Kerberoastas. Det behövs även att Event ID 4769 loggas, vilket kan ses nedan och i Figur 13.

Computer Configuration >> Windows Settings >> Security Settings >> Advanced Audit Policy Configuration >> System Audit Policies – Local Group olicy Object >> Account Logon >> Audit Kerberos Service Ticket Operations

Pseudoalgoritmerna för upptäckt av Kerberoasting är:

Tillvägagångssätt 1

1. Händelseloggarna innehåller Event-ID 4769, och
2. Service Name är inte lika med krbtgt, och
3. Service Name slutar inte med $, och
4. Ticket Options är 0x40810000, och
5. Felkod (Failure Code) är 0x0, och
6. Ticket Encryption Type är 0x17

Tillvägagångssätt 2

1. Händelseloggarna innehåller Event-ID 4769, och
2. Ticket Options är 0x40810000, och
3. Service Name är det fejkade SPN

Avslutande ord

Bloodhound är ett mångsidigt verktyg för både angripare och försvarare och kan på ett bra sätt användas för att kartlägga svagheter i en organisations domän. För försvarare bör det periodiskt användas för att upptäcka potentiella svagheter och luckor i övervakningen.

BloodHound och Kerberoasting undgår upptäckt i många domäner då teknikerna använder samma samma kommunikationskanaler och protokoll som legitima tjänster. Det är därför svårare att upptäcka och därför upprepas rekommendationen gällande försvarare – därmed är det viktigt att försvarare (Blue Teams) periodiskt använder BloodHound för att upptäcka svagheter och luckor i övervakningen.

För angripare (penetrationstestare) bör inte BloodHound användas för mer än ett uppdrag och den virtuella maskin/dator som använts för uppdraget bör ominstalleras. Det är möjligt att radera databasen på Neo4j och bearbeta ny data från ett nytt uppdrag men det rekommenderas inte.