Zero-permission malware is malicious code that runs without needing user-granted permissions or obvious access prompts. In practice, it exploits trusted apps, abused interfaces, or pre-existing device capabilities to operate quietly. In identity security, it can hijack sessions, steal secrets, or pivot through legitimate NHI credentials without triggering standard permission controls.
How Zero-Permission Malware Works
Zero-permission malware succeeds by avoiding the normal user-consent moment that many people associate with compromise. Rather than asking for obvious permissions, it rides inside a trusted app, abuses an approved interface, or uses capabilities that are already present on the device to perform malicious actions quietly.
That makes the technique especially dangerous in environments where users and defenders expect permission prompts to be the primary warning signal. If the malware inherits trust from the hosting process, it can look like ordinary application activity while still reaching data, services, or sessions that the user never intended to expose.
Why It Is Dangerous in Identity-Centric Environments
The identity-security impact is what elevates this term beyond generic malware. Zero-permission malware can hijack authenticated sessions, copy tokens or cookies, and move through legitimate access paths without needing to steal a password first. When an endpoint already holds valid access, the malware often needs only to observe or reuse it.
That matters because modern environments depend on short-lived sessions, delegated access, and service credentials that are useful to legitimate automation and equally useful to an attacker once exposed. In practice, the malware can turn a trusted user context into a launch point for further access, privilege escalation, or lateral movement.
Common Entry Paths and Abuse Patterns
Typical abuse patterns include malicious package updates, compromise of a trusted utility, or exploitation of an app that already has broad local or cloud-side reach. The malware may also abuse browser sessions, developer tooling, sync clients, or integration agents that routinely handle secrets and authenticated requests.
Because those pathways are already normalised, defenders may miss the compromise if they focus only on permission dialogs or traditional payload behaviour. The real signal is often not a new permission request, but an established application suddenly performing identity-sensitive actions such as exporting secrets, opening API connections, or reusing a session in an unusual context.
For a broader view of how malware families combine concealment, loaders, and evasion, see the Malware Guide.
Detection, Containment, and Recovery
Detection should focus on behaviour, not just prompts. Review unusual child processes, token use, script execution, browser or SSO session reuse, secret access, and unexpected outbound connections from software that should not be handling those assets. Post-incident review should also ask whether the malware accessed credentials, sessions, keys, or vault-backed material that can outlive the initial infection.
Containment usually requires more than removing the binary. Organisations often need to revoke sessions, rotate exposed secrets, invalidate tokens, and inspect adjacent systems for follow-on use of the same access path. Where the malware operated through a trusted integration or cloud workload, inventory the affected credential chain rather than assuming the endpoint cleanup alone closes the incident.
When malware lands inside a production access path, secret rotation and session invalidation can become urgent. The CircleCI breach 2023 shows how malware-driven session theft can expose CI/CD secrets and force broad credential rotation.
Risk and Threat Considerations
Zero-permission malware is risky because it defeats a common mental model: no prompt does not mean no compromise. Once malicious code can operate inside trusted software or trusted sessions, the attacker can blend into ordinary authentication and application traffic while reaching data that looks legitimate to downstream systems.
Failure mechanism: The malware inherits trust from an already-authorised app, session, or local capability, then reuses that trust to access secrets, tokens, or connected services without tripping standard permission checks.
Impact: Organisations can lose confidentiality, identity assurance, and control over downstream systems at the same time, especially when rotated secrets, active sessions, or privileged service credentials are exposed.
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 |
|---|---|---|
| CIS Controls v8 | CIS-10 — Malware Defenses | Zero-permission malware is a malware detection and containment problem. |
| Recommendation — Harden malware defenses and monitor for trusted-process abuse that bypasses user prompts. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | The term centers on malicious code that must be detected and contained on endpoints. |
| IA-5 — Authenticator Management | The malware can steal or replay sessions, tokens, and secrets that must be rotated after compromise. | |
| AC-6 — Least Privilege | The threat exploits trusted apps and pre-existing capabilities, so excess privilege enlarges impact. | |
| Recommendation — Deploy malicious code protection and tune it for behaviour-based detection. Rotate exposed authenticators and invalidate compromised sessions after suspected abuse. Limit the privileges of apps, users, and service credentials to reduce abuse potential. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | The term explicitly involves session hijacking and reuse of legitimate identity material. |
| T1055 — Process Injection | Zero-permission malware often hides inside trusted apps or processes to act quietly. | |
| Recommendation — Hunt for replayed sessions, cookies, and tokens used as alternate authentication material. Detect and block suspicious code running inside trusted processes. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The definition says the malware can steal secrets and pivot through legitimate NHI credentials. |
| NHI-05 — Overprivileged NHI | Legitimate NHI credentials and trusted interfaces become more damaging when access is excessive. | |
| NHI-07 — Long-Lived Secrets | Persistent credentials and sessions increase the window for quiet abuse after infection. | |
| Recommendation — Scan for secret exposure paths and rotate credentials after compromise. Right-size non-human access so stolen credentials expose less privilege. Reduce secret lifetime so malware has less time to reuse stolen material. | ||
Practitioner Guidance
What to watch for: Treat trusted-process abuse as a malware class of its own. Review whether endpoint, browser, and cloud logs can show secret reads, session use, or token replay from software that should not normally touch those assets, then pair that telemetry with fast revocation paths.
Governance implication: Ownership should cover the whole trust chain, not just the malware sample. Security teams, IAM owners, and platform owners need a shared playbook for session invalidation, secret rotation, and post-compromise review when malware operates through legitimate access rather than obvious permission prompts.
Related resources from NHI Mgmt Group
- What breaks when permission creep is not controlled in a zero-trust programme?
- What do teams get wrong about permission creep in zero trust?
- Why does Zero Trust reduce the value of chasing every threat alert or malware campaign?
- What do teams get wrong about zero trust when they assume attackers will always use malware or vulnerabilities?