Caller-Controlled Azure VM Extension Names Can Evade Password-Reset Detection

Summary

Sysdig TRT demonstrated that a custom Azure VM extension name can bypass name-based password-reset alerts. Successful extension-write logs omit the publisher and type, and Microsoft’s documented validation event did not appear in testing. Microsoft said this is not a se

Key points

Sysdig TRT successfully reset a Linux VM password using VMAccess deployed under the custom resource name my-custom-name-12345; the expected detection alert did not fire.
Azure extension resource names are caller-controlled, so matching only known names such as enablevmAccess, VMAccessForLinux, or VMAccessAgent can be bypassed.
Successful extension-write activity logs show the generic Microsoft.Compute/virtualMachines/extensions/write operation and resource name, but not the extension publisher or type.
In Sysdig’s April 2026 testing, the Microsoft.Resources/deployments/validate/action event described in Microsoft’s Azure Threat Matrix guidance did not occur.
Sysdig recommends monitoring extension-write operations and correlating with Azure Resource Graph or the Extensions API to identify the actual publisher and type.
Microsoft told Sysdig the issue is not considered a security vulnerability because resource names are user-specified.

Article Details

Attack Vectors: An attacker with permission to write VM extensions can use VMAccess to reset a VM password or SSH key and choose an arbitrary extension resource name, evading detections that match known names.
The successful extension write appears in the activity log as the generic Microsoft.Compute/virtualMachines/extensions/write operation; the log does not include the extension publisher or type.
Sysdig TRT reported that the Azure Threat Matrix validation telemetry did not fire during its tests.
Defensive Notes: Detect Microsoft.Compute/virtualMachines/extensions/write operations rather than relying on known extension resource names; expect this to generate false positives.
Correlate extension writes with Azure Resource Graph or the Extensions API to check the installed extension's publisher and type.
Investigate any extension deployment on sensitive VMs, regardless of its resource name.
Configure host and network logging on each VM if those logs are needed; the article says they are not passed to Azure by default.

MITRE ATT&CK

T1036 · MasqueradingThe article identifies masquerading through an arbitrary, potentially benign-looking VM extension resource name that evades name-based password-reset detection.

Vendors

MicrosoftMicrosoft said this is not a security vulnerability, but the report shows the issue affects Azure VMAccess, Azure Portal, Azure CLI, and the Azure Threat Matrix guidance.SysdigSysdig TRT found that Azure VM password reset telemetry can be evaded because VM extension names are caller-controlled, letting an attacker rename VMAccess deployments and reset credentials without triggering expected

Products

AzureSysdig TRT found that Azure VM password reset telemetry can be evaded because VM extension names are caller-controlled, letting an attacker rename VMAccess deployments and reset credentials without triggering expected Azure CLIMicrosoft said this is not a security vulnerability, but the report shows the issue affects Azure VMAccess, Azure Portal, Azure CLI, and the Azure Threat Matrix guidance.Azure PortalMicrosoft said this is not a security vulnerability, but the report shows the issue affects Azure VMAccess, Azure Portal, Azure CLI, and the Azure Threat Matrix guidance.Azure Resource GraphRecommended detection should rely on extension write operations, Azure Resource Graph, or the Extensions API rather than resource-name matching alone.Azure VMAccessMicrosoft said this is not a security vulnerability, but the report shows the issue affects Azure VMAccess, Azure Portal, Azure CLI, and the Azure Threat Matrix guidance.Sysdig SecureFurthermore, enterprise cloud security tools like Sysdig Secure ship detection rules that alert on suspicious extension deployments.