What’s In An Azure Subscription ID?

“Can I be hacked if someone has my Azure Subscription ID?”

“Is my Azure Subscription ID the key to the kingdom?”

I’ve had this conversation a number of times with colleagues and clients alike.  What is this ID that Azure assigns to your account, and can it be leveraged to gain access to your subscription?  Not really.  So let’s take a look at what an Azure Subscription ID is, how it works, and how it should be handled.

An Azure Subscription ID is a GUID – a globally unique identifier – that identifies your subscription and the underlying services.  When someone hears this, they immediately think of it in the same regard as a user account, but it’s really not.  What it is, is directions to a container of the services that you want to access, if you have the permissions to do so.  In order to access a particular subscription ID, you need to do the following:

  • Be authenticated to Azure (through the portal, CLI, or PowerShell).
  • Have your Microsoft Azure or Active Directory ID assigned the permissions to view the subscription ID.

Let’s test this.

Here’s a subscription ID for you to play with:

$UnknownID = 'f2007bbf-f802-4a47-9336-cf7c6b89b378'

Looks pretty unassuming.  So I’m going to see if I can look at the properties of this subscriptionID without authenticating to Azure.

PS C:\WINDOWS\system32> $UnknownID = 'f2007bbf-f802-4a47-9336-cf7c6b89b378'

PS C:\WINDOWS\system32> Get-AzureRmSubscription -SubscriptionId $UnknownID
Get-AzureRmSubscription : Run Login-AzureRmAccount to login.
At line:1 char:1
+ Get-AzureRmSubscription -SubscriptionId $UnknownID
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Get-AzureRmSubscription], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,Microsoft.Azure.Commands.Profile.GetAzureRMSubscriptionCommand

PS C:\WINDOWS\system32>

Well…that gave me bupkus.  So let’s authenticate and try again.

PS C:\WINDOWS\system32> Get-AzureRmSubscription -SubscriptionId $UnknownID
Get-AzureRmSubscription : Subscription f2007bbf-f802-4a47-9336-cf7c6b89b378 was not found in tenant . Please verify 
that the subscription exists in this tenant.
At line:1 char:1
+ Get-AzureRmSubscription -SubscriptionId $UnknownID
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureRmSubscription], PSArgumentException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Profile.GetAzureRMSubscriptionCommand

PS C:\WINDOWS\system32>

So I log into Azure, and try again to resolve the SubscriptionID to the tenants that I have access to, and it returns an error stating that there is no such subscription in my tenant.  So by means of leveraging both unauthenticated and authenticated means, I cannot see any information pertinent to this SubscriptionID.

So, let’s try using our preferred internet search provider.  Which, if you’ve tried this, you’ll actually get search hits because this is my subscriptionID – one that I use for just about all of my Azure examples.  However, you’ll find that the only thing that comes up are links to my articles.  There is nothing from an Azure standpoint that is publicly available when searching for this ID.  Even publicly available blob URIs.

Shameless plug: Read my articles. I put a lot of love into those.

So what have we figured out so far?

  • No information in Azure that is tied to your SubscriptionID is made publicly available by search.
  • No information in Azure that is tied to any SubscriptionID is made available unauthenticated.
  • No information in Azure that is tied to a SubscriptionID is made available to you if you are authenticated with an account that does not have permissions to view that SubscriptionID.

So what do we need?  User creds.  If you have access to a user credential that has admin rights to a subscription (or multiple subscriptions), you don’t even need the SubscriptionID.

PS C:\WINDOWS\system32> Get-AzureRmSubscription

Name     : ProdSub
Id       : 1a8c783b-3317-4535-8f12-5066eec9094c
TenantId : 1f9d2d05-2bef-4f58-8f74-697e76e704db
State    : Enabled

Name     : LastWordInNerd
Id       : f2007bbf-f802-4a47-9336-cf7c6b89b378
TenantId : 96b32bac-743d-49bb-adff-7552b2d86956
State    : Enabled
<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>

Notice that after I authenticated to Azure, I was able to use the Get-AzureRmSubscription command to get the entire list of subscriptions that I have access to.  I have the metaphorical keys to the castle, or multiple castles, if I have the admin credentials.  After I have those credentials, I use the subscriptionID (of which I now have) to put myself into the context of the Azure Subscription.  I’m telling Azure, “I want to work in THIS subscription,” and it takes me there.

What you really need to protect are your credentials.  This can easily be handled with multi-factor authentication.  Use it.  At the very least, privileged accounts should have this enabled by default.  According to a 2017 Verizon Data Breach Investigations Report, 81% of hacking-related breaches leveraged either stolen and/or weak passwords.

If you haven’t enabled multi-factor authentication in your environment yet, and you’ve already gone to (or are planning on going to) the cloud, a subscription ID is the least of your concerns.