For customers that are using Azure Automation in many cases have been using it to build runbooks to automate against Azure environments (using a built-in AzureRunAsAccount) which is automatically created using the Azure Portal wizard. This creates a service principal in Azure Active Directory and gets by default contributor access to the environment.
This configuration, unfortunately, stores the password (as a self-signed certificate) as part of the extended attributes as part of the object in Azure AD. So, using simple Graph API calls you can collect the attribute for an environment where you have user access to Azure AD. This can then be used to authenticate to the environment and get contributor access. This vulnerability was found by Karl Fosaaen and described in detail here –> CVE-2021- 42306: CredManifest | Critical Vulnerability Found in Microsoft Azure (netspi.com)
This affects if you are using Azure Automation and have a RunAsAccount which has been created or renewed before 15th October this year. Automation Run As accounts created with an Azure Automation self-signed certificate between 10/15/2020 and 10/15/2021 that have not been renewed are impacted.
There are different ways to mitigate this which are described here –> https://lnkd.in/gH2FPcST
Renew the RunAsAccount
1: Go into the Automation Account –> Run As Accounts
2: Click renew certificate
Then remove the old certificate chain within the application manifest. Locate the application ID under App Registrations within Azure Active Directory
Then go into Manifest. Then under Key Credential you should have two certificates here (the old one and the new one) Remove the old credential so you only have the new one left.
This means that Runbooks will continue to run as before without the need to make any changes. However, in one year time you will need to remember to renew the certificates or you can investigate Azure Managed Identities (which is now supported for Azure Automation as of October this year) That requires a bit more work since you need to enable it for the automation account and change the runbooks.
1: Enable System Assigned Identity.
2: Assign the managed identity access to the Azure environment
3: Define the Identity within the runbooks.
If you are using the deprecated AzureRM cmdlets, you can use Connect-AzureRMAccount -Identity instead.
# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process
# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context
# set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext
Regardless of which one you define you should still enable diagnostics of Service Principal and Managed Identity logon via Azure Active Directory diagnostics to a Log Analytics workspace.
That way we can also monitor the usage of managed identity and service pricinpals within Log Analytics or Azure Sentinel. These data will then get stored within the following tables
AADManagedIdentitySignInLogs | where ServicePrincipalName == <VM or application name> | project TimeGenerated, Category, ResultType, CorrelationId, ServicePrincipalId, ResourceDisplayName, IPAddress, LocationDetails |