--- title: OAuth Consent Abuse Bypasses MFA Through Third-Party App Permissions - Capstone Technologies Group description: OAuth consent abuse grants attackers refresh tokens that survive password resets and MFA re-enrollment. How the attack chain works and what audit logs reveal. canonical_url: https://captechgroup.com/threat-intelligence-center/oauth-consent-abuse-bypasses-mfa-through-third-par-3e298c language: en-GB date: 2026-09-19T12:35:41Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/oauth-consent-abuse-bypasses-mfa-through-third-par-3e298c. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 5850 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/oauth-consent-abuse-bypasses-mfa-through-third-par-3e298c. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. Attackers are getting into SaaS tenants by asking users for permission. A link arrives through email, chat, a shared document, or an issue tracker, and it leads to a real OAuth authorization flow at a provider your staff already trust. The application on the other side presents itself as something ordinary, like a productivity connector, a reporting tool, or a workflow assistant. Original reporting for this article comes from [Dark Reading](https://www.darkreading.com/vulnerabilities-threats/mfa-oauth-consent-abuse "Source: Dark Reading"). Because the user is already signed in, the prompt feels routine. The consent screen lists the permissions the app wants. The user clicks approve. From that point the attacker no longer needs a password. Depending on the provider, the app type, your tenant policy, and the scopes granted, they hold tokens or app grants that allow ongoing API access until someone revokes the permissions or invalidates the tokens. Nothing was stolen and nothing was installed. Access was delegated, which is exactly what OAuth was built to do. This is why MFA does not cover the gap. MFA secures authentication, meaning it proves the person logging in is who they claim to be. It has no say over what that person is allowed to authorize afterward, and subsequent API access by the app does not re-prompt the user for a second factor. What the attacker can reach depends on the scopes approved. The source describes access that includes reading and searching mailboxes, enumerating files, extracting source code, modifying repository settings, reading CI/CD metadata, and interacting with business platforms through approved APIs. For your security team, the activity looks unremarkable. Sign-ins succeed, the domains are legitimate, and the API traffic is authorized. Endpoint and network tools generally see nothing, because there is no malware and no traditional command-and-control channel to catch. The consent decision, made by one user in a few seconds, becomes a standing access path into email, file storage, and source control. OAuth consent abuse in SaaS tenants 1 A link arrives by email, chat, a shared document, or an issue tracker and points to a genuine authorization flow at a trusted provider. 2 The application poses as a productivity connector, reporting tool, or workflow assistant. The user is already signed in, so the permission screen looks routine.OAuth authorization request 3 The attacker holds tokens or app grants instead of a password. MFA covers authentication only, and later API calls do not re-prompt for a second factor.High 4 Granted scopes allow mailbox reading and search, file enumeration, source code extraction, repository setting changes, CI/CD metadata reads, and calls to business platforms. 5 Sign-ins succeed, domains are legitimate, and API traffic is authorized. With no malware or command-and-control channel, endpoint and network tools see little until the grant is revoked or tokens are invalidated.High ## The Consent Grant Attack Chain Step by Step The chain starts before any user sees a prompt. The attacker registers an application in a cloud tenant they control, gives it a display name that reads like ordinary business tooling, and populates the publisher and reply URL fields so the consent screen looks unremarkable. Nothing about that registration touches your environment, which is why there is no early signal to catch. Next comes scope selection. The attacker builds an authorization URL that requests exactly the permissions needed for the objective: read access to mail, read/write access to files across the tenant, directory read for user enumeration, and `offline_access` so the authorization server issues a refresh token alongside the short-lived access token. That last scope is the one that converts a single click into durable access. Delivery reuses whatever channel the target already trusts. A [phishing](https://attack.mitre.org/techniques/T1566/ "MITRE ATT&CK: T1566") message, a calendar invite, a link pasted into a chat thread, or a message sent from an internal account the attacker already controls all work, because the destination is a genuine provider authorization endpoint. This maps to **MITRE ATT&CK T1528 (Steal Application Access Token)**, with delivery through T1566 phishing. The permission model determines the blast radius. Delegated permissions let the app act as the consenting user and are bounded by that user's own rights. Application permissions let the app act on its own behalf across the tenant and generally require an administrator. A standard user granting delegated mail access exposes one mailbox. An administrator granting application-level file or directory permissions exposes the tenant, which is why attackers aim their lures at accounts holding global admin, application admin, or cloud application admin roles. Once consent is recorded, the provider creates a service principal in your directory representing that external app, and the attacker holds a refresh token. Refresh tokens survive password changes in many configurations and are not invalidated by re-enrolling MFA, because the token was issued to the application rather than minted from the user's current credential. The practical consequence: standard account-compromise response steps can complete while the attacker's API session keeps running. The source states plainly that access continues until the permissions are revoked or the tokens are invalidated. Post-consent activity runs entirely through approved APIs. Observed behaviors in this pattern include: - Bulk mailbox reads and targeted keyword searches across historical mail (T1114.002) - Creation of inbox rules that auto-forward or hide replies, giving the attacker a persistent feed of new correspondence (T1114.003) - Enumeration and download of OneDrive and SharePoint content, including credential material stored in documents - Directory enumeration to map users, groups, and role holders for the next consent lure - Repository setting changes and access to CI/CD metadata where source control is connected Because this traffic originates from the provider's own API surface using valid tokens, endpoint agents and network sensors see nothing anomalous. There is no implant, no beaconing, and no command-and-control channel of the kind those tools were built to find. The observable evidence lives in identity and audit logs. Look for service principal and OAuth2 permission grant creation events, first-time consent to an app with no prior tenant history, admin consent granted outside change windows, and sudden volume spikes in Graph or equivalent API calls tied to a new application ID. Token use from ASNs, hosting providers, or countries that do not match the consenting user's normal sign-in pattern is another marker, as is an account whose read volume jumps from a handful of documents to bulk retrieval within the same authenticated session. OAuth consent abuse: stage by stage 1 The attacker registers an application in a tenant they control, with a display name, publisher and reply URL that read like ordinary business tooling. Nothing touches the target environment.Low 2 An authorization URL requests mail read, tenant-wide file read/write, directory read for user enumeration, and the scope that returns a refresh token alongside the access token.offline\_access 3 Phishing mail, a calendar invite, a chat link, or a message from an already-controlled internal account carries the link, since the destination is a genuine provider authorization endpoint.T1566 / T1528 4 Delegated permissions bound the app to the consenting user's rights; application permissions act tenant-wide. Lures target global admin, application admin, and cloud application admin roles.High 5 A service principal for the external app appears in the directory and the attacker holds a refresh token. Password resets and MFA re-enrollment do not invalidate it; access continues until permissions are revoked or tokens invalidated.High ## Business Exposure From Tokens That Outlive Credential Resets A revoked password does nothing to an OAuth grant. When your helpdesk resets a user's credentials and re-registers their MFA method, the app grant and its refresh token keep working, because they were issued against an authorization the user gave rather than against the password. That is the operational gap: your standard account-compromise playbook closes the front door while the API session stays open. Because the access continues until someone explicitly revokes the grant or invalidates the tokens, these compromises tend to run long. There is no failed login pattern, no malware alert, no unusual endpoint behaviour to trip over. Your security team sees successful sign-ins, a legitimate provider domain, and API traffic that looks like every other integration in the tenant. What the attacker does with that time is read. Mailbox access lets them search executive and finance correspondence for payment terms, banking details, pending acquisitions, and legal advice. Document store access lets them enumerate and pull files in bulk. None of that requires writing anything back, which is why the activity can pass as ordinary usage for extended periods. Mailbox read access is also the raw material for invoice fraud. An attacker who can follow a live payment thread knows the supplier, the amount, the approval chain, and the tone your finance staff use with each other. Business email compromise built on that level of context is considerably harder for your accounts payable team to question, and the redirected payment usually comes out of your own funds while the dispute is resolved. Scoping the incident afterwards is where the cost multiplies. When access arrives through an approved API rather than a login, you cannot simply pull a list of sessions from one place and draw a line around them. You need the sign-in records to establish who consented and when, the audit logs to establish what the grant permitted, and the Graph or equivalent API activity to establish what was actually read. Those sources live in different places, have different retention periods, and do not always correlate cleanly by user. - Which mailboxes and sites the application touched, and whether it read or only enumerated - Whether the grant was tenant-wide or limited to the consenting user's own data - Whether refresh-token activity originated from infrastructure you have never seen before - Which downstream SaaS platforms the same application also held access to That uncertainty has a direct regulatory consequence. GDPR and comparable regimes treat unauthorised access to personal data as a reportable event regardless of how the access was obtained, and consent-based access is unauthorised the moment it was obtained through deception. If your logs cannot show what the application read, your counsel is likely to advise notifying on the assumption that everything within scope was accessed. Your notification population becomes the size of the permission, not the size of the confirmed theft. There is a supply-chain version of this as well. If a SaaS vendor you already approved has its own app registration compromised, the grant in your tenant is genuine, the publisher is verified, and the integration has been running for months. Your review process has no reason to flag it, and the access reaches whatever data you authorised the vendor to handle. ## Detecting Malicious Consent Grants and Rogue Service Principals Begin with an inventory pass, because you cannot spot a rogue grant without knowing what normal looks like in your tenant. Export every enterprise application and service principal that already holds a delegated or application permission, then sort by scope sensitivity rather than by app name. Most organizations doing this for the first time find consents they never approved, apps whose business owner left the company, and integrations granted years ago that still hold mail or file permissions. Once you have that baseline, the hunting queries are straightforward. In Entra ID audit logs, filter on the operations `Consent to application`, `Add service principal`, and `Add delegated permission grant`. Those three events tell you when an app entered your tenant, who authorized it, and what it was allowed to touch. Pull the initiating user, the target application ID, and the permission strings from each record. The patterns worth escalating are specific: - A newly registered application receiving high-privilege scopes within minutes of its first appearance in your tenant. - Apps with no verified publisher, or a publisher domain that does not match the vendor the app claims to be. - Consent events clustered in time across multiple users, which usually means one link circulated through a team channel or distribution list. - `offline_access` requested alongside mail or file permissions, since that combination is what converts a one-time approval into continuing API access. - Admin consent granted outside your normal change window or by an account that does not usually approve integrations. Your sign-in logs carry the second half of the picture. Filter for service principal sign-ins rather than user sign-ins, and look at the source infrastructure behind them. Token activity originating from hosting providers or geographies your staff never work from is one of the clearest post-consent signals available, and the source guidance calls out refresh-token use from unfamiliar infrastructure specifically. For tooling, Microsoft Defender for Cloud Apps lets you build OAuth app policies that alert or auto-revoke when an app requests scopes above a threshold you define. The Entra ID risky applications view surfaces apps flagged for suspicious registration or credential behavior. On the Google side, the Workspace admin console app access reports show which third-party apps hold which API scopes and let you restrict access by scope category. Several open-source review scripts also dump tenant app registrations with scope detail, which is useful when you want a point-in-time snapshot you can diff against last quarter's export. Getting those audit events into the same place as the rest of your identity telemetry is what makes the detection durable. In environments Capstone manages, Adlumin ingests directory audit and sign-in data so a consent grant to an unverified publisher, or a burst of service principal additions, produces an alert that a human reviews. Without that correlation, the events sit in a portal nobody opens between quarterly reviews. Finally, watch what the authorized identity does afterward. A user whose normal pattern is opening a handful of documents, then suddenly performing bulk downloads, mailbox searches, repository configuration changes, or CI/CD updates through an API, warrants investigation even though the session is fully authenticated and passed MFA. Set your review cadence so every app holding high-value scopes gets revalidated on a schedule, with an accountable owner recorded against each one. ## Containment and Hardening Actions for Identity Administrators Delete the app grant before you do anything else. Resetting the password, re-registering MFA, and revoking sign-in sessions do not touch the consent record, so the application keeps calling APIs with the permissions it was given. In the Entra admin center, go to `Enterprise applications`, open the offending app, and remove both the user consent and the service principal object itself. Once the grant is gone, invalidate refresh tokens for every account that approved the app, not only the first user you found. Consent phishing campaigns usually land in several inboxes at once, and a single unrevoked token restores the attacker's access to everything the scopes cover. Then clean up what the access was used for. Mail-level persistence is the most common follow-on, so pull and review: - Inbox rules that move, mark as read, or delete messages containing finance or security keywords - Mailbox forwarding, both user-configured forwarding and transport rules at the tenant level - Delegate and mailbox permission changes made during the exposure window - Any app-created secrets, certificates, or connected API keys that should now be rotated Finish the immediate phase with a scope audit. Write down exactly which permissions were granted and map each one to the data it reaches, whether that is mailbox content, tenant-wide file storage, directory information about your staff, repository contents, or pipeline metadata. That mapping is what your legal and compliance team will use to decide notification obligations, so it needs to be accurate rather than approximate. In the short term, close the approval path. Under `Enterprise applications > Consent and permissions > User consent settings`, move end users off unrestricted consent. The workable middle setting allows user consent only for apps from verified publishers requesting low-impact permissions, which keeps calendar and small productivity connectors flowing while sending anything touching mail, files, or directory data to review. Turn on the admin consent workflow at the same time and staff it properly. Name the reviewers, set a response time your business can live with, and require a stated business justification plus an accountable owner on every request. If reviews take a week, staff will find unsanctioned workarounds and you lose the visibility you just built. Also restrict group and team owner consent, which is a separate setting and a frequent gap. Where your licensing supports it, apply Conditional Access to workload identity sign-ins so service principals can only authenticate from expected network locations, which limits how useful a stolen token is from unfamiliar infrastructure. For the longer term, put app registrations on a review cadence the same way you review firewall rules. Each quarter, pull the list of consented applications, confirm the business owner is still employed and still needs the integration, and strip scopes that exceed the current use case. Apps with no identified owner get removed. Build an approved-app allowlist from that review so requests can be answered quickly, and extend the same controls to every identity provider you run. If you use Google Workspace alongside Microsoft 365, configure app access control so unconfigured third-party apps are blocked by default and only trusted apps reach Gmail and Drive APIs. Finally, add consent phishing to awareness training as its own scenario. Show staff a real authorization screen and teach them to ask why the app needs those specific permissions, who published it, and whether your organization approved it. Track completion for the teams with the most sensitive mailbox and repository access first. ## Treating Application Consent as a Privileged Access Decision An OAuth consent is an access grant, and it belongs in the same category as adding someone to a privileged group or opening a firewall rule. When a user approves an application, they are issuing delegated authority over mail, files, repositories, CRM records, or cloud console data through approved APIs. Your identity metrics rarely reflect that. MFA adoption rates, blocked risky sign-ins, and privileged account coverage all describe authentication, and none of them tell you who in your organization can hand third-party applications access to enterprise data. That is the question worth answering before anything else. Scope approvals deserve the same scrutiny you already apply to production access and privileged roles: specific, justified, documented, and revalidated on a schedule. A calendar integration asking for broad file access is a configuration you would reject in any other part of your stack. The highest-value action is to remove unrestricted end-user consent as a default and review the application grants that already exist in your tenant for high-privilege scopes. Everything else in OAuth governance depends on knowing what has already been authorized and limiting who can authorize more. Train your users toward a different question at the prompt. Confirming the page really belongs to Microsoft, Google, GitHub, or Salesforce settles nothing, because the authorization flow is genuine. The useful questions are why this application needs these permissions, who published it, and whether your organization approved it. That is a harder lesson than traditional phishing awareness, and it is the one that matches how access is actually granted in SaaS environments. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-09-19T12:35:41Z", "datePublished": "2026-09-19T12:35:41Z", "description": "OAuth consent abuse grants attackers refresh tokens that survive password resets and MFA re-enrollment. How the attack chain works and what audit logs reveal.", "headline": "OAuth Consent Abuse Bypasses MFA Through Third-Party App Permissions", "image": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/oauth-consent-abuse-bypasses-mfa-through-third-par-3e298c" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/oauth-consent-abuse-bypasses-mfa-through-third-par-3e298c" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "45504-1583", "streetAddress": "2071 N Bechtle Ave, Box 143", "addressCountry": "US" } ] } ```