The Expendable Extension Name Azure VMAccess Naming Chaos, Password Resets, and a Detection Gap
The Expendable Extension Name: Azure VMAccess Naming Chaos, Password Resets, and a Detection Gap
In early April, the Sysdig Threat Research Team (TRT) identified a detection flaw in the process for Azure VM password resets and VMAccess naming. This flaw allows attackers to assign any name to Azure VM extensions, giving them the ability to obtain read/write access, change passwords, and persist in the victim environment without being detected. Additionally, the Sysdig TRT found that the telemetry documented by the Azure Threat Matrix for this detection did not fire when the event was triggered. We promptly reported these issues to Microsoft upon identification. Their official response is: “Upon investigation, we have determined that this is not considered a security vulnerability because resource names are always user specified.”
Azure VM extensions are programs that run on virtual machines to perform post-deployment configuration and management tasks. They execute with elevated privileges on the VM and are deployed through the Azure control plane, meaning anyone with the right ARM (Azure Resource Manager) permissions can push code or configuration changes to a VM without needing OS-level access. The VMAccess extension is particularly sensitive: It resets passwords and SSH keys on VMs, and through this flaw, allows an attacker to reset the password and maintain persistence in the environment. Detection rules for VMAccess typically match on the extension resource name in the activity log’s resourceId or entity field, looking for strings like enablevmaccess, VMAccessForLinux, or VMAccessAgent. However, the VM extension doesn’t have just one known name; it can have any name at all depending on which tool is used to reset it.
To further complicate matters, the activity log for a successful extension write does not include the extension publisher or type. The only identifying information is the caller-controlled resource name and a generic operation string. Any attacker who can write a VM extension can reset credentials and name the operation whatever they want, and default detection rules will never see it. Host and network-level logging for VMs (e.g., Windows event logs and /var/log) are also not passed to Azure by default. According to the Azure Threat Matrix, users are supposed to detect this password reset via an event containing the operation name “Validate Deployment,” where Properties_d has ‘vmaccesswindowspasswordreset’. However, this detection never fired in any of the tests performed by the Sysdig TRT in April 2026. During testing of this activity, the Microsoft.Resources/deployments/validate/action event never occurred, meaning that the Microsoft-provided guidance on detection was not effective here.
The VMAccess extension was deployed to a clean Linux VM via the AZ CLI using a completely arbitrary resource name: ‘my-custom-name-12345’. Azure accepted ‘my-custom-name-12345’, the password was reset, and the extension was installed. The detection that was supposed to catch it did not fire an alert. The activity log entry for this successful password reset showed: { “operationName”: { “value”: “Microsoft.Compute/virtualMachines/extensions/write” }, “resourceId”: “…/extensions/my-custom-name-12345”, “status”: { “value”: “Succeeded” } }. This Azure control plane telemetry constitutes a clear example of MITRE ATT&CK technique T1036 (Masquerading). The extension resource name in the resourceId path is an unreliable detection signal. Instead, Sysdig TRT recommends matching on the operation name Microsoft.Compute/virtualMachines/extensions/write to capture all extension deployments regardless of naming.
To read the complete article see: Read full article