A secret stealer is malware designed to locate and extract credentials from files, memory, environment variables, and configuration stores. Its value to attackers is reuse, because stolen secrets often unlock cloud services, source control, and automation systems with little immediate friction.
Expanded Definition
A secret stealer is a form of malware built to harvest credentials from places where teams routinely leave them behind: local files, memory, environment variables, build logs, browser stores, and misconfigured configuration repositories. In NHI security, the term is broader than password theft because the target is often machine-readable access material such as API keys, tokens, certificates, and cloud access profiles.
Definitions vary across vendors on whether a secret stealer must exfiltrate data in real time or whether any malware that enumerates and stages secrets qualifies. NHI Management Group treats the term functionally: if the code is designed to discover reusable secrets and move them to an attacker-controlled destination, it fits the category. That makes it adjacent to infostealers, but more specific to operational access theft in infrastructure and software delivery environments.
Secret stealers are often discussed alongside the OWASP Non-Human Identity Top 10 because their value depends on weak secret handling, not just malicious code execution. The most common misapplication is treating them as generic malware only, which occurs when defenders ignore secrets embedded in CI/CD systems, containers, and source control.
Examples and Use Cases
Implementing defenses against secret stealers rigorously often introduces friction in developer workflows, requiring organisations to weigh faster delivery against tighter secret handling and verification.
- A developer accidentally commits an API token to a repository, and a secret stealer running in a compromised CI job scans the checkout and exfiltrates the token before cleanup.
- A build runner inherits environment variables from an orchestration layer, and the malware enumerates those variables to recover cloud credentials and deployment tokens.
- A workstation infection finds browser-stored cloud console sessions, then uses the session material to access production services without triggering a password reset.
- An attacker drops a malicious package or action into a pipeline, then the payload harvests credentials from logs and temporary files, as seen in the Reviewdog GitHub Action supply chain attack.
- A container image includes a plaintext config file with long-lived secrets, allowing malware to retrieve them later from mounted volumes or image layers, a pattern analysed in the Guide to the Secret Sprawl Challenge.
For handling guidance, teams often compare these scenarios with the OWASP Non-Human Identity Top 10 because secret exposure is rarely isolated to one endpoint; it spreads across code, runtime, and automation boundaries.
Why It Matters in NHI Security
Secret stealers are operationally dangerous because stolen secrets usually unlock services directly. Once a token or key is reused, the attacker may not need to bypass MFA, exploit a vulnerability, or maintain long-term malware persistence. That is why NHI Management Group reports that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage. In practical terms, the malware converts a storage mistake into a privileged access event.
This risk is amplified by weak lifecycle controls. Secrets that never rotate, remain valid after notification, or sit outside approved vaults are much easier for malware to monetise than short-lived dynamic credentials. That is why NHI governance focuses on secret discovery, rotation, offboarding, and strict placement controls in line with the Ultimate Guide to NHIs and broader identity guidance in the OWASP Non-Human Identity Top 10. Secret stealers also commonly abuse build and delivery infrastructure, making CI/CD pipeline exploitation case study a relevant reference point for detection and containment.
Organisations typically encounter the full impact only after an unexpected cloud login, source-control compromise, or pipeline misuse, at which point secret stealer activity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret theft maps to improper secret management and credential exposure. |
| NIST CSF 2.0 | PR.AA-5 | Access credentials must be managed and protected across systems and workflows. |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero Trust assumes compromise and limits value of stolen credentials through continuous verification. |
| CSA MAESTRO | A-1 | Agentic systems rely on secrets that must be protected from unauthorized extraction. |
| NIST SP 800-63 | Digital identity guidance helps distinguish authenticators, tokens, and credential lifecycle. |
Inventory exposed secrets, remove hardcoded credentials, and rotate anything a secret stealer could reuse.
