The setup is the same as the previous scenario; you only need to slightly change the terraform (main.tf) script. Azure provider doesn’t allow sensitive values in its output, so add sensitive = true to your code.

Also, change the storage account name. The hardcoded storage account subscription is unavailable.

Build the terraform plan.

terraform plan -out <filename>

Once successfully built, we apply those changes using:

terraform apply <filename>

To get the initial account info (username and password), use:

terraform output --json

Enumeration

Let’s login with the credentials obtained from the terraform output:

az login --service-principal -u <username> -p <password> --allow-no-subscription

We’ll use ScoutSuite to enumerate permissions and resources accessible to this service principal. ScoutSuite queries for all possible Azure resources and potential misconfigurations.

ScoutSuite supports multiple authentication methods. We will execute the following as we have already logged into our target Azure account via az CLI.

python scout.py azure --cli

Once ScoutSuite successfully analyzes the environment, we get an audit report.

It has audited all the services the service principal can access and given us a list of misconfigurations. After going through the issues, we found a service that stands out the most: Key Vault.

Key Vault is Azure’s service for storing and managing sensitive data like keys, secrets, and certificates. We are likely to stumble upon more secrets.

From the issues, we find the key vault named batcave has RBAC disabled.

When RBAC is disabled on a key vault, access is governed by the vault’s access policies. Managing access policies involves specifying the permissions for different principals (users, groups, or applications) directly within the vault’s settings. This method allows for fine-grained control over access to the vault’s keys, secrets, and certificates.

After further analyzing the issues and resources, we found an interesting Azure role named “No Administering Resource Locks.”

This role is not a standard Azure role, and it alone is not significant to this scenario. Maybe it’s just a hint for the player.

Azure Resource Locks are additional security measures to prevent resource tampering or deletion. The hint may indicate that some critical resources don’t have a resource lock.

We can manually test the environment using this initial foothold information from the ScoutSuite report.

Exploitation

Let’s try printing all the key vaults.

az keyvault list

Let’s fetch all secrets from the key vault batcave.

az keyvault secret list --vault-name batcave

In the id section, we can see the secret named butler. We then pass this on to reveal the secret.

az keyvault secret show --vault-name batcave --name butler

We have found the credentials of a possible regular user account.

Regular user accounts are linked to individual identities and include wider access authorizations suitable for different positions within a company.

Let’s see if this user credential works.

az login -u <username> -p <password>

It worked.

Going by the hint that “No Administering Resource Locks,” let’s see if this compromised user can edit the Key Vault’s access policy and update its privileges.

Let’s try making our compromised user butler the owner of the key vault batcave.

Executing the command without scope gives us an error.

Now, we assign the scope at the subscription level, which gives us elevated privileges at the specified level or scope.

az role assignment create --assignee <assignee username> --role <role> --scope <scope define>

To verify our elevated permissions, use the command below to list all role assignments for a specific user or service principal.

az role assignment list --all --assignee

We can see roledefinitionName is set to Owner, which means we have successfully elevated our privileges.

Conclusion

In conclusion, Scenario 2 of XMGoat shows how an attacker can use the leaked credentials of a Service Principal to enumerate secrets stored in the Key Vault. These secrets, which included the credentials of a regular account, were used to update the access policies of the Key Vault and escalate privileges to become the Owner of the Key Vault.