Fraud, phishing, and espionage show identity abuse at scale

At a glance

What this is: This is SentinelOne's analysis of identity abuse across fraud, phishing, and espionage, showing how account compromise, token persistence, and network intrusion can all sit in the same control gap.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern identity abuse as a lifecycle and assurance problem across human accounts, tokens, and delegated access, not as isolated incident types.

By the numbers:

• International law enforcement arrested 5,811 suspects and seized approximately $293 million in illicit assets in Operation First Light 2026.
• Operation First Light 2026 spanned 97 countries and blocked over 31,000 fraudulent bank accounts and virtual wallets.

Context

Identity abuse now spans fraud, phishing, and espionage because the same access primitives are being reused across very different adversary objectives. The control problem is no longer limited to password theft or one compromised account; it includes token persistence, delegated access, and the operational reuse of identities after initial compromise.

SentinelOne's article ties together a large-scale law enforcement crackdown, a device-code phishing campaign against Microsoft 365, and state-aligned intrusions against Pakistani law enforcement networks. The common thread is not the sector or motive, but the way identity trust is captured, extended, and operationalised after access is obtained.

Key questions

Q: What breaks when device code phishing is not separately governed?

A: MFA can still fail if the user is tricked into approving a legitimate device authorization request. The access is then issued through the correct identity provider, which makes the session look normal even though the attacker initiated the flow. Teams need to govern the approval path itself, not just the password or second factor.

Q: Why do stolen tokens often survive password resets and MFA changes?

A: Because tokens are issued after authentication and often remain valid independently of later password or MFA updates. Unless the organisation revokes the token itself, the attacker can continue using the bearer credential until it expires or is explicitly invalidated. That is why token lifecycle control matters more than login hardening alone.

Q: What are the signs that a compromised cloud identity is being used for persistence?

A: Watch for new roles, altered trust policies, unusual token issuance, access at odd hours, and identity-management actions that do not match the workload’s normal function. Those signals often show that the attacker has moved from initial access into durable access paths.

Q: How should teams respond when fraud, phishing, and espionage all use the same identity path?

A: Treat the access path as the primary object of defence and response, not the incident label. Fraud, phishing, and espionage can all exploit the same account, token, or delegated trust mechanism, so containment must focus on revocation, telemetry, and scope review across the identity estate. Separate motives do not justify separate controls.

Technical breakdown

How device-code phishing turns OAuth flow into initial access

OAuth 2.0 device code flow was designed for input-constrained devices, where a user authenticates elsewhere and the device polls for approval. Attackers abuse that trust model by presenting a convincing verification page and asking the victim to authorise an attacker-controlled device. The victim is not handing over a password, which is why MFA can still appear satisfied while the attacker acquires a valid token path. In this pattern, the weakness is not the protocol itself but the mismatch between the protocol's intended use and the attacker’s chosen context. Practical implication: monitor device-code events as a distinct authentication signal, not just as another login.

Practical implication: treat device-code approval as a high-risk authentication event and review where the flow is actually necessary.

Why token persistence outlives the original compromise

Forg365's browser extension shows how a foothold becomes durable access. Once the attacker has an initial grant, the extension can request account data, clear session cookies, and trigger a hidden OAuth flow to capture fresh tokens without forcing the user back through visible reauthentication. That shifts the issue from password theft to session continuity, because the attacker is now operating inside the token lifecycle. The real asset is not the password but the ability to keep refreshing access quietly. Practical implication: revoking a password alone is insufficient when the abuse path is token-based.

Practical implication: revoke OAuth grants and session tokens, not just passwords, when investigating token-driven compromise.

How web portals and malware become intelligence infrastructure

The espionage campaigns against Pakistani law enforcement illustrate how attackers use web applications, network appliances, and malware together to establish persistence and surveillance. In one case, malware was disguised as a portal update and an AsyncRAT client was used to hold a foothold inside internal police networks. That pattern turns a business-facing or public-facing system into a collection point for operational intelligence and civilian data. The technical point is that compromise is often layered: application access opens the door, but the payload converts that access into long-term surveillance. Practical implication: inspect portal update paths and endpoint payload trust boundaries together, not separately.

Practical implication: validate portal update chains and endpoint trust boundaries as one attack surface.

Threat narrative

Attacker objective: The objective is to maintain durable access to accounts and internal systems long enough to harvest data, support fraud operations, or conduct espionage without repeated authentication friction.

1. Entry occurred through device-code phishing, where victims were steered to authorise an attacker-controlled gadget rather than surrendering a password.
2. Credential access was sustained through session and token abuse, with ForgCookie requesting account data and triggering hidden OAuth activity to capture fresh tokens.
3. Escalation followed as attackers retained continuous Microsoft 365 access without reauthentication, turning a single approval into durable account control.
4. Impact was persistent mailbox and service access that supported post-compromise activity while reducing the chances of user suspicion or simple password-reset remediation.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity abuse is now a cross-domain governance problem, not a single-threat category. Fraud operations, phishing kits, and espionage intrusions may differ in motive, but they increasingly converge on the same control surfaces: authentication events, token lifecycles, and delegated access paths. That means the governance model has to span human users, service access, and post-compromise token handling. The practitioner conclusion is straightforward: treat identity abuse as a lifecycle issue across the full access chain.

Device-code flows create a trust boundary that many programmes still misclassify. The protocol is legitimate, but legitimacy is not the same as safety when the approval step can be socially engineered. This is why policy exceptions around device-code auth need explicit justification and monitoring rather than quiet enablement. The practitioner conclusion is to make device-code usage visible, rare, and reviewable.

Token persistence is the real control gap when reauthentication never happens. Password resets address the symptom, not the session continuity that attackers exploit after initial access. Once refresh tokens and OAuth grants can be silently reused, the account becomes a persistence layer. The practitioner conclusion is that incident response must include the token estate, not just the account owner.

Broadening identity abuse into espionage shows how access is converted into intelligence value. The same access path that enables fraud can be repurposed for surveillance, data collection, and operational visibility. That is why IAM, PAM, and incident response need shared telemetry and common revocation logic across email, web portals, and endpoint-controlled sessions. The practitioner conclusion is to govern access as an enterprise-wide control plane, not a product silo.

Third-party and public-facing systems can become identity amplification points. When a portal or appliance is compromised, the attacker inherits trust relationships that extend well beyond the first foothold. That turns a local intrusion into a broader governance failure over who can act, persist, and observe. The practitioner conclusion is to examine which systems can mint or extend trust on behalf of others.

What this signals

Identity abuse now behaves like a shared control-plane problem. When fraud operators, phishing kits, and espionage crews all pursue durable access through the same identity systems, the old separation between account security and incident response becomes less useful. IAM teams need to think in terms of access continuity, not just login success.

Device-code approval deserves a higher-risk policy state. If a user can be socially engineered into approving an attacker-controlled device, then the protocol’s usability benefit is also its governance weakness. The practical shift is to narrow exceptions, increase logging, and make the flow visible to security operations.

Token revocation has become a first-class recovery step. Password resets remain necessary, but they do not close the door on attacker-controlled sessions. For most organisations, the decisive move is to align Microsoft Entra monitoring, consent governance, and incident response around the token lifecycle.

For practitioners

• Audit device-code authentication use Inventory where device-code flows are permitted, justify each exception, and alert on unexpected device-code approvals in Microsoft Entra and related identity logs.
• Revoke OAuth grants during compromise handling Add OAuth consent grants, refresh tokens, and session cookies to your containment checklist so that account recovery actually severs attacker persistence.
• Separate phishing response from password-only remediation When a campaign uses token capture or adversary-in-the-middle techniques, require token invalidation and app consent review instead of relying on password resets alone.
• Correlate portal compromise with endpoint payload trust Review public-facing applications, update mechanisms, and malware delivery paths together so that a portal compromise cannot silently become internal surveillance.

Key takeaways

• Identity abuse in this article is not limited to one threat type. Fraud, phishing, and espionage all depend on controlling or extending trust inside identity systems.
• The evidence shows scale and persistence, from global fraud enforcement actions to token-driven Microsoft 365 hijacking and network-level espionage campaigns.
• Teams limit damage by governing device-code flows, revoking OAuth grants and tokens, and treating access continuity as the core response problem.

Key terms

• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• Token Persistence: Token persistence is the retention of access or refresh tokens beyond the immediate task that justified them. In browser-based integrations, it increases the chance of unauthorized reuse, complicates revocation, and creates a governance problem because the credential outlives the user’s intent.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Identity Abuse: Identity abuse is the misuse of valid credentials, tokens, delegated permissions, or trusted access relationships to move through an environment. It is dangerous because it often appears legitimate to systems and operators until the attacker has already advanced.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.