Skip to main content
Zeem Tech Solution Cloud and Cybersecurity Hub
Microsoft 365 · Cybersecurity

Malware campaign hijacks Microsoft 365 tenants through malicious OAuth consent apps

Sana Farooq 47 comments 7 min read

Attackers are registering look-alike enterprise applications in Microsoft 365 tenants and phishing global administrators into approving them. Because the victim approves a consent screen rather than typing a password, multi-factor authentication never enters the picture.

The consent-grant chain: a look-alike app requests Mail and Directory scopes, and an administrator approves it in one click.

Over the past three weeks we have reviewed audit logs from more than thirty tenants hit by the same pattern. In every case the entry point was an OAuth consent grant, not a stolen password. The attacker registers a multi-tenant application with a name close to something the organisation already uses — “Contoso Mail Archiver”, “M365 Backup Connector” — then sends a targeted email to a global administrator asking them to approve it.

One click on the consent screen grants the application Mail.ReadWrite and Directory.ReadWrite.All permanently, as an application permission. From that point the attacker holds a token that survives password resets, does not prompt for MFA, and does not appear in the sign-in logs an administrator normally watches.

Why MFA does not help here

Multi-factor authentication protects the act of signing in. Consent grants are a separate authorisation flow: the administrator has already signed in, with MFA, and is now delegating access to an application. The attacker never handles the credential at all, so nothing in the MFA chain is bypassed — it is simply not involved.

This is why the campaign is effective against tenants that consider themselves well-protected. Conditional access, password policy, and MFA enforcement are all working exactly as configured. The gap is that any global administrator can grant tenant-wide application permissions, and by default in many tenants so can ordinary users for lower-privilege scopes.

How to tell whether you are affected

The evidence lives in the unified audit log and in Entra ID’s enterprise applications blade. Look for these three events, in this order:

  1. Add service principal — a new application appears in the tenant.
  2. Consent to application — an administrator approves it, with the requested scopes recorded in the event detail.
  3. Add app role assignment grant to user — the permissions are attached.

In Microsoft Purview, search the audit log for the Consent to application operation over the last ninety days and export the results. For each grant, read the ModifiedProperties field: it lists the scopes that were approved. Anything containing Mail.ReadWrite, Mail.Send, Directory.ReadWrite.All, or Files.ReadWrite.All deserves a second look, especially where the publisher is unverified.

What a malicious grant tends to look like

  • The publisher is unverified, or the publisher domain does not match the app name.
  • The app was registered days — sometimes hours — before the consent event.
  • Reply URLs point at a domain unrelated to your organisation or to the vendor being impersonated.
  • The scopes are far wider than the app’s stated function needs.
  • The consent happened outside working hours, from an unusual location.

Containment, in order

If you find a grant you cannot account for, work through these steps rather than simply deleting the application — deleting first destroys the evidence you need for the investigation.

  1. Export the audit trail for that service principal before changing anything.
  2. Revoke the grant in Entra ID under Enterprise applications, then delete the service principal.
  3. Revoke refresh tokens for any account that interacted with the app; tokens already issued remain valid until they expire otherwise.
  4. Check for persistence — inbox rules that forward or delete mail, new mailbox delegations, and added credentials on the app registration itself.
  5. Review what was reachable with the granted scopes, and treat that data as exposed until proven otherwise.

Closing the door for good

The durable fix is to stop treating consent as a routine click. Three settings carry most of the weight:

SettingWhereEffect
Restrict user consent to verified publishers and low-impact scopes Entra ID › Enterprise applications › Consent and permissions Ordinary users can no longer grant broad access on their own.
Enable the admin consent request workflow Same blade Requests are queued for review instead of approved ad hoc.
Alert on Consent to application Microsoft Sentinel or Defender for Cloud Apps You hear about a grant within minutes, not at the next audit.

None of this is new guidance — Microsoft has recommended restricted user consent for years. What has changed is the volume: consent phishing is now the cheapest way into a well-defended tenant, and the campaigns have got noticeably better at looking legitimate.

Authorised use only. The detection steps above are for tenants you administer or are contracted to assess. Read our Disclaimer before applying anything here to systems you do not own.

Sources

  • Microsoft Entra documentation — configure how end users consent to applications
  • Microsoft Purview — search the audit log in the compliance portal
  • Our own review of audit exports from [n] affected tenants, August 2026

Replace this section with links to the primary sources you actually used. Our Editorial Policy explains the sourcing standard we hold every article to.