What are the signs that an account is being used for persistence after compromise?

Unexpected forwarding rules, login alerts from unfamiliar locations, changes to recovery settings, and activity that continues after a password reset are all strong indicators. These signals mean the attacker may still have a foothold through session persistence or mailbox control.

Why This Matters for Security Teams

Account persistence after compromise is dangerous because the attacker does not need to keep breaking in. Once a mailbox, SaaS admin account, API key, or service account remains active, the compromise can survive password resets, MFA changes, and even user awareness. NHIMG research shows that 91.6% of secrets remain valid five days after an organisation is notified, which illustrates how slowly many environments remove attacker access. That lag is exactly what persistence exploits.

The most common failure is treating the first alert as the end of the incident instead of the start of a broader identity investigation. Persistent access often hides in forwarding rules, delegated mailbox permissions, recovery setting changes, OAuth grants, or sessions that were not invalidated. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to monitor account activity, revoke access promptly, and validate that controls actually removed attacker paths. In practice, many security teams discover persistence only after the attacker has already used the account for follow-on access, not during the initial compromise window.

How It Works in Practice

Persistence is usually a sign that the attacker is using the account as a durable access point rather than a one-time entry method. That can happen through mailbox rule abuse, token theft, delegated access, cloud app consent, lingering sessions, or a second identity that was created during the intrusion. A password reset alone may not stop any of these, which is why teams need to inspect the full identity surface, not just the credential.

Several behaviours are especially useful for detection:

• Mail forwarding or inbox rules that move, delete, or hide messages.
• Recovery email, phone, or MFA device changes that weaken account recovery.
• New OAuth app grants, refresh tokens, or API permissions that outlive the password.
• Login activity from unfamiliar IPs, geographies, devices, or user agents.
• Activity continuing after a reset, which suggests an active session or alternate path remains.

Strong investigations combine identity telemetry, mail audit logs, session revocation, token review, and permission review. That is also why the broader NHI problem matters: NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and lack of visibility makes hidden persistence much harder to spot. For context on how compromised identities support wider intrusion chains, see the The 52 NHI breaches Report and the Salt Typhoon US telecoms breach, both of which show how stolen credentials can support sustained access beyond the initial intrusion. These controls tend to break down in environments with federated identity, long-lived OAuth grants, and unmanaged service accounts because the attacker can persist outside the main login path.

Common Variations and Edge Cases

Tighter account monitoring often increases alert volume and response workload, so organisations must balance visibility against operational noise. That tradeoff matters because not every suspicious sign means active persistence, but ignoring weak signals creates an opening for long dwell time.

Current guidance suggests treating the following as high-priority edge cases:

• Shared mailboxes or admin accounts, where legitimate usage can mask hostile activity.
• Federated identity environments, where the password is not the only control plane.
• Cloud-native and SaaS accounts, where tokens and app consents can survive password resets.
• Service accounts and automation identities, where interactive login is unusual but persistence may appear through API access.

Another common exception is delayed or partial remediation. If recovery settings are restored but tokens are not revoked, or if sessions remain valid on unmanaged devices, the attacker may re-enter without triggering a fresh password alert. Best practice is evolving toward full containment checks that include mailbox rules, token revocation, delegated permissions, and device/session review. For a broader view of why identity persistence remains so hard to eradicate, NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now explains why long-lived access paths remain a recurring risk. These controls tend to break down in hybrid environments where legacy authentication, multiple identity stores, and weak offboarding processes prevent a clean cutoff.

Related resources from NHI Mgmt Group

• What are the signs that an AWS account has been used for privilege escalation and persistence in EKS?
• How should security teams govern API keys used for generative AI access?
• When does a service account become a compliance problem?
• Who is accountable when an executive account is used for fraud after MFA success?