Skip to content

[New Rule] Azure Subscription Permission Elevation #1630

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #1872
austinsonger opened this issue Nov 26, 2021 · 4 comments · Fixed by #4742
Closed
Tracked by #1872

[New Rule] Azure Subscription Permission Elevation #1630

austinsonger opened this issue Nov 26, 2021 · 4 comments · Fixed by #4742
Assignees
Labels

Comments

@austinsonger
Copy link
Contributor

austinsonger commented Nov 26, 2021

Description

Identifies when a user has been elevated to manage all Azure Subscriptions. This setting could allow an attacker access to Azure subscriptions in your environment.

Required Info

Target indexes

filebeat-*, logs-azure*

Platforms

Azure

Optional Info

Query

(event.dataset:azure.activitylogs and 
azure.activitylogs.operation_name: "MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION" and 
event.outcome:(Success or success)) or
(event.dataset:azure.auditlogs and azure.auditlogs.operation_name: "Assigns the caller to user access admin" and 
event.outcome:(Success or success))

New fields required in ECS/data sources for this rule?

Related issues or PRs

False Positives

MITRE

Tactic Technique ID Technique Name Sub-Technique Name

References

@botelastic
Copy link

botelastic bot commented Jan 25, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@botelastic botelastic bot added the stale 60 days of inactivity label Jan 25, 2022
@w0rk3r w0rk3r removed the stale 60 days of inactivity label Jan 31, 2022
@botelastic
Copy link

botelastic bot commented Apr 1, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@botelastic botelastic bot added the stale 60 days of inactivity label Apr 1, 2022
@botelastic
Copy link

botelastic bot commented Apr 8, 2022

This has been closed due to inactivity. If you feel this is an error, please re-open and include a justifying comment.

@terrancedejesus
Copy link
Contributor

terrancedejesus commented May 22, 2025

👋🏽 Hey @austinsonger. Thanks for opening this request. After further review and reading a recent Permiso blog, I agree this is a decent signal of privilege escalation into Azure resources if a global admin in Entra ID is compromised. As a result, I've opened a new PR and linked it to this issue.

As you are aware, global admins in Entra ID do not always transfer RBAC to Azure subscriptions that may exist as they are intentionally separated. However, a global admin can elevate their privileges to control subscriptions via a simple toggle in Entra ID. While I did not find a great example of this in-the-wild via OSINT - Permiso has a decent blog covering this from red-team perspective - https://permiso.io/blog/azures-apex-permissions-elevate-access-the-logs-security-teams-overlook

As a side note, when I replicated this and reviewed telemetry, I noticed this was only logged for us in Entra ID audit logs where the query was

event.dataset: azure.auditlogs and azure.auditlogs.operation_name: "User has elevated their access to User Access Administrator for their Azure Resources"

We will keep the query to Entra ID audit logs only for now to allow the opportunity for tuning if necessary on a single data source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment