Agent Foskett Investigation • Microsoft Entra ID • OAuth • Consent Grants • Service Principals • AuditLogs • KQL
The OAuth App Was Deleted — But the Permission Grant Was Still There
The suspicious OAuth application had already been removed.
The administrator opened Microsoft Entra ID and could no longer find it.
The immediate assumption was simple: problem solved.
But Agent Foskett had another question.
What permissions had the application been given before it disappeared?
The live object was gone.
The historical evidence was not.
And the audit trail showed that deleting the app was only the end of the story — not the beginning.
Deleted Does Not Mean Uninvestigable
When an application object disappears, reconstruct the consent and permission timeline from historical telemetry before deciding what the app could access.
✓ Find the consent event
✓ Identify granted permissions
✓ Reconstruct creation and deletion
The application was gone
By the time the SOC began the deeper investigation, the suspicious enterprise application was no longer visible in the tenant. That removed an obvious place to inspect current permissions, owners and configuration. It did not remove the historical evidence showing how the identity entered the environment or what administrators and users had done with it.
Object deletedThe current Microsoft Entra view no longer showed the suspicious application identity.
Consent still matteredThe investigation needed to establish what access had been granted while the object existed.
History became the evidenceAudit telemetry could reconstruct actions that the current portal view could no longer show.
Start with OAuth consent activity
Search Microsoft Entra AuditLogs for consent and permission-grant operations. The goal is to identify when access was granted, who initiated the action and which application or service principal was involved.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any
("Consent", "permission grant", "OAuth2PermissionGrant")
| project TimeGenerated,
OperationName,
InitiatedBy,
TargetResources,
AdditionalDetails,
Result,
CorrelationId
| order by TimeGenerated ascFind the service principal history
Next, look for creation, update and deletion events associated with the application's display name, application ID or object ID. Even when the current object is gone, these events can establish when the service principal appeared and when it was removed.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let AppName = "Document Review Portal";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has AppName
| where OperationName has_any
("service principal", "application")
| project TimeGenerated,
OperationName,
InitiatedBy,
TargetResources,
Result
| order by TimeGenerated ascWhat permissions were actually granted?
The important evidence is not merely that consent occurred. Inspect the target resources and modified properties recorded with the audit event to identify the permission scopes or roles represented in the grant. Depending on the event type and telemetry, some useful details may be embedded in dynamic fields rather than exposed as simple columns.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any
("Consent", "permission grant")
| extend Targets = tostring(TargetResources),
Details = tostring(AdditionalDetails)
| project TimeGenerated,
OperationName,
InitiatedBy,
Targets,
Details,
Result
| order by TimeGenerated ascWho approved the access?
Consent context changes the investigation. A user granting delegated permissions, an administrator granting tenant-wide consent and an automated application-management action are different stories. Preserve the initiating identity and correlate it with sign-in activity around the same time.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ User
| project TimeGenerated,
AppDisplayName,
IPAddress,
ResultType,
ConditionalAccessStatus,
DeviceDetail
| order by TimeGenerated ascBuild the lifecycle timeline
Once the relevant audit events are identified, put them in chronological order. The sequence can show whether consent happened immediately after creation, whether permissions changed later and whether deletion occurred only after suspicious activity was discovered.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let AppName = "Document Review Portal";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has AppName
or tostring(AdditionalDetails) has AppName
| project TimeGenerated,
OperationName,
InitiatedBy,
Result,
CorrelationId
| order by TimeGenerated ascLook for related cloud activity
If Defender XDR or connected cloud telemetry contains activity associated with the application or initiating user, pivot into it. The permission grant tells you what access was authorised; activity evidence helps determine whether that access appears to have been exercised.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let AppName = "Document Review Portal";
CloudAppEvents
| where Timestamp > ago(30d)
| where tostring(RawEventData) has AppName
or Application has AppName
| project Timestamp,
Application,
ActionType,
AccountDisplayName,
IPAddress,
RawEventData
| order by Timestamp ascDeletion changes the present, not the past
The analyst must distinguish the current tenant state from the historical exposure. If the relevant application and associated grant have been removed, that changes what exists now. It does not erase the period during which access was granted, nor does it answer whether the permissions were used before removal.
Current stateDetermine whether the application, service principal and relevant grants still exist.
Historical stateUse audit evidence to reconstruct the permissions and identities involved before deletion.
Activity stateSearch available telemetry for evidence that the granted access was actually exercised.
What the evidence can and cannot prove
A historical consent or permission-grant event proves that access was authorised at that point in time. It does not automatically prove malicious use. Likewise, the absence of a live service principal today does not prove that every related artefact was removed correctly. Verify current state separately from historical activity.
ProvenThe audit trail can establish creation, consent, permission changes and deletion events that were recorded by Microsoft Entra.
Requires correlationWhether those permissions were exercised should be supported by sign-in, application or cloud activity evidence where available.
Do not assumeDeleting one visible object should not be treated as proof that the entire incident has been contained.
Agent Foskett's investigation mindset
When an object disappears before the investigation begins, do not mistake absence for lack of evidence. Historical telemetry can often reconstruct the sequence that the live portal no longer displays.
Reconstruct before concludingFind creation, consent, permission and deletion events before deciding what happened.
Permissions define potentialUnderstand what the application was authorised to do before hunting for evidence that it did it.
Verify containmentConfirm the current state of related application identities and grants rather than relying on one deletion action.
Investigation findings
The suspicious OAuth application was no longer present when the investigation began, but Microsoft Entra audit evidence reconstructed its lifecycle. The logs showed when the service principal appeared, who initiated consent, which permission-grant activity occurred and when the object was deleted. The investigation then moved beyond the deleted object to determine what access had existed and whether available cloud telemetry showed that access being used.
The deletion was not the first eventThe audit timeline exposed the application's history before removal.
The grant mattered more than the nameThe permissions defined the potential impact of the OAuth relationship.
Containment required verificationThe team checked the remaining tenant state and related telemetry rather than assuming deletion closed the incident.
Related Agent Foskett investigations
Continue with OAuth, service-principal and Microsoft Entra identity investigations.
The OAuth App Asked for PermissionInvestigate the consent request that begins an OAuth access story.The New Service Principal Had No OwnerTrace creation, permissions and ownership of an unfamiliar non-human identity.The Service Principal Had Global AdministratorInvestigate excessive privilege assigned to an application identity.
Final thought
A deleted application can disappear from the current Microsoft Entra view while its security story remains in the logs. When the live object is gone, reconstruct the lifecycle: who created it, who consented, what permissions were granted, what activity followed and when it was removed. The portal tells you what exists now. The audit trail tells you what existed when it mattered.
Who granted access?Identify the initiating user or administrator and correlate their activity.
What could the app do?Recover the permission-grant evidence before assessing impact.
What remained afterwards?Verify current tenant state and hunt for related activity before closing the incident.
