Rappel de ce qu’est une subscription Azure

Une subscription Azure (en français abonnement) est un conteneur de ressources et de services cloud associé à un tenant, qui permet de gérer la facturation, les accès et le déploiement des ressources Azure.

Architecture des ressources sur Azure

Fonctionnement de l’attaque 

Sur Microsoft Azure, on considère la situation de départ suivante : 

• Il y a une organisation légitime (tenant victime), qui contient ou non une subscription. 
• Il y a une organisation malveillante (tenant de l’attaquant) sous le contrôle d’un attaquant. 

L’attaque suit alors les 4 étapes suivantes : 

Etapes de l’attaque Azure

1. L’attaquant doit être présent dans les deux organisations : Il compromet donc un administrateur interne au tenant victime pour faire inviter son compte externe dans le tenant, ou bien il convainc un administrateur non compromis de se faire inviter, sous un prétexte quelconque. Dans les deux cas, l’administrateur l’invite dans le tenant victime. 
2. L’attaquant prend pour cible une subscription existante ou bien en crée une nouvelle lui-même (ce qui nécessite des permissions), associé à un compte de facturation existant. 
3. L’attaquant obtient le rôle Owner sur la subscription visée. S’il l’a créée lui-même, il l’est déjà par défaut, sinon il doit le recevoir d’un administrateur. 
4. L’attaquant effectue le transfert de la subscription de l’organisation de départ à l’organisation d’arrivée. 

La subscription est désormais sous le contrôle complet de l’organisation de l’attaquant et peut facturer l’ancien compte de facturation.  

Pourquoi cette attaque est dangereuse ? 

Cette attaque est potentiellement très dangereuse car elle est instantanée à réaliser si les conditions sont réunies, donne à l’attaquant un contrôle complet sur la ressource et son éventuel contenu, et est irréversible sans intervention du support. 

Une attaque instantanée 

Par défaut, n’importe quel utilisateur Owner sur une subscription Azure, qui est également présent dans un autre tenant, peut effectuer le transfert sans restriction. 

Des conséquences multiples et potentiellement irréversibles 

La subscription passe sous le contrôle du tenant malveillant qui l’a récupérée. Il peut donc : 

• Avoir le contrôle total dessus tandis que l’utilisateur d’origine n’y a plus accès 
• En extraire toutes les ressources ou informations 
• L’utiliser en faisant facturer l’utilisation à l’ancien moyen de facturation appartenant au propriétaire légitime 

Note : Un intérêt du subscription hijacking est d’amener les ressources dans son propre environnement hors de contrôle du propriétaire légitime, pour s’en servir à son propre compte ou pour facturer des nouvelles utilisations à l’ancien propriétaire. Cependant, un simple transfert sans utilisation entraîne déjà des conséquences importantes : l’utilisateur aura perdu sa subscription, et donc aura perdu toutes les ressources, mais également la structure (rôles, assignations, règles), qui peut être très longue à reconstruire. 

Si le propriétaire légitime peut bloquer la facturation une fois qu’il réalise ce qu’il se passe, il n’y a en revanche pas de moyen de récupérer la subscription si l’attaquant a retiré tous les anciens Owner de celle-ci. La seule alternative devient alors de se tourner vers le support de Microsoft. 

L’article suivant de Derk van der Woude décrit un cas de minage de cryptomonnaies effectué avec des subscriptions volées et facturé à l’ancien propriétaire : 

https://derkvanderwoude.medium.com/azure-subscription-hijacking-and-cryptomining-86c2ac018983 

Comment s’en protéger ? 

Pour se protéger d’un transfert illégitime de subscription, il existe des mesures préventives que l’on peut citer pour prévenir chaque étape de l’attaque : 

Mesures préventives 

1. Accès de l’attaquant aux ressources : politiques d’accès conditionnelles

Les politiques d’accès conditionnel basées sur le risque permettent de renforcer automatiquement la sécurité en adaptant les contrôles selon le niveau de risque détecté lors d’une connexion ou associé à un utilisateur. Elles permettent par exemple de bloquer les accès suspects ou d’imposer une authentification multi facteur (MFA). Ainsi, l’accès d’un invité suspect pourrait être bloqué. 

      2. Montée en privilège/obtention du rôle Owner : gestion des identités privilégiées 

La gestion des identités privilégiées (Privileged Identity Management, PIM)​ permet d’accorder des rôles à privilèges élevés seulement quand cela est nécessaire, via une élévation temporaire, approuvée et justifiée. Il réduit ainsi les risques liés aux permissions excessives grâce au contrôle, au suivi et aux notifications d’activation. 

      3. Transfert de la subscription : politique de subscription (subscription policy) 

Une subscription policy permet de bloquer le transfert d’une subscription Azure vers ou hors du tenant afin d’éviter les détournements. Elle s’implémente via Azure Policy en définissant puis assignant une règle qui restreint les actions de transfert, avec des revues régulières pour garantir son efficacité. Elle s’applique à toutes les subscriptions se trouvant dans son scope d’assignation. 

Solutions de détection 

Certaines solutions permettent de détecter cette attaque sur Microsoft Azure : 

• UEBA (Sentinel) : détecte les comportements anormaux (connexions inhabituelles, accès sensibles, modifications inattendues). Cela permet d’identifier rapidement un compte compromis avant qu’il ne puisse détourner une subscription. 
• Privileged Identity Management (PIM)​ : contrôle les élévations de privilèges et peut déclencher des alertes en cas d’activation d’un rôle privilégié. 
• Alerte Sentinel personnalisée : Peut surveiller spécifiquement les événements indiquant un transfert de subscription. La règle analyse régulièrement les logs AzureActivity et déclenche immédiatement une alerte lorsqu’une opération suspecte comme le déplacement d’une subscription est détectée. 

Stratégie de résilience 

La stratégie de résilience à mettre en place est une sauvegarde (backup) des ressources qui permet de les restaurer en cas de détournement effectif de la subscription. 

1. Isoler les sauvegardes Azure Backup dans une subscription dédiée réservé aux backups avec des règles de sécurité strictes 
2. Protéger les sauvegardes : activer le soft delete (pas de suppression définitive immédiate), la suppression réversible, l’immutabilité (empêche la modification ou la suppression pendant une période), des verrous anti-suppression 
3. Multiplier les copies, éventuellement vers un autre tenant 
4. Sauvegarder également la gouvernance (configurations Entra ID via Microsoft 365 DSC, configuration d’infrastructure avec Terraform) 
5. Automatiser la reconstruction avec l’infrastructure-as-code (Blueprints, ARM, Terraform) 
6. Tester régulièrement les backups 

Réaction à l’attaque 

Subir cette attaque revient à perdre sa subscription Azure. Auquel cas, les options sont limitées. Il faut très rapidement : 

• Bloquer les accès de l’attaquant et révoquer les éventuels secrets compromis dans l’attaque 
• Contacter le support Microsoft Billing pour bloquer la facturation 
• Contacter le support Microsoft (technique/Azure) pour tenter de récupérer la subscription 

Et sur les autres providers ? (AWS et GCP) 

Une fois cette attaque identifiée sur Azure, la question de son existence (ou d’un équivalent) sur AWS et GCP se pose alors. Le concept de subscription n’existe pas en tant que tel sur ces deux fournisseurs cloud, cependant, des unités hiérarchiques équivalentes jouent le même rôle. S’il était possible de les migrer vers une autre organisation AWS et GCP de manière illégitime, ce serait un équivalent du subscription hijacking sur ces fournisseurs.  

AWS : un équivalent possible mais avec des conditions distinctes 

Sur AWS, l’équivalent hiérarchique de la subscription est le compte AWS : un compte AWS, présent dans une organisation, contient des utilisateurs IAM, des ressources et c’est à son niveau que la facturation est gérée, si elle n’est pas consolidée par le compte de gestion. 

Le but d’un attaquant serait donc ici de faire migrer ce compte AWS vers une autre organisation. 

Chemin à suivre 

Le chemin à suivre pour effectuer la migration est le suivant : 

Etapes de l’attaques AWS 

Un compte AWS contient : 

• Un utilisateur root, unique, qui dispose de tous les droits sur le compte 
• Des utilisateurs IAM disposant de droits IAM attribués

Dès lors, deux stratégies sont envisageables pour l’attaquant : parvenir à compromettre le root (auquel cas il peut effectuer toute action) ou réussir à monter en privilèges sur un utilisateur IAM classique. Cependant, l’approbation du root reste requise pour l’étape 1 (il peut par exemple avoir été manipulé pour effectuer cette action). De plus, si des guardrails ou des stratégies de contrôle des services (Service Control Policies) sont appliqués, le compte root doit toujours valider l’opération. Par conséquent, un utilisateur IAM, même avec des droits élevés, ne peut pas toujours migrer un compte de manière autonome. 

Des conséquences similaires à l’attaque Azure ? 

Il est établi que sur Azure, le transfert de la subscription entraînait une perte de contrôle totale sur celui-ci. Ici, sur AWS, deux nuances sont à introduire : 

• D’abord, comme le montre le schéma précédent, la facturation doit impérativement être changée (vers un mode de facturation indépendant) pour permettre la migration du compte sur une autre organisation, ce qui élimine le risque de se voir facturer des services par l’attaquant après la migration
• Ensuite, dans le cas théorique où c’est un utilisateur IAM non-root qui a réalisé la migration du compte (en ayant recueilli toutes les permissions nécessaires), alors cet utilisateur n’a pas un contrôle total sur ce compte, même en le laissant indépendant (standalone), ou en le faisant rejoindre une organisation sous son contrôle. Les comptes AWS ont en effet une forte indépendance, et le fait d’avoir un compte AWS dans son organisation ne permet pas d’en faire ce que l’on souhaite (accéder à certaines ressources, le supprimer) si l’on ne dispose pas du root

Conclusion 

Si l’attaque semble théoriquement possible sur AWS, elle nécessite plus de conditions et entraîne moins de conséquences négatives définitives que sur Azure. En définitive, le seul moyen de prendre le contrôle total d’un compte AWS reste de disposer de son root. 

GCP : un équivalent possible mais plus difficile à réaliser 

Sur GCP, l’architecture est plus proche d’Azure. L’équivalent de la subscription Azure est le projet GCP. Ici, le but de l’attaquant serait donc de faire migrer un projet d’une organisation GCP à une autre.  

Chemin à suivre 

Les étapes à suivre pour effectuer la migration sont les suivantes : 

Etapes de l’attaque GCP 

Des conséquences similaires à l’attaque Azure ? 

Les conséquences en cas de migration de projet GCP sont les mêmes que pour une subscription Azure : une perte de contrôle totale sur l’élément, et le risque de se voir facturer une utilisation de l’attaquant si la facturation n’a pas été modifiée. 

Conclusion 

Un détournement de ressources similaire au subscription hijacking visant Microsoft Azure est donc théoriquement possible sur GCP. Les conditions plus strictes qui sont nécessaires rendent cependant ce cas moins probable, mais il doit être considéré. 

Résumé des conséquences 

Résumé des conséquences

Conclusion 

Le subscription hijacking doit donc être considéré comme une attaque d’importance aux conséquences graves et à fort impact pour les organisations ou entreprises touchées. Protéger les unités hiérarchiques gérant la facturation et les ressources contre tout déplacement ou migration illégitime (les mesures vont varier suivant le fournisseur cloud visé), et prévoir des processus de remédiation et de sauvegarde en cas de perte est crucial pour la sécurité d’une organisation. 

Cet article Le subscription hijacking sur Microsoft Azure  est apparu en premier sur RiskInsight.