Search Microsoft Purview Audit or the Audit area in the Microsoft Defender portal for Consent to application, then investigate the app, permissions, consent scope and related sign-in activity. Treat the event as a lead—not proof of phishing: legitimate apps also receive consent, and Microsoft says the act of consenting alone is not malicious.
What OAuth consent phishing looks like
In this attack, a user is persuaded to authorize an attacker-controlled application, often through a phishing link or another attacker-controlled route. The app can then call APIs with the access the user granted. Unlike password theft, this can leave an app authorized to act on a user’s behalf; resetting the password or requiring MFA does not itself revoke that grant. Microsoft’s application security operations guidance and its incident response playbook describe this pattern.
As an Amazon Associate I earn from qualifying purchases.
How to find consent events in Microsoft 365
- Open Microsoft Purview Audit or the Audit area in the Microsoft Defender portal. Search the relevant date range and, where useful, narrow by user. The audit search is available in Audit Standard and Audit Premium, subject to subscription and licensing-dependent retention. See Microsoft’s audit log search guidance.
- Search for the activity Consent to application. Open matching records and inspect the event details, including IsAdminConsent, the actor, targets and other available properties. Microsoft’s guidance says an audit entry may take 30 minutes to 24 hours to appear; do not treat an empty recent search as conclusive.
- Save the event details and time range for correlation. An admin-consent indicator can signal broad access, but it does not establish that the grant was malicious.
Microsoft lists related ApplicationManagement audit activities: Add delegated permission grant indicates delegated access; Add app role assignment to the service principal indicates app-only access. Corresponding remove activities record revocation. Use these names to guide the investigation, then inspect the targets and details rather than relying on the label alone. See Microsoft Entra application-permission audit events.
How to assess the app and consent scope
For each unexpected event, identify the application and the grant it received. Review the consent type, resource or API, granted scopes, app purpose, publisher verification, app name, domain and redirect URI. Ask whether the permissions make sense for the app’s stated function and whether the app was approved under your organization’s process.
- Principal means consent for an individual user’s account data. AllPrincipals means an administrator granted tenant-wide consent. Tenant-wide grants can increase potential impact, but they are not automatically malicious.
- Pay particular attention to broad or high-impact delegated permissions and app-only roles that expose sensitive APIs. Confirm exactly what was granted and which users or resources it can affect.
- Check names and domains carefully. Attackers can imitate familiar app names or use lookalike domains and redirect URLs. A verified publisher is useful evidence, not a substitute for reviewing the requested scopes and the app’s purpose.
- Do not assume that broad permissions make an app malicious: native Microsoft 365 apps may legitimately need them. Validate the app’s identity, actual tenant context and expected function before drawing a conclusion.
Microsoft’s consent-grant incident response playbook explains the Principal and AllPrincipals distinction and the investigation steps.
How to confirm whether the event is an attack
There is no single audit field in Microsoft’s guidance that proves consent phishing. Build a timeline around the grant and check whether the user, app and permissions fit the circumstances.
- Review Entra audit logs for the consent and subsequent grant changes. Identify the consenting user, affected application, granted permissions and the period during which access was available.
- Review sign-in activity for users authorized to use the app, concentrating on the relevant time period and any activity that is unexpected for those users or the app.
- Compare the app, publisher, domain and redirect URI with the organization’s approved application inventory and the user’s business need. Ask the user or app owner whether they expected to approve the prompt.
- Determine which users and data could have been exposed based on the grant and available activity records. If auditing was not enabled before the suspected incident, audit-based scoping for the missing period is unavailable.
The Entra admin center supports visual review of grants for one user at a time. Microsoft’s playbook also describes PowerShell inventory for reviewing grants and OAuth apps across users. Its portal method shows admin-consent grants only for the last 90 days; that is a limitation of the documented method, not proof that older grants do not exist. Retention and visibility depend on licensing and the route used. See the incident response playbook and application security operations guidance.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Which warning signs deserve investigation?
- An unexpected grant by a privileged user or someone with access to sensitive information.
- High-impact scopes, app-only roles for sensitive APIs, or an AllPrincipals grant without a clear approved need.
- An unfamiliar or misspelled app name, suspicious publisher, questionable domain, or unexpected redirect URI.
- Permissions that are excessive or unrelated to the app’s stated purpose, or a grant that the user and app owner do not recognize.
These are investigation signals, not a verdict. Microsoft explicitly cautions that consenting itself is not malicious; confirm the app’s identity, purpose, permission scope and organizational context before classifying an event as an attack.
How to contain a confirmed malicious grant
- Revoke the malicious OAuth consent grant or app-role assignment so the authorization is removed.
- Disable the malicious application to prevent it from obtaining new tokens.
- Investigate affected users and the access window using the permissions and activity records available to your organization. Address any other account or data exposure identified during that review.
- Report the malicious application through Microsoft’s documented process. Microsoft’s response playbook covers revocation and reporting.
A password reset alone is not containment for an OAuth grant: it does not revoke the application’s authorization.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to reduce the chance of a repeat
- Restrict user consent to applications that meet organizational criteria, such as verified publishers and selected low-risk permissions.
- Train users and administrators to examine the publisher, requested permissions and app purpose before approving a prompt.
- Review consent grants routinely; Microsoft recommends weekly reviews for organizations with many apps and users.
- For continuous monitoring, consider application governance or Defender for Cloud Apps policies where licensed. Microsoft’s security operations guidance also identifies end-user consent events and high-risk delegated grants or app-role assignments to sensitive APIs as monitoring candidates, including Sentinel templates for alerting.
Choose a review or alerting approach that fits tenant scale, available licensing, retention requirements and whether the team needs continuous monitoring or periodic checks. See Microsoft Entra security operations for applications.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
