Heads up: a batch of seemingly useful npm date and streak utilities were found secretly delivering a RedC2 4.0 Linux backdoor. These packages actually work as advertised — then quietly unpack and run a native binary that phones home to a command-and-control (C2) service. In short: useful little helpers up front, covert implant under the hood.

What was discovered

Security researchers from TrendAI analyzed a set of npm modules that contain a bundled native binary disguised as a math or accelerator file. The module’s entry point launches that binary the moment the package is imported, so a single dependency (even transitive) is enough to trigger the drop and execution.

The planted files have names like math-core.bin, math-calc.bin, calc-math.dat, calc-cache.bin, or calc-mapping.bin, and usually sit inside dist/ or dist/internal/. Regardless of name, the payload is the same: a Linux beacon component of the RedC2 framework that registers with a remote operator and waits for commands.

The JavaScript loader (for example, dist/index.mjs) re-exports the visible helpers so the package appears legitimate, then marks the bundled binary executable and starts it as a detached background process. No install hook and no exported function call are required — just an import.

RedC2 is advertised as a cross-platform C2 toolset that supports surveillance, credential theft, file transfer, staged payloads, multi-beacon control and even an AI command layer. It includes a built-in assistant that can translate human language instructions into complex post-exploitation command sequences, making orchestration easier for attackers of varying skill levels.

Why this matters and what you can do

This incident highlights two nasty trends: the clever use of legitimate-looking packages to deliver native implants, and the rise of C2 frameworks with AI-powered helpers that lower the skill bar for complex intrusions. The result: supply-chain style compromises that can infect systems without a single manual click.

Practical steps to reduce risk:

  • Audit dependencies: review your dependency tree and lockfiles for unknown or unmaintained packages, especially those with tiny, odd names.
  • Inspect package contents: when possible, open packages before installing. Look for unexpected native binaries inside dist/ folders.
  • Pin and lock: use package-lock.json / yarn lock or a private registry to control exactly which package versions are allowed.
  • Least privilege: run builds and services with minimal privileges so a dropped binary can’t easily persist or escalate.
  • Monitor and detect: watch for unusual outbound connections from build systems and developer machines; flag processes that spawn unexpected native executables from node_modules.
  • Rotate secrets: if you suspect compromise, rotate credentials and API keys that might have been exposed.
  • Use code signing and provenance tooling where possible to assert publisher identity.

If you maintain packages, treat publishing credentials like gold: enable 2FA, review CI secrets, and keep an eye on your registry activity. If you consume third-party modules, prefer well-known libraries and consider supply-chain scanning tools as part of your CI pipeline.

In short: a cute calendar helper could be a Trojan horse. Stay suspicious, check your modules, and don’t let a tiny utility drop a background sleeper on your servers.