Red flags include installation-time scripts, runtime code that scans files or environment variables, attempts to read secrets, silent exception handling, outbound calls to unexpected endpoints, and payloads hidden inside images or other innocuous files. Droppers may also fetch a second-stage binary after install, while stealers often target API keys, private keys, and source code directories.
What to look for when a package acts like a stealer or dropper
Packages that behave like stealers or droppers usually show intent mismatch: the declared function is harmless, but the install or runtime behaviour reaches into sensitive local state, reaches out to unfamiliar infrastructure, or prepares a second-stage payload. The most useful signal is not any single trick, but the combination of secrecy, unnecessary access, and post-install activity that does more than the package description would justify.
One of the clearest patterns is package abuse that steals credentials from users, especially when install-time code inspects environment variables, home directories, shell history, cloud config files, or source trees. If a dependency that should only add functionality starts enumerating secrets or scanning for tokens, that is a strong stealer indicator.
A second pattern is dropper-like staging, where the package does little itself but fetches, unpacks, or decrypts a second payload after install. That is especially concerning when the package hides its behaviour behind obfuscation, unusual archive formats, image files, or other innocuous containers, because the visible package is then only a delivery vehicle for the real payload.
Behaviour that separates malicious installers from noisy but benign packages
credential stealer and droppers often try to blend in by using installation hooks, background threads, or exception swallowing so the package appears to succeed even when it is probing for secrets or calling out to a remote server. Benign packages may read configuration or make outbound requests, but they normally do so transparently and for a declared purpose.
Watch for code that reads API keys, private keys, tokens, SSH material, browser stores, cloud metadata, or repository files without an obvious product reason. Also watch for packages that contact domains unrelated to the vendor, rotate through multiple endpoints, or stage data exfiltration through generic telemetry, because those are common indicators of stealthy collection and remote control.
It also matters whether the package acts once or keeps reaching back. A one-time setup script is not the same as a dropper that persists, downloads additional code, and then changes behaviour again later. The latter pattern is more dangerous because the first package is only the entry point, while the later payload can be updated independently.
Why these indicators matter in real deployments
Packages that inspect secrets or pull second-stage content can expose more than the host that installed them. They can leak repository credentials, cloud access, signing material, or private code, and then use that access to pivot into build systems, CI/CD runners, or other development environments. That makes them especially risky in automated pipelines where a single dependency can be executed at scale.
Supply-chain incidents are often hard to spot because malicious behaviour is mixed into ordinary package installation, test execution, or dependency resolution. A package can look normal in static metadata yet behave differently when installed, when a specific environment variable exists, or when it detects a high-value target such as a developer workstation or CI runner.
For broader context on package compromise patterns and secret exposure paths, see the Shai Hulud npm malware campaign and the reviewdog GitHub Action supply chain attack.
Risk and Threat Considerations
These packages are risky because they turn normal trust in install-time behaviour into a collection and delivery channel. The immediate threat is secret theft, but the downstream threat is broader: once a package can read tokens or fetch a hidden payload, it can enable account takeover, source code theft, lateral movement, or repeated compromise through later updates.
Failure mechanism: the package abuses trusted installation or runtime execution to search for secrets, evade notice through quiet error handling, or retrieve a second-stage binary or script from an external location.
Impact: exposed credentials, compromised repositories or cloud accounts, hidden persistence, and a wider supply-chain blast radius if the package is used in build or deployment automation.
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 MITRE ATT&CK define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Package stealers target secrets during install or runtime. |
| NHI-03 — Vulnerable Third-Party NHI | Malicious packages abuse supply-chain trust to exfiltrate secrets. | |
| NHI-07 — Long-Lived Secrets | Stealers often hunt for durable tokens, keys, and credentials. | |
| Recommendation — Scan dependencies for secret access and block packages that read credentials unnecessarily. Vet third-party packages for supply-chain abuse before allowing them in build pipelines. Reduce long-lived secrets so stolen material has less reuse value. | ||
| MITRE ATT&CK | T1005 — Data from Local System | Stealer behaviour includes reading local files and directories for secrets. |
| T1105 — Ingress Tool Transfer | Droppers commonly fetch second-stage payloads from remote locations. | |
| Recommendation — Hunt for packages that enumerate local files or source trees at install time. Inspect outbound fetches from packages for unexpected remote payload transfer. | ||
Practitioner Guidance
What to verify: Treat any package that reads environment variables, scans file trees, or makes unexpected outbound connections as suspect until you can explain each action against the package’s stated purpose. If the behaviour only appears during install, in CI, or on machines with privileged credentials present, raise the severity.
Decision rule: If a package touches secrets, reaches for a second payload, or hides its errors, prioritise containment and review over functional debugging. The key question is not whether it “works”, but whether its behaviour is narrower than its access.
Practitioner takeaway: The most reliable indicator of a stealer or dropper is not one suspicious line of code, it is an unjustified combination of secret access, concealment, and staged execution that exceeds what the package needs to do.
Related resources from NHI Mgmt Group
- What are the signs that an open-source package is behaving like a supply chain attack?
- What are the signs that a package build path is behaving like a compromise rather than a normal release?
- What are the signs that a PyPI package is acting like a stealer and RAT rather than normal application code?
- What are the signs that a package install is behaving like malware rather than ordinary dependency setup?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
