Privileged role assignment is one of the highest-impact post-compromise techniques in Entra ID environments. An attacker who gains access to any account with sufficient permission can grant themselves or a backdoor account Global Administrator, Privileged Role Administrator, or any other Tier-0 Entra role — permanently or via Privileged Identity Management (PIM) for time-limited activation.
The attack is silent if change management controls are absent — a successful role grant in Audit Logs looks identical to a legitimate IT operation. The difference is context: who made the grant, when, from which IP, and whether an approved change ticket exists. This SOP walks analysts through that context-checking process step by step, before any query is run.
◈ Table of Contents
01
Background
CONTEXTB1Attack Techniques & MITRE Mapping
| Phase | MITRE | Attacker Goal | Key Indicator |
|---|---|---|---|
| Direct role grant | T1098.003 | Add permanent Global Admin or PRA role to compromised/backdoor account | AuditLogs: Operation = "Add member to role", Category = RoleManagement, Result = success |
| PIM eligible grant | T1098.003 | Add attacker account as PIM-eligible — can self-activate role without further privilege | AuditLogs: Operation = "Add eligible member to role in PIM" |
| PIM self-activation | T1078.004 | Activate eligible role after initial access — bypasses break-glass monitoring if role was quietly added | AuditLogs: Operation = "Add member to role (PIM activation)", initiatedBy = victim account |
| Follow-on: Conditional Access modification | T1556.006 | Disable CA policies that would block the attacker (MFA, compliant device) | AuditLogs: Operation = "Update conditional access policy", Result = success — disable state |
| Follow-on: Federated identity credential | T1556.006 | Add credential to existing service principal for persistent OIDC-based access | AuditLogs: Operation = "Add federated identity credential to application" |
| Follow-on: Application backdoor | T1098.001 | Add attacker-controlled service principal with application permissions (no MFA required) | AuditLogs: Operation = "Add app role assignment to service principal" |
B2Critical Roles to Monitor — Tier-0 Entra ID Roles
| Role Name | Risk | Why Attackers Want It |
|---|---|---|
| Global Administrator | CRITICAL | Full tenant control — can modify any identity, disable MFA, remove CA policies, access all admin portals |
| Privileged Role Administrator | CRITICAL | Can assign ANY role including Global Admin — used to escalate other compromised accounts |
| Security Administrator | HIGH | Can modify Conditional Access, Defender XDR settings, Identity Protection — disables detection |
| Application Administrator | HIGH | Can add credentials to existing enterprise apps — creates persistent service principal access |
| Hybrid Identity Administrator | HIGH | Controls AD Connect — can compromise on-premises-to-cloud sync and manipulate synced identities |
| Exchange Administrator | MEDIUM | Full access to all mailboxes — BEC and data exfiltration via email |
B3Log Sources & Prerequisites
| Source | Sentinel Table | Key Fields | Required Setting |
|---|---|---|---|
| Entra ID Audit Logs | AuditLogs | OperationName, Category, Result, InitiatedBy, TargetResources, ActivityDateTime | Entra ID → Diagnostic settings → Audit Logs → Log Analytics workspace |
| Entra PIM Audit | AuditLogs (Category=RoleManagement) | Same as above — PIM events have Category=RoleManagement and specific OperationName prefixes | Entra ID P2 (PIM requires P2 licence) |
| Sign-in Logs | SigninLogs | IPAddress, LocationDetails, RiskLevelDuringSignIn — correlate initiator account at time of grant | Entra ID → Diagnostic settings → Sign-in logs → Log Analytics workspace |
02
Identification
DETECT & INVESTIGATE◈ Privileged Role Assignment Abuse — Investigation Workflow
I1Confirm the Role Grant — Audit Logs, PIM, and Roles BladeMANUAL + KQL
WHY
A role grant logged as "success" is indistinguishable from a legitimate IT change at the data layer alone. You must confirm the operation details, identify the initiator, and establish whether a matching approved change ticket exists — before querying at scale. This step determines whether you have an incident or a normal admin operation.
◈ Where to Check — Entra Audit Logs (primary)
Entra ID→Audit logs→Category = RoleManagement
- 1Navigate to Entra ID → Audit logs. Set filter: Category = RoleManagement, date range = ±30 minutes around the alert timestamp. Set Status = Success.
- 2Find the role grant event. Open it and note three things: Operation name (see Key Indicators table), Initiated by (the account that made the change — this is the account to investigate), and Target (the account that received the role).
- 3Compare the grant timestamp against your organisation's change management window. If the grant falls outside approved hours (typically Mon–Fri, business hours, excluding public holidays) — flag as suspicious regardless of who the initiator is.
- 4Open an ITSM ticket search for the initiator UPN with the date range ±2 hours. A legitimate admin change ALWAYS has a pre-approved ticket. If none exists — treat as unauthorized.
◈ Where to Check — PIM Assignments
Entra ID→Roles and administrators→[Role name]→Assignments
- 5Navigate to Entra ID → Roles and administrators. Click the specific role name from the alert. Select the Assignments tab — check Active and Eligible sub-tabs. The grantee UPN must appear here. Note whether assignment is Permanent or has an End date.
- 6Navigate to Identity Governance → Privileged Identity Management → Azure AD roles → Audit to see the full PIM activation history. Filter by role name. Look for "Add eligible member to role in PIM" operations — these are often more covert as the attacker accounts for role activation as a separate step.
Key Indicators — Audit Log Operation Names & Fields
| Operation / Field Value | Meaning | Analyst Action |
|---|---|---|
| Add member to role | Direct permanent role assignment — no PIM activation required. Highest severity. | Check initiator sign-in risk. Verify ITSM ticket. If no ticket: immediate contain. |
| Add eligible member to role in PIM | Attacker added account as PIM-eligible — can self-activate role later at any time. Often missed because no active role exists yet. | Block activation. Remove eligible assignment. Audit for self-activations since grant time. |
| Add member to role (PIM activation) | Attacker or compromised account self-activated a PIM role. Time-limited but dangerous during the window. | Check if activation was approved. Remove active assignment. Check what was done during activation window. |
| Add scoped member to role in PIM | Role assigned to specific resource scope (e.g. single subscription) — often used to reduce detection risk while maintaining targeted access. | Identify the scope resource. Treat same as global assignment for Tier-0 roles. |
| Category = RoleManagement | All of the above operation types appear under this Audit Log category — use as primary filter in Sentinel and Audit Logs portal. | Primary KQL filter. Combine with Result=success and TargetResources to identify role name. |
| Result = success | Grant completed — the target now holds the role. Contrast with Result=failure (failed attempt — still worth investigating as recon). | Confirmed active threat. Escalate immediately for Tier-0 roles. |
DETECTS: All successful Entra ID role assignments in the last 7 days — extracts initiator, grantee, role name, and timestamp so analysts can identify anomalous grants outside change windows or to unexpected accounts.
KQL — Microsoft Sentinel: All role grant events (last 7 days)
AuditLogs
| where TimeGenerated > ago(7d)
| where Category == "RoleManagement"
| where Result == "success"
| where OperationName in (
"Add member to role",
"Add eligible member to role in PIM",
"Add member to role (PIM activation)",
"Add scoped member to role in PIM"
)
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| extend InitiatorIP = tostring(InitiatedBy.user.ipAddress)
| extend RoleGranted = tostring(TargetResources[0].displayName)
| extend Grantee = tostring(TargetResources[1].userPrincipalName)
| project TimeGenerated, OperationName, Initiator, InitiatorIP, RoleGranted, Grantee
| where RoleGranted in ("Global Administrator","Privileged Role Administrator",
"Security Administrator","Application Administrator",
"Hybrid Identity Administrator","Exchange Administrator")
| order by TimeGenerated desc
DETECTS: Splunk equivalent — searches Entra audit source for role management success operations and extracts the key fields for analyst triage.
SPL — Splunk: Role grant detection
index=azure sourcetype=azure:aad:audit Category=RoleManagement Result=success
(OperationName="Add member to role" OR OperationName="Add eligible member to role in PIM"
OR OperationName="Add member to role (PIM activation)")
| spath "InitiatedBy.user.userPrincipalName" output=Initiator
| spath "InitiatedBy.user.ipAddress" output=InitiatorIP
| spath "TargetResources{0}.displayName" output=RoleGranted
| spath "TargetResources{1}.userPrincipalName" output=Grantee
| where RoleGranted IN ("Global Administrator","Privileged Role Administrator",
"Security Administrator","Application Administrator")
| table _time, OperationName, Initiator, InitiatorIP, RoleGranted, Grantee
| sort -_time
PIM eligible assignments are often ignored because no active role exists yet. However, an attacker who adds themselves as PIM-eligible can self-activate the role at any time — including after a password reset — because eligibility is not revoked by credential change. Always check both Active AND Eligible tabs.
I2Investigate Initiator Account & Post-Grant Follow-on ActionsMANUAL + KQL
WHY
The initiator account is the pivot point. If it was compromised (risky sign-in before the grant), every action it took after gaining Tier-0 access must be reviewed. Attackers typically execute follow-on actions within minutes of a successful grant — disabling Conditional Access, adding service principal credentials, or creating backdoor app registrations — to lock in persistence before the role is revoked.
◈ Where to Check — Initiator Sign-in Risk
Entra ID→Users→[Initiator UPN]→Sign-in logs
- 1Navigate to Entra ID → Users → [Initiator UPN] → Sign-in logs. Filter to ±4 hours around the grant time. Look at Risk Level column and Risk event types on each sign-in. Any medium/high risk event before the grant = initiator account was compromised when it made the change.
- 2Note the sign-in IP. If the initiator's pre-grant sign-in IP differs from their usual IP pattern (different country, anonymised proxy ASN, TOR exit node) — treat initiator as compromised and escalate to L2 immediately.
◈ Where to Check — Follow-on Actions Post-Grant
Entra ID→Audit logs→Initiated by = [Initiator UPN]→Date = Grant time onwards
- 3Navigate to Entra ID → Audit logs. Filter Initiated by = initiator UPN, date range = grant timestamp to now. Look for any of these high-risk operations: Update conditional access policy (detection evasion), Add service principal credentials (backdoor), Add application (rogue app), Add federated identity credential (external OIDC persistence).
- 4If any of the above post-grant operations are found — escalate immediately to L2/IR. These indicate the attacker has already begun entrenching and the scope is wider than a single role grant.
- 5Navigate to Entra ID → App registrations / Enterprise applications → filter by Owner = initiator UPN or Created date near grant time. New app registrations created after the grant are almost certainly attacker-created backdoors.
DETECTS: All post-grant audit events by the initiator account from the grant time forward — identifies Conditional Access policy modifications, service principal credential adds, and new app registrations that indicate follow-on persistence activity.
KQL — Post-grant follow-on actions by initiator
let grantTime = datetime(2026-06-22T00:00:00Z); // replace with actual grant timestamp
let initiatorUPN = "[email protected]"; // replace with actual initiator
AuditLogs
| where TimeGenerated > grantTime
| where InitiatedBy.user.userPrincipalName =~ initiatorUPN
| where Result == "success"
| extend OperationName, Category
| project TimeGenerated, OperationName, Category,
Target = tostring(TargetResources[0].displayName),
TargetType = tostring(TargetResources[0].type)
| where OperationName has_any (
"Update conditional access policy",
"Add service principal credentials",
"Add application",
"Add federated identity credential",
"Update application",
"Add app role assignment",
"Add owner to application"
)
| order by TimeGenerated asc
DETECTS: Initiator account's sign-in risk level and IP at the time of the role grant — confirms whether the initiator was under attacker control when they executed the privilege escalation.
KQL — Initiator sign-in risk at grant time
let grantTime = datetime(2026-06-22T00:00:00Z); // replace with actual grant timestamp
let initiatorUPN = "[email protected]"; // replace with actual initiator
SigninLogs
| where TimeGenerated between (grantTime - 4h .. grantTime + 1h)
| where UserPrincipalName =~ initiatorUPN
| where ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| extend RiskEvents = tostring(RiskEventTypes_V2)
| project TimeGenerated, IPAddress, Country, RiskLevelDuringSignIn, RiskEvents, AppDisplayName
| order by TimeGenerated desc
DETECTS: Post-grant follow-on suspicious operations by the initiator in Splunk — equivalent to the KQL above for environments with Entra audit logs ingested via the Azure Monitor connector.
SPL — Post-grant follow-on actions (Splunk)
index=azure sourcetype=azure:aad:audit Result=success
"InitiatedBy.user.userPrincipalName"="[email protected]"
earliest="2026-06-22T00:00:00" latest=now
| spath "TargetResources{0}.displayName" output=Target
| where OperationName IN ("Update conditional access policy",
"Add service principal credentials","Add application",
"Add federated identity credential","Add app role assignment")
| table _time, OperationName, Target
| sort _time
Conditional Access policy disablement is the single highest-risk follow-on action. An attacker who disables MFA requirements or removes compliant-device checks can maintain tenant access through any account, even after password resets. Check the CA policy modification event contents — what did the policy look like before vs after?
03
Containment
STOP ITBased on Identification Findings:
Confirmed
Role grant outside approved change window AND no matching ITSM ticket confirmed, OR initiator account had risky sign-in before the grant, OR any follow-on CA policy change / service principal credential / new app registration found after the grant → Execute C1 immediately, escalate to L2.
Uncertain
Role grant is outside change hours but initiator account shows no sign-in risk and change ticket may exist in another ITSM system → Contact the initiator's manager directly (phone call — do not email, attacker may control mailbox). Block sign-in as a precautionary hold while ticket is verified. Hold for maximum 30 minutes.
False Pos.
Approved change ticket confirmed in ITSM, initiator account has no risky sign-ins, no follow-on suspicious actions, grantee is a known IT staff member — document the ticket ID, close ticket, and flag Sentinel analytics rule for tuning (add change window exclusion).
C1Remove Unauthorized Role & Block Involved AccountsImmediate
- 1Remove the granted role from the grantee account: Entra ID → Roles and administrators → [Role name] → Assignments → [Grantee UPN] → Remove. For PIM eligible assignments: Identity Governance → PIM → Azure AD roles → [Role] → Eligible assignments → Remove.
- 2Revoke all sessions for BOTH accounts (initiator and grantee): Entra ID → Users → [UPN] → Revoke sessions for each. If the initiator account was compromised, its active session may still be live and holding a privilege that was just removed from the grantee.
- 3Block sign-in for both accounts: Entra ID → Users → [UPN] → Account enabled → toggle OFF. Do this for both the initiator and the grantee. The grantee may be an attacker-controlled shadow account created specifically for this escalation.
- 4Revoke any new OAuth grants or service principal credentials created post-grant: Entra ID → Enterprise applications → [Application] → Credentials & secrets → remove any credentials added after the grant time.
- 5Re-enable or restore any Conditional Access policies modified after the grant: Entra ID → Protection → Conditional Access → Policies → check Enabled state — any policy disabled after the grant timestamp should be immediately re-enabled.
Removing a role does NOT revoke the existing session of the grantee account. If the attacker has an active session, they retain the role's permissions until the session expires (up to 1 hour for Entra tokens without CAE). Always revoke sessions immediately after removing the role.
04
Eradication
CLEAN UPE1Full Tenant Backdoor Audit & Identity Remediation
- 1Audit all Tier-0 role assignments for unrecognised accounts: Entra ID → Roles and administrators → Global Administrator → Assignments → Active + Eligible tabs. Every UPN must be confirmed as a legitimate IT staff member. Any unrecognised account must be removed and investigated.
- 2Audit new app registrations and enterprise application credentials created during the compromise window: Run the KQL post-grant follow-on query for the full compromise window (initiator's first risky sign-in through containment time). Remove every rogue credential and app registration found.
- 3Audit all Conditional Access policies for state changes during the compromise window: Entra ID → Protection → Conditional Access → Policies. Review the Modified timestamp column. Any policy modified during the compromise window should be compared against its last-known-good state and reverted or reviewed by the Security Architecture team.
- 4Enable PIM for all Tier-0 roles (if not already active): Identity Governance → PIM → Azure AD roles → [Role] → Settings → Require approval for activation. PIM with approval requirement means even a compromised Privileged Role Admin cannot silently grant roles — a second approver must confirm.
- 5Remediate the initiator account: Issue a Temporary Access Pass, force MFA re-registration, and review all actions taken by this account for 14 days prior to the grant. If the initiator's account was obtained via AiTM or credential stuffing, cross-reference SOP-18 or SOP-04 respectively.
Eradication Complete When
- Unauthorized role removed from grantee; all active and eligible assignments for Tier-0 roles audited and clean
- Sessions revoked for initiator and grantee; accounts re-enabled only after identity remediation complete
- All post-grant service principal credentials and app registrations created during compromise window removed
- All Conditional Access policies verified in known-good state; any modified during window restored
- PIM approval-required enforcement confirmed for all Global Admin and PRA roles
- Sentinel alert rule tuned to exclude approved change windows (reduces false positives for legitimate admin operations)
05
Escalation
TIERSESCEscalation Decision Table
| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 | Single unauthorized role grant confirmed, no follow-on actions, role removed, sessions revoked, no evidence of initiator compromise | L2 SOC Analyst | Hand off: initiator UPN, grantee UPN, role name, grant timestamp, ITSM ticket status, containment actions taken |
| L2 → IR + CISO | Any of: initiator account had risky sign-in before grant; follow-on CA policy changes, service principal credentials, or new app registrations found; multiple accounts received elevated roles from same initiator; or tenant-wide role audit reveals additional unrecognised Tier-0 members | IR Team + CISO | Declare SEV1 or SEV2. Initiate full IR. Legal notification assessment if any tenant-wide data access occurred. Engage CISO for board-level notification decision. |
| L2 → Security Engineering | PIM not enabled for Tier-0 roles; no Sentinel analytics rule was detecting role grants; Conditional Access policies lacked protection for privileged admin actions | Security Architecture | Priority task: enable PIM with approval for all Tier-0 roles; deploy Microsoft-provided Sentinel analytics rule "Privileged Role Assigned Outside PIM" (or equivalent); configure Entra ID Protection for admin accounts. |
Authorized security research & penetration testing only. Unauthorized use is illegal. Built by Rudra Verma | Senior Cyber Security Architect & Researcher | CyberHawk Threat Intel
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, SOC playbooks, and hands-on detection engineering content.
"They can't exploit you if you are the Exploit."