L'escalade Azure est un problème de plan d'autorisation. Un principal qui peut écrire le graphe RBAC, ou qui contrôle une ressource portant une identité managée, se promeut sans toucher à un hôte. Les chemins ci-dessous sont les équivalents côté plan de ressources Azure du catalogue AWS IAM, ancrés dans les recherches MicroBurst de NetSPI et BARK de SpecterOps.
Les chemins#
- Écriture d'attribution de rôle :
Microsoft.Authorization/roleAssignments/writepour se donner Owner ou Contributor à n'importe quel scope. - Définition de rôle personnalisé :
roleDefinitions/writepour concevoir un rôle avec des actions joker, puis se l'auto-attribuer. - Elevate access : activer User Access Administrator au scope racine pour atteindre chaque abonnement du tenant.
- Attribution d'identité managée : attacher une identité managée privilégiée à une ressource que vous contrôlez, puis forger son token.
- Modèle de déploiement : un déploiement ARM ou une ressource deploymentScripts qui s'exécute sous une identité privilégiée.
Choisir un chemin#
Un roleAssignments/write est le levier le plus direct quand vous le détenez. Sinon, le contrôle d'une ressource qui porte déjà une identité managée privilégiée (une VM, une Function, un Automation Account) est en général la voie vers le haut : empruntez l'identité via les identités managées et la surface de compute. BARK énumère lesquels de ces chemins le principal courant peut atteindre.