What are rogue apps and how can I stop them?
ChatGPT
Claude
Gemini
Perplexity
GrokIn brief
Rogue apps are malicious OAuth apps that bypass MFA via consent phishing. How MSPs detect, remove, and prevent illicit consent grants in Microsoft 365 and
"Rogue app" is the plain-English name for a malicious OAuth application, an app an attacker registers and tricks a user into granting access to. Microsoft calls this an illicit consent grant; the attack that plants it is consent phishing. What makes it dangerous is that it sidesteps the defenses you already trust: once a user clicks "Accept," the app has account-level access to their mail and files, and resetting the password or turning on MFA does not remove it.
At a glance
Quick takeaways
- A rogue app is a malicious OAuth application. The user willingly grants it access on a real Microsoft or Google consent screen, so no password is ever stolen.
- Microsoft states plainly that password resets and MFA do not remediate this attack, because the app is external to your tenant. That is why rogue apps "bypass MFA" and persist.
- Detection lives in the audit log: search Microsoft Purview / Defender for "Consent to application" events. Microsoft advises reviewing consent grants weekly if you run many apps and users.
- The entry point is almost always an account without MFA. In Microsoft's 2022 spam case, the compromised admin accounts had no MFA; Midnight Blizzard (APT29) got in through a legacy test account with no MFA.
- This is an identity-console problem, not a DNS one. DMARC, SPF, and DKIM do not stop consent phishing, but strong email-security posture is what keeps the account-compromise door shut in the first place.
What exactly is a rogue app?
In an illicit consent grant attack, an attacker registers an app in Microsoft Entra ID that requests access to data like contacts, email, or documents. They then use phishing (or malicious code injected into a trusted site) to drive a user to the app's consent screen and get them to approve it. Because the Microsoft identity platform hosts that consent screen and lists the requested permissions, it looks completely legitimate, and unsuspecting users accept (per Microsoft Entra ID docs).
The moment consent is granted, the app holds a token that lets it act on the user's data, without ever needing an account in your organization. That external position is the whole problem. As Microsoft spells out, normal remediation like resetting passwords or requiring MFA is not effective here, because those controls protect accounts, and the malicious app is not an account.
Microsoft, Google, and CISA don't use the term "rogue app": their language is "illicit consent grant," "consent phishing," and "malicious OAuth application." Treat "rogue app" as a useful umbrella, not an official technical term.
Why do rogue apps bypass MFA and passwords?
Consent phishing bypasses authentication entirely. Credential phishing tries to steal a password; consent phishing skips that step and asks the user to authorize an app. The user is fully authenticated (they log in normally, MFA and all) and then hand a third-party app a durable OAuth token. Nothing about that flow is "wrong" from the login system's point of view.
That is also why rogue apps are such good persistence. In Microsoft's September 2022 spam campaign, attackers credential-stuffed into Azure AD accounts that lacked MFA, registered a malicious OAuth app, gave it the Exchange.ManageAsApp permission, added their own credentials to it, and used it to create transport rules that sent spam. In some cases they didn't even reuse the app for weeks or months after planting it. In the Midnight Blizzard (APT29) intrusion disclosed in January 2024, the actor compromised a legacy OAuth app, created more malicious apps, and granted itself the Exchange Online full_access_as_app role to read mailboxes, retaining access even after losing the original account. The common thread in both: the initially compromised account had no MFA.
How do I detect rogue apps in Microsoft 365?
Start in the audit log. In the Microsoft Defender portal (security.microsoft.com), open Audit and search for "Consent to application" activities. Those events are your primary indicator of compromise. Microsoft recommends reviewing consent grants weekly in tenants with many registered apps and a large user base.
To inventory what's already been consented to, you have three options (per Microsoft Learn):
- Entra admin center: Identity → Users → All users → pick a user → Applications, to see per-user app access.
- Self-service: have users check myapps.microsoft.com, where they can view and revoke their own app access.
- PowerShell: the fastest method. Microsoft references a community script,
Get-AzureADPSPermissions.ps1, run through the Microsoft Graph PowerShell SDK (Connect-MgGraph), to dump every OAuth consent grant and app across all users into a single CSV. (The filename references the retired AzureAD module, but the current doc runs it via Graph.)
AllPrincipals consent type (access to everyone's content), broad Read/Write.All permissions, and suspicious client display names. CISA's AA21-008A advisory adds more signals: audit the creation and use of service-principal credentials, watch for dormant apps, and flag credentials that allow non-interactive sign-in. CISA's free Sparrow tool checks OAuth consent and Graph API permissions across your service principals and apps.
How do I remove a rogue app?
Per Microsoft, you have several remediation moves. Use more than one:
- Revoke in Entra: user → Applications → select the app → Remove.
- Revoke the consent grant in PowerShell:
Remove-MgOauth2PermissionGrant. - Revoke a service app role assignment:
Remove-MgServicePrincipalAppRoleAssignment. - Disable sign-in for the affected account as a short-term containment step.
DisabledDueToViolationOfServicesAgreement and cannot be deleted (so it can't be re-instantiated), and a Privileged Role Administrator is emailed if anyone had already consented.
How do I prevent rogue apps?
Prevention is a consent-policy problem. Microsoft recommends configuring user consent settings so users can only consent to apps that meet criteria you set: for example, apps from your own organization or from verified publishers, and only for low-risk permissions you choose. Publisher Verification is Microsoft's vetting process for confirming a developer's authenticity; even then, review the requested permissions, because a verified publisher is not a blank check.
Do not let users lean on app names or domain URLs as proof of authenticity, Microsoft warns that attackers spoof both to look legitimate. For deeper coverage, Microsoft points to Defender for Cloud Apps OAuth app policies and app governance to detect and remediate risky apps, plus Defender for Office 365 to block consent-phishing emails before they land.
On Google Workspace, the equivalent control lives under Security → Access and data control → API controls → App access control. Each app can be Trusted (all scopes, including restricted services), Limited (unrestricted Google services only), or Blocked (no access at all). You can restrict specific services like Gmail or Drive so an app can't be added unless you've explicitly trusted it. Google also restricts unverified apps that access Gmail data and have more than 100 users worldwide. New installs of those are blocked unless an admin trusts the app.
Where does Palisade fit?
Palisade does not scan Entra or Workspace OAuth grants or remediate rogue apps. That work happens in the Microsoft and Google admin consoles above. What Palisade addresses is the entry point. Every one of these cases started with a compromised email account, and rogue apps are one more reason to keep your email-security posture tight: enforced MFA, clean authentication, and no unmonitored mailboxes. Think of it as layered defense: Hosted DMARC and the free tools harden the account and the domain, while OAuth governance closes the consent path.
Related reading
Questions readers ask
Frequently asked questions
Written by
Taylor TabusaCo-Founder & Head of Business Development, Palisade
Taylor Tabusa is the co-founder and Head of Business Development at Palisade, helping managed service providers turn email security into a practical, valuable service.
More from Taylor →
