Agent Foskett Case File • Microsoft Entra ID • AuditLogs • Group Membership • Access Investigation • KQL
The User Wasn't in the Group Yesterday — Today They Could Access Everything
Yesterday the user could not access the application.
Today they could.
No application role had been assigned directly to the account.
No one remembered approving new access.
But one thing had changed.
The user was now a member of the group that granted it.
Agent Foskett needed to know:
Who added them — and what happened after the access changed?
The Access Changed Because the Membership Changed.
Microsoft Entra audit logs record group-management activity, including member additions. The investigation starts with the membership event, then follows the initiator, target group and subsequent sign-ins.
✓ Find the group membership event
✓ Identify who initiated the change
✓ Reconstruct the access timeline
The permission was indirect
The user did not need a permission assigned directly to their account.
The group already had access.
Once the account became a member, the effective access changed with it.
The investigation was not only about what the user could access. It was about the identity change that made the access possible.
The group already had access.
Once the account became a member, the effective access changed with it.
The investigation was not only about what the user could access. It was about the identity change that made the access possible.
Start with the group-management audit event
Microsoft Entra audit logs include group-management activity such as
Add member to group. Agent Foskett searched AuditLogs for successful member additions involving the affected user.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
let User = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where ActivityDisplayName == "Add member to group"
| where Result =~ "success"
| where tostring(TargetResources) has User
| project TimeGenerated,
ActivityDisplayName,
Result,
InitiatedBy,
TargetResources,
CorrelationId
| order by TimeGenerated ascThe event proved a membership change occurred
The audit event established that Microsoft Entra recorded a successful
But that was only the first fact.
Agent Foskett still needed to identify the group, the initiator and the business reason for the change.
Membership was the mechanism. Attribution required the rest of the audit record.
Add member to group operation involving the account.But that was only the first fact.
Agent Foskett still needed to identify the group, the initiator and the business reason for the change.
Membership was the mechanism. Attribution required the rest of the audit record.
Expand TargetResources instead of reading the JSON by eye
TargetResources can contain multiple objects associated with the operation. Agent Foskett expanded the array so the user and group information could be examined as separate rows.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
let User = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where ActivityDisplayName == "Add member to group"
| where tostring(TargetResources) has User
| mv-expand Target = TargetResources
| extend TargetType = tostring(Target.type),
TargetName = tostring(Target.displayName),
TargetUPN = tostring(Target.userPrincipalName),
TargetId = tostring(Target.id)
| project TimeGenerated,
TargetType,
TargetName,
TargetUPN,
TargetId,
InitiatedBy,
CorrelationId
| order by TimeGenerated ascWhich group changed the user's effective access?
Finding a group addition did not automatically explain the impact.
Agent Foskett had to establish what the target group actually controlled. Was it tied to an enterprise application, a SharePoint site, an Azure role path, a licensing assignment or another resource?
A group membership event becomes security-relevant when you understand what membership grants.
Agent Foskett had to establish what the target group actually controlled. Was it tied to an enterprise application, a SharePoint site, an Azure role path, a licensing assignment or another resource?
A group membership event becomes security-relevant when you understand what membership grants.
Who initiated the membership change?
The
Agent Foskett extracted both possibilities instead of assuming that a human administrator had made the change.
InitiatedBy field became the next pivot. Depending on the operation, the initiator may be represented as a user or an application.Agent Foskett extracted both possibilities instead of assuming that a human administrator had made the change.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
let User = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where ActivityDisplayName == "Add member to group"
| where tostring(TargetResources) has User
| extend InitiatingUser =
tostring(InitiatedBy.user.userPrincipalName),
InitiatingApp =
tostring(InitiatedBy.app.displayName),
InitiatingIp =
tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated,
Result,
InitiatingUser,
InitiatingApp,
InitiatingIp,
TargetResources,
CorrelationId
| order by TimeGenerated ascAn authorised administrator could still make an unauthorised change
The initiator might legitimately have permission to manage group membership.
That establishes capability — not intent.
Agent Foskett checked whether there was an approved access request, expected administrative workflow or automation process that explained the addition.
Permission explains how the change could happen. It does not explain why it happened.
That establishes capability — not intent.
Agent Foskett checked whether there was an approved access request, expected administrative workflow or automation process that explained the addition.
Permission explains how the change could happen. It does not explain why it happened.
Was the membership direct, automated or governed?
Not every group membership change has the same origin. Membership may be managed directly, through automation, dynamic membership logic or identity-governance workflows depending on the organisation.
Agent Foskett preserved the exact audit evidence and initiator context before deciding which path applied.
Do not force every group change into a manual-admin narrative.
Agent Foskett preserved the exact audit evidence and initiator context before deciding which path applied.
Do not force every group change into a manual-admin narrative.
What happened after the user gained access?
The membership change mattered because it altered what the identity could reach.
Agent Foskett pivoted into
Agent Foskett pivoted into
SigninLogs to examine authentication activity after the group addition and identify which applications the account accessed.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
let User = "alex.wilson@contoso.com";
let MembershipTime = datetime(2026-10-01 22:14:00);
SigninLogs
| where TimeGenerated between
(MembershipTime .. MembershipTime + 6h)
| where UserPrincipalName =~ User
| project TimeGenerated,
AppDisplayName,
IPAddress,
Location,
ResultType,
ResultDescription,
ConditionalAccessStatus
| order by TimeGenerated ascA sign-in after the change was correlation — not automatic proof
A successful sign-in after the group addition can establish that the account was active after its access changed.
It does not, by itself, prove that the newly granted group access was used during that sign-in.
Agent Foskett correlated the application, resource-specific telemetry and business context before drawing that conclusion.
Build the sequence first. Prove resource use with the telemetry that records it.
It does not, by itself, prove that the newly granted group access was used during that sign-in.
Agent Foskett correlated the application, resource-specific telemetry and business context before drawing that conclusion.
Build the sequence first. Prove resource use with the telemetry that records it.
Did the same initiator add anyone else?
One unexpected membership change might be a mistake. A pattern of additions by the same identity could indicate a larger access problem.
Agent Foskett scoped successful group additions performed by the same initiator.
Agent Foskett scoped successful group additions performed by the same initiator.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let Initiator = "helpdesk.admin@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == "Add member to group"
| extend InitiatingUser =
tostring(InitiatedBy.user.userPrincipalName)
| where InitiatingUser =~ Initiator
| where Result =~ "success"
| project TimeGenerated,
TargetResources,
CorrelationId
| order by TimeGenerated descRemoval does not erase the access window
Even if the user is later removed from the group, the period between addition and removal still matters.
Agent Foskett searched for the corresponding
Fixing the membership closes the path. It does not erase what may have happened while the path was open.
Agent Foskett searched for the corresponding
Remove member from group event and treated those timestamps as the boundaries of the potential access window.Fixing the membership closes the path. It does not erase what may have happened while the path was open.
Build the access timeline
Agent Foskett organised the evidence chronologically.
User lacks membershipEstablish the account's expected access state before the change.
Member addedPreserve the exact Entra audit event, group and timestamp.
Initiator identifiedDetermine which user, application or workflow caused the membership change.
Effective access changesEstablish what the target group grants to its members.
Post-change activityCorrelate sign-ins and resource-specific telemetry after the addition.
Access window scopedDetermine whether and when the membership was later removed.
What Agent Foskett checked
Membership eventWas a successful Add member to group operation recorded?
Target groupWhich group gained the user, and what access did that group provide?
InitiatorWhich user, application or workflow initiated the change?
Approval contextWas there a legitimate request or governed process explaining the addition?
Post-change activityWhat did the identity do after its effective access changed?
Removal eventWhen did the access path close, if the membership was later removed?
What the evidence can and cannot prove
Microsoft Entra audit logs can establish that a group-management operation was recorded, which resources were involved and initiator context available in the event.
They do not automatically establish malicious intent or prove that every permission associated with the group was exercised.
Likewise, sign-in telemetry can show account authentication activity after the membership change, but resource-specific evidence may be needed to prove exactly what data or service was accessed.
Prove the membership change. Establish what it granted. Then prove what was used.
They do not automatically establish malicious intent or prove that every permission associated with the group was exercised.
Likewise, sign-in telemetry can show account authentication activity after the membership change, but resource-specific evidence may be needed to prove exactly what data or service was accessed.
Prove the membership change. Establish what it granted. Then prove what was used.
The lesson
Yesterday the user was not in the group.
Today they could reach resources they could not reach before.
Agent Foskett followed the Entra audit trail, found the membership event, identified the initiator and reconstructed the access window around it.
Access does not always change because a permission was assigned directly. Sometimes one group membership changes everything.
Today they could reach resources they could not reach before.
Agent Foskett followed the Entra audit trail, found the membership event, identified the initiator and reconstructed the access window around it.
Access does not always change because a permission was assigned directly. Sometimes one group membership changes everything.
Investigation principle: When access appears unexpectedly, investigate the identity and group changes that altered effective permission.
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, Microsoft Sentinel and Microsoft Entra ID.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
Final thought
Unexpected access is not always created by an obvious role assignment.
Sometimes the permission already exists — and the identity is simply moved into the path that grants it.
Find the membership event. Identify the initiator. Establish what the group grants. Then follow the account activity that came afterward.
Yesterday the user was outside the group.
Today they were inside it.
The audit trail knew who changed that.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
Sometimes the permission already exists — and the identity is simply moved into the path that grants it.
Find the membership event. Identify the initiator. Establish what the group grants. Then follow the account activity that came afterward.
Yesterday the user was outside the group.
Today they were inside it.
The audit trail knew who changed that.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
