MACT

What MACT Is and Why It Matters

MACT is a cloud abuse technique built around credibility. Attackers place malicious or modified applications inside a compromised tenant so the app inherits the tenant’s apparent trust, making persistence, phishing, and access abuse harder to spot.

The core idea is not just that an application is malicious, but that it is embedded in an environment the organisation already trusts. That context can let the app look normal to users, defenders, and even downstream integrations, especially when tenant controls are weak or visibility is limited.

Because MACT sits at the intersection of cloud compromise, application trust, and post-compromise persistence, it is best understood as an abuse of tenant legitimacy rather than a standalone malware family.

How MACT Works Inside a Compromised Tenant

MACT typically begins after an attacker gains control of a cloud tenant or an equivalent trusted environment. From there, they create, alter, or register an application so it blends into the tenant’s normal operational patterns, naming conventions, and approval paths.

Once the malicious application exists inside that trusted boundary, it can be used to sustain access, trigger deceptive user flows, or reach data and services that would be harder to access from an external hostile account. In some cases, the app becomes a durable foothold that survives the original intrusion method.

The important security property is trust transference. Defenders often treat tenant-resident applications as lower risk than external artifacts, so the attacker benefits from the tenant’s reputation, configuration, and allowed integrations.

Security Implications of Tenant-Credible Applications

MACT can weaken the signal defenders rely on when distinguishing legitimate enterprise applications from attacker-controlled ones. That makes it especially concerning in environments with many apps, delegated administration, or broad consent and registration workflows.

It also creates a path for abuse beyond simple persistence. A convincing tenant-local application can support phishing, token capture, unauthorized data access, or movement into downstream systems that trust the tenant or its apps.

NIST Cybersecurity Framework 2.0, NIST SP 800-53 Rev 5 Security and Privacy Controls, and MITRE ATT&CK Enterprise Matrix are all useful reference points because MACT touches governance, access control, detection, and post-compromise tradecraft.

How Teams Should Interpret and Classify MACT

MACT is not just “a malicious app.” The distinguishing feature is the compromised credible tenant, which changes the threat model by adding trust abuse and tenant-internal camouflage to the malicious payload.

That distinction matters for triage and hunting. A suspicious app may be obvious when it is external, but much harder to dismiss when it originates from inside a tenant that already has valid administrative context, normal usage history, and expected integration activity.

OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 help frame the issue as one of trust boundaries, application governance, and control over tenant-resident actors rather than simple malware detection.

Risk and Threat Considerations

MACT is risky because it weaponizes legitimacy. A malicious app that lives inside a compromised tenant can bypass user intuition, blend into normal administrative activity, and remain useful even after the initial intrusion path changes.

Failure mechanism: The attacker gains tenant-level trust, then uses that position to register or alter an app that inherits the tenant’s credibility, allowing persistence, deception, and unauthorized access to continue with reduced scrutiny.

Impact: Organisations can miss active compromise, over-trust apparently internal applications, and suffer extended data exposure, phishing success, or repeated re-entry into the environment.

Practitioner Guidance

Why practitioners should care: MACT is a cloud trust problem as much as a malware problem, so ownership needs to span identity, application governance, and tenant administration. If app creation inside a tenant is not tightly controlled and routinely reviewed, the attacker’s foothold can look operationally normal.

What to watch for: Unexpected application registration, permission changes, consent grants, or new internal apps appearing in tenants that already show compromise indicators deserve priority review, especially when they coincide with unusual sign-in, token, or admin activity.