Why treat a single successful role assignment as critical?

Because Microsoft.Authorization/roleAssignments/write is how every RBAC grant in Azure happens, including granting Owner or Contributor on a resource group or subscription. In the validation sample, attacker@external.com is granted Owner on prod-rg — a durable, subscription-wide privilege that survives a password reset and needs no further exploitation to use. Legitimate role grants are planned, ticketed, and performed by a known IAM admin; an unplanned one succeeding is the clearest sign a foothold is being converted into standing access.

Why group a Key Vault secret delete with a VM delete under one rule instead of two separate ones?

Because they are the same move at different layers — destroying something the defender needs once privilege has already been obtained. Deleting db-password from prod-kv removes a credential (and any record of what it was), while deleting the prod-app-01 VM destroys the host itself, along with whatever forensic evidence lived on its disk. Both are irreversible without a backup, both are rare in normal operations, and both show up as the same shape in the log: a *delete operationName with status: Succeeded. Treating them as one 'destructive sabotage' rule keeps the detection narrow without needing three separate alerts for what is functionally one failure mode.

Doesn't a VM or secret get deleted during normal cleanup?

Occasionally, which is why the false positives list calls out decommissioning runbooks explicitly. The distinguishing factor is correlation: a legitimate teardown comes from a known automation principal or admin, during a known maintenance window, usually alongside other expected ARM operations (deallocate, disk cleanup, DNS record removal). The validation sample has none of that context — a single external-looking caller granting itself Owner, then deleting a secret, then deleting a production VM, all within two minutes, with no prior resource-group activity from that principal.

Should I correlate the three selections by caller, or alert on each independently?

Both, for the same reason as other control-plane takeover rules in this library: each operation is individually rare enough to alert on alone, so don't wait for the full sequence before responding to the first one. But correlating by caller and clientIpAddress turns three isolated alerts into one high-confidence incident — in the sample, the same caller (attacker@external.com) performs the role grant and the secret delete from 185.220.101.42, then the VM delete from 45.142.212.100 two minutes later, which is exactly the grant-then-destroy pattern this rule exists to catch.

CRITICAL Azure ARM Activity Log Privilege Escalation & Destructive Sabotage LTR-0022 ✓ validated

Detect Privilege Escalation and Destructive Sabotage in Azure Activity Logs

Published October 12, 2026

MITRE ATT&CK: T1098.003 T1485

Sigma Rule

title: Azure Activity Log — Privilege Escalation and Destructive Sabotage
id: 23e56145-36f5-4e22-b3d5-f8df05fba9a6
status: experimental
description: >
  Detects the three highest-impact control-plane operations an attacker
  performs once they hold a foothold in an Azure subscription: granting a new
  role assignment (durable privilege), deleting a Key Vault secret (destroying
  credentials or covering tracks), and deleting a virtual machine (destructive
  impact). Each is independently rare and meaningful in a healthy environment,
  so any one of them succeeding is worth an alert on its own.
references:
  - https://attack.mitre.org/techniques/T1098/003/
  - https://attack.mitre.org/techniques/T1485/
author: LogTriage
date: 2026/10/12
logsource:
  product: azure
  service: azure.activitylogs
detection:
  role_assignment_grant:
    operationName: 'Microsoft.Authorization/roleAssignments/write'
    status: 'Succeeded'
  keyvault_secret_delete:
    operationName: 'Microsoft.KeyVault/vaults/secrets/delete'
    status: 'Succeeded'
  vm_delete:
    operationName: 'Microsoft.Compute/virtualMachines/delete'
    status: 'Succeeded'
  condition: role_assignment_grant or keyvault_secret_delete or vm_delete
falsepositives:
  - Planned, ticketed role grant during onboarding or break-glass access by a known admin
  - Decommissioning runbook deleting a retired VM and its associated secrets together
level: critical
tags:
  - attack.privilege_escalation
  - attack.impact
  - attack.t1098.003
  - attack.t1485

What this rule detects

Once an attacker has a foothold in an Azure subscription, three control-plane operations do more damage than almost anything else they can do: grant themselves a durable role, delete a secret, and delete a VM. All three appear in the Azure ARM Activity Log as a Microsoft.{Provider}/{resource}/{write|delete} operationName with status: Succeeded.

This rule fires on any one of:

Microsoft.Authorization/roleAssignments/write — a new RBAC role assignment succeeded (privilege escalation / persistence).
Microsoft.KeyVault/vaults/secrets/delete — a Key Vault secret was deleted (credential destruction / anti-forensics).
Microsoft.Compute/virtualMachines/delete — a virtual machine was deleted (destructive impact).

Detection logic

Each selection is narrow: a specific operationName combined with status: Succeeded, so a failed (denied) attempt at any of these — which Azure RBAC should produce for an attacker without existing elevated access — does not fire the rule. Only a successful operation does, because a denied attempt is a control working as intended, while a success is the control having already failed.

The three are joined with or rather than folded into a single threshold, matching the pattern used elsewhere in this library for independently rare, high-signal events (see the Duo MFA fatigue rule and the Google Workspace admin-takeover rule): each operation alone justifies an alert, and requiring all three before firing would mean missing an attacker who only gets through one of them before being stopped.

Validated against a real sample

Validated against azure_activity_attack.json (shipped with LogTriage), which contains the full chain from a single external caller:

attacker@external.com granted Owner on prod-rg via roleAssignments/write, from 185.220.101.42
The same caller deleting the db-password secret from prod-kv one minute later, from the same IP
The same caller deleting the prod-app-01 virtual machine two minutes after that, from a second IP (45.142.212.100)

The rule fires on all three events and stays silent on the matching benign log, which contains only virtualMachines/start, storageAccounts/write, and deployments/write operations from alice@corp.com and bob@corp.com — no role assignments and no deletes of any kind.

False positives

The quiet, expected version of each operation comes from a known admin or automation principal, inside a change window, usually bundled with other ordinary ARM activity. A planned role grant during onboarding, or a decommissioning runbook that deletes a retired VM and its associated secrets together, are the two recurring legitimate cases — both should correlate with a ticket and a recognizable caller, which an attacker’s freshly-used or external account will not have.

Frequently Asked Questions

Why treat a single successful role assignment as critical?: Because Microsoft.Authorization/roleAssignments/write is how every RBAC grant in Azure happens, including granting Owner or Contributor on a resource group or subscription. In the validation sample, attacker@external.com is granted Owner on prod-rg — a durable, subscription-wide privilege that survives a password reset and needs no further exploitation to use. Legitimate role grants are planned, ticketed, and performed by a known IAM admin; an unplanned one succeeding is the clearest sign a foothold is being converted into standing access.
Why group a Key Vault secret delete with a VM delete under one rule instead of two separate ones?: Because they are the same move at different layers — destroying something the defender needs once privilege has already been obtained. Deleting db-password from prod-kv removes a credential (and any record of what it was), while deleting the prod-app-01 VM destroys the host itself, along with whatever forensic evidence lived on its disk. Both are irreversible without a backup, both are rare in normal operations, and both show up as the same shape in the log: a *delete operationName with status: Succeeded. Treating them as one 'destructive sabotage' rule keeps the detection narrow without needing three separate alerts for what is functionally one failure mode.
Doesn't a VM or secret get deleted during normal cleanup?: Occasionally, which is why the false positives list calls out decommissioning runbooks explicitly. The distinguishing factor is correlation: a legitimate teardown comes from a known automation principal or admin, during a known maintenance window, usually alongside other expected ARM operations (deallocate, disk cleanup, DNS record removal). The validation sample has none of that context — a single external-looking caller granting itself Owner, then deleting a secret, then deleting a production VM, all within two minutes, with no prior resource-group activity from that principal.
Should I correlate the three selections by caller, or alert on each independently?: Both, for the same reason as other control-plane takeover rules in this library: each operation is individually rare enough to alert on alone, so don't wait for the full sequence before responding to the first one. But correlating by caller and clientIpAddress turns three isolated alerts into one high-confidence incident — in the sample, the same caller (attacker@external.com) performs the role grant and the secret delete from 185.220.101.42, then the VM delete from 45.142.212.100 two minutes later, which is exactly the grant-then-destroy pattern this rule exists to catch.

Related Resources

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs