Detection rules › Splunk

Azure AD Admin Consent Bypassed by Service Principal

Status
production
Severity
medium
Group by
aws::recipientAccountId, aws::userAgent, dest, roleDescription, roleId, roleValue, signature, src, user, user_id, vendor_product
Author
Mauricio Velazco, Splunk
Source
github.com/splunk/security_content

The following analytic identifies instances where a service principal in Azure Active Directory assigns app roles without standard admin consent. It uses Entra ID logs from the azure_monitor_aad data source, focusing on the "Add app role assignment to service principal" operation. This detection is significant as it highlights potential bypasses of critical administrative consent processes, which could lead to unauthorized privileges being granted. If confirmed malicious, this activity could allow attackers to exploit automation to assign sensitive permissions without proper oversight, potentially compromising the security of the Azure AD environment.

MITRE ATT&CK coverage

Rule body splunk

name: Azure AD Admin Consent Bypassed by Service Principal
id: 9d4fea43-9182-4c5a-ada8-13701fd5615d
version: 12
creation_date: '2024-02-14'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies instances where a service principal in Azure Active Directory assigns app roles without standard admin consent. It uses Entra ID logs from the `azure_monitor_aad` data source, focusing on the "Add app role assignment to service principal" operation. This detection is significant as it highlights potential bypasses of critical administrative consent processes, which could lead to unauthorized privileges being granted. If confirmed malicious, this activity could allow attackers to exploit automation to assign sensitive permissions without proper oversight, potentially compromising the security of the Azure AD environment.
data_source:
    - Azure Active Directory Add app role assignment to service principal
search: "`azure_monitor_aad` (operationName=\"Add app role assignment to service principal\" OR operationName=\"Add member to role*\") src_user_type=servicePrincipal | rename properties.* as * | eval roleId = mvindex('targetResources{}.modifiedProperties{}.newValue',0) | eval roleValue = mvindex('targetResources{}.modifiedProperties{}.newValue',1) | eval roleDescription = mvindex('targetResources{}.modifiedProperties{}.newValue',2) | eval user_id = mvindex('targetResources{}.id', 0), user=coalesce(user,mvindex('targetResources{}.displayName',0)) | rename initiatedBy.app.displayName as src_user, userAgent as user_agent | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by dest user src vendor_account vendor_product src_user user_id roleId roleValue roleDescription user_agent signature | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_admin_consent_bypassed_by_service_principal_filter`"
how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category
known_false_positives: Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed.
references:
    - https://attack.mitre.org/techniques/T1098/003/
drilldown_searches:
    - name: View the detection results for - "$dest$"
      search: '%original_detection_search% | search  dest = "$dest$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$dest$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$dest$") | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: 7d
      latest_offset: "0"
finding:
    title: Service principal $src_user$ bypassed the admin consent process and granted permissions to $user$
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: src_user
          type: user
          score: 50
          message: Service principal $src_user$ bypassed the admin consent process and granted permissions to $user$
analytic_story:
    - Azure Active Directory Privilege Escalation
    - NOBELIUM Group
asset_type: Azure Active Directory
mitre_attack_id:
    - T1098.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: identity
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_bypass_admin_consent/azure_ad_bypass_admin_consent.log
          source: Azure AD
          sourcetype: azure:monitor:aad
      test_type: unit

Stages and Predicates

Stage 1: search

`azure_monitor_aad` (operationName="Add app role assignment to service principal" OR operationName="Add member to role*") src_user_type=servicePrincipal

Stage 2: rename

| rename properties.* as *

Stage 3: eval

| eval roleId = mvindex('targetResources{}.modifiedProperties{}.newValue',0)

Stage 4: eval

| eval roleValue = mvindex('targetResources{}.modifiedProperties{}.newValue',1)

Stage 5: eval

| eval roleDescription = mvindex('targetResources{}.modifiedProperties{}.newValue',2)

Stage 6: eval

| eval user_id = mvindex('targetResources{}.id', 0), user=coalesce(user,mvindex('targetResources{}.displayName',0))

Stage 7: rename

| rename initiatedBy.app.displayName as src_user, userAgent as user_agent

Stage 8: fillnull

| fillnull

Stage 9: stats

| stats count min(_time) as firstTime max(_time) as lastTime by dest user src vendor_account vendor_product src_user user_id roleId roleValue roleDescription user_agent signature

Stage 10: search

| `security_content_ctime(firstTime)`

Stage 11: search

| `security_content_ctime(lastTime)`

Stage 12: search

| `azure_ad_admin_consent_bypassed_by_service_principal_filter`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
operationNameeq
  • "Add app role assignment to service principal"
  • "Add member to role*"
sourcetypeeq
  • azure:monitor:aad
src_user_typeeq
  • servicePrincipal