Azure Key Vaults are an attractive target for threat actors as it contains information that may allow a threat actor to gain access to sensitive keys / passwords and certificates that can further the attack chain – leading to persistence, lateral movement, and data collection. The Azure Key Vault is often used by developers for managing keys, certificates, and passwords (tokens, API keys and secrets).
The following three permissions below can be abused by a threat actor in this attack chain allowing them access to read secrets in cleartext and modify access policies (i.e. granting read permissions to another malicious account). I would recommend that during Azure audit assessments, that service principals / managed identities / users with access to these three permissions are properly audited:
- Microsoft.KeyVault/vaults/read
- Microsoft.KeyVault/vaults/secrets/read
- Microsoft.KeyVault/vaults/accessPolicies/write
Attack Conditions
Abuse of Azure Key Vaults requires that an attacker has gained access to an account with the rights to view / list the relevant Key Vaults that the attacker wants to target. The compromise of the Azure Key Vault tends to happen later down the attack chain – after the attacker has gained access to an Azure tenant. If the compromised account does not have the appropriate permissions, the threat actors are still able to enumerate other accounts that they can abuse – i.e. automation accounts, storage accounts, managed identifies and other service principals.
The abuse of service principals, storage and automation accounts have been previously covered in my blog posts below:
In most scenarios developers will have automated applications being able to directly interact/read from Azure Key Vault. In these instances, an attacker should focus primarily on the compromise of these service principal accounts as these accounts will have delegated permissions required to perform this attack.
Attack Methodology
Step 1: Perform reconnaissance by listing all key vaults in the environment
This step requires that the user account or service principal account that you possess contains the permission of Microsoft.KeyVault/vaults/read as this permission allows an account to list all the key vaults contained within the environment. This allows an attacker to figure out which key vaults they want to access / gain some broader understanding of what’s contained within the key vaults (only if the client has a good naming convention haha).
The screenshot below shows that this tenant has two Azure Key Vaults – the one we will focus on for the sake of this blog post is named “Purplehazee”.
Step 2: List the keys and secrets stored within the Azure Key Vault
To pillage/compromise the credentials and keys stored within each key vault, an attacker needs to know the names of the keys/secrets that are stored. To list the keys and secrets within a vault, an attacker also needs to be delegated the permission of Microsoft.KeyVault/vaults/secrets/read.
There are two options for reading from an Azure vault – they are to read the “keys” or to read the “secrets”. The ID for all Azure Key Vaults follows the following convention of:
- https://<keyvault-name>.vault.azure.net/secrets/<secretname>
- https://<keyvault-name>.vault.azure.net/keys/<keyname>
In the screenshot below, you can see I have enumerated the secrets stored inside the vault “Purplehazee”. There is one key stored within this vault named “DontSeeMe”.
Enumerating for keys, you can see that there is also one encryption key stored in this vault named “myspecialkey”. Creative I know!
Step 3: Compromise the plaintext secrets and encryption keys!
Now that the attacker knows the names of the secrets and keys stored within the Vault, the attacker only needs to show the plaintext value of each secret/key. As you can see below in this screenshot, the plaintext password for the key “DontSeeMe” is “ohnoiamseen”.
Vice versa for listing out the plaintext key for my key named “myspecialkey” as you can see in the screenshot below.
Step 4: Persistence Time! Modify the access policy by adding a malicious account
To maintain persistence into the Key Vault in case the attacker account has been locked out, if an attacker-controlled user has been granted the permission of Microsoft.KeyVault/vaults/accessPolicies/write – the attacker can add another user account to the Key Vault.
Just for your interest, this permission delegates quite a lot of power to an account including the ability to merge access policies.
To abuse this permission, the attacker can add a malicious user account to the Key Vault – this can be a user account or a service principal account. In this instance, the attacker (me) has added the user “bananaboy” to the Key Vault.
You can view all the service principals and users that have access to the Key Vault within the portal – here you can see BananaBoy has appeared! 
Detection Methodology
If you do not enable diagnostic logging on Azure Key Vaults, you will not get many interesting logs. Given all the actions I have taken above including enumerating the keys/secrets and viewing them – none of these generate logs in the Azure Vault activity logs! The only action that generates logs in the Activity Logs is modification of the access policies.
Azure Activity Logs (I don’t recommend this method for detection)
The activity logs will store information relating to set-up of the Azure Vault, deletion of the vault and other administrative changes such as modification of the access policy. It will not contain contextual information of other attack actions i.e. viewing / access to secrets and keys. As such, this is not my recommended detection approach. I strongly recommend that diagnostic logging is enabled for proper telemetry.
During this attack flow, I modified the access policy by adding a malicious user “Bananaboy” to the Azure Vault “purplehazee”. This activity was recorded in the Azure Activity Log. To hunt for this entry – I would recommend looking for:
- Changed Property – properties.accessPolicies[id]
The “ID” that is contained within this log entry pertains to the user that was added. You will need to correlate this with the UPN of the user / service principal that was added for this to make more sense.
The JSON breakdown of this will show a little more information but it will not contain the information we want to see pertaining to – attacker IP and breakdowns of the contextual activity post and prior to this access policy being modified.
Diagnostic Logging – Recommended Method for Detection
To gain a full understanding of the timeline of events leading up to an access policy being modified – I strongly recommend that all Azure administrators enable diagnostic logging setting in their Azure Key Vaults. This will allow you to capture events pertaining to read/access and enumeration of Key Vaults.
Be aware that if you have several automation accounts that are reading/writing/accessing Vault, I encourage you to ensure these IPs/accounts have been baselined for activity so that the malicious activity stands out. Most Key Vaults for organisations are heavily utilised via automation accounts / service principals in an automated fashion – so one-off access to secrets/keys should not appear too often.
The screenshot below shows how to enable the diagnostic logging in the diagnostic settings. Ensure that both the “audit” and “AllLogs” buttons are ticked:
The KQL query I utilised to view the activities in the Azure Key Vault is as follows:
This straight away revealed results pertaining to my attacker IP (TOR exit node) and actions taken to view and enumerate the Azure Keys and Secrets.
The operations I recommend hunting for include the following:
- KeyList
- KeyGet
- KeyDecrypt
- KeyListDeleted
- SecretGet
- SecretList
- SecretRecover
- SecretGetDeleted
- SecretListDeleted
- SecretList
- CertificateGet
- CertificateList
- CertificateRecover
- CertificateGetDeleted
Please note the operations pertaining to deletion and recovery – you can recover deleted keys! I did not document this in the attack methodology but please be aware that this is a possibility.
References
https://docs.microsoft.com/en-us/azure/key-vault/general/logging?tabs=Cerificates
https://docs.microsoft.com/en-us/azure/key-vault/general/security-features
https://docs.microsoft.com/en-us/azure/key-vault/general/overview
https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs#send-to-log-analytics-workspace
Comments
Post a Comment