OAuth token theft and malware chaining expose persistent identity gaps

At a glance

What this is: Anomali’s Cyber Watch pulls together multiple active campaigns to show that attackers are chaining social engineering, malware, and OAuth abuse through trusted channels rather than relying on a single tactic.

Why it matters: IAM and security teams need to treat consent, token issuance, and behavioural monitoring as part of the attack surface, because identity compromise increasingly arrives through legitimate-looking workflows.

Context

OAuth abuse is no longer a narrow application-security problem. When attackers can pivot from a fake login prompt, a compromised extension registry, or a malicious agent flow into usable tokens, the real governance gap is not just access control but trust in the channel that issues access. The identity question is whether the organisation can tell the difference between a valid request and a socially engineered one.

The article ties together campaigns that differ in delivery but share the same strategic pattern: get a user or developer to authorise something, then convert that trust into persistence, lateral access, or exfiltration. For IAM and NHI programmes, that means the boundary between human consent, delegated application access, and non-human token use is now a primary control surface, not an edge case.

Key questions

Q: What breaks when OAuth consent is treated like a one-time setup step?

A: Consent turns into standing delegated access when teams stop tracking scopes, owners, and tenant-specific service principals after approval. The result is access that outlives the business need and becomes difficult to review, revoke, or explain during governance checks.

Q: Why do stolen OAuth tokens and publishing secrets create such broad risk?

A: They let attackers act as trusted users or trusted automation, which collapses the gap between initial compromise and downstream abuse. A single token can expose mail, chat, files, code publishing, or cloud actions depending on scope. The risk grows when grants are long-lived and the environment does not continuously verify who should still hold them.

Q: What are the signs that malware has crossed into identity abuse?

A: Look for unusual consent events, new token issuance, suspicious publishing activity, impossible travel tied to bearer-token use, and developer tooling that suddenly requests access it never needed before. Those signals indicate the campaign has moved beyond endpoint infection and is now using identity artefacts for persistence or propagation.

Q: How should teams respond when a trusted channel is used to steal tokens?

A: Contain the identity first by revoking suspicious grants, rotating exposed secrets, and invalidating active sessions before you focus only on host cleanup. Then review adjacent applications, developer accounts, and automation paths that may share the same trust boundary. If the channel was trusted once, assume related access paths may also be compromised.

Technical breakdown

Why OAuth consent is a high-value attack path

OAuth consent flows give a third-party application delegated access without sharing the user’s password. That is useful for modern software, but it also creates a clean social-engineering target: if the user approves a malicious or compromised app, the attacker can receive a bearer token that inherits whatever scopes were granted. Because the token is valid inside the ecosystem, downstream services may treat the request as legitimate unless additional policy or detection is in place. In practice, the risk sits in the combination of consent, scope design, and weak review of who can request access.

Practical implication: Treat OAuth consent as a privileged decision point and restrict which apps can request high-impact scopes.

How malware chaining turns one compromise into more access

The campaigns in the article show a recurring pattern: one foothold becomes a launch point for a second stage. A registry infection can steal developer secrets, a token theft can unlock cloud or collaboration data, and an update or script execution path can be used to maintain access or spread further. This chaining matters because defenders often optimise for the first event, such as phishing or malware execution, while missing the identity artefacts that convert a local compromise into broader account abuse. The technical challenge is that the malware is not only stealing data; it is harvesting the trust objects that let the attacker move as the victim.

Practical implication: Correlate malware detections with token, session, and secret misuse so the response covers identity abuse, not only endpoint cleanup.

Why developer ecosystems are attractive for identity theft

Extension registries, package managers, and build tooling hold a dense concentration of credentials, publishing rights, and automation tokens. GlassWorm and similar activity show how attackers use these environments to capture secrets and then reuse trusted publishing paths to propagate malicious updates. That is a machine-identity and developer-identity problem at the same time: the attacker wants the credentials that let code be published, pipelines be triggered, and services be accessed without further user interaction. When these identities are long-lived or weakly scoped, the compromise outlives the original infection point.

Practical implication: Inventory developer and CI/CD credentials as governable identities, not just as secrets stored in tooling.

Threat narrative

Attacker objective: The attacker wants durable access that survives the initial compromise, letting stolen tokens and developer secrets drive follow-on theft, propagation, or espionage.

1. Entry begins with social engineering or trusted-channel abuse, including fake login prompts, malicious extension delivery, or a compromised account used to send convincing content.
2. Credential access follows when the target grants OAuth consent or the malware extracts tokens, publishing secrets, browser credentials, or repository access material.
3. Escalation occurs as stolen tokens and secrets are reused to act as the victim, publish further malware, or maintain access through proxies and persistence tooling.
4. Impact is persistent identity abuse across email, chat, file systems, developer ecosystems, or update channels, with exfiltration and propagation continuing after the initial lure.

Breaches seen in the wild

• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Consent has become a security boundary, not just a user experience step. OAuth approval screens and trusted chatbot or app flows now function as the moment where identity is delegated. Once a user authorises access, the resulting token can outlive the interaction and be reused elsewhere, which means governance must move closer to issuance and consent policy. Practitioners should treat approval flows as a control point that deserves policy, monitoring, and review.

Malware chaining exposes a governance gap between endpoint security and identity security. The article’s campaigns show that attackers rarely stop at code execution or local infection. They use malware to reach tokens, secrets, and publishing rights, then use those artefacts to impersonate users or automate further abuse. That is a classic case of identity spillover, where the real loss is not the malware binary but the access material it extracts. Practitioners should align endpoint, IAM, and secret governance so one control failure does not become a fleet-wide access problem.

Token theft is now a lifecycle problem, not a one-time compromise event. When bearer tokens, OAuth grants, and developer publishing credentials are long-lived, the attacker does not need to stay present in the original session. They can return through legitimate channels until the grant is revoked or the scope is removed. This is where non-human identity governance intersects directly with human IAM: the organisation must know which delegated identities exist, who approved them, and how they are retired. Practitioners should make token lifecycle visibility a standing governance requirement.

What this signals

Token governance now sits alongside endpoint defence as a frontline control. The campaigns in this article show that attackers often do not need to break authentication if they can persuade a user or developer to authorise access on their behalf. That makes consent review, app allowlisting, and grant revocation part of the same security conversation as malware detection and phishing defence.

Developer tooling is a non-human identity risk surface. Extension registries, package managers, and CI/CD systems hold the secrets that let attackers publish, propagate, and persist. Once those credentials are stolen, the compromise can move through trusted automation rather than through the original workstation, so governance needs to follow the credential, not just the device.

For practitioners

• Tighten OAuth consent governance Restrict which applications can request high-impact scopes, require admin approval for risky consent, and review legacy grants that no longer match business need.
• Correlate endpoint and identity telemetry Link malware detections to token use, consent events, repository access, and cloud sign-ins so an endpoint alert can trigger identity containment.
• Inventory developer and publishing credentials Treat npm, GitHub, extension registry, and CI/CD tokens as governed identities with owners, scopes, and revocation paths.
• Shorten the lifetime of delegated access Move toward narrower scopes and faster revocation for OAuth grants, service tokens, and publishing rights that do not need to persist.

Key takeaways

• Attackers are chaining phishing, malware, and OAuth abuse to turn trusted identity workflows into access pathways.
• The core risk is not one malware family but the reuse of tokens, publishing rights, and delegated grants after compromise.
• Consent governance, token lifecycle control, and behavioural visibility are the controls most likely to reduce the blast radius.

Key terms

• OAuth consent abuse: OAuth consent abuse occurs when a user is tricked into granting an application access scopes that the attacker can later use for data access or workflow abuse. It is an identity governance problem because the security decision is made at authorisation time, not only at login.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Developer Publishing Credential: A developer publishing credential is a secret that allows code, packages, or extensions to be uploaded to a trusted repository or marketplace. If stolen, it can turn a single endpoint compromise into ecosystem-wide distribution of malicious updates.
• Consent Governance: Consent governance is the set of policies, systems, and evidence needed to collect, record, propagate, and withdraw permission for data processing. It becomes operationally meaningful only when the organisation can prove that downstream systems honour the decision consistently across channels and vendors.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern human and non-human access with the same discipline.