Azure Sikkerhet

Angrepsveier i Azure 

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.

Directory Activity

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.

/en/azure-dominance-paths/images/DiagnosticSettingsDisabled.png

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.

https://portal.cloudappsecurity.com/#/audits?service=eq(i:12260,)&activity.eventType=eq(12260:EVENT_AZURE_GENERIC:Microsoft.Authorization%2FelevateAccess%2Faction,)&source=eq(t:2,)&activityObject=eq(%2Fproviders%2FMicrosoft.Authorization,)

/en/azure-dominance-paths/images/ElevateAzureSubscriptionAccess_MDA.png
Deteksjon i Microsoft Defender for Cloud Apps

Ytterligere informasjon:

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

/en/azure-dominance-paths/images/Invoke-AzVMRunCommand.gif
Azure VM Run Command-demo

Angrepssti

Gjenkjenning

All denne aktiviteten vil bli logget i abonnementsaktivitetsloggen så vel som på målmaskinen.

Aktivitetslogg for abonnement

/en/azure-dominance-paths/images/AzureVMRunCommand-AzureActivityLog.png

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/azure-dominance-paths/images/AzureSubscriptionActivityLogToLogAnalytics_2.png

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.

/en/azure-dominance-paths/images/AzureVMRunCommand-Event4688.png

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
/en/azure-dominance-paths/images/AzureVMRunCommand-KQLDetection.png
Oppdag Azure VM Kjør kommandoangrep med KQL

Microsoft tilbyr selv flere og mer komplekse jaktsøk for denne aktiviteten.

Ytterligere informasjon

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.

/en/azure-dominance-paths/images/AzureLighthouse-Delegation.jpg

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.

/en/azure-dominance-paths/images/AzureLighthouse-CreateOffer.png
Legg til autorisasjon
/en/azure-dominance-paths/images/AzureLighthouse-ARMOffer.png
Opprett ARM Template

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.

/en/azure-dominance-paths/images/AzureLighthouse-DeployOffer.png
Deploy Lighthouse

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 

/en/azure-dominance-paths/images/AzureLighthouse-MyCustomers.png

Angrepssti

Azure Lighthouse

Gjenkjenning

Den opprinnelige distribusjonen er synlig, men kan også slettes fra distribusjonsdelen i abonnementet.

/en/azure-dominance-paths/images/AzureLighthouse-DetectionDeployment.png

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
/en/azure-dominance-paths/images/AzureLighthouse-ManagedServicesDefinition.png
/en/azure-dominance-paths/images/AzureLighthouse-ManagedServicesAssignment.png
/en/azure-dominance-paths/images/AzureLighthouse-ServiceProviders.png

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.

/en/azure-dominance-paths/images/AzureLighthouse-RBAC.png
/en/azure-dominance-paths/images/AzureLighthouse-Activity.png

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

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

Delegerte administrative privilegier

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.

/en/azure-dominance-paths/images/DelegatedAdministrativePrivileges-Partner.png
/en/azure-dominance-paths/images/DelegatedAdministrativePrivileges-RemoveRoles.png

Dette er også det Microsoft anbefaler til sine partnere.

/en/azure-dominance-paths/images/DelegatedAdministrativePrivileges-MicrosoftRecommendation.png

Ytterligere informasjon

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

Administrerte identiteter

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 

/en/azure-dominance-paths/images/ManagedIdentity-List.png
Liste over alle administrerte identiteter

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

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.

Angrepssti

API-tillatelser

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 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

Azure AD-roller

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

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/azure-dominance-paths/images/ExcludeSyncAccount.png
Ekskludert fra sikkerhetsstandarder

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

AAD Connect

Ytterligere informasjon

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

Active Directory Federation Server

Ytterligere informasjon

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 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

Azure Policy med Guest Configuration Service

Ytterligere informasjon

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.

/en/azure-dominance-paths/images/NewRunAsAccount.png

Run As -kontoer bruker sertifikatbasert autentisering, dette sertifikatet opprettes automatisk inkludert en Run As som tilkobling for enklere bruk i automatiserings-runbooks.

/en/azure-dominance-paths/images/AzureRunAsConnection.png

Angrepssti

Azure Automation Hybrid Runbook Worker

Ytterligere informasjon

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.

/en/azure-dominance-paths/images/luignzNyR-o.png
Sikkerhetsveikart – Toppprioriteringer for de første 30 dagene, 90 dagene og utover

Du bør også lese om Microsofts plan for rask modernisering av sikkerhet, spesielt » Sikring av privilegert tilgang«.

/en/azure-dominance-paths/images/end-to-end-approach.png

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ø.

Similar Posts

Legg igjen en kommentar