Threat Brief: Identity-Based Persistence

Bottom line

Resetting the password on the compromised account does not evict an actor who has already added their own MFA method, application credential, consent, account or trust. Several documented intrusions kept access this way. An incident closed on “we reset the account” should be treated as open.

Key judgments

• Persistence is moving into identity objects that few teams review. MFA registrations, application credentials, OAuth consents, federation settings and newly created accounts all outlast a password reset. Confidence: high that the techniques are in active use, moderate on how widespread they are.

• The documented cases are consistent. CISA’s advisory on Scattered Spider describes actors registering their own MFA tokens and creating new identities, and records an earlier technique of adding a federated identity provider with automatic account linking. Microsoft documented Storm-0501 registering an actor-owned tenant as a federated domain and Midnight Blizzard using OAuth applications to keep access after losing the original account.

• These changes are visible if someone is looking. Every one of them requires a configuration change that is written to an audit log. The common gap is not detection capability. It is that the relevant logs are not retained, not forwarded or not reviewed during an investigation.

• Eviction scope is usually set too narrowly. It stops at the accounts known to be compromised, when it needs to cover everything those accounts could change.

The mechanisms

Remote access tools can serve the same purpose and are covered separately in the brief on remote access tool abuse. This brief stays on identity.

Why password resets create false confidence

A reset feels decisive, and it is the standard first response. It also answers only one question: can the actor still sign in with that password? It says nothing about whether they hold a second way in.

The Storm-0501 case shows the sequence clearly. The actor reset a synced administrator’s password itself, registered its own MFA method on the account, and later added a trusted federated domain for token forging. Of those three footholds, the password was the least durable. Rotating it would have changed nothing about the other two.

Midnight Blizzard illustrates the other half. Microsoft reported that misuse of OAuth lets the actor keep access even after losing the account it first compromised. Removing that one account would not have removed the applications the account had created and consented to.

What a complete eviction covers

Start by setting the earliest credible time of compromise. Everything changed after that point is in scope, whether or not it looks related.

1. Revoke sessions and refresh tokens for every account in scope, not only the passwords. A valid token can outlive a reset.

2. Review authentication methods on compromised and privileged accounts. Remove anything the owner cannot account for, and confirm new registrations went through the intended process.

3. Review application identities. List credentials added to app registrations and service principals, and consents or app-only permissions granted, within the window. Remove unknown, unused and over-scoped identities. In Exchange Online, review identities holding application impersonation or full mailbox access roles.

4. Review federation and domain settings. Confirm that every trusted domain and identity provider is expected. Treat any unexplained change as confirmed compromise of the tenant.

5. Review new accounts, role assignments and group changes since the earliest compromise time, including accounts created by or for the actor in connected platforms.

6. Rotate credentials at the scope of exposure. If directory replication abuse is confirmed or suspected, treat every directory credential as exposed. Where the Kerberos ticket-granting account was exposed, it needs two resets spaced to allow replication.

7. Rotate secrets and keys that the in-scope accounts and applications could read, including signing material where tokens could be forged.

8. Watch for re-entry. Raise alerting on the same change events, and on logons from the actor’s infrastructure, for a defined period before declaring the incident closed.

Where to look

MITRE’s detection guidance for account manipulation points to the same families of events: attribute changes on accounts, SSO and SAML attribute changes, new users and role changes made through APIs, and role escalation in connected platforms. Translate those into a short list your investigators can run on day one.

• Authentication method added, changed or removed for any account.

• Credential, certificate or secret added to an application or service principal.

• Application registered, consent granted, or application permission assigned.

• Federation, domain or identity provider settings changed.

• Account created, role assigned, or privileged group membership changed.

• Directory replication requested by a host that is not a domain controller.

• Role elevation operations in the cloud control plane.

These queries only work if the logs exist. Check retention and forwarding before an incident. Many organizations find that the authentication method and application audit logs are kept for a shorter time than the investigation needs, or are not sent to the central platform at all.

Questions for leaders to ask before closing an incident

Limits of the evidence

The cases cited are public reports from specific victims and actors, and several involve Microsoft cloud services. CISA notes that the federated identity provider technique has not been seen recently in Scattered Spider activity, so it should be read as a historical example rather than a current trend. No public source gives reliable rates for how often incidents are closed with persistence left behind. That claim is an analytical judgment, informed by the documented cases and by what incident responders commonly find, and it should be tested against your own post-incident reviews.

Next step

Pick your last identity-related incident and check the closure record against the eviction list above. Anything the record cannot show is a gap in the process, and a reason to run the missing checks now. Cybrilliant can support a post-incident identity review if an independent check on closure would help.

Sources

1. CISA, FBI and international partners. Scattered Spider cybersecurity advisory (joint advisory, updated edition). cisa.gov

2. Microsoft Threat Intelligence. Storm-0501’s evolving techniques lead to cloud-based ransomware. microsoft.com

3. Microsoft Security Response Center and Microsoft Threat Intelligence. Midnight Blizzard: Guidance for responders on nation-state attack. microsoft.com

4. MITRE ATT&CK. Account Manipulation (T1098), including the Additional Cloud Credentials sub-technique, mitigations and detection guidance. attack.mitre.org