Agent Foskett Academy • KQL Academy • Module 11 • Lesson 135

Lesson 135 — The Privileged Role Became Active at 2:07 AM

Privileged Identity Management is designed to reduce standing administrative access by allowing eligible users to activate powerful roles when they need them.

That makes role activation a normal administrative event — until the timing, source, identity or surrounding activity stops looking normal.

At 2:07 AM, a privileged role became active. The investigation is not simply “which role?” It is: who requested the elevation, what account received it, what evidence was recorded by PIM, which sign-in preceded it, and what happened once the privilege existed?

Privilege is temporary in PIM. The evidence created by an unexpected activation can be much more permanent.

Start Lesson 135 Back to KQL Academy

Agent Foskett KQL Academy privileged role activation investigation

What you will investigate

A Microsoft Entra privileged role activation occurring at an unusual time.

✓ Discover PIM audit operations

✓ Identify the privileged target

✓ Inspect the initiator and change details

✓ Correlate activation with sign-ins

The investigation begins

01:58 UTC ↓ Administrator account signs in ↓ Source IP is unfamiliar ↓ 02:07 A privileged role becomes active ↓ The activation itself is successful ↓ PIM did what it was designed to do ↓ But the time and sign-in context are unusual ↓ QUESTION Was this legitimate just-in-time administration... or did an attacker elevate a compromised identity?

Learning objectives

Use Microsoft Entra audit telemetry to discover PIM activity, identify privileged role events involving a target identity, determine who or what initiated them, inspect recorded role-change details and correlate the event with nearby sign-ins.

Why this is not a PIM basics lesson

The Academy already teaches Privileged Identity Management concepts. Here we are treating PIM as an investigation data source and asking what its audit evidence tells us during a suspected identity compromise.

Step 1 — discover PIM activity in AuditLogs

Microsoft Entra audit data identifies the service that logged an activity. Start by isolating events logged by Privileged Identity Management and inspect the operation names actually present in your tenant.

123456789101112

AuditLogs
| where TimeGenerated > ago(7d)
| where LoggedByService =~ "Privileged Identity Management"
| project TimeGenerated,
          OperationName,
          Category,
          Result,
          ResultReason,
          InitiatedBy,
          TargetResources,
          AdditionalDetails
| order by TimeGenerated desc

Why discover first?

PIM produces different audit operations for assignment, activation, approval, expiration and policy activity. Rather than guess one exact operation string, first examine the events your environment records and then narrow the investigation.

PIM activation is expected behaviour

An eligible administrator activating a role is not inherently suspicious. PIM exists to provide time-limited privileged access. The investigation begins when the activation does not fit the administrator's normal timing, source, reason or expected work.

Step 2 — understand the PIM operation vocabulary

Summarize PIM audit operations over a wider period. This gives you the tenant's own vocabulary and shows which events are common or rare.

123456

AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService =~ "Privileged Identity Management"
| summarize OperationCount=count()
          by OperationName, Result
| order by OperationCount desc

Normal is tenant-specific

One environment may have frequent PIM activations throughout the night because of a global operations team. Another may almost never see privileged activity outside local business hours. Your baseline matters.

Rare does not equal malicious

A rare operation is a reason to look closer, not a reason to accuse. Emergency maintenance, incident response and after-hours changes can all produce legitimate privileged activity.

Step 3 — focus on the identity under investigation

Now isolate PIM events involving the target account. TargetResources is dynamic, so expand it where possible but keep a string fallback for environments where the useful identity value sits elsewhere in the structure.

123456789101112131415

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService =~ "Privileged Identity Management"
| mv-expand Target = TargetResources
| extend TargetUPN = tostring(Target.userPrincipalName)
| where TargetUPN =~ TargetUser
       or tostring(TargetResources) contains TargetUser
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          AdditionalDetails
| order by TimeGenerated desc

Target versus actor

The identity receiving or affected by privilege is not always the same identity that initiated the action. Keep those concepts separate throughout the investigation.

Which role was involved?

Review the target resource and modified properties to identify the role or assignment involved. High-impact roles such as Global Administrator or Privileged Role Administrator deserve particular scrutiny when the event is unexpected.

Step 4 — identify who initiated the privileged action

InitiatedBy can contain a user or application. Extract both possibilities so the evidence does not assume every privileged event was initiated by a human administrator.

123456789101112131415

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService =~ "Privileged Identity Management"
| where tostring(TargetResources) contains TargetUser
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName),
         ActorApp = tostring(InitiatedBy.app.displayName)
| project TimeGenerated,
          OperationName,
          Result,
          ActorUPN,
          ActorApp,
          TargetResources,
          AdditionalDetails
| order by TimeGenerated desc

A self-initiated activation still needs context

If the target user also appears as the initiator, that proves the audit event was associated with that identity. It does not prove the legitimate human owner controlled the account at the time.

Approval does not end the investigation

Where approval is part of your PIM configuration, approval information is useful evidence. But an approved request can still deserve investigation if the initiating identity was compromised or the request context was misleading.

Step 5 — inspect modified properties and additional details

PIM audit events can contain role, assignment and workflow details in structured fields. Expand the modified properties where present, but keep AdditionalDetails visible because justification, ticket or workflow information may also help explain the event.

123456789101112131415161718

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService =~ "Privileged Identity Management"
| where tostring(TargetResources) contains TargetUser
| mv-expand Target = TargetResources
| mv-expand Property = Target.modifiedProperties
| extend PropertyName = tostring(Property.displayName),
         OldValue = tostring(Property.oldValue),
         NewValue = tostring(Property.newValue)
| project TimeGenerated,
          OperationName,
          Result,
          PropertyName,
          OldValue,
          NewValue,
          AdditionalDetails
| order by TimeGenerated desc

Look for the role name

The modified properties can expose useful before-and-after information, including role-related values. During discovery, do not throw away properties just because their names look unfamiliar — first understand what your tenant records.

Justification is evidence, not proof

A convincing justification string does not make an activation legitimate. Attackers can type text too. Compare the reason with the actual ticket, change window, administrator schedule and surrounding telemetry.

Step 6 — correlate the privileged event with SigninLogs

Now place the PIM audit event beside nearby sign-ins. A ±2 hour window lets us see which authentication activity surrounded the privileged elevation.

123456789101112131415161718192021222324252627282930313233343536

let TargetUser = "alex.wilson@contoso.com";
let PrivilegedEvents =
    AuditLogs
    | where TimeGenerated > ago(7d)
    | where LoggedByService =~ "Privileged Identity Management"
    | where tostring(TargetResources) contains TargetUser
    | project AuditTime=TimeGenerated,
              OperationName,
              AuditResult=Result,
              InitiatedBy,
              TargetResources,
              AdditionalDetails;
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| project SignInTime=TimeGenerated,
          IPAddress,
          Location,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus,
          AuthenticationRequirement
| extend JoinKey = 1
| join kind=inner (PrivilegedEvents | extend JoinKey = 1) on JoinKey
| where SignInTime between (AuditTime - 2h .. AuditTime + 2h)
| project AuditTime,
          OperationName,
          AuditResult,
          SignInTime,
          IPAddress,
          Location,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus,
          AuthenticationRequirement
| order by AuditTime asc, SignInTime asc

What would increase concern?

An unfamiliar source IP immediately before activation, unusual geography, repeated failures followed by success, an unexpected application, abnormal Conditional Access context or a newly registered authentication method can all strengthen the case for compromise.

What would support legitimacy?

A familiar administrator workstation, expected corporate network, approved maintenance window, valid change ticket and normal privileged workflow can support a benign explanation — especially when those facts agree with one another.

After elevation, investigate the actions

Role activation is often the beginning of the most important part of the timeline. Once privilege became active, what changed? Look for directory modifications, policy changes, new role assignments, application changes, authentication-method changes or other administrative actions that follow the elevation.

Evidence table

Observation	What it supports	What it does not prove
PIM event recorded	Privileged Identity Management logged the activity.	That the activity was malicious or legitimate.
Target identity received privilege	The account was affected by the privileged role workflow.	Who controlled the account.
Actor appears in InitiatedBy	The audit event was associated with that user or application.	That the expected human operator performed it.
Activation at 2:07 AM	The event occurred outside an expected time for some environments.	That after-hours work is malicious.
Unfamiliar sign-in before activation	The preceding authentication differs from observed history.	That the source belongs to an attacker.
Privileged actions follow activation	The newly active role was followed by administrative activity.	Whether those actions were authorised without business context.

Agent Foskett's investigation

01:58 Administrator signs in ↓ The source IP is new ↓ 02:07 PIM logs privileged activity ↓ The target identity is identified ↓ The initiator is extracted ↓ Modified properties reveal the role context ↓ Additional details are reviewed ↓ KQL brings SigninLogs into the same timeline ↓ The privileged event occurred minutes after the unusual authentication ↓ The change ticket is checked ↓ No approved work exists ↓ Post-activation administrative activity begins ↓ The privilege event becomes a critical pivot in the identity compromise investigation

The role activation was not suspicious because it happened at 2:07 AM. It became suspicious because the rest of the evidence could not explain why it happened at 2:07 AM.

Investigation questions to ask next

Which privileged role was activated or assigned?
Was the account eligible for that role before the event?
Who or what initiated the PIM activity?
Was approval required, and who approved it?
Was a justification or ticket number recorded?
Did the activation occur during an authorised maintenance window?
What sign-in immediately preceded the privileged event?
Did the source IP, device and location fit the administrator's baseline?
Were authentication methods, Conditional Access or role assignments changed afterwards?
What privileged actions occurred while the role was active?

Lesson 135 key takeaways

PIM activation is normal administrative behaviour until context makes it unusual.
Use AuditLogs and LoggedByService to discover PIM activity.
Discover operation names in your own tenant before hard-coding narrow detections.
Keep the target identity separate from the initiating identity or application.
Inspect target resources, modified properties and additional details.
Justification, approval and ticket data are supporting evidence, not automatic proof of legitimacy.
Correlate PIM events with SigninLogs.
After-hours activity must be compared with the organisation's real operating pattern.
Investigate what happened after privilege became active.
A privileged role event can become the central pivot in an identity compromise timeline.

Continue your KQL investigation training

Lesson 135 continues Module 11: Identity Threat Hunting. Next we widen the investigation from one identity to several accounts touched by the same source IP.

KQL Academy Lesson 134 — Conditional Access Result Microsoft Entra Security Academy Agent Foskett Academy

Related Agent Foskett Investigations

Continue the privileged identity theme with investigations where administrative changes, persistence and unexpected identity activity become the key evidence.

The User Was Added to a Privileged Group at 3:12 AM The Service Principal Had Global Administrator The MFA Method Was Added at 3:14 AM Browse Agent Foskett Investigations

🔎 KQL Academy — Module 11: Identity Threat Hunting

Use KQL to investigate identity behaviour as evidence.

⬅ Previous lesson

Lesson 134 — The Conditional Access Result Didn't Tell the Whole StoryInvestigate what a Conditional Access outcome does — and does not — prove.

✅ Current lesson

Lesson 135 — The Privileged Role Became Active at 2:07 AMCorrelate privileged role activity with sign-ins and surrounding identity evidence.

Next lesson

Lesson 136 — The Same IP Address Touched Five AccountsUse KQL to pivot from one source IP across multiple identities and expose coordinated authentication activity.

Investigate Microsoft Entra PIM role activation with KQL

Lesson 135 of the Agent Foskett KQL Academy teaches analysts how to investigate Microsoft Entra Privileged Identity Management activity using AuditLogs, LoggedByService, InitiatedBy, TargetResources, modified properties and surrounding SigninLogs activity.

Privileged role activation investigation in Microsoft Entra

Privileged role activation is expected in a just-in-time administration model, but unusual timing, authentication context, initiators or follow-on actions can turn a routine PIM event into a critical identity compromise clue.