ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Entra ID • Global Administrator • AuditLogs • PIM • KQL

Nobody Created the Account — Yet It Had Global Administrator

The identity was sitting in Microsoft Entra ID.

It had one of the most powerful roles in the tenant:

Global Administrator.

The team searched for the obvious question — who created the account?

The answer wasn't obvious at all.

Agent Foskett changed the question: who gave this identity privilege, and what happened immediately before and after?

Discuss Identity SecurityBack to investigations
Agent Foskett investigating a Global Administrator role assignment in Microsoft Entra ID
The Privilege Was the Evidence

The missing creation event did not make the identity legitimate. The investigation moved to directory audit history, role assignments and the administrative chain that produced the privilege.

✓ Unexpected identity
✓ Global Administrator privilege
✓ Audit trail reconstruction

The account was already there

The security team found an identity that did not fit the expected administrative model. It was not one of the recognised administrator accounts, yet it held Global Administrator.

Searching only for a simple account-creation event did not immediately explain the situation.

That did not end the investigation. It changed it.

An identity does not become dangerous because it exists. It becomes dangerous because of what it can do.
Unexpected identityThe account did not match the known administrator population.
Global AdministratorThe role gave the identity extensive control over the Microsoft Entra tenant.
Missing explanationThe obvious creation trail did not immediately explain how the privilege appeared.

Agent Foskett followed the administrative chain

Instead of asking only when the account was created, Agent Foskett reconstructed the sequence of directory changes around the identity.

Who modified it? Who assigned a role? Was the assignment direct or eligible through Privileged Identity Management? Was another administrator involved? Did the identity authenticate immediately afterwards?

The investigation moved from account existence to privilege provenance.

Start with the identity in AuditLogs

Microsoft Entra audit logs record many directory changes. Begin by finding operations that reference the suspicious identity and review the initiator, operation, result and target resources.
identity-audit-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
let Target = "admin@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has Target
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          AdditionalDetails,
          CorrelationId
| order by TimeGenerated asc

Find role-management activity

Next, narrow the audit trail to role-related operations. The exact operation names visible in a tenant can vary with the role-management workflow, so use the audit data itself to identify the relevant assignment, activation or membership events rather than relying on one hard-coded event name.
role-management-events.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
AuditLogs
| where TimeGenerated > ago(30d)
| where Category =~ "RoleManagement"
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          AdditionalDetails,
          CorrelationId
| order by TimeGenerated desc

Who initiated the change?

The target identity tells you who received privilege. The initiator can tell you who or what caused the directory change. Review whether the operation was initiated by a user, an application or another service context, then pivot on that actor across the same investigation window.
initiator-pivot.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
let Actor = "admin2@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(InitiatedBy) has Actor
| project TimeGenerated,
          Category,
          OperationName,
          Result,
          TargetResources,
          CorrelationId
| order by TimeGenerated asc

Did the privileged identity sign in afterwards?

A role assignment is important. What happened after it can be even more important. Correlate the identity with Microsoft Entra sign-in telemetry to determine whether the newly privileged account authenticated, from where, to which application and under what Conditional Access result.
privileged-signins.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
let Target = "admin@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ Target
| project TimeGenerated,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ConditionalAccessStatus
| order by TimeGenerated asc

PIM changes the question

Not every privileged identity is permanently assigned to a role. Microsoft Entra Privileged Identity Management can make users eligible for roles and allow controlled activation when required.

That means an analyst should distinguish between permanent assignment, eligibility and activation.

An unfamiliar Global Administrator may be evidence of compromise — or it may reflect an authorised PIM workflow. The audit trail is what separates those possibilities.
AssignmentWas the role granted directly and persistently?
EligibilityWas the identity made eligible to activate the role through PIM?
ActivationWas privileged access activated, and was that activation expected and approved?

Build the privilege timeline

The strongest investigation does not treat the role assignment as an isolated event. Reconstruct what happened before it and after it.

For example: an administrator authenticates, a directory operation changes the target identity, Global Administrator privilege becomes available, and the target identity then signs in or performs additional administrative activity.

The role assignment is one event. The administrative chain is the investigation.
BeforeWho authenticated or changed directory objects before the privilege appeared?
PrivilegeWhich audit event explains the role assignment, eligibility or activation?
AfterWhat did the newly privileged identity do once the role was available?

What Agent Foskett checked

Target identityWas the account expected, managed and owned by the organisation?
RoleWas Global Administrator assigned directly, made eligible or activated?
InitiatorWhich user, application or service initiated the administrative operation?
CorrelationWhich related audit events share timing or correlation identifiers?
Sign-insDid the identity authenticate after privilege became available?
Subsequent changesDid the privileged identity modify users, roles, applications or security configuration?

What the evidence can and cannot prove

An unfamiliar Global Administrator deserves immediate explanation, but unfamiliar does not automatically mean malicious. Emergency access accounts, automation, approved administrative identities and PIM workflows can all create legitimate privileged access patterns.

Likewise, failing to find the creation event in the first search does not prove that no creation record ever existed. Retention, ingestion, search scope and the identity's actual origin all matter.

The conclusion should come from the complete administrative history available to the investigation.

The lesson

Nobody could immediately explain who created the account.

But that was not the most important question anymore.

The identity had Global Administrator.

So Agent Foskett followed the privilege: the role-management events, the initiator, PIM activity, sign-ins and the changes that followed.

When privilege appears unexpectedly, investigate how it was granted — not just when the identity was born.
Investigation principle: Privilege has provenance. Reconstruct the administrative chain.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.Who is Agent Foskett?Meet the investigator behind the case files and the principle: follow the evidence.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The account existed. The privilege needed an explanation.
Follow the role assignment, the initiator and what happened next.
Continue the Investigation

Final thought

Attackers do not always need malware when they can obtain administrative control through identity and privilege.

A role assignment can be quieter than an endpoint alert and far more powerful.

When a privileged identity appears, don't stop at the account object. Follow the people, applications and audit events that gave it authority.

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

Nobody Created the Account — Yet It Had Global Administrator

This Agent Foskett case file examines a Microsoft Entra ID privilege investigation where an unexpected identity holds Global Administrator and the analyst must reconstruct how that authority was granted.

Microsoft Entra ID Global Administrator Investigation With KQL

Use AuditLogs, RoleManagement events and SigninLogs to investigate role assignments, PIM eligibility and activation, initiating administrators, suspicious privileged identities and subsequent administrative activity.

Investigating Unexpected Privilege in Microsoft Entra ID

Unexpected Global Administrator access should be investigated through the complete administrative chain: target identity, initiator, role-management event, PIM workflow, authentication and the actions performed after privilege became available.