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.
When malware starts behaving like an identity problem
Once malware moves from simple endpoint compromise into identity abuse, the telemetry changes. You stop seeing only host-level execution and begin seeing actions that require valid trust, such as consent grants, token creation, privileged publishing, and access requests from tools or workloads that did not previously need them. The key question becomes whether the attacker is merely running code, or is now borrowing authority.
That shift matters because identity artefacts can outlive the original infection. A stolen session, abused refresh token, or newly approved consent can let the campaign persist even after the endpoint is cleaned. In practice, the strongest signal is not one event in isolation, but a cluster of identity-side anomalies that line up with recent malware activity.
- Unusual consent prompts or grants, especially for applications that were not previously approved by the user or administrator.
- New token issuance, refresh-token churn, or repeated bearer-token use from unusual locations, devices, or user agents.
- Suspicious publishing activity, such as packages, workflows, or content appearing from an account that has no normal release history.
Why the identity symptoms look different from ordinary infection
Identity abuse usually appears as a mismatch between expected role and observed action. Malware that has captured a browser session, OAuth grant, API token, or developer credential can call services that the endpoint alone could never reach. That is why impossible travel, atypical token redemption, or access from a new automation path can be more informative than the original malware alert.
Publishing and collaboration systems are especially useful indicators because they show intent to propagate. If a compromised account suddenly pushes packages, edits CI/CD settings, or requests permissions for developer tooling, the campaign is often trying to turn trust relationships into a distribution channel. The endpoint infection is the entry point; the identity artefact is the lever.
Signals such as token minting, consent anomalies, and developer tooling requesting broader access than before should be read together. A single alert may reflect user behaviour or admin work, but a sequence of new consent, token use, and privileged publishing is much more consistent with identity abuse than with routine malware alone.
What practitioners should verify before calling it identity abuse
The most important distinction is between suspicious-but-legitimate access and access that has become impossible to explain from normal business use. Start by validating whether the account, token, or application had a documented need for the requested scope, whether the consent was user-driven or silently granted, and whether the publishing or access event aligns with the account’s historic pattern.
If the answer is no, treat the identity artefact as part of the incident, not as a side effect. Sessions, refresh tokens, API keys, and consented applications should be reviewed as first-class objects because they can remain usable after the original endpoint is remediated. In this stage, the goal is to determine whether the malware has become a persistence mechanism, a propagation mechanism, or both.
When the behaviour crosses into identity territory, it often leaves a governance trail. Look for newly registered applications, broadened scopes, unusual delegated access, changes in publishing rights, or access from developer utilities that have never been part of the user’s normal operating environment. Those are the points where malware begins to resemble abuse of trust rather than ordinary host compromise.
Risk and Threat Considerations
Identity abuse changes the blast radius of malware because the attacker is no longer limited to the infected machine. A valid token, consented application, or abused publishing path can let the campaign persist, move laterally, or reappear after endpoint cleanup.
Failure mechanism: The malware steals or induces trust material, then uses it to mint tokens, grant access, or operate through approved tooling that defenders may not associate with the infection.
Impact: Compromise can spread across mail, code, cloud, or collaboration platforms, and the malicious activity may survive device reimaging until tokens, consents, and delegated access are revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | Identity abuse commonly uses stolen sessions or tokens to act as valid accounts. |
| Recommendation — Hunt for valid-account use after malware alerts and revoke suspicious sessions or tokens. | ||
| CIS Controls v8 | CIS-5 — Account Management | Consent, tokens, and publishing rights are account and access artefacts that need control. |
| Recommendation — Review and revoke unnecessary account access paths, including tokens, consents, and delegated rights. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance, bearer-token use, and credential lifecycle are central to identity abuse detection. |
| AC-6 — Least Privilege | Overbroad scopes and newly requested access signal privilege expansion during malware abuse. | |
| Recommendation — Rotate or invalidate compromised authenticators and enforce lifecycle controls for tokens and secrets. Reduce granted scopes and remove excess privilege from accounts, apps, and developer tooling. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Compromised non-human identities and tokens become dangerous when excess privilege exists. |
| Recommendation — Audit non-human identities for excess privilege and narrow scopes before reuse spreads compromise. | ||
Practitioner Guidance
What to prioritise: Check identity-side events first when malware and unusual access occur together. A token, consent, or publishing action with no clear business justification is more urgent than a noisy host alert because it can keep working after the endpoint is cleaned.
What to verify: Confirm whether the account had a legitimate need for the granted scope, whether the token was issued from a known device and location, and whether the publishing or access pattern matches the account’s historical role. If those checks fail, treat the identity artefact as compromised until proven otherwise.
Practitioner takeaway: The practical test is persistence through trust, if the campaign can keep operating through valid consent, bearer tokens, or developer access, you are dealing with identity abuse, not just malware infection.
Related resources from NHI Mgmt Group
- What is the difference between prompt injection risk and identity abuse in agents?
- Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
- What does AI model abuse reveal about the current NHI threat surface?
- Why is the abuse of NHIs a priority for security teams?