Summary
Secureworks® Counter Threat Unit™ (CTU) researchers discovered that Microsoft Azure enables cloud to on-premises lateral movement via Azure Arc. Due to the nature of Azure Arc, this lateral movement can also allow a threat actor to pivot from an organization's Azure tenant to the organization's on-premises Google Cloud Platform (GCP) or Amazon Web Services (AWS) environments.
Exploitable Azure Arc elements
Azure Arc is a hybrid and multi-cloud management solution. It can manage Windows and Linux physical on-premises servers and VMs hosted in other cloud environments, such as GCP or AWS.
The Log Analytics Contributor role provides access to storage accounts, VM extensions, alert rules, diagnostic settings, operational insights, support, and even deployments. It can perform many actions associated with accessing, tracking, and distributing logs across the organization, but the following actions are relevant to the attack chain identified by CTU™ researchers:
- Microsoft.ClassicCompute/virtualMachines/extensions/*
- Microsoft.Compute/virtualMachines/extensions/*
- Microsoft.HybridCompute/machines/extensions/write
Azure offers many extensions that are easily downloadable and configurable on VM or hybrid compute devices. The Log Analytics Contributor role needs access to extensions used by security alerting or monitoring software in order to create alerts for malicious or anomalous activity observed in the associated VM or hybrid compute device. CTU researchers identified three extensions that can be abused:
- enableVMAccess
- Custom Script Extension
- PowerShell Desired State Configuration (DSC)
The enableVMAccess extension is available on all VMs within an organization's tenant. It can reset a VM user's password or SSH authorized_keys file and facilitate end users' access to the VM. A threat actor could abuse this extension to reset the administrator password of a high-profile or sensitive VM and gain access to that system for credential scraping and post-compromise activities.
The Custom Script Extension allows an administrator to configure their VM or hybrid compute system via a PowerShell or Linux bash script from an Azure storage account. This extension is available on cloud-hosted VMs and physical on-premises devices via Azure Arc.
The PowerShell DSC extension can configure VMs by deploying a PowerShell DSC script from an Azure storage account.
Attack sequence
Threat actors could abuse the Custom Script Extension to compromise Arc-connected systems and cloud-only VMs. The following steps depict how an attacker could move laterally from Azure Arc to an on-premises system, where they could execute malicious code:
- Browse to the Azure Arc portal and click Machines (see Figure 1).
Figure 1. Azure Arc portal option to view managed systems. (Source: Secureworks) - Identify the Arc-connected systems (see Figure 2).
Figure 2. Arc-connected systems in the example environment. (Source: Secureworks) - Select one of the Arc-connected systems, then click Extensions in the next window (see Figure 3).
Figure 3. Option to view extensions associated with an Arc-connected system. (Source: Secureworks) - Click Add (see Figure 4).
Figure 4. Option to add an extension. (Source: Secureworks) - Type Custom Script Extension in the search bar (see Figure 5).
Figure 5. Search for Custom Script Extension. (Source: Secureworks) - Select the Custom Script Extension for Windows - Azure Arc tile and click Next (see Figure 6).
Figure 6. Initiating installation of the Custom Script Extension. (Source: Secureworks) - Click Browse next to the Script file (Required) field (see Figure 7).
Figure 7. Searching for the Custom Script Extension script file. (Source: Secureworks) - Select a storage account (see Figure 8).
Figure 8. Identifying a viable storage account for the malicious code. (This example shows a search for ‘rce' because CTU researchers created the ‘rcetest' storage account for this scenario.) (Source: Secureworks) - Select a storage container (see Figure 9).
Figure 9. Storage containers associated with the storage account. (Source: Secureworks) - Upload a Cobalt Strike PowerShell Beacon to the storage container (see Figure 10).
Figure 10. Interface to upload files to the container. (Source: Secureworks) Select the file and click Next, redirecting back to the main extension configuration page.
- Select Review + create (see Figure 11).
Figure 11. Interface to review and finalize the configuration. (Source: Secureworks) - Wait for the Cobalt Strike Beacon to phone home from the on-premises or external cloud system (see Figure 12).
Figure 12. Cobalt Strike Beacon phoning home. (Source: Secureworks)
Detection
CTU researchers created the following KQL query to determine if an account possessing the Log Analytics Contributor role has attempted to perform any write action using an Arc extension on an on-premises or multi-cloud system:
AzureActivity | where OperationNameValue == "MICROSOFT.HYBRIDCOMPUTE/MACHINES/EXTENSIONS/WRITE" | where tostring(parse_json(Authorization).evidence.role) == "Log Analytics Contributor"
Communication with Microsoft
CTU researchers reported this issue to the Microsoft Security Response Center (MSRC) on April 4, 2024. MSRC responded on June 3, indicating that it is a "by design" issue:
Thank you again for submitting this issue to Microsoft. Currently, MSRC prioritizes vulnerabilities that are assessed as "Important" or "Critical" severities for immediate servicing. After careful investigation, this case has been assessed to working as intended. As per our current design, we need to allow LA admin to configure and install LA Legacy agents. More documentation can be found here: Manage access to Log Analytics workspaces - Azure Monitor | Microsoft Learn. This case does not meet MSRC's bar for immediate servicing however, we have shared the report with the team responsible for maintaining the product or service. They will take appropriate action as needed to help keep customers protected.
Conclusion
A threat actor who obtains the Log Analytics Contributor role within a given Azure tenant could use that account to execute code on any VM within the tenant. They could also pivot from the Azure tenant to on-premises systems or Azure Arc-connected systems, which could include VMs in GCP, AWS, or other third-party cloud environments.