Multifactor authentication closes off the attacks that depend on a stolen password alone. It does not protect what is issued after the sign-in. Once a user has authenticated, the identity provider hands out tokens and cookies, and those artifacts are what applications trust for the rest of the session.
Attackers have adjusted. They persuade a user to grant access to an application, relay a sign-in through a proxy, or copy tokens from a compromised endpoint. This article explains those techniques in a Microsoft Entra ID context, what to review in the tenant, which logs record the activity and how to respond.
Why the token became the target
OAuth 2.0 and OpenID Connect separate authentication from access. The user proves who they are once. After that, access tokens, refresh tokens and session cookies carry the proof. A resource such as Exchange Online validates the token it receives. It does not ask how the holder obtained it.
Most of these are bearer tokens: whoever presents one is treated as the rightful holder. Access tokens are short lived. Refresh tokens last far longer and are exchanged for new access tokens without another MFA prompt. A password reset alone does not reliably end that chain, and it has no effect on a consent grant.
Two consequences follow:
- Anything that lets an attacker obtain a token after the MFA step bypasses MFA without breaking it.
- An application that holds its own grant does not need the user's session at all.
Techniques that work against tenants with MFA
Illicit consent grants
The attacker registers a multi-tenant application in a tenant they control, gives it a plausible name and sends the victim a link to the genuine Microsoft consent prompt. The user signs in normally, MFA included, and approves the requested delegated permissions. The application then receives tokens of its own, usually with offline_access so that it can keep refreshing them.
Nothing is stolen in the usual sense. The sign-in is legitimate, the prompt is genuine and the grant persists until someone removes it. If the person consenting is an administrator who consents on behalf of the organization, the grant covers every user.
Device code phishing
The device authorization flow exists for devices that have no browser or keyboard. The attacker starts the flow against a legitimate client ID, receives a user code and sends it to the victim with a pretext such as a meeting invitation. The victim enters the code on the real Microsoft device login page and completes MFA. The attacker, who has been polling the token endpoint, receives the access and refresh tokens.
Adversary-in-the-middle phishing
A reverse proxy sits between the victim and the real sign-in page. The victim sees a working sign-in, types the password and approves the MFA prompt. The proxy relays every step and keeps the session cookie that comes back. Replaying that cookie from another browser yields an authenticated session.
One-time codes, push approvals and SMS can all be relayed this way. Methods bound to the origin of the site, such as FIDO2 security keys, passkeys and Windows Hello for Business, do not complete against a look-alike domain.
Token theft from endpoints
Malware running as the user can copy browser cookies and cached refresh tokens from a signed-in device. Devices joined or registered to Entra ID also hold a primary refresh token (PRT), which provides single sign-on across applications.
The PRT is bound to the device, and its keys are protected by the TPM where one is present, which makes exporting it much harder. An attacker with code execution on the device can still use it in place to request tokens for as long as that access lasts.
Service principals and application credentials
Applications have identities too. An attacker who gains a role such as Application Administrator, or ownership of an app registration, can add a new secret or certificate to an existing application and then sign in as that application with the client credentials flow. No user is involved, so MFA and user-scoped conditional access policies do not apply.
What matters is what the application may do. Application permissions in Microsoft Graph such as Mail.Read and Files.Read.All cover every mailbox and every file in the tenant, not one user's data. Directory.ReadWrite.All allows broad changes to directory objects. AppRoleAssignment.ReadWrite.All and RoleManagement.ReadWrite.Directory can be used to grant further privilege, and should be treated like a highly privileged directory role.
What to review in Microsoft Entra ID
The following areas form the core of an identity security review for a tenant that already has MFA.
- User consent settings. Decide whether users may consent at all. A common position is to allow consent only for verified publishers and a short list of low-impact permissions, and to send everything else through the admin consent workflow so that a named reviewer sees each request.
- Enterprise applications and app registrations. Build an inventory: each service principal, its delegated and application permissions, who consented, its owners, its credentials and their expiry, and its last sign-in. Pay most attention to multi-tenant apps from unverified publishers that hold mail, file or directory permissions.
- Roles that control applications. Application Administrator, Cloud Application Administrator and application owners can add credentials. Keep these assignments few, and eligible instead of permanent where privileged identity management is available.
- Risky sign-ins and risky users. Entra ID Protection includes detections for anomalous token use and unfamiliar sign-in properties. They are useful signals, and they depend on licensing.
- Workload identity sign-ins. Service principal sign-ins are recorded in their own log. Where licensing allows, conditional access for workload identities can restrict where a single-tenant service principal signs in from.
Conditional access, token protection and continuous access evaluation
Conditional access is where several of these paths are narrowed. Require a phishing-resistant authentication strength, starting with administrators. Require a compliant or hybrid joined device for sensitive applications, a condition that a phishing proxy cannot satisfy. Block the device code flow with the authentication flows condition, with exceptions only for the users and devices that need it.
Token protection binds sign-in session tokens to the device they were issued to. It supports a limited set of clients and resources, so check the current scope and run the policy in report-only mode before enforcing it.
Continuous access evaluation lets supported services such as Exchange Online and SharePoint Online reject a token shortly after a critical event, for example account disablement, a password change or session revocation. It applies only to clients and resources that support it. None of these controls is a guarantee. Each one removes a path or shortens the time a stolen token stays useful.
Telemetry that shows OAuth abuse
| Source | What to look for |
|---|---|
Entra AuditLogs |
"Consent to application", "Add delegated permission grant", "Add app role assignment to service principal", "Add service principal", "Add service principal credentials", and "Update application" events that record certificate or secret changes |
SigninLogs (interactive) |
Sign-ins where the authentication protocol is device code, unfamiliar application names, an IP address or user agent that changes shortly after a successful MFA |
| Non-interactive user sign-ins | Token refreshes from networks the user has never used. A replayed refresh token appears here, not in the interactive log |
| Service principal sign-ins | Application sign-ins from new IP addresses, or soon after a credential was added |
| Microsoft 365 unified audit log | MailItemsAccessed, New-InboxRule, Set-InboxRule, forwarding changes, bulk file downloads, and records where the application ID is one you do not recognize |
Many tenants export only SigninLogs and AuditLogs to their SIEM. Non-interactive and service principal sign-ins are separate categories in the Entra diagnostic settings and must be selected. Without them, token replay and application abuse are largely invisible.
Sequence matters more than any single event. A consent event followed by mail access from the same application ID is a far stronger signal than either alone. Writing and testing those correlations is detection engineering work, and it should include the false positives produced by legitimate app onboarding.
Responding to a suspected token or consent compromise
- Scope before removing anything. Identify the user, the application ID, the service principal, the source IP addresses and the time of the first grant or sign-in. Export the grant details and the sign-in records.
- Revoke the user's sessions. This invalidates refresh tokens. Access tokens already issued stay valid until they expire unless the resource enforces continuous access evaluation. Reset the password. If endpoint theft is suspected, isolate the device and keep the user off it until it is cleaned or rebuilt.
- Check what was added. Review authentication methods and registered devices created during the window. An attacker who registers an MFA method or a device keeps access after the session is revoked.
- Remove a malicious application. Disable sign-in for the service principal, remove its delegated permission grants and app role assignments, and delete it once evidence is captured. Revoking user sessions does not remove the grant itself.
- Clean up an abused legitimate application. Remove the credentials the attacker added, rotate the remaining secrets and certificates, and review what the application did through service principal sign-ins and, where enabled, Microsoft Graph activity logs.
- Review the mailbox and data. Look for inbox rules, forwarding, delegate access, external sharing links and any further consent or role changes made by the compromised identity.
These steps belong in a written runbook that the incident response team has rehearsed, with the required Entra roles assigned in advance.
Where to start
- Check the user consent setting and turn on the admin consent workflow with named reviewers.
- Export every service principal with its permissions, and review each one that holds tenant-wide mail, file or directory access.
- Send audit logs, non-interactive sign-ins and service principal sign-ins to the SIEM, and alert on consent and credential changes.
- Block the device code flow for everyone who does not need it, and require phishing-resistant MFA for administrators.
- Write the token compromise runbook and walk through it once with the people who would run it.