Det er vanskelig å skape og vedlikeholde et sikkert miljø. Og med hver teknologi eller produkt som legges til i infrastrukturen, blir det mer komplisert. Microsoft Azure som et skymiljø er intet unntak fra denne regelen, og med de mange tjenestene og funksjonene som legges til hvert år blir det bare mer komplisert selv om man ikke har endret noe. Fordi det er viktig å holde IT-systemene sikre når man flytter til skyen, er det viktig å vite hvilke dårlige praksiser man bør unngå og hvilke angrepsscenarier som finnes der ute.
La oss se på kjente angrepsveier i et Azure-miljø. Angrepene er ikke nye for mange, og er basert på offentlig forskning fra andre IT-sikkerhetseksperter. I likhet med lokal Active Directory er det viktig å gjøre denne informasjonen så lett tilgjengelig som mulig. Å vise hvordan ulike tjenester og tillatelser kan føre til et sårbart miljø er nøkkelen, og å ha all denne informasjonen på ett sted er en god start.
Siden angrepsgrafer bidrar til å lette noe av kompleksiteten, er denne oversikten basert på de forskjellige angrepsveiene med denne modellen.
Avhengig av informasjonen som er inkludert i det publiserte arbeidet for hver angrepsvei, er oppskriften basert til en kort angrepsbeskrivelse, og du må lese de originale artiklene for å få detaljerte detaljer og dyptgående forklaringer.
De fleste av disse angrepene er ikke bare av akademisk natur, men brukes av angripere i den virkelige verden .
Hvis det er gitt, vil alle jakt-spørringer være basert på PowerShell- eller Kusto/KQL-spørringer. For sistnevnte må du videresende Azure- og Azure AD-aktivitet til et Log Analytics-arbeidsområde. Dette arbeidsområdet trenger ikke være Microsoft Sentinel-aktivert for å utføre spørringene.
Elevate Azure Subscription Access
Elevate Azure Subscription Access beskriver den legitime metoden for å bruke Global Admin-rollen for å få økte tillatelser i Azure-miljøet ditt.
For å oppnå dette har angriperen allerede utvidet tilgang til miljøet ditt. Global Admin-rollen gir personen som har den Gud-lignende tillatelser i tenanten. Tenk på det som domeneadministratoren i ditt lokale Active Directory.Angriperen må aktivere innstillingen «Tilgangsadministrasjon for Azure-ressurser» i Azure AD- properties. Dette legger til gjeldende bruker til rollen » User Access Administrator» på tenant roten. Dette lar angriperen legge til ytterligere rolletillatelser ( Azure RBAC ) for ondsinnede applikasjoner som brukes på hvert abonnement eller administrasjonsgruppe i tenant.
Angrepsvei
Gjenkjenning
Endringen av «Access management for Azure resources»-innstillingen vil ikke vises i subscription audit log og vil heller ikke vises i Azure AD audit log.Denne endringen vil imidlertid bli logget i » Directory Activity «-loggen som er tilgjengelig via «Monitor». Bytt fra “Activity” til “Directory Activity” for å se endringer.
Du kan også bruke denne PowerShell kommandoen til å sjekke om det er noen brukere med denne typen rolle tilordning på root scope.
Get-AzRoleAssignment | Where-Object {$_.RoleDefinitionName -eq "User Access Administrator" -and $_.Scope -eq "/"}Jakt forespørsler
Jeg vet ikke om en innebygd måte å videresende disse loggene til et Log Analytics-arbeidsområde eller Microsoft Sentinel som vil tillate å lete etter handlingen
Microsoft.Authorization/elevateAccess/action.
Diagnostic Settings Option er grået ut i portalen for denne loggen.
Men som Christopher Brumm ( @cbrhh ) har påpekt, er det en artikkel som forklarer hvordan du bruker et varsel i Microsoft Defender for Cloud Apps (Microsoft Cloud App Security) og integrerer det i Microsoft Sentinel.
Hvis du allerede har satt opp Microsoft Azure som en kobling i MDA (MCAS), kan du bruke følgende dyplenke for å sjekke loggene dine.
Ytterligere informasjon:
- Keys of the kingdom: Playing God as Global Admin by Dr. Nestori Syynimaa (@DrAzureAD)
- Monitor Elevate Access Activity In Azure by Sami Lamppu (@samilamppu)
- Elevate access to manage all Azure subscriptions and management groups
Azure VM Run Command eller Custom Script execution
Angrepsbeskrivelse:
Med ett fotfeste i et abonnement og en rolletilordning fra Virtual Machine Contributor eller en hvilken som helst egendefinert rolle som har
Microsoft.Compute/virtualMachines/*
tillatelsen, kan angriperen utføre skript eller PowerShell-kommandoer på en hvilken som helst virtuell maskin innenfor dette abonnementet.
Dette lar angriperen gå fra skymiljøet til ditt lokale miljø, og hvis serverne er koblet til det interne nettverket, gå videre derifra.
Skriptet som sendes til VM-en ligger på angriperens datamaskin, eller som vist i denne demoen, direkte i Azure Cloud Shell.
Invoke-AzVMRunCommand -ResourceGroupName 'RESOURCEGROUP' -Name 'VMNAME' -CommandId 'RunPowerShellScript' -ScriptPath ./runcommand.ps1
Angrepssti
Gjenkjenning
All denne aktiviteten vil bli logget i abonnementsaktivitetsloggen så vel som på målmaskinen.
Aktivitetslogg for abonnement
Du kan videresende abonnementsaktivitetsloggen til et sentralt Log Analytics-arbeidsområde og bruke Azure Monitor eller Microsoft Sentinel til å opprette et varsel eller en hendelse basert på aktiviteten.
En annen metode er å bruke Azure Policy-definisjonen Configure Azure Activity logs to stream to specified Log Analytics workspace for å automatisere denne konfigurasjonen på alle abonnementene dine.
Jaktspørring
En enkel spørring for å oppdage dette ville være følgende. Make_list brukes fordi hver vellykket utførelse har tre hendelser. Godta, start og suksess.
Siden du kan utføre denne kommandoen fra Azure Cloud Shell, er ip-adressen kanskje ikke angriperens egen ip-adresse, men en Microsoft-adresse.
AzureActivity
| where CategoryValue == "Administrative"
| where OperationNameValue =~ "Microsoft.Compute/virtualMachines/runCommand/action"
| extend VMName = tostring(todynamic(Properties).resource)
| summarize make_list(ActivityStatusValue), TimeGenerated = max(TimeGenerated) by CorrelationId, CallerIpAddress, Caller, ResourceGroup, VMName
Microsoft tilbyr selv flere og mer komplekse jaktsøk for denne aktiviteten.
- Azure VM Run Command operations executing a unique PowerShell script
- Azure VM Run Command executed from Azure IP address
Ytterligere informasjon
- Keys of the kingdom: Playing God as Global Admin by Dr. Nestori Syynimaa (@DrAzureAD)
- Lateral Movement With Managed Identities Of Azure Virtual Machines by @DebugPrivilege
- Run scripts in your Windows VM by using action Run Commands
- NOBELIUM targeting delegated administrative privileges to facilitate broader attacks
Azure Lighthouse
Angrepsbeskrivelse
Azure Lighthouse er i seg selv en legitim måte å administrere ressurser hos andre tenants. Men en angriper kan lure en administrator eller bruke en kapret konto for å godta den delegerte tillatelsesforespørselen.
For å oppnå dette oppretter angriperen en tilpasset mal med den nødvendige rolledefinisjonen. Merk at du ikke kan bruke eier eller noen innebygd rolle med DataActions- tillatelser.
Den resulterende malen må distribueres innenfor tenant eieren. En separat distribusjon er nødvendig for hvert abonnement. Angriperen kan bruke Azure Policy til å distribuere dette på en automatisert måte.
Etter at denne distribusjonen er fullført, kan angriperen få tilgang til ressursene i målet tenant-abonnement fra sin egen tenant. Fordi angriperen har bidragsytertilgang, er en lignende angrepsbane Invoke-AzVMRunCommand mulig.
Fra angripersiden kan du se kundene dine i det respektive bladet i Azure Portal
Angrepssti
Gjenkjenning
Den opprinnelige distribusjonen er synlig, men kan også slettes fra distribusjonsdelen i abonnementet.
En bedre måte å oppdage denne typen angrep på er å se etter uventet tilordning av en Microsoft.ManagedServices registrering. Sjekk jaktsøket for dette.
I tenanten kan du også sjekke hvilke tjenestetilbud som for øyeblikket er aktive gjennom PowerShell eller i Azure Portal.
Get-AzManagedServicesDefinition
Get-AzManagedServicesAssignment
Det som kan være et problem i den nåværende forhåndsvisningstilstanden til tjenesten, men som gjør gjenkjenningen litt vanskeligere, er RBAC-visningen for det angrepne abonnementet. Det er ingen omtale av den ekstra bidragsyteren.
Jaktspørsmål
Spørsmål om Microsoft.ManagedServices registreringer.
AzureActivity
| where OperationNameValue =~ "Microsoft.ManagedServices/registrationAssignments/Write"
For å se etter operasjoner utført av en bruker fra en annen tenant.
let HomeTenantId = "YOURTENANTID";
AzureActivity
| extend TenantId = todynamic(Claims).['http://schemas.microsoft.com/identity/claims/tenantid']
| where TenantId != HomeTenantId
| where isnotempty( TenantId )
| sort by TimeGenerated
Ytterligere informasjon
- Role support for Azure Lighthouse
- Recommended security practices
- Securing Azure Lighthouse with Azure Policy and Azure Privileged Identity Management for MSP’s and customers
Delegerte administrative privilegier
Angrepsbeskrivelse
Konseptet med delegerte administrative privilegier for partnere er noe som ble etablert for Cloud Solution Providers (CSP). De kan tilby lisenser og tjenester til kunder og på den annen side ta over første- og andrenivåstøtte for disse kundene og tjenestene.
Ideen var god, men det de fleste kunder ikke visste var at CSP-en fikk Global Admin-tillatelser i tenanten deres. Og kunden har ingen måte å kontrollere hvilken bruker av partneren som får tilgang til dataene deres. Bare partneren kunne implementere et rollebasert tilgangskonsept. Og selv dette er stort sett en alt eller ingenting-tilnærming som ikke tillater å skille mellom kunder kun mellom roller.
Dette var en utfordring for Microsoft da NOBELIUM begynte å målrette CSP-er med delegerte administrative rettigheter.
I februar 2022 ga Microsoft ut detaljerte delegerte administratorrettigheter (GDAP) for å redusere disse vidtrekkende tillatelsene.
Angrepssti
Gjenkjenning
Sjekk partnerne dine i Microsoft Admin Center og fjern unødvendige tillatelser. De kan fortsatt tilby deg lisenser og støtte.
Bruk Azure Lighthouse eller direkte Azure RBAC-tildelinger der det er nødvendig.
Dette er også det Microsoft anbefaler til sine partnere.
Ytterligere informasjon
- Microsoft partners: The Good, The Bad, or The Ugly? by Dr. Nestori Syynimaa (@DrAzureAD)
- NOBELIUM targeting delegated administrative privileges to facilitate broader attacks
Administrerte identiteter
Angrepsbeskrivelse
Administrerte identiteter er en fin måte å minimere behovet for å håndtere legitimasjon og gi tillatelser til ikke-menneskelige enheter.
Ressurser som virtuelle maskiner kan aktiveres for å bruke system- eller brukertildelte administrerte identiteter, og denne identiteten kan deretter gis tillatelser på andre ressurser.
Hvis du bruker den virtuelle maskinen, kan du bruke den administrerte identiteten og dermed få tilgang til disse ressursene uten å ha kjennskap til noen legitimasjon.
En angriper kan bruke dette til sin fordel når den administrerte identiteten er gitt til mange tillatelser. For eksempel kan en virtuell maskin med en administrert identitet som ble gitt bidragsyter på et abonnement overta abonnementet og alle ressursene i abonnementet eller til og med flytte til andre virtuelle maskiner i dette abonnementet.
Angrepssti
Gjenkjenning
Sjekk dine administrerte identiteter og deres tillatelser og begrens dem til de minimale tillatelsene som trengs. Prinsippet om minste privilegium er nøkkelen her.
Du får en oversikt over alle administrerte identiteter i Azure AD – Enterprise applications
Du kan bruke PowerShell til å liste opp alle RBAC-tillatelser for de administrerte identitetene.
$ManagedIdentities = Get-AzADServicePrincipal | ? ServicePrincipalType -eq "ManagedIdentity"
foreach ($ManagedIdentity in $ManagedIdentities) {
Get-AzRoleAssignment -ObjectId $ManagedIdentity.Id
}
Ytterligere informasjon
- Lateral Movement With Managed Identities Of Azure Virtual Machines by @DebugPrivilege
- Detecting privilege escalation with Azure AD service principals in Microsoft Sentinel by Matt Zorich (@reprise_99)
API-tillatelser
Angrepsbeskrivelse
Enterprise-applikasjoner og applikasjonsregistreringer er en grunnleggende del av Azure AD. En stor del av applikasjonsadministrasjon i Azure AD handler om å gi de riktige tillatelsene for de brukte applikasjonene.
Å gi en app-apptillatelser gir appen tilgang til Graph endepunktene og relaterte datasett uavhengig av om en bruker er logget på eller ikke. Appen kan bruke apphemmeligheter eller sertifikater for å autentisere mot tjenesten og få tilgang til dataene.
Noen tillatelser gir omfattende tillatelser og er potensielt skadelige. Avhengig av tillatelsene som allerede er oppnådd i miljøet, kan en angriper legge til en tilpasset appregistrering, gi disse tilleggstillatelsene og bruke denne applikasjonen som en bakdør til tenanten.
Se opp for følgende tillatelser og fjern dem hvis mulig.
- AppRoleAssignment.ReadWrite.All – Gir applikasjonen tillatelse til å gi ytterligere privilegier til seg selv, andre applikasjoner eller en hvilken som helst bruker.
- Application.ReadWrite.All – Gir applikasjonen tillatelse til å opptre som andre enheter.
- RoleManagement.ReadWrite.Directory – Gir applikasjonen tillatelse til å gi ytterligere privilegier til seg selv, andre applikasjoner eller en hvilken som helst bruker.
Angrepssti
Gjenkjenning
Bruk skriptet AuditAppRoles.ps1 publisert av Andy Robbins.
Hvis du bruker Microsoft Defender for Cloud Apps (Microsoft Cloud App Security) i miljøet ditt, er det et innebygd varsel Unusual addition of credentials to an OAuth app som kan brukes som en indikator på ondsinnet aktivitet.
Jaktspørsmål
Sjekk om noen av de nevnte tillatelsene er gitt til en applikasjon.
let DangerousPermissions = dynamic(["AppRoleAssignment.ReadWrite.All","Application.ReadWrite.All","RoleManagement.ReadWrite.Directory"]);
AuditLogs
| where OperationName == "Add app role assignment to service principal"
| mv-expand TargetResources
| mv-expand TargetResources.modifiedProperties
| where TargetResources_modifiedProperties.displayName == "AppRole.Value"
| extend InitiatedByUserPrincipalName = InitiatedBy.user.userPrincipalName
| extend AddedPermission = replace_string(tostring(TargetResources_modifiedProperties.newValue),'"','')
| where AddedPermission in~ ( DangerousPermissions )
Ytterligere informasjon
- Azure Privilege Escalation via Azure API Permissions Abuse by Andy Robbins (@_wald0)
- Everything About Service Principals, Applications, And API Permissions by @DebugPrivilege
- Azure AD privilege escalation – Taking over default application permissions as Application Admin by Dirk-jan Mollema (@_dirkjan)
- Detect and Remediate Illicit Consent Grants
- Delegate app registration permissions in Azure Active Directory
- OAuth app policies
- Tutorial: Investigate and remediate risky OAuth apps
Azure AD-roller
Angrepsbeskrivelse
Tildeling av feil Azure AD-roller til en bruker eller applikasjon kan resultere i en angrepsbane til global admin. Spesielt rollen «Privileged Authentication Administrator» er som å gi brukeren globale admin-tillatelser, siden man kan tilbakestille passordet til enhver GA, endre MFA-innstillingene og ta over kontoen.
Rollen «Privileged Role Administrator» gir enheten som har den tillatelse til å legge til flere Azure AD-roller til enhver bruker, inkludert rollen som Global Administrator. Dette utvides også til API-tillatelser og lar brukeren gi samtykke for enhver tillatelse til enhver applikasjon. Se API-tillatelser for å se hva en angriper kan gjøre med dette.
Angrepssti
Gjenkjenning
Jaktspørsmål
Bruk Azure AD-audit loggen for å oppdage endringer i disse rollene.
let HighPrivRoles = dynamic(["Company Administrator","Privileged Authentication Administrator","Privileged Role Administrator"]);
AuditLogs
| where OperationName == "Add member to role"
| mv-expand TargetResources
| mv-expand TargetResources.modifiedProperties
| where TargetResources_modifiedProperties.displayName == "Role.DisplayName"
| extend InitiatedByUserPrincipalName = InitiatedBy.user.userPrincipalName
| extend AddedToRole = replace_string(tostring(TargetResources_modifiedProperties.newValue),'"','')
| where AddedToRole in~ (HighPrivRoles)
Ytterligere informasjon
- Azure Privilege Escalation via Service Principal Abuse by Andy Robbins (@_wald0)
- HOWTO: Set an alert to notify when an additional person is assigned the Azure AD Global Administrator role by Sander Berkouwer @SanderBerkouwer
- Password reset permissions
- Privileged Role Administrator
AAD Connect
Angrepsbeskrivelse
Når du installerer Azure AD Connect for å synkronisere identitetene dine fra on-prem til Azure AD, opprettes det en bruker kalt MSOL_[0-9a-f]{12} i begge katalogene. Denne brukeren har omfattende tillatelser i on-prem og skymiljøet ditt. Denne brukeren er også ekskludert fra sikkerhetsstandarder, og de fleste selskaper ekskluderer den fra sine retningslinjer for conditional access policies.
En angriper, med administratorrettigheter på Azure AD Connect-serveren, kan trekke ut passordet til denne brukeren og autentisere mot AAD for å tilbakestille passordene til brukerne. Hvis du synkroniserer en lokal administratorkonto og har gitt denne brukeren, f.eks. global admin, kan angriperen bruke dette som et inngangspunkt til din AAD.
I on-prem miljøet har MSOL-bruken i de fleste tilfeller også muligheten til å tilbakestille passord og til og med lese passord ved hjelp av DCSync. Angriperen kan nå be om passordet til krbtgt brukeren og bruke dette til å lage Golden eller Silver Kerberos-billetter.
Du bør behandle Azure AD Connect-serveren din som en domenekontroller. Dette er helt klart en Tier 0-maskin.
Synkroniser heller ikke noen admin-brukere mellom AD og AAD. Prøv å etablere trust mellom disse to katalogene.
I tillegg til Microsofts anbefalinger om herding, kan du gå enda lenger og begrense brukerens muligheter MSOL_ til de organisasjonsenhetene og brukerne som må synkroniseres. Og krbtgt er ingen av disse brukerne.
Bruk av Pass-through Authentication (PTA) tillater ikke nøyaktig samme angrepsvektor, men en angriper kan høste passordene som sendes til serveren og bruke dem til å bevege seg sideveis gjennom miljøet.
Angrepssti
Ytterligere informasjon
- Unnoticed sidekick: Getting access to cloud as an on-prem admin by Dr. Nestori Syynimaa (@DrAzureAD)
- Decrypting ADSync passwords – my journey into DPAPI by Dr. Nestori Syynimaa (@DrAzureAD)
- Shooting Up: On-Prem to Cloud — Detecting “AADConnect” Creds Dump by Krishna (@kirtar_oza)
- Abuse of Azure AD Connect Sync Service Account by Sami Lamppu (@samilamppu) and Thomas Naunheim (@Thomas_Live)
- Harden your Azure AD Connect server
- Azure Active Directory Connect Installation with Granular Permissions by Tony Brzoskowski (@tobrz)
Active Directory Federation Server (ADFS)
Angrepsbeskrivelse
Når angriperen får tilgang til det private nøkkler på Active Directory Federation Server (ADFS), kan angriperen lage falske SAML-svar som aksepteres av enhver tjeneste som stoler på ADFS-tjenesten. Derfor ble dette angrepet i utgangspunktet også kalt «Golden SAML», med henvisning til det gylne billettangrepet ved bruk av Kerberos.
Enhver bruker som er synkronisert fra on-prem til skyen, som omdirigeres til ADFS for autentisering, kan etterlignes uten å vite passordet.
Som en bonus kan dette angrepet til og med omgå ethvert MFA-krav, fordi det forfalskede SAML-svaret kan inneholde nødvendig informasjon om at en MFA ble utført av brukeren.
Angrepssti
Ytterligere informasjon
- Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps by Shak Reiner (@shakreiner)
- Unnoticed sidekick: Getting access to cloud as an on-prem admin by Dr. Nestori Syynimaa (@DrAzureAD)
- Making the Case for 30-day Token-signing and Token-decrypting Certificates in AD FS by Sander Berkouwer @SanderBerkouwer
- Backdoor Office 365 and Active Directory – Golden SAML by @inversecos
- ADFSpoof by Doug Bienstock (@doughsec)
- Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers
- Detection And Hunting Of Golden SAML Attack
Desired State konfigurasjon
Desired State Configuration (DSC) er en innebygd konfigurasjonsfunksjon for hver Windows-server med minst Windows PowerShell v4. Den er avhengig av en sentral tjeneste for å tilby konfigurasjoner, og en agent på serveren (Local Configuration Manager (LCM)) bruker disse konfigurasjonene.
Ved å bruke Azure Automation State Configuration kan du distribuere konfigurasjonsendringer til hver Windows-server i miljøet ditt, og derfor kan denne teknikken også brukes til å distribuere ondsinnede konfigurasjoner eller bakdører til serverne dine.
Angrepsbanen «Azure Policy with Guest Configuration Service» bruker etterfølgeren til Azure Automation State Configuration-tjenesten til å gjøre nøyaktig det samme.
Angrepssti
Ønsket Desired State konfigurasjon
Ytterligere informasjon
- Azure Persistence with Desired State Configurations by Jake Karnes (@jakekarnes42)
- Azure Automation State Configuration overview
Azure Policy med Guest Configuration Service
Angrepsbeskrivelse
Azure Policy with Guest Configuration Service er etterfølgeren til Azure Automation State Configuration-tjenesten og bruker den nye plattformuavhengige versjonen av PowerShell (tidligere PowerShell Core).
Angriperen kan lage tilpassede konfigurasjonspakker og distribuere dem gjennom innebygde Azure-funksjoner. I dette tilfellet må angriperen også distribuere Guest Configuration Service utvidelsen til hver angrepet maskin, siden denne metoden ikke er innebygd i Windows.
Siden denne funksjonen er inkludert i Azure Policy, kan angriperen gjemme seg helt åpent, så lenge administratorene ikke overvåker for å lukke Azure-policyene som blir distribuert.
Guest Configuration-utvidelsen kjører i SYSTEM konteksten, så ethvert angrep trenger ikke å fikle med begrensede privilegier på målmaskinen. Så snart den målrettede maskinen har ytterligere tillatelser i Azure-miljøet, gjennom den obligatoriske systemadministrerte identiteten, kan angriperen bruke denne til å flytte sideveis i miljøet.
Angrepssti
Ytterligere informasjon
- Persistence with Azure Policy Guest Configuration
- How to create custom guest configuration package artifacts
Azure Automation Hybrid Runbook Worker
Angrepsbeskrivelse
Azure Run As-kontoer var standardmetoden for å legge til Azure-tillatelser til enhver Azure Automation-konto, før administrerte identiteter ble introdusert. Microsoft anbefaler ikke bruken lenger.
Run As -kontoer bruker sertifikatbasert autentisering, dette sertifikatet opprettes automatisk inkludert en Run As som tilkobling for enklere bruk i automatiserings-runbooks.
Angrepssti
Ytterligere informasjon
- Abusing Azure Hybrid Workers for Privilege Escalation – Part 1 by Karl Fosaaen @kfosaaen
- How to create an Azure Automation Run As account
- Limit Run As account permissions
Jeg har forsøkt å legge til de viktigste koblingene til eksterne kilder på slutten av hver angrepsvei, slik at du kan sjekke ut hvilke endringer som kan være nødvendig i miljøet ditt. Men her finner du litt tilleggsinformasjon og verktøy du kan bruke i ditt miljø i dag.
Skulle du trenge en hurtigstart, les Sikkerhetsveikart – Toppprioriteringer for de første 30 dagene, 90 dagene og utover av Microsoft og se økten på YouTube.
Du bør også lese om Microsofts plan for rask modernisering av sikkerhet, spesielt » Sikring av privilegert tilgang«.
Verktøy
Denne listen inneholder ikke alle verktøyene som allerede er nevnt i denne artikkelen, men er mer en hederlig omtale av noen få verktøy som er veldig nyttige og jeg ønsker å fremme.
AAD Internals
For alt relatert til Azure AD bør du definitivt sjekke ut AAD Internals PowerShell-modulen skrevet av Dr. Nestori Syynimaa. Det er det mest omfattende verktøysettet hvis du vil tukle med Azure AD og alt relatert.
Finn den på GitHub og i PowerShell-galleriet.
Bloodhound
Bloodhound la til støtte for noen Azure AD-baserte angrepsbaner i november 2020 og enda mer støtte for Azure i mars 2022. Det er også et flott verktøy for ditt on-prem miljø.
