OAuth Consent Investigations: Permissions, Actors and Audit Evidence

Technique & Investigation of the Day · Educational, defensive guidance for authorized environments.

Why it matters

An application can receive access through a genuine consent screen and still be inappropriate for the user or organization. Evaluate the application identity, permission grant and observed use separately. A recognizable application name or a successful consent event is not enough to establish trust.

OAuth consent investigations: investigation path. Preserve the grant; Validate the application owner; Consent and permission-change audit events with actor, application and resource identifiers.; Assess competing explanations; Escalate; assess containment impact; Improve the approval record — Original conceptual investigation workflow. No real customer data is shown.

Required telemetry and evidence

Consent and permission-change audit events with actor, application and resource identifiers.
Service principal, publisher and permission inventory, including delegated versus application access.
Application sign-ins and resource audit events where available.
Approval records, application ownership and the relevant consent policies.

Before drawing conclusions, record collection scope, retention and any missing fields. Keep sensitive evidence in approved internal systems.

Step-by-step investigation

1. Preserve the grant

Record stable application and service-principal identifiers, consent time, actor, resource and granted permissions. Display names can change or resemble legitimate products.

2. Determine the permission model

Distinguish user-delegated permission from application permission and identify the effective scope. An administrator consent action can affect a different population than a single user’s grant.

3. Validate the application owner

Compare the exact identity and permission request with the approved application record. Publisher information helps establish context but is not a complete security assessment.

4. Query subsequent use

Look for application sign-ins and resource actions consistent with the grant. Separate permission to access information from evidence that information was actually accessed.

5. Assess competing explanations

Check recent integrations and approved onboarding. Unexpected broad access, no accountable owner and unexplained resource activity together warrant more scrutiny than a permission label alone.

6. Improve the approval record

Document why the grant was legitimate, unauthorized or unresolved. Feed the result into consent review and inventory maintenance rather than treating removal of one grant as the entire lesson.

OAuth consent investigations: evidence checklist. Consent and permission-change audit events with actor, application and resource identifiers.; Service principal, publisher and permission inventory, including delegated versus application access.; Application sign-ins and resource audit events where available.; Approval records, application ownership and the relevant consent policies. — Original conceptual evidence checklist. No real customer data is shown.

Read-only investigation pseudocode

INPUT authorized consent and application activity exports
SELECT new or expanded grants within scope
RESOLVE actor, application ID, resource and permission model
CORRELATE subsequent resource activity
COMPARE with approval and owner records

Test and adapt: this is illustrative pseudocode, not executable vendor syntax or a tested production detector. Validate field semantics, time boundaries and results in an authorized environment. It does not change systems.

Legitimate activity versus suspicious activity

Collaboration integrations and migration tools can request broad access for legitimate reasons. Their scope should match a documented purpose and review period. An app that copies a familiar name but has a different identifier must be evaluated independently.

Tuning and false positives

Tune by exact app identity, permission scope and approved population. Review material permission changes even for known apps. Avoid a blanket exception for all verified publishers or all grants by privileged users.

Escalation, containment and documentation

Coordinate grant removal and session/application response with identity and service owners. Revocation can interrupt production integrations. Preserve grant and resource evidence and investigate the affected scope under the approved incident process.

Close with an evidence-based disposition: explained activity, supported escalation or unresolved visibility gap. Include identifiers, times, source coverage, competing explanations and the response owner.

MITRE ATT&CK context

Use behavior-specific ATT&CK mapping after establishing what occurred. Consent alone does not demonstrate token theft, credential theft or information collection.

Key takeaways

Preserve the grant: define the question before broadening the search.
Assess competing explanations: corroborate the explanation with independent evidence.
Keep the observed facts, assumptions and response decisions separate.

References

Microsoft: app consent investigation

Original educational workflow and conceptual diagrams for Hack Invasion. Public documentation informs source-specific details; investigation decisions require local validation.