Abus d'attributions de rôles Azure et elevateAccess
Comment les attaquants s'élèvent via les attributions de rôles Azure et elevateAccess, à quoi ressemblent les événements roleAssignments/write, comment trier.
En bref. L'élévation de privilèges dans Azure, c'est surtout une opération : Microsoft.Authorization/roleAssignments/write. Ce qui la rend suspecte, c'est le rôle (Owner, User Access Administrator, Role Based Access Control Administrator, ou Contributor donné à une identité non humaine), l'appelant (un principal de service, ou un principal qui s'attribue un rôle à lui-même) et l'étendue (abonnement ou racine). La version nucléaire est Microsoft.Authorization/elevateAccess/action : un Administrateur général s'octroie User Access Administrator à l'étendue racine /, sur tous les abonnements. Cet événement est écrit dans le log de niveau tenant : un export d'abonnement ne le montre pas.
Les attributions de rôles sont la colonne vertébrale de l'autorisation dans Azure, et donc la première chose qu'un intrus disposant de quelques droits cherche à étendre. C'est aussi de l'administration courante, ce qui rend inutile une simple liste d'événements roleAssignments/write. Cet article explique comment distinguer les deux.
Comment fonctionne l'élévation via Azure RBAC
Une attribution de rôle lie trois éléments : un principal, une définition de rôle et une étendue. Quiconque détient Microsoft.Authorization/roleAssignments/write sur une étendue peut y créer des attributions. Parmi les rôles intégrés, cela correspond à Owner, User Access Administrator et Role Based Access Control Administrator.
Les chemins d'élévation que je rencontre le plus souvent :
| Point de départ | Élévation | Pourquoi ça marche |
|---|---|---|
| Secret fuité d'un principal de service CI/CD à qui l'on a donné User Access Administrator « pour déployer des attributions de rôles » | Il s'attribue Contributor ou Owner sur l'abonnement | Automatisation surprivilégiée |
| Administrateur général compromis dans Entra ID | elevateAccess → User Access Administrator sur / → Owner sur n'importe quel abonnement | Entra et Azure RBAC sont séparés, mais les Administrateurs généraux peuvent faire le pont |
| Contributor sur un Key Vault utilisant les stratégies d'accès | S'ajoute à la stratégie d'accès du coffre | Pas du RBAC, mais même idée : voir l'article Key Vault |
| Owner d'un compte Automation ou d'une VM dotée d'une identité managée privilégiée | Exécute du code sous cette identité | Traité dans l'abus d'identités managées |
MITRE ATT&CK suit l'octroi sous T1098.003 Additional Cloud Roles et l'usage d'identités cloud légitimes sous T1078.004 Cloud Accounts.
Ce qu'est elevateAccess, et où c'est journalisé
L'élévation d'accès est une fonctionnalité documentée et légitime : un Administrateur général de Microsoft Entra ID peut activer « Access management for Azure resources » et recevoir le rôle User Access Administrator à l'étendue racine /. De là, il peut s'attribuer n'importe quel rôle sur n'importe quel abonnement et groupe d'administration du tenant. Microsoft recommande de retirer cet accès une fois la tâche terminée (élever l'accès pour gérer tous les abonnements Azure).
Le piège forensique, c'est où c'est journalisé. D'après la même page, les entrées d'élévation d'accès apparaissent dans les journaux d'audit de l'annuaire Microsoft Entra (service « Azure RBAC (Elevated Access) », en préversion au moment de l'écriture) et dans la vue Directory Activity de l'Activity Log, c'est-à-dire le log de niveau tenant. L'opération est Microsoft.Authorization/elevateAccess/action avec l'étendue /providers/Microsoft.Authorization. Un az monitor activity-log list par abonnement ne la renvoie pas. Exportez le niveau tenant avec az rest comme indiqué dans le guide d'export.
Ce chemin n'a rien d'exotique. L'analyse par Microsoft de Storm-0501 décrit un acteur utilisant elevateAccess/action pour obtenir User Access Administrator, puis roleAssignments/write pour prendre Owner sur les abonnements.
Lire un événement roleAssignments/write
Dans le schéma REST / CLI, les détails utiles sont répartis entre l'événement et le corps de sa requête :
| Champ | Où | Pourquoi c'est important |
|---|---|---|
caller et claims | Événement | Qui a créé l'attribution. Un appelant en GUID avec une claim appid est un principal de service ; une claim xms_mirid signale une identité managée |
httpRequest.clientIpAddress | Événement | D'où vient l'appel |
properties.requestbody → PrincipalId, RoleDefinitionId, Scope | Corps de requête | Qui a reçu quel rôle, où |
authorization.evidence.role | Schéma des logs de ressources | Quel rôle a permis à l'appelant d'agir |
status.value | Événement | Started / Succeeded / Failed : les échecs sont intéressants aussi |
RoleDefinitionId est un GUID. Les identifiants des rôles intégrés sont fixes et documentés dans les rôles intégrés Azure ; par exemple Owner est 8e3af657-a8ff-443c-a75c-2fe8c4bcb635, Contributor b24988ac-6180-42a0-ab88-20f7382dd24c et User Access Administrator 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9.
Deux signaux peu coûteux mais forts :
- L'appelant s'attribue un rôle à lui-même. Comparez l'object ID de l'appelant avec
PrincipalIddans le corps de la requête. Des scripts d'amorçage légitimes le font parfois ; les attaquants, tout le temps. - Le bénéficiaire n'est pas humain et le rôle est large. Un principal de service ou une identité managée qui reçoit Owner ou Contributor sur tout un abonnement mérite un responsable et un numéro de ticket.
Ce que signale l'analyseur
L'analyseur Azure Forensics implémente quatre règles RBAC, toutes sur l'Activity Log :
| Règle | Détecte | Niveau |
|---|---|---|
AZ-RBAC-001 | Owner, User Access Administrator ou Role Based Access Control Administrator attribué | Moyen |
AZ-RBAC-002 | Principal de service ou identité managée recevant Owner, Contributor ou un rôle de gestion des accès | Haut |
AZ-RBAC-003 | Principal qui s'attribue un rôle à lui-même (object ID de l'appelant = bénéficiaire) | Haut |
AZ-RBAC-004 | elevateAccess/action : un Administrateur général s'élève à l'étendue racine | Haut |
Associez-les à AZ-ID-001 (principal de service utilisé depuis une nouvelle IP) et la chaîne se lit généralement toute seule : nouvelle IP → auto-attribution → la suite.
Checklist de tri
Pour chaque attribution signalée :
- Y a-t-il un ticket de changement ? Demandez à l'équipe plateforme avant de conclure ; beaucoup d'attributions « suspectes » sont des correctifs du vendredi soir.
- Qui est l'appelant, et ce comportement est-il habituel ? Pivotez sur l'appelant dans l'onglet Entités. Un principal de déploiement qui n'a jamais attribué de rôle auparavant est un signal fort.
- Depuis quelle IP ? Comparez avec les IP de référence de l'appelant. Les runners CI changent d'IP ; les attaquants changent d'IP et d'horaires.
- Qu'a-t-il fait ensuite de ses nouveaux droits ? Regardez l'heure suivante d'événements du bénéficiaire. Un rôle que personne n'utilise est une erreur ; un rôle utilisé en quelques minutes pour exécuter des commandes ou lire des secrets est une attaque.
- A-t-il été retiré ? Les attaquants font parfois le ménage avec
roleAssignments/delete. La suppression est journalisée elle aussi. - Pour
elevateAccess: quel Administrateur général, depuis quelle connexion ? C'est une question Entra ID pour m365forensics.com.
Remédiation
- Supprimez les attributions créées pendant l'incident (
az role assignment delete) et passez en revue qui détient Owner et User Access Administrator à chaque étendue. - Retirez l'attribution User Access Administrator sur
/créée par l'élévation d'accès ; Microsoft documente le bouton du portail comme la suppression par CLI / REST. - Faites tourner les identifiants de tout principal de service ayant créé ou reçu une attribution suspecte.
- Réduisez les privilèges permanents : pas de User Access Administrator pour les identités CI/CD ; envisagez Privileged Identity Management pour les humains.