Agent Foskett Case File • Microsoft Entra ID • Effective Access • Permissions • Audit Evidence
The Security Group Was Empty — But the User Still Had Access
The administrator checked the security group.
The user was not there.
No membership.
No obvious entitlement.
No reason they should still be able to open the resource.
Except they could.
The group membership was correct. The assumption about the permission path was not.
Agent Foskett stopped asking whether the user belonged to one group and started asking a different question:
What path was actually granting the access?
Membership Is Not Effective Access
A security-group membership check answers one question. It does not enumerate every possible path through which a user may have received permission.
✓ Confirm the resource access
✓ Enumerate permission paths
✓ Reconstruct the change history
The obvious check said the user had no access
The request sounded straightforward: remove a user's access to a protected Microsoft 365 resource.
The expected security group was checked. The user was not a member.
Someone concluded the access must already be gone.
A validation test proved otherwise.
The user could still reach the resource.
That changed the investigation. Agent Foskett was no longer checking a group. He was investigating effective access.
The expected security group was checked. The user was not a member.
Someone concluded the access must already be gone.
A validation test proved otherwise.
The user could still reach the resource.
That changed the investigation. Agent Foskett was no longer checking a group. He was investigating effective access.
One empty group proves surprisingly little
A resource can receive permissions through more than one route. Depending on the workload and configuration, access might come from direct assignment, another group, a nested group relationship, a SharePoint group, inherited permissions, a Microsoft 365 group or another entitlement mechanism.
The first task was therefore to separate two questions:
Is the user in this group?
and
Why can the user access this resource?
They are not the same question.
The first task was therefore to separate two questions:
Is the user in this group?
and
Why can the user access this resource?
They are not the same question.
Expected pathThe security group everyone believed controlled access.
Effective accessThe permissions the user actually had at the resource.
Change historyThe audit evidence explaining how that permission path came to exist.
Start with the resource, not the assumption
Agent Foskett confirmed that access still worked and documented the exact resource involved. That matters because permission models differ between workloads.
Instead of beginning with the group administrators expected to be authoritative, he worked backwards from the resource and enumerated the identities and groups that could actually reach it.
Effective access is determined at the destination.
Instead of beginning with the group administrators expected to be authoritative, he worked backwards from the resource and enumerated the identities and groups that could actually reach it.
Effective access is determined at the destination.
Investigation principle: Never use the expected permission path as proof of the effective permission path.
Check direct and group-based access
The resource permissions showed more than the expected security group. Agent Foskett looked for direct user assignments and additional groups, then traced those groups back through Microsoft Entra ID.
A user who is absent from one group may still receive equivalent access through another principal.
A user who is absent from one group may still receive equivalent access through another principal.
Nested membership can hide the path
Where nested security groups are used and supported by the access scenario, the visible assignment may point to a parent group rather than the individual user.
That creates a common investigative trap: checking only direct membership and concluding the user is not entitled.
Agent Foskett mapped the relationship instead:
User → Group B → Group A → Resource
The user did not need to appear as a direct member of the group shown on the resource for a nested relationship to matter in a supported scenario.
That creates a common investigative trap: checking only direct membership and concluding the user is not entitled.
Agent Foskett mapped the relationship instead:
User → Group B → Group A → Resource
The user did not need to appear as a direct member of the group shown on the resource for a nested relationship to matter in a supported scenario.
Audit the identity changes
Once a candidate permission path was identified, Agent Foskett moved into Microsoft Entra audit evidence. The goal was not merely to prove the current configuration. It was to establish when the entitlement changed and who changed it.
In Microsoft Sentinel environments where Entra audit logs are available in
In Microsoft Sentinel environments where Entra audit logs are available in
AuditLogs, KQL can help reconstruct group-membership changes.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
AuditLogs
| where TimeGenerated > ago(30d)
| where Category =~ "GroupManagement"
| where OperationName has_any (
"Add member to group",
"Remove member from group")
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources,
CorrelationId
| order by TimeGenerated descFind changes involving the user
The broad group-management query established the available events. Agent Foskett then narrowed the search to audit records containing the user's identity and inspected the target resources and initiator.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let User = "alex@contoso.com";
AuditLogs
| where TimeGenerated > ago(90d)
| where Category =~ "GroupManagement"
| where tostring(TargetResources) has User
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources,
CorrelationId
| order by TimeGenerated ascThe audit event answered who — not automatically why
The logs could show that an administrator, service or workflow changed membership. That did not automatically make the change malicious.
Agent Foskett compared the actor, timestamp and target with approved requests, administrative activity and the user's role.
A legitimate help-desk change can create unexpected access just as easily as malicious activity can.
Unexpected does not mean hostile. It means unexplained.
Agent Foskett compared the actor, timestamp and target with approved requests, administrative activity and the user's role.
A legitimate help-desk change can create unexpected access just as easily as malicious activity can.
Unexpected does not mean hostile. It means unexplained.
What if the permission came from SharePoint?
For SharePoint and OneDrive investigations, Agent Foskett also checked the workload's own permission model and audit trail. A user can receive access through a SharePoint group, direct permission or sharing operation that is not explained by inspecting a single Entra security group.
Where Microsoft 365 audit data is ingested into Sentinel, relevant workload audit events can be investigated in
Where Microsoft 365 audit data is ingested into Sentinel, relevant workload audit events can be investigated in
OfficeActivity. The exact operations available depend on the workload, auditing configuration and event being investigated.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload =~ "SharePoint"
| where Operation has_any (
"Permission",
"Sharing",
"Member")
| project TimeGenerated,
UserId,
Operation,
Site_Url,
OfficeObjectId,
Parameters
| order by TimeGenerated descBuild the permission timeline
The current permission explained how the user could still access the resource. The audit history explained when that path appeared.
Agent Foskett combined both into one timeline.
Agent Foskett combined both into one timeline.
09:12 — Expected access removedThe user is removed from the group administrators believed controlled the resource.
09:18 — Access still succeedsValidation proves another entitlement path remains.
09:31 — Alternate path identifiedResource permissions and audit history expose the effective access route.
What Agent Foskett checked
Resource permissionsWhich principals actually had access to the destination?
Direct assignmentWas the user explicitly granted access?
Other groupsWas another security or Microsoft 365 group providing entitlement?
Nested relationshipsCould a supported nested-group path explain effective access?
Audit historyWho changed the membership or permission, and when?
ValidationAfter remediation, was access actually tested again?
What the evidence can and cannot prove
An empty security group does not prove that a user has no access to a resource. It proves only that the user is not a member of that group in the way you checked it.
Likewise, a group-membership audit event does not by itself prove that the membership granted access to the resource under investigation.
Permission models vary across Microsoft Entra ID, SharePoint, Teams, applications and Azure resources. Nested-group behaviour and support also depend on the service and scenario.
The resource's effective permissions and the relevant audit evidence have to be correlated.
Likewise, a group-membership audit event does not by itself prove that the membership granted access to the resource under investigation.
Permission models vary across Microsoft Entra ID, SharePoint, Teams, applications and Azure resources. Nested-group behaviour and support also depend on the service and scenario.
The resource's effective permissions and the relevant audit evidence have to be correlated.
The lesson
The administrator was correct: the security group was empty.
That was never the real question.
The real question was why the user could still reach the resource.
Agent Foskett worked backwards from effective access, identified the alternate permission path and used audit evidence to reconstruct how it got there.
Access is not defined by the group you expected to control it. Access is defined by every permission path that actually reaches the resource.
That was never the real question.
The real question was why the user could still reach the resource.
Agent Foskett worked backwards from effective access, identified the alternate permission path and used audit evidence to reconstruct how it got there.
Access is not defined by the group you expected to control it. Access is defined by every permission path that actually reaches the resource.
Investigation principle: When the entitlement says no but the resource says yes, believe the resource — then find the path.
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.
Final thought
Permission investigations become dangerous when administrators stop after checking the control they expected to matter.
Start with what the user can actually reach. Enumerate every plausible entitlement path. Then use the audit history to explain how that access came to exist.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
Start with what the user can actually reach. Enumerate every plausible entitlement path. Then use the audit history to explain how that access came to exist.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
