T1098.003 Splunk · SPL

Detect Additional Cloud Roles in Splunk

An adversary may add additional roles or permissions to an adversary-controlled cloud account to maintain persistent access to a tenant. For example, adversaries may update IAM policies in cloud-based environments or add a new global administrator in Office 365 environments. With sufficient permissions, a compromised account can gain almost unlimited access to data and settings, including the ability to reset the passwords of other admins. This account modification may immediately follow account creation or other malicious account activity. Adversaries may also modify existing valid accounts that they have compromised, potentially leading to privilege escalation and lateral movement to additional accounts. In some cases, adversaries may add roles to adversary-controlled accounts outside the victim cloud tenant, allowing external accounts to perform actions inside the victim tenant. Threat groups such as Scattered Spider, LAPSUS$, and Storm-0501 have used this technique to gain persistent administrative access to cloud environments.

MITRE ATT&CK

Tactic
Persistence Privilege Escalation
Technique
T1098 Account Manipulation
Sub-technique
T1098.003 Additional Cloud Roles
Canonical reference
https://attack.mitre.org/techniques/T1098/003/

SPL Detection Query

Splunk (SPL)
spl
index=azure_audit OR index=o365 OR index=azure_activity
(
  sourcetype="azure:aad:audit"
  OR sourcetype="o365:management:activity"
  OR sourcetype="azure:activity"
)
| eval operation=coalesce('Operation', 'operationName', 'OperationName')
| eval initiated_by=coalesce('UserId', 'InitiatedBy.user.userPrincipalName', 'Caller', 'Actor{}.ID')
| eval target_user=coalesce('ObjectId', 'TargetResources{}.userPrincipalName', 'Target{}.ID')
| eval role_assigned=coalesce('ModifiedProperties{}.NewValue', 'TargetResources{}.modifiedProperties{}.newValue', 'role')
| eval src_ip=coalesce('ClientIP', 'InitiatedBy.user.ipAddress', 'callerIpAddress')
| eval result_status=coalesce('ResultStatus', 'resultDescription', 'ActivityStatus')
(
  operation IN (
    "Add member to role.",
    "Add eligible member to role.",
    "Add member to role in PIM requested.",
    "Add member to role completed (PIM activation).",
    "Assign directory role to user",
    "Microsoft.Authorization/roleAssignments/write",
    "Microsoft.Authorization/elevateAccess/action",
    "Microsoft.Authorization/roleDefinitions/write"
  )
  OR (operation LIKE "%role%" AND (operation LIKE "%add%" OR operation LIKE "%assign%" OR operation LIKE "%write%"))
)
| eval is_high_privilege=if(
    match(lower(role_assigned), "global administrator|company administrator|privileged role administrator|security administrator|exchange administrator|sharepoint administrator|user access administrator|owner|privileged authentication administrator|hybrid identity administrator|application administrator"),
    1, 0
  )
| eval is_success=if(lower(result_status) IN ("success", "succeeded", ""), 1, 0)
| where is_success=1
| table _time, operation, initiated_by, target_user, role_assigned, src_ip, is_high_privilege, result_status, index, sourcetype
| sort - _time
| sort - is_high_privilege
high severity high confidence

Detects cloud role assignment operations across Azure AD audit logs, Office 365 Management Activity, and Azure Activity logs ingested into Splunk. Normalizes fields across sourcetypes using coalesce, identifies role assignment and elevation operations by operation name pattern matching, and flags high-privilege role assignments. Sorts results by most recent and by high-privilege flag to surface the most critical events first.

Data Sources

Cloud Service: Cloud Service ModificationUser Account: User Account ModificationAzure AD Audit LogsOffice 365 Management ActivityAzure Activity Logs

Required Sourcetypes

azure:aad:audito365:management:activityazure:activity

False Positives & Tuning

  • Legitimate IT administrators assigning roles as part of onboarding new employees or service accounts during approved change windows
  • Privileged Identity Management (PIM) activations by authorized users performing time-bound role elevations for maintenance tasks
  • Automated infrastructure provisioning pipelines (Terraform, Bicep, ARM templates) that assign roles as part of resource deployment
  • Help desk or identity governance processes granting temporary access to resolve user issues under a ticketed change request
  • Azure AD Connect or other hybrid identity synchronization services that periodically update role memberships
Download portable Sigma rule (.yml)

Other platforms for T1098.003


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Assign Global Administrator Role to User via Azure AD PowerShell

    Expected signal: Azure AD AuditLogs: OperationName 'Add member to role' with TargetResources containing the target UPN and RoleName 'Global Administrator'. InitiatedBy will show the executing account's UPN and IP address. Event appears in AuditLogs within 5-15 minutes. Unified Audit Log: RecordType 8, Operation 'Add member to role.' with similar details.

  2. Test 2Assign Azure Subscription Owner Role via Az PowerShell (RBAC Escalation)

    Expected signal: AzureActivity log: OperationNameValue 'Microsoft.Authorization/roleAssignments/write' with ActivityStatusValue 'Success', Caller set to the executing account, ResourceId containing the subscription scope and roleAssignment GUID. Event appears in AzureActivity within 2-5 minutes.

  3. Test 3Use elevateAccess API to Gain User Access Administrator at Root Scope

    Expected signal: AzureActivity log: OperationNameValue 'Microsoft.Authorization/elevateAccess/action' with ActivityStatusValue 'Success', Caller set to the Global Admin account. A second event 'Microsoft.Authorization/roleAssignments/write' at scope '/' will also appear as the role is auto-assigned.

  4. Test 4Add External Guest Account to Privileged Role via Microsoft Graph API

    Expected signal: Azure AD AuditLogs: OperationName 'Add member to role' with TargetResources showing the guest account UPN (ending in #EXT# or external domain) and RoleName 'Security Administrator'. InitiatedBy shows the account that executed the Graph API call with its IP address. Graph API calls appear as 'Microsoft Graph' in the InitiatedBy.app field when authenticated via service principal.

Unlock Pro Content

Get the full detection package for T1098.003 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections