In 2017 Wesley and I gave a presentation at SHA2017 about honey/pot/tokens. We actually planned on building a fully fledged platform. But never came further then the POC phase of that project. This week we got a product demo from the guys at Thinkst, i’ve always loved this way of thinking: let the attacker come to you. During the demo I saw a cool honeytoken for o365. This gave me an idea to see if we could build tokens that could be used in Azure.
This week I had to deploy some new Azure Key Vault, vaults. We wanted to limit access to one service principal, limit the IP’s that were allowed to access the vault and log all access to Azure Sentinel. Our backend uses the service principal credentials to authenticate to the Key Vault and query the secrets.
While building this I worried about an attacker gaining access to the service principal credentials and stealing the information from the keyvault. The IP filter rule makes this more difficult for an attacker. But at the same time why not make extra keyvaults as a honeytoken? Leave them in repo’s, emails and documentation. The moment someone queries the vault we know someone stole our stuff! This type of token could be a nice indicator for when an attacker has already gained access to our environment. But is trying to escalate those privileges. We might want to give it an interesting name to make sure the attackers try and use it.
Building it
So how do we make this? Preferably in an automated manner so we can re-use it. There are some prerequisites, we assume you are already using Azure Sentinel to log stuff to. If you are using o365 but not logging to Sentinel you are missing out. (free SIEM essentially)
So I built a script that does the following:
- Creates a resource group to put everything in (easy cleanup)
- Creates a key vault
- Creates a service principal
- Gives the service principal read access to the newly created key vault
- Configure audit logging and send it to Sentinel.
- Output the tokens so we can spread them
- Generate KQL queries so we can detect the use of our tokens
After running the script it will look like this:
Detecting it
Now all audit log messages related to our newly created keyvault will be logged to our Sentinel. We can essentially alert on anything related to audit log. But to be sure no internal Azure processes trigger an alert we can filter on certain operations. We filter on the following operations:
- Authentication
- SecretGet
- SecretList
AzureDiagnostics
| where ResourceType == "VAULTS"
| where Resource == "HONEYTOKENSKV"
| where OperationName in ("SecretGet","Authentication", "SecretList")
| order by TimeGenerated desc
We can add this to a sentinel rule in order to check for someone accessing our keyvault. If you want to have this sent to a webhook or email you can build a playbook to automatically forward them.
bonus
We already have a service principal that we leak. What if the attacker doesnt know its supposed to be used for Azure Key Vault? We can monitor the log to see if someone logs into our AzureAD. I read a blog recently that describes the options to enable logging for the service principal logons. Essentially its: AzureAD->Monitoring->Diagnostic Settings . Here you can modify the entries being logged to your Sentinel environment.
We can use this log to query for logons from our service principal. So lets say we found the creds to a service principal and logged on:
we can then query for this in our Sentinel environment:
AADServicePrincipalSignInLogs
| where ServicePrincipalName == "honeytokensSP"
Conclusion
Honey pots and honey tokens can be a way of finding shenanigans with high reliability. The tokens, once used indicate an active attacker. Having these inside Azure can be of great benefit in detecting said shenanigans. This blog focuses on the key vault and service principal avenue. But way more can be thought of. Maybe a fake backup administrator with fake creds inside the description or Azure Functions app with an interesting name. The thing with honeypots and honeytokens is that many people still don’t place them. It’s a shame they can be quickly deployed and greatly improve the chances of detecting an attacker.