Subscription hijacking is a cloud attack first identified on Microsoft Azure: it consists of an attacker successfully transferring an Azure subscription from its original Azure organization to an organization under malicious control. This attack allows the attacker to take full control of the subscription and its content and even continue billing the original organization for their use of the stolen subscription.

 

Reminder of what  an Azure subscription is 

 

An Azure subscription is a container for cloud resources and services associated with a tenant, which enables the management of billing, access, and the deployment of Azure resources. 

 

Azure resources architecture

 

Operation of the attack 

 

On Microsoft Azure, the following initial situation is considered : 

• There is a legitimate organization (the victim tenant), which may or may not contain a subscription
• There is a malicious organization (the attacker’s tenant) under the attacker’s control

The attack then follows these four steps: 

Steps of the attack on Azure

 

1. The attacker must be present in both organizations: they therefore compromise an internal administrator in the victim tenant to have their external account invited into the tenant, or they convince a non compromised administrator to invite them under some pretext. In both cases, the administrator invites them into the victim tenant
2. The attacker targets an existing subscription or creates a new one themselves (which requires permissions), associated with an existing billing account in the victim tenant
3. The attacker obtains the Owner role on the targeted subscription. If they created it themselves, they already have this role by default; otherwise, they must receive it from an administrator
4. The attacker transfers the subscription from the original organization to the destination organization

The subscription is now under the full control of the attacker’s organization and can continue billing the former billing account.  

 

Why is this attack dangerous ? 

 

This attack is potentially very dangerous because it can be carried out instantly if the conditions are met, gives the attacker full control over the resource and any of its content, and is irreversible without support intervention. 

 

An instantaneous attack 

 

By default, any user with the Owner role on an Azure subscription who is also present in another tenant can perform the transfer without restriction. 

Multiple and potentially irreversible consequences 

The subscription comes under the control of the malicious tenant that has taken it over. They can therefore: 

• Having full control over it while the original user no longer has access 
• Extract all resources or information from it 
• Use it while charging the usage of the former billing method belonging to the legitimate owner 

 

Note: A purpose of subscription hijacking is to bring the resources into the attacker’s own environment, outside the control of the legitimate owner, to use them for their own benefit or to bill new usage to the former owner. However, even simple transfer without any use already causes major consequences: the user will have lost their subscription, and thus will have lost all resources, but also the structure (roles, assignments, rules), which can be very time‑consuming to rebuild. 

If the legitimate owner can block billing once they realize what is happening, there is, however, no way to recover the subscription if the attacker has removed all former Owners from it. The only remaining option is to turn to Microsoft support. 

The following article by Derk van der Woude describes a case of cryptocurrency mining carried out using stolen subscriptions and billed to the former owner: 

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

 

How to be protected against it ? 

 

To protect against an illegitimate subscription transfer, there are preventive measures that can be applied to mitigate each step of the attack: 

Preventive measures 

1. Attacker’s access to resources : conditional access policies 

Conditional access policies based on risk automatically strengthen security by adapting controls according to the level of risk detected during a sign‑in or associated with a user. For example, they can block suspicious access or require multi‑factor authentication (MFA). Thus, the access of a suspicious guest could be blocked. 

     2. Privilege escalation/obtaining the Owner role: privileged identity management 

Privileged Identity Management (PIM) allows high‑privilege roles to be granted only when needed, through temporary, approved, and justified elevation. It reduces risks linked to excessive permissions through control, monitoring, and activation notifications. 

 

     3. Subscription transfer : subscription policy 

A subscription policy makes it possible to block the transfer of an Azure subscription to or from the tenant to prevent hijacking. It is implemented through Azure Policy by defining and then assigning a rule that restricts transfer actions, with regular reviews to ensure its effectiveness. It applies to all subscriptions within its assignment scope. 

 

Detection solutions 

 

Certain solutions can detect this attack on Microsoft Azure: 

• UEBA (Sentinel) : detects abnormal behavior (unusual sign‑ins, access to sensitive resources, unexpected changes). This helps quickly identify a compromised account before it can hijack a subscription. 
• Privileged Identity Management (PIM)​ : monitors privilege elevations and can trigger alerts when a privileged role is activated. 
• Custom Sentinel Alert : can specifically monitor events indicating a subscription transfer. The rule regularly analyzes Azure Activity logs and immediately triggers an alert when a suspicious operation like the moving of a subscription is detected. 

 

Resilience strategy 

The resilience strategy to be implemented is a backup of resources that allows them to be restored in the event of an actual subscription hijacking. 

1. Isolate Azure Backup backups in a dedicated subscription reserved for backups with strict security rules 
2. Protect backups: enable soft delete (no immediate permanent deletion), reversible deletion, immutability (prevents modification or deletion for a set period), and anti‑deletion locks 
3. Create multiple copies, potentially to another tenant 
4. Back up governance as well (Entra ID configurations via Microsoft 365 DSC, infrastructure configuration with Terraform) 
5. Automate reconstruction with infrastructure‑as‑code (Blueprints, ARM, Terraform) 
6. Regularly test backups 

 

Response to the attack 

 

Suffering a subscription hijacking means losing control of your Azure subscription. In that case, options are limited. You should very quickly: 

• Block the attacker’s access and revoke any secrets potentially compromised during the attack 
• Contact Microsoft Billing support to stop billing 
• Contact Microsoft technical/Azure support to attempt to recover the subscription 

 

And on other providers? (AWS and GCP) 

 

Once this attack has been identified on Azure, the question arises as to whether it also exists (or if an equivalent exists) on AWS and GCP. The concept of a subscription does not exist as such with these two cloud providers; however, equivalent hierarchical units play the same role. If it were possible to migrate them to another AWS or GCP organization in an illegitimate way, this would constitute the equivalent of subscription hijacking on those platforms.  

 

AWS : an existing equivalent with distinct conditions 

 

On AWS, the hierarchical equivalent of an Azure subscription is the AWS account: an AWS account, located within an organization, contains IAM users, resources, and is the level at which billing is handled if it is not consolidated by the management account. 

The goal of an attacker would therefore be to have this AWS account migrated to another organization. 

 

Steps to follow 

 

The steps to follow are : 

  

Steps of the attack on AWS

 

An AWS account contains: 

• A unique root user, who has all rights on the account 
• IAM users with assigned IAM permissions 

 

From there, two strategies are possible for the attacker: either compromise the root user (which would allow any action) or succeed in escalating privileges on a regular IAM user. However, root approval is still required for step 1 (for example, the attacker may have manipulated the root user into performing this action). Moreover, if guardrails or Service Control Policies are enforced, the root user must still validate the operation. As a result, an IAM user, even with elevated rights, cannot always migrate an account on their own. 

 

Similar consequences to the Azure attack ? 

 

It is established that on Azure, transferring a subscription results in a total loss of control over it. Here, on AWS, two nuances must be introduced: 

• First, as shown in thepreviousdiagram, billing must be changed (to an independent billing mode) to allow the account to migrate to another organization, which eliminates the risk of being charged for services used by the attacker after the migration
• Second, in the theoretical case where it is a non‑root IAM user who performed the migration (having gathered all the necessary permissions), this user does not have full control over the account, even if they leave it standalone or make it join an organization under their control. AWS accounts are highly independent, and simply having an account within one’s organization does not allow arbitrary actions (accessing certain resources,deletingthe account) without possessing the root user

 

Conclusion 

 

If the attack seems possible on AWS in theory, it requires more conditions and results in fewer definitive negative consequences than on Azure. Ultimately, the only way to take full control of an AWS account remains to obtain its root user. 

 

GCP : a possible equivalent but more difficult to realize 

 

On GCP, the architecture is closer to Azure. The equivalent of an Azure subscription is the GCP project. Here, the attacker’s goal would therefore be to migrate a project from one GCP organization to another.  

 

Steps to follow 

 

The steps to follow are : 

  

Steps of the attack on GCP

 

Similar consequences to the Azure attack ? 

 

The consequences of migrating a GCP project are the same as for an Azure subscription: a total loss of control over the asset, and the risk of being billed for the attacker’s usage if billing has not been modified. 

 

Conclusion 

 

A resource hijacking scenario similar to Azure subscription hijacking is therefore theoretically possible on GCP. However, the stricter conditions required make this case less likely, though it must still be considered. 

Summary of the consequences 

 

Summary of the consequences

 

Conclusion 

 

The subscription hijacking must therefore be considered a major attack with severe and high‑impact consequences for affected organizations or companies. Protecting the hierarchical units that manage billing and resources against any illegitimate move or migration (with measures that vary depending on the cloud provider) and establishing remediation and backup processes in case of loss is crucial for an organization’s security.