What are the signs that a malicious dependency campaign is using dynamic channel lists to keep changing targets without publishing a new package version?

What the runtime pattern says about the campaign

The key sign is not just that a package is suspicious, but that its behaviour is reconfigurable after install. If the code pulls a live list from a remote source, then the operator can retarget existing installs without publishing a new package version. That changes the package from a static artifact into a control plane for ongoing targeting.

When that happens, the package version, checksum, and repository history can look stable while the real targeting logic lives elsewhere. Practitioners should treat the remote list as the effective payload surface, because the package may be only a loader for continuously updated instructions.

Which artefacts usually move together

Campaigns of this type often leave a distinctive cluster of indicators: remote JSON or similar list retrieval at runtime, repeated channel identifiers reused across many package names, and code that differs only in the endpoint or list contents. That combination suggests the same operator infrastructure is being repurposed across multiple packages rather than each package being independently maintained.

Another useful clue is retargeting without republishing. If an installed copy suddenly starts pointing at a new set of targets because the remote list changed, then the package has a mutable dependency on external content. A normal software update changes the package itself; this pattern changes behaviour through an outside list, which is easier for an operator to swap quietly.

How to distinguish this from ordinary telemetry or configuration

Not every runtime fetch is malicious. Legitimate software may check configuration, feature flags, or policy files. The difference here is that the remote list is used to alter which packages, hosts, or environments are acted on, and the same structure appears across many package names. A shared list format plus copy-pasted loader logic is stronger evidence than a single network call.

It also helps to compare the package’s declared purpose with its actual network and file behaviour. If the package claims to provide a narrow utility but repeatedly fetches a changing target list, that mismatch is a strong sign that targeting logic has been externalised. The most important question is whether the remote content affects control flow, not whether the package has a network dependency at all.

Risk and Threat Considerations

Dynamic channel lists make dependency abuse harder to contain because the attacker can change targets after trust has already been granted to the package. That means detection based only on package publication events, version bumps, or static hashes will miss the real change in behaviour.

Failure mechanism: A loader package fetches remote instructions at runtime, and the operator updates the list to redirect already-installed copies toward new targets without touching the package version. Reused identifiers and near-identical code help the campaign scale across multiple package names while keeping the targeting logic centralised.

Impact: The same malicious package can pivot quickly, expand its reach, and survive partial takedowns because defenders are chasing a moving external list rather than a single immutable release. That raises the odds of missed victims, delayed containment, and repeated compromise across environments.

Practitioner Guidance

What to verify: Confirm whether the package retrieves remote data that changes execution targets, not just static configuration. If the fetched content is materially influencing behaviour, treat the remote source as part of the threat surface and preserve the list snapshots alongside the package sample.

What to prioritise: Correlate package name, channel ID, endpoint, and target list content across the full set of related packages. Shared channel IDs or identical loader fragments are more actionable than a single suspicious domain, because they show campaign reuse and make clustering possible.

Practitioner takeaway: The strongest signal is mutable targeting, not simply malicious code. If the package can keep changing victims through a remote list, your response should focus on the loader, the list source, and all installs that trust it.

Related resources from NHI Mgmt Group

• What are the signs that a malicious package campaign is trying to occupy dependency names?
• How should teams reduce risk from malicious npm package installs?
• What breaks when organisations rely on package version checks without verifying what code actually runs during dependency installation?
• What is the difference between malicious package publishing and a controlled dependency confusion challenge in practice?