ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Entra ID • PIM • Privileged Roles • AuditLogs • KQL

The Account Wasn't an Administrator — Until PIM Activated the Role

The account looked ordinary.

No permanent Global Administrator assignment.
No standing privileged role.
Nothing in the current role list explained the administrative action.

But the audit trail showed something the current-state view could not.

For a limited window, the account had been privileged.

Microsoft Entra Privileged Identity Management had activated the role.

Agent Foskett now had two timelines to reconstruct:

When did the privilege exist — and what happened while it did?

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating Microsoft Entra Privileged Identity Management role activation
Privilege Can Be Temporary

A current role assignment is a snapshot. PIM investigations require the analyst to reconstruct the historical privilege window and correlate it with the actions performed during that window.

✓ Find the activation
✓ Establish the privilege window
✓ Correlate administrative activity

The current role list looked clean

An administrative change had been attributed to a user account that did not appear to hold the required privileged role.

The first check seemed reassuring: the account was not a permanent administrator.

But that only described the account now.

Agent Foskett asked whether the account had been eligible for the role and whether Microsoft Entra PIM had activated that privilege at the time of the change.

Current privilege and historical privilege are different evidence.

PIM changes the investigation question

Privileged Identity Management is designed to reduce standing privilege by allowing eligible users to activate roles when required, subject to the controls configured by the organisation.

That means an analyst investigating a historical administrative action cannot rely only on today's active role assignments.

The investigation needs to establish the lifecycle of the elevation.
EligibleWas the identity eligible for the privileged role?
ActivatedDid an activation occur during the incident window?
ActivityWhat did the account do while the elevated role was active?

Find the PIM activity in the audit trail

Where Microsoft Entra audit logs are available in Microsoft Sentinel, AuditLogs can be used to explore role-management activity. Agent Foskett started broadly rather than depending on a single hard-coded operation name.
pim-role-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
AuditLogs
| where TimeGenerated > ago(30d)
| where Category has "Role"
    or OperationName has_any (
        "role",
        "eligible",
        "activation")
| project TimeGenerated,
          Category,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          CorrelationId
| order by TimeGenerated desc

The activation event became the anchor

The audit trail showed role-management activity involving the account during the period under investigation.

Agent Foskett inspected the event details to identify the target identity, role, initiator and available activation context. Exact operation names and fields can differ with the event and log representation, so the raw audit record mattered.

The key finding was temporal:

the account's privilege had a beginning.

That timestamp became the anchor for everything that followed.

Search specifically for the identity

Once the account was known, Agent Foskett narrowed the audit search and reviewed all relevant role-related records involving that identity rather than treating one activation event in isolation.
identity-pim-history.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
let User = "alex@contoso.com";
AuditLogs
| where TimeGenerated > ago(90d)
| where tostring(TargetResources) has User
    or tostring(InitiatedBy) has User
| where Category has "Role"
    or OperationName has_any (
        "role",
        "eligible",
        "activation")
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          CorrelationId
| order by TimeGenerated asc

Activation is not automatically suspicious

PIM exists so authorised administrators can activate privileged roles when they need them. A successful activation is therefore not evidence of compromise by itself.

Agent Foskett checked the available context against the organisation's expected process: the user, requested role, timing, approval or justification requirements where configured, and the work that was supposed to occur.

The investigation was not “Why did PIM work?” It was “Did this activation make sense?”
Investigation principle: Legitimate security controls still generate evidence that must be interpreted in context.

Now define the privilege window

The important investigative boundary was the period during which the role was active.

Agent Foskett recorded the activation time and the end of the elevation based on the available PIM and audit evidence. That created a window in which administrative actions deserved closer scrutiny.

Instead of asking whether the account had ever performed privileged activity, the question became much more precise:

What changed between elevation and expiry?

Correlate administrative actions inside the window

Agent Foskett searched the audit trail for actions initiated by the account during the elevated period. The query below is deliberately broad because the administrative operations of interest depend on the role and incident.
activity-during-elevation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let User = "alex@contoso.com";
let PrivilegeStart = datetime(2026-09-28 09:02:00);
let PrivilegeEnd   = datetime(2026-09-28 09:47:00);
AuditLogs
| where TimeGenerated between
    (PrivilegeStart .. PrivilegeEnd)
| where tostring(InitiatedBy) has User
| project TimeGenerated,
          Category,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          CorrelationId
| order by TimeGenerated asc

The timeline changed the meaning of the action

An administrative change that originally seemed impossible now had an explanation: at that exact time, the account possessed the required temporary privilege.

But explanation is not exoneration.

Agent Foskett still had to determine whether the elevation and the subsequent action were expected, approved and consistent with the user's work.
09:02 — Role activatedPIM elevation creates the temporary privileged window.
09:19 — Administrative actionThe account performs the change under investigation while elevated.
09:47 — Privilege endsThe role is no longer active, leaving the current-state view looking ordinary again.

Check the sign-in context too

Privilege answers what the account was authorised to do. It does not prove who was actually controlling the session.

Agent Foskett therefore correlated the privilege window with Microsoft Entra sign-in evidence where available: IP address, location context, device information, authentication details, Conditional Access results and other surrounding sign-ins.

A perfectly valid PIM activation from an abnormal session can change the incident entirely.
signins-around-pim.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let User = "alex@contoso.com";
let PrivilegeStart = datetime(2026-09-28 09:02:00);
SigninLogs
| where TimeGenerated between
    (PrivilegeStart - 30m .. PrivilegeStart + 60m)
| where UserPrincipalName =~ User
| project TimeGenerated,
          IPAddress,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus,
          DeviceDetail,
          LocationDetails
| order by TimeGenerated asc

What Agent Foskett checked

EligibilityWas the user legitimately eligible for the privileged role?
ActivationWhen was the role activated and what context was recorded?
Privilege windowExactly when could the account exercise the elevated permissions?
Audit activityWhat administrative changes occurred while privilege was active?
Sign-in contextDid the session around the activation look normal for the user?
Business contextWas the elevation expected, justified and consistent with approved work?

What the evidence can and cannot prove

A PIM activation proves that temporary privileged access was activated according to the evidence recorded by the service. It does not automatically prove malicious intent.

Likewise, an administrative action inside the privilege window does not by itself prove that PIM caused the action or that the same human controlled every relevant session.

Audit events, sign-in telemetry, PIM configuration and business context must be correlated.

Exact operation names, fields and available details can vary, so analysts should inspect the audit records present in their own tenant rather than relying on one universal string.

Temporary privilege still leaves a permanent investigative trail.

The lesson

The account was not an administrator when the investigation began.

That statement was true.

It was also incomplete.

At the time of the administrative action, PIM had temporarily elevated the identity.

Agent Foskett reconstructed the activation, defined the privilege window, examined the actions performed inside it and checked the session context surrounding the elevation.

A current role assignment tells you who is privileged now. An investigation must determine who was privileged then.
Investigation principle: Privilege is a timeline, not just a checkbox.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR and Microsoft Sentinel.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The account wasn't privileged now. It was privileged then.
Find the activation. Define the window. Investigate what happened inside it.
Continue the Investigation

Final thought

Just-in-time privilege is designed to reduce risk, but it also changes how privilege investigations must be performed.

Do not stop at the current role list.

Reconstruct eligibility, activation, expiry, administrative activity and sign-in context as one timeline.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Account Wasn't an Administrator — Until PIM Activated the Role

This Agent Foskett investigation examines temporary administrative privilege through Microsoft Entra Privileged Identity Management and shows why current role assignments cannot explain historical privilege on their own.

Investigating Microsoft Entra PIM Role Activations

Use Microsoft Entra audit evidence to identify role-management activity, establish a PIM privilege window and correlate administrative actions with the period in which an identity was elevated.

Microsoft Sentinel KQL for PIM and Privileged Identity Investigations

Where the relevant Microsoft Entra logs are ingested, AuditLogs and SigninLogs can help investigators correlate role activation, administrative activity and sign-in context while validating findings against PIM configuration and business context.