Threat Brief: Cloud Persistence Techniques

Most cloud persistence does not live on a server. It lives in identity objects: an application secret, a role assignment, a federation trust, a registered MFA method. Resetting the compromised user’s password removes none of them.

Key judgments

Observed means a named source reported it. Assessed means it is our reading of that evidence.

What has been observed

MITRE ATT&CK catalogs the building blocks. Adding credentials to cloud accounts, applications and service principals is one. Adding roles to an account the attacker controls is another. Creating new cloud accounts and service-linked identities is a third. Named groups appear against each of them, including APT29, Scattered Spider, LAPSUS$ and Storm-0501.

Two incident write-ups show how these pieces combine in practice. In Microsoft’s responder guidance on Midnight Blizzard, the actor took over a legacy test OAuth application that already held elevated access, created new malicious applications and a new user, and granted the applications a role that reaches every mailbox. The access ran through the applications. It outlasted the loss of the original compromised account.

Microsoft’s analysis of Storm-0501 goes further. After reaching an on-premises domain, the actor abused directory synchronization accounts to enumerate the cloud tenant. It found a synchronized Global Administrator with no MFA method registered, reset the password, and registered its own MFA method. For backdoor access it added an attacker-controlled tenant as a trusted federated domain, which allowed it to forge SAML tokens and sign in as almost any user. It then elevated to Owner across subscriptions, copied data out, and deleted snapshots, restore points and backups.

The persistence mechanisms

Why defenses miss it

Detection programs are tuned to sign-in anomalies: impossible travel, new devices, failed MFA. Persistence changes are administrative events. When an administrator account performs them, they look like normal work. Control-plane audit logs are frequently collected and rarely alerted on, and the objects involved, app registrations and service principals, are often owned by platform or development teams rather than security. Nobody can say which secrets on which apps are supposed to exist.

Visibility is also split. In the Storm-0501 case Microsoft noted that Defender coverage across the victim’s separate domains and tenants was fragmented, and much of the activity went unnoticed.

What defenders should change

1. Make eviction a full enumeration. For any identity compromise, list everything the account created or changed in the exposure window: application credentials, consents, role assignments, federation settings, MFA registrations, access keys. Revoke those, not only the user’s sessions.

2. Treat persistence-class admin events as high severity. Alert on new credentials on applications and service principals, admin consent grants, privileged role assignments, federation changes, and MFA registration on privileged accounts. Confirm the exact event names and log availability in your own tenants before you build the rules.

3. Close the MFA gap on privileged accounts. Require a registered, phishing-resistant method before an account can hold a privileged role. Use separate cloud-only accounts for administrators, as Microsoft recommends after Storm-0501.

4. Inventory non-human identities and give each an owner. Remove unused privileged apps and mailbox-wide permissions, expire secrets, and disable app passwords unless something requires them.

5. Restrict who can change trust. Limit who can alter federation settings, grant admin consent or create applications with credentials.

6. Test the path. Run a purple-team exercise that adds a secret to a test app, assigns a role and registers an MFA method. Check that an alert fires and that the responder knows how to revoke each item.

Hunting hypotheses

• Applications or service principals that gained credentials outside a change window and then authenticated from a new network.

• Privileged accounts with an MFA method registered recently from an unfamiliar device.

• Role assignments to identities created recently, or external to the tenant, with no matching ticket.

• Sequences of account creation, role assignment and credential generation within a short window.

What we do not know

Prevalence is unknown. Public reporting skews toward high-profile actors and toward Microsoft Entra and AWS, so Google Cloud and smaller providers are covered less well here, though the same patterns apply to service accounts and role bindings. Providers change logging and defaults, so event names and retention need local validation.

What to do with this

Take the last cloud account compromise your team handled and check whether the closure record lists every credential, role and trust the intruder touched. If it ends with a password reset, the persistence question is still open.

Sources

• MITRE ATT&CK, Account Manipulation: Additional Cloud Credentials (T1098.001)

• MITRE ATT&CK, Account Manipulation: Additional Cloud Roles (T1098.003)

• MITRE ATT&CK, Create Account: Cloud Account (T1136.003)

• Microsoft Security Blog, Midnight Blizzard: Guidance for responders on nation-state attack

• Microsoft Security Blog, Storm-0501’s evolving techniques lead to cloud-based ransomware