Suspicious OAuth consent: investigate the application's access
Connect consent, service principals, permissions and observed activity to assess suspicious OAuth access and verify a targeted response.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
Someone reports accepting an unusual access request. The application has a reassuring name and the human sign-in shows no obvious anomaly. The SOC still needs to answer another question: what access did the application obtain, and which operations can actually be linked to it?
Microsoft's illicit-consent guidance explains why password resets or MFA alone do not address this application-access mechanism. That does not establish that a particular consent is malicious; it identifies where investigation must continue. Source: Microsoft, detecting and remediating illicit consent grants
The examples concern Microsoft Entra. The method is independent of the collection tool and assumes no available Seculogik integration. Verify investigation and response capabilities in your environment with authorized people.
1. Separate the request, granted access and use
Our recommendation: open the case with three distinct observations. What did the application request? What permission was actually granted? What activity can be found on the resource? A consent-screen screenshot replaces neither a permission inventory nor evidence of an operation.
Preserve the initial report, directory, period, targeted resources and references to collected evidence. A familiar display name does not identify the application on its own. Excessive permission can justify protection even when use remains unknown; that decision must retain its reasoning and limitations.
Establish who can confirm the business need. The user may explain their intention without having technical visibility into every permission. Ask the service owner to confirm expected use without relying solely on the potentially compromised account.
2. Identify the application and its local principal
Microsoft distinguishes the application object from its local representation, the service principal, in a directory. The global application identifier and local principal's object identifier therefore describe different objects. Source: Microsoft, application and service principal objects
Our recommendation: record the directory, appId, service principal objectId, target resource and observed actor together. Include display names for readability without using them as the sole correlation key. Record the source of each identifier and check that exports refer to the same object.
Resolve differences between the declared application, present principal and authorized resource. Name-only searches may join different objects or miss a rename. If an object is no longer available, preserve its references in historical evidence and mark what cannot be checked against current state.
3. Classify permissions precisely
Delegated permissions let an application act on behalf of a signed-in user. Graph records them as oAuth2PermissionGrant objects: clientId identifies the client service principal object, not its appId; resourceId identifies the resource principal. The consentType distinguishes individual consent from consent covering all users. Source: Microsoft Graph, oAuth2PermissionGrant
Our recommendation: record the resource, actual granted scopes, consent type and relevant user where applicable. Keep the observed requester separate from the permission's beneficiary. Do not infer scope solely from an “admin consent” label.
An appRoleAssignment can concern a user, group or service principal. An application role assigned to the client service principal represents an application permission. Not every role assignment should therefore be classified as independent application access. Source: Microsoft Graph, appRoleAssignment
Our recommendation: identify beneficiary type, resource and exact role, then compare the assignment with approved need. Preserve authorization-object identifiers so responders can make a targeted decision rather than remove everything matching a list of names.
4. Build two timelines and retain unknowns
Entra audit logs describe changes affecting applications, among other objects. Microsoft documents actor, target, status and, where applicable, old and new property values. Source: Microsoft, Entra audit logs
Our recommendation: first build the authorization timeline: principal creation or modification, consent, permission changes and any removal. Preserve zoned timestamps, identifiers, reported outcome and source. Distinguish current visible state from the state demonstrated during the period under investigation.
Then build the usage timeline: available application authentication records, resource access and operations actually logged. A consent event does not establish document reading. Successful authentication alone does not prove an export. For each conclusion, identify supporting evidence and how strongly it links to the application.
Ask about actual coverage, enabled categories, exclusions and retention or export limitations. An empty search must remain “no use found in the sources examined” when those limits prevent a stronger conclusion. Do not invent a timeline to fill missing history.
5. Prepare a targeted, authorized response
Microsoft's permission-review guidance distinguishes user and admin consent. Removal mechanisms differ: the documentation notes that user consent cannot be revoked from the corresponding portal tab and requires the supported interfaces. Source: Microsoft, reviewing application permissions
Our recommendation: have the identity team and business owner define the target. Which permission, resource, principal and population require treatment? Who authorizes disruption, and who can execute and check the action? A generic deletion command does not replace those decisions.
Preserve useful evidence where urgency permits. If protection must precede collection, record what becomes unavailable. Assess legitimate dependencies and fallback options; automatically blocking every application and automatically retaining every permission are both inadequate defaults.
A provider seeing the alert may not administer the directory. If the authorized operator is unavailable, use the planned fallback and inform the decision maker about waiting risk. Distinguish a submitted request, completed action and verified outcome.
6. Check the effect and possibility of renewed consent
Microsoft states that revoking a granted permission does not itself prevent a user from consenting again to the application's request. Prevention of renewed authorization therefore needs separate assessment. Source: Microsoft, permission-revocation limitations
Our recommendation: check affected objects after the action and investigate relevant subsequent changes or activity. Have responders verify session and token effects for the particular mechanism and service; promise neither instantaneous termination nor a universal delay from permission removal alone.
Any access test must be prepared by an authorized operator within approved scope, without obtaining and replaying a suspicious token. Examine risk-appropriate consent policy, exceptions and legitimate needs as well. A preventive control must be tested or remain explicitly unverified.
An exercise and a usable conclusion
Entirely fictional case: an application presented as a filing tool receives user consent. Inventory confirms delegated access to a document resource. Logs establish consent, but available sources do not let investigators attribute a file read to that application.
The business owner does not recognize the need. The identity team removes the targeted authorization under mandate and verifies its state; preventing renewed consent remains a separate action. The case does not conclude “no data accessed”: it retains the visibility limitation and assigns further collection to an owner.
To accept the exercise, another analyst must locate exact objects, observed permissions, proven or unknown use, response authority and completed checks. The conclusion distinguishes facts, accepted risk and the next decision. No outcome in this example describes a real customer or product capability.
Use our free investigation resources to record the evidence. To prepare an access and response-procedure review, talk to us about your project.