Kom igång med Powershell-hacking mot Azure AD

En vanlig uppfattning angående molntjänster är att leverantören säkerställer säkerheten så länge man använder default-inställningar i sin molninstans, så det kan väl inte finnas någon anledning att göra ett penetrationstest mot sin Azure AD-instans.

Visst stämmer det väl att leverantören har bra koll på själva hårdvaran och en del grundläggande funktioner, men felkonfigurationer och osäkra inställningar (som även inkluderar vissa defaultinställningar) i din egen instans ansvarar de givetvis inte för. Och säkerhetsinställningar är inte alltid lätta att få en samlad översikt över i Azure. Så visst är det en bra idé att penetrationstesta Azure AD-instanser, som dessutom kan vara en väg in till en synkad on-prem AD-domän.

Tänkte nämna några tips hur man kan komma igång med detta med hjälp av Powershell.

Förberedelser

Till att börja med så kan Powershells “Execution policy” behöva ändras innan installationer och körning av nedan moduler (används med försiktighet, man kan exempelvis välja att det bara ska gälla aktuell session, se ^[1] för alternativ):

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

Moduler

Sen bör vi installera/importera några powershell-moduler som kan vara bra att ha:

Az^[2], AzureAD^[3] och MSOnline^[4]

Dessa moduler är från Microsoft, prereqs för vissa av de övriga modulerna nedan. Installeras från PSGallery med hjälp av nedanstående kommandon.

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
Install-Module AzureAD
Install-Module MSOnline

AADInternals^[5]

Oumbärlig modul, massor av kommandon för Azure AD-hacking. Kan också installeras via PSGallery och kan sedan importeras:

Install-Module AADInternals
Import-Module AADInternals

MicroBurst^[6]

Ytterligare en modul med en hel del kommandon för Azure AD-hacking. Denna laddas ned, förslagsvis som zipfil från github^[6], packas upp och importeras med kommandot (byt ut [SÖKVÄG] till sökvägen dit du packade upp filen):

Import-Module  .\[SÖKVÄG]\MicroBurst-master\MicroBurst.psm1

MSOLSpray^[7]

Modul/script för password spraying. Ladda ned .ps1-filen från github^[7] och importera med kommandot (byt även här ut [SÖKVÄG] mot sökvägen där du sparade filen):

Import-Module .\[SÖKVÄG]\MSOLSpray.ps1

Rekognosering

Ett av de första stegen i varje penetrationstest är rekognosering, givetvis även så om man ska penetrationstesta Azure-instanser. Alla kommandon nämnda i detta inlägg kan ske utan inloggning och utnyttjar publika API:er.

Våra förutsättningar för detta test är att det enda vi känner till är en dns-adress, lab.simovits.net.

För att hitta information om en tenant (motsvarande ungefär domän i vanligt AD-sammanhang) kan man börja med bland annat kommandona:

Get-AADIntTenantDomains lab.simovits.net
Invoke-AADIntReconAsOutsider -DomainName lab.simovits.net

^{Inte så mycket info, men nästa kommando ger mer.}

*^{Resultatet visar en del nyttig info såsom tenant id, namn och alternativa domännamn, och huruvida SSO och några andra egenskaper är aktiva.}*

Nu har vi även ett alternativt namn, själva tenantnamnet som är mer standard, och testar att använda det för att enumerera aktiverade vanliga tjänster/subdomäner med kommandot:

Invoke-EnumerateAzureSubDomains -Base simovitslab

*^{Funna subdomäner indikerar aktiverade tjänster på tenanten.}*

Av detta kan vi se att det bland annat verkar finnas en lagringsyta aktiverad med namnet simovitslabstorage. Vi kan försöka enumerera denna lagringsyta efter publikt tillgängliga filer genom kommandot:

Invoke-EnumerateAzureBlobs -Base simovitslab

Kommandot använder en ordlista för att leta efter vanliga containernamn (jfr mappnamn), och man kan använda en egen lista om man vill. Har man väl hittat en container listas alla eventuella filer som ligger där (om containerns åtkomstnivå är satt till ”Container”).

Ser lovande ut, det finns en publikt tillgänglig fil med ett mycket intressant namn. Vi kan öppna angiven länk till filen med exempelvis en vanlig browser för att kika på innehållet:

Nja, kanske inte så intressant ändå, så vi går vidare med nästa steg som kan vara att försöka enumerera användare. Här måste man gissa på olika användarnamn, men har man med övrig surfning på aktuellt måls hemsida, google och/eller linkedin hittat namn på anställda kan man först ta reda på vilken namnstandard som verkar användas genom att i en lista ange några olika permutationer av en användare och använda denna lista med kommandot:

Get-Content .\[SÖKVÄGTILLLISTA].txt | Invoke-AADIntUserEnumerationAsOutsider

^{Lista med olika gissningar på namnstandard}

*^{Raden vid pilen visar att användarnamnet är giltigt}*

Det ser ut som att namnstandarden består av användarens förnamn. Efter rigid efterforskning på internet har jag lyckats komma fram till en trolig lista på samtliga anställda som jag tillämpat samma namnstandard på och lagt i en ny lista, och även slängt in några övriga vanligt förekommande användarnamn. Jag kör samma kommando igen men med nya listan som input:

*^{En hel del bekräftat existerande användarnamn}*

Vi verkar haft rätt om namnstandarden och hittade även några allmänna konton: “admin” och “servicedesk”.

Password spraying

Om det är en väldigt stor organisation och man hittat många användare kan det sen vara värt att testa password spraying, vilket innebär att gissa ett lösenord mot alla användare. Denna metod är normalt inte så effektiv, men används eftersom man kommer börja låsa ut användarna om man gissar för många lösenord per användare i för snabb följd. Man bör alltså bara testa detta en eller ett väldigt fåtal gånger med god tid mellan försöken. Trots ineffektiviteten kan man som sagt ha tur med en bra gissning mot en stor organisation.

Jag uppdaterade listan på användare vi använde ovan så den nu bara består av bekräftat giltiga användare, och använder den som input för nästa kommando.

Password spray kan göras med exempelvis modulen MSOLSpray och kommandot nedan (byt ut [SÖKVÄGTILLLISTA] mot lista på bekräftade användare, samt [LÖSENORDSGISSNING] till det lösenord du vill testa mot dessa användare)

Invoke-MSOLSpray -UserList .\[SÖKVÄGTILLLISTA].txt -Password "[LÖSENORDSGISSNING]"

Nej men, se god dag då! Servicedesk använder tydligen lösenordet ”Sommar2022!”. Oväntat!

Nu kan vi använda denna användare för att köra ytterligare mängder av kommandon som en inloggad användare/insider, och kanske logga in i portalen och kika runt för att sedan beroende på vad vi hittar kanske försöka eskalera behörigheter ytterligare eller hitta på andra post-exploitation-åtgärder.

Om användaren/tenanten dock använder MFA och/eller Conditional Access blir det givetvis ett/några extra steg för att försöka kringgå dessa skydd. Därför blir väl kontentan av detta inlägg den självklara rekommendationen att aktivera båda dessa funktioner (som inte är aktiverade by default) i sin Azure AD-instans.

Detta var ju givetvis bara några exempel på kommandon och en bråkdel av vad man kan göra med dessa powershellmoduler och/eller övrig Azure-hacking, men det får räcka för detta inlägg.