Agent Foskett Academy • SOC Analyst Academy • Module 3 • Lesson 25 • Identity Incidents

Lesson 25 — The Privileged Role Became Active Overnight

At 02:07, a privileged Microsoft Entra role became active.

There was no planned maintenance window. The administrator was not on call. Twenty minutes later, sensitive directory changes began appearing in the audit trail.

The role activation was not automatically malicious — Privileged Identity Management exists so eligible administrators can elevate when required. But unexpected privilege plus unusual timing plus follow-on changes gave the SOC a very different investigation.

Privilege elevation is not the verdict. The reason, identity, timing and actions performed after elevation tell the story.

Investigate the Privilege Activation Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating an unexpected privileged role activation

At 02:07, privilege changed the risk

The analyst must identify the role, who activated it, whether the elevation was expected, what authentication preceded it and what the privileged identity did next.

✓ Identify the activated privileged role

✓ Validate PIM and approval context

✓ Correlate elevation with sign-in activity

✓ Follow privileged actions after activation

Case briefing

01:58 — SUCCESSFUL SIGN-IN PRIVILEGED USER 02:07 — ROLE ACTIVATED PRIVILEGED DIRECTORY ROLE 02:09 — PIM ACTIVATION COMPLETED 02:18 — DIRECTORY CHANGE 02:24 — SECURITY CONFIGURATION CHANGE 02:31 — ANOTHER PRIVILEGED ACTION CHANGE WINDOW NONE ADMINISTRATOR NOT ON CALL THE EASY VERDICT "PIM activation succeeded." THE SOC QUESTION "Why did this identity become privileged at 02:07, and what happened next?"

Investigation objective

Determine whether the privileged role activation was legitimate, whether the expected PIM controls were satisfied and whether the elevated identity performed suspicious actions afterwards.

Investigator's rule

Privilege changes the impact calculation immediately. Activity that might be medium priority for a normal account can become urgent when the identity gains administrative capability.

Stage 1 — establish the privilege event

Question	Why it matters
Which role became active?	Different roles expose different resources and administrative capabilities.
Who activated it?	Confirm the identity and whether activation was self-service or administratively initiated.
When did activation occur?	Timing helps correlate the event with sign-ins and later changes.
Was approval required?	Approval context can reveal whether normal PIM governance was followed.
Was a justification supplied?	The reason should make sense against the work actually performed.
What happened after activation?	Privileged actions determine the real impact of the event.

Time of day is context

02:07 is not proof of compromise. Administrators sometimes work overnight. But unusual timing should increase scrutiny when there is no maintenance window or operational reason.

The role itself matters

Do not write “admin role activated” and move on. Record the exact role because its permissions define what the elevated identity could potentially change.

Stage 2 — find privileged role activity with KQL

Use Microsoft Entra audit telemetry to identify role-management and PIM-related operations involving the target identity.

12345 678910 111213141516

let TargetUser = "admin@contoso.com";
AuditLogs
| where TimeGenerated > ago(24h)
| where Category =~ "RoleManagement"
   or OperationName has_any ("role", "PIM", "eligible", "activation")
| where tostring(InitiatedBy) has TargetUser
   or tostring(TargetResources) has TargetUser
| project TimeGenerated,
          OperationName,
          Category,
          Result,
          InitiatedBy,
          TargetResources,
          AdditionalDetails
| order by TimeGenerated asc

Inspect the returned records

Operation names and details can vary. Review the raw audit event to identify the target role, initiating identity, result and any useful activation metadata.

Do not lose the governance context

PIM may require MFA, approval, justification or other activation controls. Determine which controls were expected and whether the activation followed them.

Stage 3 — correlate the activation with authentication

01:58 SUCCESSFUL SIGN-IN ↓ SOURCE / DEVICE / MFA ↓ 02:07 PRIVILEGED ROLE ACTIVATED ↓ EXPECTED PIM CONTROLS? ↓ 02:18+ PRIVILEGED CHANGES ↓ ONE CONTINUOUS IDENTITY STORY?

Start before the elevation

The investigation should begin with the authentication that established the session. If that sign-in is suspicious, the later privilege activation becomes much more serious.

Check who approved the request

If approval was required, validate the approver and timing. An unexpected approval can become a second identity pivot rather than reassurance.

Stage 4 — review sign-ins around the elevation

Build a tight sign-in timeline around the privileged activation and compare source, device, application and authentication context.

12345 678910 11121314 15161718

let TargetUser = "admin@contoso.com";
SigninLogs
| where TimeGenerated between (
    datetime(2026-08-25 01:30:00) ..
    datetime(2026-08-25 03:00:00)
)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ConditionalAccessStatus,
          AuthenticationDetails,
          DeviceDetail
| order by TimeGenerated asc

Privilege plus unfamiliar source raises priority

A privileged activation following authentication from a new source or unexpected device deserves rapid escalation, especially when the administrator cannot explain the activity.

Normal authentication does not end the investigation

Even if MFA and Conditional Access succeeded, the session may still be compromised. Continue into the privileged actions performed after elevation.

Stage 5 — follow what privilege enabled

ROLE ACTIVATED ↓ WHAT CHANGED? USERS? GROUPS? ROLES? APPLICATIONS? CONDITIONAL ACCESS? AUTHENTICATION METHODS? SERVICE PRINCIPALS? SECURITY SETTINGS? ↓ EXPECTED ADMINISTRATION OR ATTACKER OBJECTIVE?

The post-activation actions are critical

An unexplained role activation with no subsequent activity is one investigation. The same activation followed by security-control changes is a much higher-risk story.

Look for persistence and defence evasion

Attackers with privilege may create additional administrators, change authentication methods, modify Conditional Access, add credentials to applications or weaken security controls.

Stage 6 — test competing explanations

Hypothesis	Evidence to test
Legitimate emergency administration	Administrator confirmation, incident/change record, expected source and actions matching the stated reason.
Forgotten maintenance activity	Operational records, team confirmation and changes consistent with planned work.
Compromised privileged identity	Suspicious sign-in, unexplained activation and abnormal privileged actions.
Misused legitimate access	Valid authentication and PIM controls but actions inconsistent with authorised duties.
Governance gap	Activation without expected approval, MFA, justification or other required controls.

Stage 7 — make the SOC decision

PRIVILEGED ROLE ACTIVATED ↓ IDENTIFY ROLE + USER ↓ VALIDATE PIM CONTROLS ↓ CORRELATE PRECEDING SIGN-IN ↓ CHECK APPROVAL + JUSTIFICATION ↓ FOLLOW PRIVILEGED ACTIONS ↓ TEST LEGITIMATE EXPLANATIONS ↓ ASSESS IMPACT ↓ CLOSE / CONTINUE / ESCALATE / CONTAIN

The important question is not simply whether privilege was activated. It is whether the complete privileged-access story makes sense.

Write the investigation finding

IDENTITY TRIAGE FINDING A privileged Microsoft Entra role became active for admin@contoso.com at 02:07. No approved maintenance window was active. The administrator was not expected to be performing work at that time. The activation followed a successful sign-in and was followed by sensitive directory and security configuration changes. The administrator could not validate the activity. DECISION Escalate and contain immediately. REASON Unexpected privilege activation combined with unexplained authentication and subsequent administrative changes creates a credible privileged-account compromise hypothesis.

Lesson 25 key takeaways

Unexpected privilege activation should immediately change the SOC risk calculation.
Record the exact privileged role rather than describing it only as administrative access.
Correlate PIM and role-management activity with the authentication that preceded it.
Validate approval, justification, MFA and other expected activation controls.
Unusual timing is context, not proof, but it can increase investigative priority.
Use AuditLogs and SigninLogs to reconstruct the privileged-access timeline.
Follow every significant action performed after elevation.
Look for persistence, additional privilege and security-control changes.
Successful authentication does not prove the privileged session was legitimate.
The final verdict should explain both why privilege was activated and what it enabled.

Module 3 — Identity Incidents

Lesson 25 follows identity risk into privileged access and shows why elevation must be investigated as part of a complete timeline. Next, Agent Foskett follows one source IP across several different user accounts.

Next: Lesson 26 — The Same IP Address Touched Five Accounts

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 3: Identity Incidents

Investigate suspicious authentication, privilege elevation and identity activity across Microsoft Entra.

← Previous lesson

Lesson 24 — Conditional Access Said Success — What Actually Happened? Interpret Conditional Access in the wider sign-in story.

✅ Current lesson

Lesson 25 — The Privileged Role Became Active Overnight Investigate unexpected privilege elevation.

Next lesson

Lesson 26 — The Same IP Address Touched Five Accounts Correlate one source across multiple identities.

How to investigate privileged role activation in Microsoft Entra

Lesson 25 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate unexpected privileged role activation, review PIM and role-management events, validate approval context and follow administrative actions after elevation.

KQL investigation of Microsoft Entra PIM and privileged access

Learn how to use AuditLogs and SigninLogs with KQL to correlate privileged role activity with authentication, identify unusual elevation and reconstruct the actions performed by a privileged identity.