Entra ID Application Self-Assigned to Privileged Role

Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to other applications.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/10/19"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/10/19"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application
 11typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal 
 12self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and
 13then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to
 14other applications.
 15"""
 16false_positives = [
 17    """
 18    Vendor onboarding or reconfiguration where a consented third-party management or backup application is deliberately
 19    granted a directory role by its own setup workflow. Confirm with the application owner and the change record, then
 20    exclude the specific application ID.
 21    """,
 22    """
 23    Local automation or provisioning applications that are designed to assign roles to themselves. Review the owner and
 24    purpose, then exclude by application ID.
 25    """,
 26]
 27from = "now-9m"
 28language = "esql"
 29license = "Elastic License v2"
 30name = "Entra ID Application Self-Assigned to Privileged Role"
 31note = """## Triage and analysis
 32
 33### Investigating Entra ID Application Self-Assigned to Privileged Role
 34
 35Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application
 36typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal 
 37self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and
 38then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to
 39other applications.
 40
 41#### Possible investigation steps
 42
 43- Identify the application with `azure.auditlogs.properties.initiated_by.app.displayName`, `azure.auditlogs.properties.initiated_by.app.appId` and `Esql.actor_sp_id`, and the role in `Esql.role_name`.
 44- Determine the owner tenant. In Entra, open Enterprise applications and check the application's owner organization, or look up `app_owner_tenant_id` on its service principal sign-ins. A multi-tenant vendor app owned by another tenant that promotes itself is the highest-risk case.
 45- Pull the service principal sign-ins for the same application around the alert. Compare source addresses and user agents against the application's expected egress. Hosting-provider or VPN addresses and scripting clients such as Python or curl are suspicious for an application that normally runs in its vendor's cloud.
 46- Pull the audit log for the same service principal around the alert: `Add service principal credentials`, `Update application – Certificates and secrets management`, `Add app role assignment to service principal`, `Add owner to application`.
 47- Review what the application did with the new role: mailbox, SharePoint, Teams and Graph activity, and any directory changes.
 48- Check whether the same application ID exists in other tenants you manage; a compromised vendor credential can be used against many tenants in a short time.
 49
 50### False positive analysis
 51
 52- Vendor-initiated role grants during a documented onboarding or migration.
 53- Local provisioning or automation applications that assign roles to themselves by design.
 54
 55### Response and remediation
 56
 57- Disable the application (do not delete it, so the configuration and evidence are preserved) and remove the role assignment.
 58- Revoke sessions and review all credentials added to applications since the assignment.
 59- Review and remove client secrets, certificates and federated credentials you did not create.
 60- Follow the vendor's advisory for credential rotation before re-enabling the application.
 61"""
 62references = [
 63    "https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access",
 64    "https://www.todyl.com/blog/investigation-unauthorized-access-through-the-connectwise-cloud-backup-microsoft-365-app",
 65    "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference",
 66    "https://trustedsec.com/blog/managing-privileged-roles-in-microsoft-entra-id-a-pragmatic-approach",
 67]
 68risk_score = 73
 69rule_id = "a069c60c-06c5-4b73-be9d-9f2201e020d4"
 70severity = "high"
 71tags = [
 72    "Domain: Cloud",
 73    "Domain: Identity",
 74    "Data Source: Azure",
 75    "Data Source: Microsoft Entra ID",
 76    "Data Source: Microsoft Entra ID Audit Logs",
 77    "Use Case: Identity and Access Audit",
 78    "Use Case: Threat Detection",
 79    "Tactic: Privilege Escalation",
 80    "Tactic: Persistence",
 81    "Resources: Investigation Guide",
 82    "Rule Type: ES|QL",
 83    "Platform: Entra ID",
 84    "Profile: Beta"
 85]
 86timestamp_override = "event.ingested"
 87type = "esql"
 88
 89query = '''
 90from logs-azure.auditlogs-* metadata _id, _version, _index
 91// role assignments performed by an application (service principal actor)
 92| where data_stream.dataset == "azure.auditlogs"
 93  and azure.auditlogs.operation_name in (
 94    "Add member to role",
 95    "Add member to role outside of PIM (permanent)",
 96    "Add member to role in PIM completed (permanent)",
 97    "Add member to role in PIM completed (timebound)",
 98    "Add eligible member to role in PIM completed (permanent)",
 99    "Add eligible member to role in PIM completed (timebound)"
100  )
101  and event.outcome in ("success", "Success")
102  and azure.auditlogs.properties.initiated_by.app.servicePrincipalId is not null
103// self-assignment: the acting service principal is the member being added
104| eval Esql.actor_sp_id = azure.auditlogs.properties.initiated_by.app.servicePrincipalId
105| where Esql.actor_sp_id == `azure.auditlogs.properties.target_resources.0.id`
106    or Esql.actor_sp_id == `azure.auditlogs.properties.target_resources.1.id`
107// the role name sits in a different modified_properties slot depending on the operation
108| eval Esql.role_name_raw = coalesce(
109    case(`azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, null),
110    case(`azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`, null),
111    case(`azure.auditlogs.properties.target_resources.0.modified_properties.2.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`, null),
112    case(`azure.auditlogs.properties.target_resources.0.modified_properties.3.display_name` == "Role.DisplayName", `azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`, null)
113  )
114| eval Esql.role_name = replace(Esql.role_name_raw, "\"", "")
115// privileged roles: every built-in role marked PRIVILEGED in the Microsoft Entra built-in roles reference, plus other
116// built-in roles with administrative control over major Entra and Microsoft 365 services or access to tenant data.
117// Matched by exact role name, not by pattern.
118| where to_lower(Esql.role_name) in (
119    // marked PRIVILEGED by Microsoft
120    "agent id administrator", "ai administrator", "ai reader", "application administrator", "application developer",
121    "attribute provisioning administrator", "attribute provisioning reader", "authentication administrator",
122    "authentication extensibility administrator", "authentication extensibility password administrator",
123    "b2c ief keyset administrator", "cloud application administrator", "cloud device administrator",
124    "conditional access administrator", "directory writers", "domain name administrator",
125    "entra soc identity responder", "external identity provider administrator", "global administrator",
126    "global reader", "helpdesk administrator", "hybrid identity administrator", "identity governance administrator",
127    "intune administrator", "lifecycle workflows administrator", "partner tier1 support", "partner tier2 support",
128    "password administrator", "privileged authentication administrator", "privileged role administrator",
129    "security administrator", "security operator", "security reader", "tenant governance administrator",
130    "user administrator",
131    // not marked privileged by Microsoft, but with administrative control over major services
132    "attribute assignment administrator", "authentication policy administrator", "cloud app security administrator",
133    "compliance administrator", "directory synchronization accounts", "dynamics 365 administrator",
134    "exchange administrator", "external id user flow administrator", "global secure access administrator",
135    "groups administrator", "knowledge administrator", "microsoft 365 backup administrator",
136    "microsoft 365 migration administrator", "on premises directory sync account", "power platform administrator",
137    "sharepoint administrator", "skype for business administrator", "teams administrator",
138    "teams telephony administrator", "windows 365 administrator", "yammer administrator",
139    // additional roles: mailbox permissions, local administrator on joined devices (current and previous display
140    // name), delegated partner access to the tenant, and approval of Microsoft support access to customer data
141    "exchange recipient administrator", "azure ad joined device local administrator",
142    "microsoft entra joined device local administrator", "customer delegated admin relationship administrator",
143    "customer lockbox access approver", "entra customer lockbox approver",
144    // legacy display name of Global Administrator
145    "company administrator"
146  )
147| drop Esql.role_name_raw
148| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace
149'''
150
151[rule.investigation_fields]
152field_names = [
153    "Esql.actor_sp_id",
154    "Esql.role_name",
155    "azure.auditlogs.operation_name",
156    "azure.auditlogs.properties.initiated_by.app.displayName",
157    "azure.auditlogs.properties.initiated_by.app.appId",
158    "azure.tenant_id",
159]
160
161[[rule.threat]]
162framework = "MITRE ATT&CK"
163
164[[rule.threat.technique]]
165id = "T1078"
166name = "Valid Accounts"
167reference = "https://attack.mitre.org/techniques/T1078/"
168
169[[rule.threat.technique.subtechnique]]
170id = "T1078.004"
171name = "Cloud Accounts"
172reference = "https://attack.mitre.org/techniques/T1078/004/"
173
174[[rule.threat.technique]]
175id = "T1098"
176name = "Account Manipulation"
177reference = "https://attack.mitre.org/techniques/T1098/"
178
179[[rule.threat.technique.subtechnique]]
180id = "T1098.003"
181name = "Additional Cloud Roles"
182reference = "https://attack.mitre.org/techniques/T1098/003/"
183
184[rule.threat.tactic]
185id = "TA0004"
186name = "Privilege Escalation"
187reference = "https://attack.mitre.org/tactics/TA0004/"
188
189[[rule.threat]]
190framework = "MITRE ATT&CK"
191
192[[rule.threat.technique]]
193id = "T1078"
194name = "Valid Accounts"
195reference = "https://attack.mitre.org/techniques/T1078/"
196
197[[rule.threat.technique.subtechnique]]
198id = "T1078.004"
199name = "Cloud Accounts"
200reference = "https://attack.mitre.org/techniques/T1078/004/"
201
202[[rule.threat.technique]]
203id = "T1098"
204name = "Account Manipulation"
205reference = "https://attack.mitre.org/techniques/T1098/"
206
207[[rule.threat.technique.subtechnique]]
208id = "T1098.003"
209name = "Additional Cloud Roles"
210reference = "https://attack.mitre.org/techniques/T1098/003/"
211
212[rule.threat.tactic]
213id = "TA0003"
214name = "Persistence"
215reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating Entra ID Application Self-Assigned to Privileged Role

Identifies an Entra ID application (service principal) assigning itself to a privileged directory role. An application typically does not promote itself, and a multi-tenant vendor application is even more uncommon. Any service principal self-assigning a privileged role should be investigated. Adversaries may compromise vendor application credentials and then escalate privileges to Exchange Administrator or Global Administrator, or subsequently add client secrets to other applications.

Possible investigation steps

  • Identify the application with azure.auditlogs.properties.initiated_by.app.displayName, azure.auditlogs.properties.initiated_by.app.appId and Esql.actor_sp_id, and the role in Esql.role_name.
  • Determine the owner tenant. In Entra, open Enterprise applications and check the application's owner organization, or look up app_owner_tenant_id on its service principal sign-ins. A multi-tenant vendor app owned by another tenant that promotes itself is the highest-risk case.
  • Pull the service principal sign-ins for the same application around the alert. Compare source addresses and user agents against the application's expected egress. Hosting-provider or VPN addresses and scripting clients such as Python or curl are suspicious for an application that normally runs in its vendor's cloud.
  • Pull the audit log for the same service principal around the alert: Add service principal credentials, Update application – Certificates and secrets management, Add app role assignment to service principal, Add owner to application.
  • Review what the application did with the new role: mailbox, SharePoint, Teams and Graph activity, and any directory changes.
  • Check whether the same application ID exists in other tenants you manage; a compromised vendor credential can be used against many tenants in a short time.

False positive analysis

  • Vendor-initiated role grants during a documented onboarding or migration.
  • Local provisioning or automation applications that assign roles to themselves by design.

Response and remediation

  • Disable the application (do not delete it, so the configuration and evidence are preserved) and remove the role assignment.
  • Revoke sessions and review all credentials added to applications since the assignment.
  • Review and remove client secrets, certificates and federated credentials you did not create.
  • Follow the vendor's advisory for credential rotation before re-enabling the application.

References

Related rules

to-top