Look for post-login changes rather than only failed logins. Common indicators include new OAuth app consent, unexplained forwarding rules, attachment downloads, payment changes, service account use outside its normal purpose, and activity that spreads across multiple SaaS applications without a clear business reason.
How to recognise an account takeover that has not stopped at the login screen
A takeover is still active when the attacker is using the SaaS account, not just trying to get in. The strongest warning signs are post-login changes, especially when they alter access, forwarding, sharing, payments, or connected apps. In practice, this means the account is behaving with a purpose that the legitimate user cannot explain.
Watch for consent grants to new OAuth applications, mailbox or document forwarding rules, unexpected downloads, and changes to billing or subscription settings. Those are often the first durable traces because they persist after a password reset if the attacker also has an active session, token, or authorised integration.
Cross-application activity is another major clue. If a single SaaS identity starts moving across CRM, email, file storage, ticketing, and collaboration tools without a clear business reason, treat that as a likely live abuse pattern. The issue is not only access to one app, but use of the account as a pivot point for broader data access.
Which signs suggest the attacker still has usable access?
The most reliable signs are actions that require a current session or a still-valid token. New device logins, unfamiliar IP ranges, repeated API or admin actions, and fresh consent to integrations can all indicate the attacker still has a path back in. A clean password reset does not matter if the session, refresh token, or delegated access remains alive.
Look closely at control-plane changes, not just content access. Creating forwarding rules, adding recovery methods, changing MFA settings, inviting new collaborators, or altering app permissions usually means the adversary is trying to preserve persistence. Gitloker GitHub extortion campaign is a good example of how malicious OAuth consent can become a durable access path.
Also pay attention to abuse that looks operational rather than obviously malicious. Small configuration edits, quiet exports, permission changes, and bulk reads often happen before visible damage. The account can appear “open” yet still be under attacker control if its actions no longer match the user’s normal workflow.
What investigators should look for first after suspicion is raised
Start with the artefacts that prove persistence. Review active sessions, refresh tokens, OAuth grants, forwarding rules, recovery settings, connected devices, and recent admin changes. If possible, correlate those events across the SaaS suite, because a live attacker often leaves a chain rather than a single alert.
Then separate normal automation from abuse. Service accounts, delegated access, and approved integrations can look noisy, so the key question is whether the behaviour matches the established business purpose, time window, and source system. Customer IAM (CIAM) Guide is useful background for understanding how legitimate consent, recovery, and step-up controls should behave when access is being abused.
If the account touches multiple systems, check for secondary impact rather than treating each app in isolation. A takeover that begins in email can become document theft, ticket manipulation, invoice fraud, or partner impersonation. Live compromise is often confirmed by that spread, especially when the activity has no clear business justification.
Risk and Threat Considerations
Active SaaS takeover is risky because the attacker often inherits trust, not just credentials. Once inside, they can hide inside normal user activity, add persistence, and use the account to reach data, approvals, or linked applications that security teams may not monitor as closely as the original login.
Failure mechanism: The compromise remains active when the attacker retains a session, token, OAuth grant, forwarding path, or delegated permission after the initial password event is remediated. That allows continued access even when the original sign-in problem appears solved.
Impact: The attacker can continue exfiltrating data, altering account settings, abusing business workflows, and pivoting into adjacent SaaS services, which can turn a single account compromise into a broader tenant or business process incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Active SaaS takeover often persists through stolen sessions or tokens. |
| Recommendation — Revoke active sessions and rotate tokens when takeover signs show valid post-login access. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Post-login abuse is detected through review of account and SaaS audit events. |
| IA-5 — Authenticator Management | Takeover response depends on revoking and rotating authenticators, tokens, and secrets. | |
| Recommendation — Correlate audit events across SaaS apps to confirm persistence and scope. Invalidate compromised authenticators and rotate any exposed credentials immediately. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Takeover signs are often visible only in logs, forwarding rules, and admin changes. |
| Recommendation — Centralise and review SaaS logs for forwarding, consent, and privilege changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | SaaS takeover frequently continues through exposed tokens, secrets, or delegated access. |
| Recommendation — Search for and revoke leaked tokens, API keys, and OAuth grants tied to the account. | ||
Practitioner Guidance
What to prioritise: Treat persistence artefacts as higher priority than the initial login vector. Revoke sessions, refresh tokens, OAuth consents, and delegated access before relying on password resets or user-level confirmation.
What to verify: Confirm whether each suspicious action aligns with a known business workflow, approved integration, or documented service-account purpose. If it does not, assume the account remains at risk until proven otherwise.
Decision rule: If the account has made post-login changes that can survive a password reset, handle it as an active takeover incident, not a suspicious login event.
Practitioner takeaway: The best indicator of a live SaaS takeover is not failed access, but unauthorised use of trusted access after entry has already succeeded.
Related resources from NHI Mgmt Group
- What are the signs that an Azure account takeover campaign is still active inside an organisation?
- How should security teams reduce account takeover risk when employees still use passwords across SaaS apps?
- What are the signs that a user account takeover is active rather than just suspicious?
- What are the signs that SaaS non-human identity abuse is still active after initial remediation?