Azure subscription hijacking and cryptomining

Derk van der Woude
8 min readJan 13, 2022

What’s the story of the attack so we can all learn from it and how to protect (prevent) or detect the attack from happening.

The attack

The victim has a Microsoft tenant (Azure AD) with a pay-as-you-go Azure subscription with a Credit Card as payment method. The initial account who created the tenant (Global Administrator) and Subscription (Owner) is vulnerable to the attack. The attacker has it’s own Microsoft tenant (Azure AD with Office 365 for mailbox access).

There are many Office 365 features (e.g. Azure AD) that require Azure resources/subscription (e.g Azure AD log analytics requires diagnostic setting is a log analytics workspace).

Overview of the attack is as follows:

  • The Azure AD break-glass account was compromised (e.g. the password was obtained from the dark web; brute-force password attack or re-used password from past SaaS hack like LinkedIn in 2012) and was used to logon to the victim-tenant Azure portal (via a VPN or TOR browser to hide their source IP-address).
  • A guest account was created (requires elevated permissions in Azure AD: Global Administrator, Guest Inviter or User Administrator) in the victim-tenant with an account from the attacker-tenant (e.g. admin@attacker.onmicrosoft.com), this account needs a mailbox for to verify the invitation.
  • The newly created guest account got Owner permissions (requires elevated permissions in Azure: Owner or User Access Administrator) on the Azure subscription in the victim-tenant.

If the Global Administrator account is not owner of an Azure subscription, he/she can take ownership of all Azure subscriptions via the option ‘Access management for Azure resources’ in Azure AD

  • Logon from the attacker-tenant to the Azure portal (section subscriptions) and switch directory to the victim-subscription
  • Change directory to transfer the Azure subscription to the attacker-tenant (Azure AD).

After the transfer, the Azure subscription is not visible/accessible in the victim-tenant so we can also not access the logs anymore. The credit card is still attached to the Azure subscription.

  • Attacker deployed (10) Azure VMs (e.g. NVv4- (GPU) or Mv2-series) to mine cryptocurrency. See example for pricing (starting from …. )

Cryptocurrency consensus algorithm Proof of Work is still used a lot (although Proof of Stake is better for our planet) and requires for example GPU (graphic card) power (much faster than CPU power), Ethereum is a Proof of Work cryptocurrency which can be mined via GPU’s so it’s very profitable if you don’t have to pay for the VM’s itself.

Another hijack can be the reset of all Azure AD accounts so nobody can access the Azure or Office 365 admin portal or Office 365 user applications, but that’s for another blog.

Azure subscription

When an Azure subscription is created a payment method (e.g. Credit Card) needs to be selected for the Pay-As-You-Go type subscription.

Personally I’d like to see the payment method reset/reconfirm after transfer of an Azure subscription to another tenant (please Microsoft…).

Protect (Prevention)

The Protect (Prevention) and Detect functions from the NIST Cybersecurity framework will be used in the blog. We will start with how to lower the risk from this attack from happening. We will also use the zero trust (implicit trust) concept meaning don’t trust anything but verify first (trust).

Multi Factor Authentication [MFA]

99% of all attacks in the Cloud start with the identity compromise. Username and password alone are very weak protection methods (often re-used and easy to compromise via phishing, brute-force or available from other breaches like LinkedIn in 2012). The advice is to use MFA for all named accounts (admin, user and guest). If MFA is not possible for unnamed accounts like the break-glass and/or service accounts, use a one-time complex password for the unnamed accounts and store the password safely on- or off-line.

The Azure AD - Conditional Access policy for Admin accounts (the scope of the blog) is assigned to all Directory roles (except the Directory synchronization accounts) without any exceptions on apps or conditions.

Block Access from untrusted locations

The accounts excluded from MFA is advised to provide extra protection next to the username and password. One option is to restrict access from untrusted locations. First we need to add trusted (IP) locations to Azure AD like the corporate Office for example (CIDR notation).

Use at least two locations for redundancy and fallback if they are restricted to IP-address(es)

Second we need to add a Conditional Access policy which Blocks access (Grant) from untrusted locations (Conditions) assigned to the unnamed accounts (Assignments).

Keep in mind the risk is if someone removes the Trusted locations, access is blocked for the unnamed accounts! But we can still use the named admin accounts

If we logon from a non-trusted location with the account we see the message below.

In part II of this blog we will look at the Azure options to prevent the attack once access is obtained in Azure by the use of Azure policies, cost alerts, resource locks, etc. Since I’m no in-depth Azure expert all recommendations are welcome, please send an e-mail to blog@nedscaper.com so we can help to make this world a safer place for all.

Detection

Disclaimer: all Azure Subscription logging is transferred with the subscription and cannot be excessed. That’s why the advise is out-of-band logging!!!!

Detection can be done in Azure Monitor and/or Microsoft Sentinel. We will use Microsoft Sentinel as the cloud-native SIEM from Microsoft to trigger alerts on detection of malicious activity or pre-defined actions. Below are some examples of detection of the steps in the attack chain (prevention is always better than the cure), please adjust queries to your needs.

Malicious logon (e.g. break-glass account)

The example query below alerts on successful logons outside of the Netherlands from the ‘break-glass’ account with display name ‘Admin Company’. This account should not be used (named accounts should be used daily) but it’s an example to detect malicious logon activity for named and unnamed accounts. Adjust accordingly to your needs.

— — — — — — — — — — — — — — — — — — — —— — — — — — -
Data connector: Azure Active Directory ->SigninLogs

SigninLogs
| where UserDisplayName == “Admin Company” and ResultType == “0” and Location != “NL”

— —— — — — — — — — — — — — — — — — — — — — — — — — -

Add guest account to Azure AD

The example query below creates an alert if a guest user is added to Azure AD. In some environments this could and should trigger an alert, in other environment this happens continuously and should not be used (to reduce noise).
— — — — —— — — — — — — — — — — — — — — — — — — — — -
Data connector: Azure Active Directory -> AuditLogs

AuditLogs
| where OperationName == “Add user” and Identity == “Microsoft B2B Admin Worker”
| project TargetResources[0].modifiedProperties[5].newValue

— — —— — — — — — — — — — — — — — — — — — — — — — — -

Add user (guest) as IAM Role on Azure subscription

The example query below creates an alert if an IAM role is added to the Azure Subscription (e.g. Owner). Use Azure Activity in the Azure Subscription to see the details (user added and role added), could not find an easy way in the KQL (again send an e-mail to blog@nedscaper.com if you have an optimized query)
— — — —— — — — — — — — — — — — — — — — — — — — — — -
Data connector: Azure Activity

AzureActivity
| where OperationNameValue == “MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE”
| where Properties contains “Start"

— — —— — — — — — — — — — — — — — — — — — — — — — — -

Azure Activity shows the details which user is added and which role was added.

Transfer Subscription

Transfer of the subscription is done from the guest tenant via the change directory option which connects the Azure Subscription to the guest Azure AD. Credit card data and log data is moved with the subscription

To detect the transfer of an Azure Subscription use the query below.
— — — —— — — — — — — — — — — — — — — — — — — — — — -
Data connector: Azure Activity

AzureActivity
| where CategoryValue == “Security”
| where Properties contains “got moved from tenant”

— — — — — — — — — — — — — — — — — — — — — — — — — — -

Final words

I hope this blogs gives insights (Security awareness) on what could happen (murphy's law) and how to prevent and/or detect this from happening (at least lower the risk). Let’s all make this world a safer place for all.

--

--