What happens when an attacker adds their own MFA method and abuses a third party app?

When an attacker adds their own MFA method and authorizes a malicious or abused app, they can keep access to the account and the data it can reach. That enables ongoing mailbox access, data theft, and possible spread to internal or external users. The result is persistent compromise that can survive simple credential resets unless all attacker controlled access paths are removed.

How the attack works when a user adds an attacker-controlled MFA method

Once an attacker can enroll their own MFA factor, they are no longer dependent on the original password alone. They can satisfy step-up checks, re-enter the account after a password reset, and keep the session or token chain alive if the environment does not invalidate existing grants. The real issue is not the new factor by itself, but the attacker’s ability to turn it into durable account control.

That control becomes more dangerous when the attacker also authorizes a third-party app or integration, because the app can hold delegated access even after the original sign-in method changes. In practice, the account may look recovered while the attacker still has a live path through MFA, consent, OAuth grants, or session persistence. This is why cleanup has to focus on all active trust relationships, not just the password.

The attack often blends abuse of authentication with abuse of authorization. One step establishes future access, the other expands what that access can reach. If the account can reach mail, files, chat, or admin functions, the attacker can use the trusted app or factor to move from account access into data access and internal reach.

For readers who want a concrete breach pattern, NHIMG’s Salesloft OAuth token breach and Klue OAuth Supply Chain Breach show how third-party consent and token access can preserve attacker reach into SaaS data paths.

Why simple credential resets do not remove the compromise

A password reset only changes one credential. It does not necessarily revoke an attacker-enrolled MFA factor, remove delegated app access, or invalidate all active refresh tokens and sessions. If those paths remain in place, the attacker can continue to authenticate or act on behalf of the user even after the obvious recovery step has been completed.

This is also why mailbox compromise is especially persistent. Mailboxes commonly hold password reset links, alerts, conversation history, and trust signals that attackers can mine to regain access elsewhere. If a malicious app has mail or profile permissions, the attacker may keep visibility even after the victim changes the password and adds a new factor of their own.

In identity terms, the key failure is incomplete revocation. Organizations often fix the primary secret but leave the secondary control plane untouched, which allows the attacker’s added MFA method, consented app, or existing session to remain valid. The result is persistent compromise, not a one-time login event.

NHIMG’s Uber Breach is a useful reminder that MFA abuse can be paired with social engineering and long-lived access paths, while Microsoft Midnight Blizzard breach shows how weak or bypassed authentication can enable broader internal exposure.

What changes once the attacker has both MFA and a third-party app

Once both pieces are in place, the attacker can maintain access across more than one recovery event and often across more than one system boundary. MFA helps them re-enter the account, while the app can preserve delegated reach into data and workflows. That combination is what turns an account compromise into a durable access foothold.

The downstream impact depends on the permissions the app already has. If it can read mail, files, directory data, or SaaS content, the attacker may exfiltrate sensitive information, impersonate the user in internal exchanges, or use the account as a staging point for further compromise. If the account has external collaboration rights, the attacker may also abuse trust with partners or customers.

In some environments, the attacker can also use the compromised account to suppress visibility, for example by creating mail rules, approving new grants, or hiding notifications. That makes detection harder because the account may still appear functional while being actively controlled by the adversary.

NHIMG’s Canvas Instructure Data Breach and Vercel Context.ai OAuth Supply Chain Breach are good examples of how third-party credential or token abuse can extend compromise beyond the original user boundary.

Risk and Threat Considerations

This pattern is dangerous because it creates a persistence layer inside the identity system itself. The attacker is not just stealing a password, they are establishing an alternate trust path that can survive normal user remediation and may remain invisible if teams only look for password reuse or login anomalies.

Failure mechanism: The attacker registers an MFA factor they control, then uses delegated app consent, tokens, or existing sessions to retain access even after the password changes.

Impact: Account recovery becomes incomplete, which can lead to mailbox monitoring, data theft, internal impersonation, and repeated re-entry into the environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers lifecycle control of added MFA factors and token revocation.
	IA-2 — Identification and Authentication (Organizational Users)	Applies because the attack abuses user authentication to retain account access.
	AC-20 — Use of External Information Systems	Relevant to third-party app abuse and delegated access paths into the account.
Recommendation — Revoke attacker-controlled authenticators and invalidate related credentials immediately. Require strong user authentication and monitor for unauthorized factor enrollment. Restrict external app access and review delegated trust relationships.
OWASP API Security Top 10	API2 — Broken Authentication	The attacker keeps access by abusing authentication and session-like access paths.
	API5 — Broken Function Level Authorization	Third-party app consent can overreach into functions the user should not expose.
Recommendation — Harden authentication flows and invalidate stolen or attacker-added access artifacts. Enforce function-level authorization on privileged or sensitive actions.

Practitioner Guidance

What to verify: Do not trust a password reset as a full remediation signal unless you have confirmed that attacker-enrolled MFA methods, third-party app grants, refresh tokens, and active sessions were all revoked. If any one of those remains, treat the account as still compromised.

Decision rule: If the attacker had the ability to add a factor or approve an app, prioritize full trust-path removal over narrow credential rotation. The order matters because the attacker’s control often sits in the authentication and authorization layers, not in the password alone.

Practitioner takeaway: Persistent account compromise is usually a revocation problem, not a login problem, so recovery must remove every attacker-controlled path to authentication and delegated access.