# What are rogue apps and how can I stop them? > 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. ## 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.) When you review the output, scrutinize apps with the **`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. Note that when Microsoft itself confirms an app violates its terms, Entra ID disables it across all Microsoft services; it shows `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](/tools/dmarc) and the free [tools](/tools/email-security-score) harden the account and the domain, while OAuth governance closes the consent path. ## Frequently asked questions ### Do DMARC, SPF, or DKIM stop rogue apps? No. Consent phishing bypasses authentication entirely: the user willingly grants OAuth scopes, and Microsoft says MFA and password resets don't remediate it. Email authentication is part of a layered posture, not a fix for this attack. ### Will resetting the user's password fix it? No. Microsoft is explicit that password resets and MFA don't remove an illicit consent grant, because the app is external to your organization. You have to revoke the app's consent or permissions directly. ### How often should we review OAuth consents? Microsoft recommends **weekly** reviews of consent grants for organizations with many registered apps and a large user base. Searching "Consent to application" in the audit log is the fastest recurring check. ### What's the single biggest risk factor? Accounts without MFA. In Microsoft's 2022 spam case the compromised admin accounts lacked MFA, and Midnight Blizzard entered through a no-MFA legacy test account. MFA doesn't remediate a planted rogue app, but it blocks the compromise that plants one. ### Is this only a Microsoft problem? No. Google Workspace has the same OAuth exposure, managed through App access control (Trusted / Limited / Blocked). Any platform that supports OAuth consent can host a rogue app. Want to check your account and domain security posture first? Run the free [Email Security Score](/tools/email-security-score): it reviews your DMARC, SPF, and DKIM setup in seconds. ## Related reading - [DMARC checker](/tools/dmarc) - [Email Security Score](/tools/email-security-score) - [Microsoft compliance checker](/tools/microsoft-compliance-checker) - [Palisade for Managed Service Providers](/for-managed-service-providers)