A hardcoded list stores the target channels inside the package, so defenders can often identify the exact abuse by reviewing the code or extracting the IDs. A remotely fetched list keeps the targets outside the package, usually in a JSON file or similar resource, which lets the attacker change victims after publication. Remote lists are harder to spot, and they support faster retargeting.
What changes when the target list is hardcoded versus fetched remotely?
The core difference is where the attacker keeps control over targeting. A hardcoded list is embedded in the package, so defenders can inspect the code or extract the identifiers and often map the abuse more quickly. A remotely fetched list moves that targeting data outside the package, which makes retargeting easier after publication and reduces the value of static review alone.
That distinction matters because the package may look stable while the abuse pattern changes underneath it. In practice, the target list becomes a living dependency: the published npm artifact is only the loader, while the real target set can be swapped, expanded, or repurposed without republishing the package.
For analysts, the difference is not just visibility, it is also trust boundary placement. A hardcoded list can usually be validated by reversing the package contents; a remote list requires you to inspect the external endpoint, its update path, and any compromise or manipulation of that external source.
Why remote target lists are harder to detect and disrupt
Remote lists are harder to spot because the package no longer needs to contain the full set of victims, selectors, or campaign identifiers. That means simple source review, signature matching, and package diffing may show very little, even though the package is actively selecting targets from elsewhere. The secret sprawl challenge is a useful companion reference here because the same operational problem appears when malicious code keeps important abuse material outside the artifact being reviewed.
They also support faster retargeting. An attacker can change the remote file after the package has been published, rotate victims without a new release, or selectively narrow the campaign if defenders start blocking known targets. That makes retrospective analysis harder, because the package version alone may not explain what it did on a given day.
Hardcoded lists, by contrast, are usually less flexible for the attacker but easier for defenders to attribute. If the list is inside the package, a one-time review can often reveal the exact scope of the campaign, which improves triage, blocklisting, and incident scoping.
What investigators should look for in malicious npm packages
The first question is whether the package is only a launcher, or whether it also controls targeting logic. Remote fetches, configuration pulls, and JSON endpoints deserve the same attention as the package code itself, because they may be the real control plane for abuse. A package that appears harmless in static review can still be dangerous if it dereferences external targeting data at runtime.
For defenders, the practical difference shows up in how you hunt. Hardcoded target lists are easier to extract from the package artifact, source maps, or deobfuscated code. Remote lists require network capture, endpoint inspection, historical artifact retention, and sometimes environment replay so you can see what the package fetched at the time it executed.
When the remote source is mutable, treat the package as a distributed attack surface rather than a self-contained file. If the external list can be altered without changing the npm release, you need to monitor the external source as part of the software supply chain, not just the published package.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Remote target lists act like externally managed abuse inventory. |
| Recommendation — Inventory and monitor every external target source used by package code. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Track external endpoints and artifacts that shape package behaviour. |
| Recommendation — Inventory the package and its external dependencies, including remote target sources. | ||
| SLSA | Supply chain integrity | Remote target lists alter artifact behaviour outside the published package. |
| Recommendation — Treat mutable external target data as part of the supply chain review. | ||
| MITRE ATT&CK | T1204 — User Execution | Malicious packages rely on execution paths that trigger hidden behaviour. |
| Recommendation — Map package execution paths to the conditions that activate remote targeting. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Runtime fetching of target lists requires visibility into executed network requests. |
| Recommendation — Log package network activity that reveals remote target retrieval. | ||
Practitioner Guidance
What to verify: Determine whether the package reads targets from bundled code, an embedded asset, or a live endpoint before you rely on a static review. If the target set is fetched remotely, preserve the fetched artifact and its URL, because the abuse path may disappear after the campaign changes.
What practitioners underestimate: Remote target lists are often treated as a minor implementation detail, but they are really a control point for campaign agility. If that control point is mutable, the package can evolve without republishing, which means your detection logic must watch both the package and the external source it consults.
Decision rule: If the list is hardcoded, prioritize code extraction and indicator matching; if it is remote, prioritize endpoint monitoring, content capture, and source integrity checks before assuming the package’s behaviour is fixed.
Practitioner takeaway: The security difference is not just concealment, it is mutability, hardcoded lists are easier to inspect, while remotely fetched lists give attackers a hidden update channel that can change targeting after release.
Related resources from NHI Mgmt Group
- What is the difference between prompt injection risk and identity abuse in agents?
- What is the difference between SAST and DAST for security teams?
- How should teams reduce risk from malicious npm package installs?
- Why do malicious npm packages that target non-human identities create such a broad blast radius?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
