What happens when a compromised tenant keeps authorizing new malicious apps even after one app is blocked?

Blocking one app is not enough if the publishing account or tenant that created it is still compromised. Attackers can register new apps, request fresh consents, and continue the campaign from a different application identity. That is why containment must include the source account, the malicious apps, and any mailbox artifacts that preserve access or enable further phishing.

Why Blocking One App Does Not End the Compromise

A blocked app is only one object in the compromise. If the tenant, publishing account, or consent path is still live for the attacker, they can keep creating new apps, reusing the same trust relationships to regain access. The practical question is not whether one malicious app was removed, but whether the attacker’s ability to obtain new authorization has been cut off.

This is why incident response has to move from single-object takedown to source containment. If the compromised tenant can still grant consent, the attacker can swap application identities and continue the campaign with little friction.

What Keeps the Attack Alive After the First App Is Blocked?

The persistence mechanism is authorization, not the original app binary. In many tenant compromise cases, the adversary relies on a standing relationship that lets them request fresh consent, register another app, or attach new permissions under a different name. The blocked app becomes expendable once the attacker has preserved control over the upstream account or admin path.

That means the dangerous state is often the tenant’s trust configuration: who can approve apps, which users or admins can grant consent, and whether those approvals are monitored or reversible. If those conditions remain unchanged, the attacker can continue using the same access path even after the first malicious app is disabled.

How Containment Should Be Scoped in Practice

Effective containment follows the access path, not the artifact. The response should include the source account that minted or approved the app, the app registrations themselves, and any mail or identity artifacts that preserve the attacker’s foothold. Where app-based abuse is involved, the investigation should also confirm whether the attacker created persistence through permissions that survive app deletion, consent grants, mailbox rules, or delegated access.

For teams working through authorization design and privilege boundaries, the key is to compare authorization models against the actual approval path, not just the visible app object. The attack ends only when the tenant can no longer authorise a replacement app or reissue the same permissions.

Risk and Threat Considerations

The risk is campaign continuity. Once attackers can keep authorizing new apps, one blocked application only forces a rename, not a stop. That creates repeated opportunities for data access, phishing, and secondary abuse because the trust relationship is still intact.

Failure mechanism: The original app is removed, but the compromised tenant, admin, or consent process remains able to register or approve a new app with equivalent permissions. Attackers then re-establish access through a fresh application identity and continue operating.

Impact: Organisations can lose time chasing individual app objects while the attacker maintains access, expands exposure, and may preserve mailbox or consent-based footholds that enable further phishing or data theft.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address 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
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	A compromised tenant can keep creating replacement apps if offboarding and revocation are incomplete.
	NHI-04 — Insecure Authentication	Fresh consents and reauthorization depend on broken trust at the source account or admin path.
	NHI-10 — Human Use of NHI	The attack depends on people approving or reapproving malicious app access on behalf of the tenant.
Recommendation — Revoke the source tenant and its grants, not just the blocked app. Harden the approval path and require stronger authentication for app consent. Restrict who can approve apps and review human-driven consent paths.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Excessive approval and consent rights let a compromised tenant keep authorizing new apps.
	IA-5 — Authenticator Management	Attacker continuity depends on reusable credentials, tokens, or grants that should be revoked and rotated.
	AU-6 — Audit Record Review, Analysis, and Reporting	Repeated app creation and consent events are detectable if the tenant’s authorisations are logged and reviewed.
Recommendation — Reduce consent and app-registration rights to the smallest necessary set. Rotate or revoke the credentials and tokens that enabled repeated app authorization. Monitor consent, app registration, and mailbox-rule activity for recurrence after containment.
MITRE ATT&CK	T1098 — Account Manipulation	Attackers often alter accounts, consents, or delegated access to persist after one app is blocked.
	T1136 — Create Account	New malicious apps are a form of attacker-created access path that replaces the blocked one.
	T1114 — Email Collection	Mailbox artifacts can preserve access and enable follow-on phishing after app blocking.
Recommendation — Hunt for added consents, delegated access, and other persistence changes. Track and block attacker-created access objects that replace the original app. Inspect mailboxes for rules, forwarding, or other artifacts that preserve attacker access.

Practitioner Guidance

What to prioritise: Treat the compromised authorisation source as the primary containment target. If the same tenant or publishing account can still approve new apps, blocking the current app is only a temporary disruption.

What to verify: Confirm whether any grant, consent, delegated permission, or mailbox artifact still permits the attacker to re-enter through a different app identity. If yes, remove that path before declaring containment.

Practitioner takeaway: The decisive control is revoking the attacker’s ability to authorise replacements, because app deletion alone does not break the underlying trust relationship.