From 2931d75692bf07cbdeb1c349bfbde4d082e7f0ea Mon Sep 17 00:00:00 2001
From: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Date: Mon, 6 Oct 2025 09:38:56 -0400
Subject: [PATCH] [New Rule] Azure RBAC Built-In Administrator Roles Assigned
 (#5113)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* [New Rule] Azure RBAC Built-In Administrator Roles Assigned
<!--
Thank you for your interest in and contributing to Detection Rules!
There are a few simple things to check before submitting your pull request
that can help with the review process. You should delete these items
from your submission, but they are here to help bring them to your attention.
-->
# Pull Request

*Issue link(s)*:
* https://github.com/elastic/detection-rules/issues/5108

<!--
  Add Related Issues / PRs for context. Eg:
    Related to elastic/repo#999
    Resolves #123
  If there is no issue link, take extra care to write a clear summary and label the PR just as you would label an issue to give additional context to reviewers.
-->

## Summary - What I changed
Adds a new rule for detecting `Azure RBAC Built-In Administrator Roles Assigned` from Azure Activity Logs. Please se issue for more details.

<!--
  Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->

## How To Test
Query can be used in TRADE serverless stack.

<!--
  Some examples of what you could include here are:
  * Links to GitHub action results for CI test improvements
  * Sample data before/after screenshots (or short videos showing how something works)
  * Copy/pasted commands and output from the testing you did in your local terminal window
  * If tests run in GitHub, you can 🪁or 🔱, respectively, to indicate tests will run in CI
  * Query used in your stack to verify the change
-->

## Checklist

<!-- Delete any items that are not applicable to this PR. -->

- [ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
- [ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours
- [ ] Secret and sensitive material has been managed correctly
- [ ] Automated testing was updated or added to match the most common scenarios
- [ ] Documentation and comments were added for features that require explanation

## Contributor checklist

- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/detection-rules/blob/main/CONTRIBUTING.md)?

* fixed query logic

* fixed query logc

* fixed query logic

* adding field to non-ecs

* updated UUID
---
 detection_rules/etc/non-ecs-schema.json       |   1 +
 ...ure_rbac_administrator_roles_assigned.toml | 110 ++++++++++++++++++
 2 files changed, 111 insertions(+)
 create mode 100644 rules/integrations/azure/privilege_escalation_azure_rbac_administrator_roles_assigned.toml

diff --git a/detection_rules/etc/non-ecs-schema.json b/detection_rules/etc/non-ecs-schema.json
index 2087ee7f4..f177b914e 100644
--- a/detection_rules/etc/non-ecs-schema.json
+++ b/detection_rules/etc/non-ecs-schema.json
@@ -201,6 +201,7 @@
     "azure.activitylogs.properties.appId": "keyword",
     "azure.activitylogs.properties.resourceDisplayName": "keyword",
     "azure.activitylogs.properties.appDisplayName": "keyword",
+    "azure.activitylogs.properties.requestbody.properties.roleDefinitionId": "keyword",
     "azure.activitylogs.properties.responseBody": "keyword"
   },
   "logs-azure.graphactivitylogs-*": {
diff --git a/rules/integrations/azure/privilege_escalation_azure_rbac_administrator_roles_assigned.toml b/rules/integrations/azure/privilege_escalation_azure_rbac_administrator_roles_assigned.toml
new file mode 100644
index 000000000..de9b0f235
--- /dev/null
+++ b/rules/integrations/azure/privilege_escalation_azure_rbac_administrator_roles_assigned.toml
@@ -0,0 +1,110 @@
+[metadata]
+creation_date = "2025/09/15"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure RBAC Built-In Administrator Roles Assigned"
+note = """## Triage and Analysis
+
+### Investigating Azure RBAC Built-In Administrator Roles Assigned
+
+This rule identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. Assignment can be done via the Azure portal, Azure CLI, PowerShell, or through API calls. Monitoring these assignments helps detect potential unauthorized privilege escalations.
+
+#### Privileged Built-In Administrator Roles
+- Contributor: b24988ac-6180-42a0-ab88-20f7382dd24c
+- Owner: 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
+- Azure File Sync Administrator: 92b92042-07d9-4307-87f7-36a593fc5850
+- Reservations Administrator: a8889054-8d42-49c9-bc1c-52486c10e7cd
+- Role Based Access Control Administrator: f58310d9-a9f6-439a-9e8d-f62e7b41a168
+- User Access Administrator: 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9
+
+### Possible investigation steps
+
+- Identify the user who assigned the role and examine their recent activity for any suspicious actions.
+- Review the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
+- Check the history of role assignments for the user who was assigned the role to determine if this is a recurring pattern or a one-time event.
+    - Additionally, identify the lifetime of the targeted user account to determine if it is a newly created account or an existing one.
+- Determine if the user assigning the role historically has the necessary permissions to assign such roles and has done so in the past.
+- Investigate any recent changes or activities performed by the newly assigned administrator to identify any suspicious actions or configurations that may have been altered.
+- Correlate with other logs, such as Microsoft Entra ID sign-in logs, to identify any unusual access patterns or behaviors for the user.
+
+### False positive analysis
+
+- Legitimate administrators may assign built-in administrator roles during routine operations, maintenance or as required for onboarding new staff.
+- Review internal tickets, change logs, or admin activity dashboards for approved operations.
+
+### Response and remediation
+
+- If administrative assignment was not authorized:
+  - Immediately remove the built-in administrator role from the account.
+  - Disable or lock the account and begin credential rotation.
+  - Audit activity performed by the account after elevation, especially changes to role assignments and resource access.
+- If suspicious:
+  - Notify the user and confirm whether they performed the action.
+  - Check for any automation or scripts that could be exploiting unused elevated access paths.
+  - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval.
+- Strengthen posture:
+  - Require MFA and approval for all privilege escalation actions.
+  - Consider enabling JIT (Just-in-Time) access with expiration.
+"""
+references = [
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles",
+    "https://orca.security/resources/research-pod/azure-identity-access-management-iam-active-directory-ad/",
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/"
+]
+risk_score = 73
+rule_id = "1a1046f4-9257-11f0-9a42-f661ea17fbce"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: azure.activitylogs and
+    event.action: "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" and
+    azure.activitylogs.properties.requestbody.properties.roleDefinitionId:
+    (
+      *18d7d88d-d35e-4fb5-a5c3-7773c20a72d9* or
+      *f58310d9-a9f6-439a-9e8d-f62e7b41a168* or
+      *b24988ac-6180-42a0-ab88-20f7382dd24c* or
+      *8e3af657-a8ff-443c-a75c-2fe8c4bcb635* or
+      *92b92042-07d9-4307-87f7-36a593fc5850* or
+      *a8889054-8d42-49c9-bc1c-52486c10e7cd*
+  )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.003"
+name = "Additional Cloud Roles"
+reference = "https://attack.mitre.org/techniques/T1098/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"