Why these two roles, and what are the IDs in the rule?

Owner and User Access Administrator are the built-in roles that can assign roles, so whoever holds one can grant themselves or anyone else any access in that scope. Built-in role definition IDs are the same in every tenant: Owner is 8e3af657-a8ff-443c-a75c-2fe8c4bcb635 and User Access Administrator is 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9. Microsoft's own alert query for privileged assignments also watches Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c); add it if Contributor grants are rare in your environment.

Why match the Started event instead of Succeeded?

Because that is where the role is. The Activity log records the request body, including RoleDefinitionId, PrincipalId and Scope, on the Started event of roleAssignments/write, and Microsoft's alert query reads it there (it filters on a status of Start or Started). The Succeeded event follows with the same correlation ID; join on correlationId if you need to confirm the grant went through. An attempt is worth an alert either way.

Why not alert on every role assignment?

Because role assignments are routine: every deployment pipeline, managed identity and access request produces them, and an alert on all of them gets ignored. Assignments of Owner and User Access Administrator are rare by comparison, and they are the ones that turn a foothold into standing control over everything in the scope.

What else in the sample shows how this grant gets used?

What the same caller does next. Two minutes after the Owner grant, attacker@external.com changes the access policies of the prod-kv Key Vault (the step that lets an identity read its secrets) and then deletes the virtual machine prod-app-01, the last from a different address. Neither later step is part of this rule, but correlating by caller turns the grant into the start of an incident rather than an isolated change.

Detect Owner and User Access Administrator Role Assignments in Azure Activity Logs

Published October 12, 2026 · Updated October 20, 2026

MITRE ATT&CK: T1098.003

Sigma Rule

title: Azure Owner or User Access Administrator Role Assignment
id: 23e56145-36f5-4e22-b3d5-f8df05fba9a6
status: experimental
description: >
  Detects an attempt to assign one of the two Azure built-in roles that grant
  control over role assignments themselves: Owner and User Access
  Administrator. The Activity log records the role in the request body of the
  Started event of Microsoft.Authorization/roleAssignments/write, which is
  where Microsoft's own alert query for privileged role assignments reads it.
references:
  - https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-alert
  - https://attack.mitre.org/techniques/T1098/003/
author: LogTriage
date: 2026/10/12
modified: 2026/10/20
logsource:
  product: azure
  service: activitylogs
detection:
  role_assignment_started:
    operationName: 'Microsoft.Authorization/roleAssignments/write'
    status:
      - 'Started'
      - 'Start'
  privileged_role:
    properties.requestbody|contains:
      - '8e3af657-a8ff-443c-a75c-2fe8c4bcb635'
      - '18d7d88d-d35e-4fb5-a5c3-7773c20a72d9'
  condition: role_assignment_started and privileged_role
falsepositives:
  - Planned privileged grants by a known IAM administrator
  - Subscription bootstrap automation assigning Owner to a platform identity
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1098.003

What this rule detects

Every Azure RBAC grant is a Microsoft.Authorization/roleAssignments/write operation. Most are routine. This rule fires on the ones that hand over control of access itself: an attempt to assign Owner or User Access Administrator, at any scope.

Detection logic

Two selections, both required:

role_assignment_started: the operation is Microsoft.Authorization/roleAssignments/write with a status of Started (raw Activity log) or Start (the ActivityStatusValue in Log Analytics). That event carries the request body.
privileged_role: the request body names the Owner role (8e3af657-a8ff-443c-a75c-2fe8c4bcb635) or the User Access Administrator role (18d7d88d-d35e-4fb5-a5c3-7773c20a72d9). Built-in role definition IDs are the same in every tenant, so the rule needs no lookup.

The condition is role_assignment_started and privileged_role.

Validated against a real sample

Validated against azure_activity_attack.json (shipped with LogTriage). The caller [email protected], from 185.220.101.42, assigns the Owner role at subscription scope (/subscriptions/abc123): a Started event whose request body carries the Owner role definition ID, followed by the matching Succeeded event. The rule fires on the Started event.

The same caller then changes the access policies of the prod-kv Key Vault and deletes a virtual machine. Those events are context, not part of this rule.

It stays silent on azure_activity_normal.json: a virtual machine start, a storage account update and a template deployment, all routine and none a role assignment.

False positives

Planned privileged grants exist: an IAM administrator onboarding a new subscription owner, or bootstrap automation assigning Owner to a platform identity. They come from known callers and usually match a change ticket. Exclude the automation’s caller rather than the role, and keep alerting on everyone else.

Frequently Asked Questions

Why these two roles, and what are the IDs in the rule?: Owner and User Access Administrator are the built-in roles that can assign roles, so whoever holds one can grant themselves or anyone else any access in that scope. Built-in role definition IDs are the same in every tenant: Owner is 8e3af657-a8ff-443c-a75c-2fe8c4bcb635 and User Access Administrator is 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9. Microsoft's own alert query for privileged assignments also watches Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c); add it if Contributor grants are rare in your environment.
Why match the Started event instead of Succeeded?: Because that is where the role is. The Activity log records the request body, including RoleDefinitionId, PrincipalId and Scope, on the Started event of roleAssignments/write, and Microsoft's alert query reads it there (it filters on a status of Start or Started). The Succeeded event follows with the same correlation ID; join on correlationId if you need to confirm the grant went through. An attempt is worth an alert either way.
Why not alert on every role assignment?: Because role assignments are routine: every deployment pipeline, managed identity and access request produces them, and an alert on all of them gets ignored. Assignments of Owner and User Access Administrator are rare by comparison, and they are the ones that turn a foothold into standing control over everything in the scope.
What else in the sample shows how this grant gets used?: What the same caller does next. Two minutes after the Owner grant, [email protected] changes the access policies of the prod-kv Key Vault (the step that lets an identity read its secrets) and then deletes the virtual machine prod-app-01, the last from a different address. Neither later step is part of this rule, but correlating by caller turns the grant into the start of an incident rather than an isolated change.

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