How to Detect Malicious Azure Persistence Through Automation Account Abuse
There are many ways an attacker can maintain persistence and create ‘backdoors’ in Azure allowing them re-entry back into the environment. Persistence is important to an attacker if compromised accounts have been discovered and removed by the victim organisation as the attackers still need to find a way to re-gain access to the environment.
Installation of a webhook to interact with malicious runbooks created through automation accounts is one way an attacker can re-gain access into a tenant if compromised account access has been revoked. I was inspired to write this blog post about how to detect this technique when I came across an excellent post written by Karl Fosaaen detailing how an attacker can abuse automation accounts to maintain persistence. I have broken down this blog post into two sections covering both the detection methodology and the attack flow. For a more detailed attack flow, I urge you to take a read Karl’s blog as I took what he detailed in his post and recreated his attack to figure out the detection methods.
In short, once an attacker is kicked out of a tenant, they can trigger their runbook to run, granting them access back into this tenant. This doesn’t have to be via the creation of a new user account as depicted in the clip below – it can also be any other action i.e. the remote execution of commands in VMs or addition of a key/certificate to service principles.
If you’re interested in the detection of other Azure persistence / backdoor methods I’ve previously covered three of those techniques in other blog posts listed below:
If you’re curious about attacks on Azure Active Directory (AAD) or M365, you can check out my attack matrix here.
- Creation of a new user account to allow the attacker back into the network (the scenario we will be using as per Karl’s blog)
- Execution of malicious scripts on VMs
- Adding certificates / key to the automation account for single-factor access into AAD
- Whatever else the attacker wants to run in PowerShell based on the privileges granted to the automation account
- Abuse of an existing automation account i.e., assigning further privileges or permissions
- Creation of a new automation account for malicious purposes
- Editing of an existing runbook and to insert malicious commands
- Creation of a new runbook that has malicious commands
- Detection of actions / commands issued within these runbooks (this can vary depending on what the threat actor is aiming to achieve)
- Review webhook creations for signs of potentially malicious webhooks a threat actor can interact with
- Review webhook requests for malicious requests
- Review all automation account creations for signs of malicious activity
- Review and assess permissions assigned to automation accounts
- Review all runbooks that are modified / created for signs of malicious activities
- Review malicious logons and other details in audit logs that may show other suspicious activities
- Operation name: Create or Update an Azure Automation webhook
- Operation name: Generate a URI for an Azure automation Webhook
- Category: ApplicationManagement
- Activity: Add service principal
- Initiated by: Managed Service Identity
- Category: RoleManagement
- Activity: Add member to role
- Property Role.DisplayName for sensitive roles i.e. User Administrator, Cloud Administrator, Virtual Machine Contributor, Global Administrator etc
- Operation: Create of Update an Azure Automation Runbook
- Operation: Publish an Azure automation runbook draft
- Operation: Write an Azure Automation runbook draft
- Filter: Runbook name (look for a runbook name outside the norm).