|

Malicious Go and npm Packages Are Dropping Cross-Platform Malware and Triggering Remote Wipes: What Developers Must Do Now

ByInnoVirtuoso

If you rely on open source to move fast—and who doesn’t—this one’s a wake‑up call. Security researchers have uncovered a wave of malicious Go modules and npm packages that quietly pull down second-stage payloads, run them in memory on both Linux and Windows, and in one case, can even wipe a developer’s machine based on a phone-number “kill switch.”

Here’s the short version: threat actors are blending supply chain deception with cross‑platform loaders, hitting CI build servers and developer workstations alike. The result is theft of browser data and device info at best—and catastrophic data loss at worst. Let’s unpack what happened, why it matters, and how to harden your pipeline today.

What happened: a two-front supply chain campaign targeting Go and npm

Researchers reported 11 malicious Go packages that embed an obfuscated loader. At runtime, the code spawns a shell, fetches a second-stage payload from interchangeable .icu and .tech C2 domains, and executes the payload in memory. This second stage can:

  • Collect host and environment info
  • Access browser data
  • Beacon to its command-and-control server
  • Retrieve platform-specific binaries (ELF on Linux, PE on Windows)

Because the loader pulls bash scripts for Linux and uses certutil.exe to fetch Windows executables, both Linux CI runners and Windows workstations are in scope. That cross‑platform reach is the point.

The identified Go packages include:

  • github.com/stripedconsu/linker
  • github.com/agitatedleopa/stm
  • github.com/expertsandba/opt
  • github.com/wetteepee/hcloud-ip-floater
  • github.com/weightycine/replika
  • github.com/ordinarymea/tnsr_ids
  • github.com/ordinarymea/TNSR_IDS
  • github.com/cavernouskina/mcp-go
  • github.com/lastnymph/gouid
  • github.com/sinfulsky/gouid
  • github.com/briefinitia/gouid

It’s likely the work of one actor based on code format and C2 reuse. And because Go allows importing modules directly from GitHub, attackers can craft names that look legitimate at a glance—amplifying confusion on pkg.go.dev when you see multiple similar modules.

Meanwhile, two npm packages—naya-flore and nvlore-hsc—masquerade as WhatsApp socket libraries. Their behavior is more destructive:

  • They pull a remote database of Indonesian phone numbers from a GitHub repo.
  • If the current phone is not on the list during a WhatsApp pairing flow, the package executes rm -rf * to recursively delete files.
  • Both packages include code to exfiltrate device info to an external endpoint, but calls are commented out, suggesting ongoing development.
  • One package contains a hardcoded GitHub Personal Access Token that could provide unauthorized repo access.

As of this writing, the npm packages had 1,110+ combined downloads and remained available in the registry. In other words, the window for accidental exposure is real.

Why this matters right now

Three reasons this should be on your radar:

1) The loader runs everywhere
Go’s cross‑compilation and “run in memory” techniques let the same malicious logic adapt to Linux build agents and Windows developer machines. The attacker doesn’t need two exploits—just one smart distribution method.

2) Developers are targeted in the flow of work
This isn’t a one-off phishing link. It’s embedded in tools you import while building software. Busy developers doing a quick search on pkg.go.dev or GitHub can grab a module with a familiar name without noticing small namespace differences.

3) Remote wipe and data theft up the stakes
The npm “kill switch” shows the willingness to cause maximum disruption. Commented-out exfil functions and a hardcoded PAT point to ongoing development and broader ambition.

Here’s why that matters: the ROI for attackers is huge. A single malicious package can land on dozens of machines, leak sensitive data, and even brick laptops—all before anyone opens a ticket.

How the Go malware chain works, in plain English

Think of the malicious Go package as a decoy with a hidden loader:

  • During runtime, it quietly spawns a shell.
  • It reaches out to rotating C2 domains on .icu and .tech.
  • It downloads a second-stage payload tailored to your system.
  • On Linux, it runs a bash script to pull an ELF binary. On Windows, it uses certutil.exe to grab a PE executable.
  • It runs the payload in memory, which keeps disk artifacts to a minimum.

From there, the payload can enumerate the host, dip into browser data, and start beaconing. If it’s running on a CI server, it might also touch secrets injected into the build environment.

Context for developers: Go’s decentralized module model lets you import packages directly from GitHub. That’s convenient, but it also opens the door to typosquatting, namespace confusion, and “looks-trusted” names that aren’t.

  • Learn more about Go module proxies and sumdb: https://go.dev/ref/mod#goproxy and https://go.dev/ref/mod#authenticating

Inside the npm “WhatsApp” packages

On the JavaScript side, the two npm packages borrowed trust from a popular use case—WhatsApp automation—and then added a destructive twist:

  • A remote phone-number database acts as a kill switch. If your number isn’t on the list when you pair, it triggers a recursive delete of local files.
  • The packages include disabled code paths for device data exfiltration, implying they’re still being shaped.
  • A hardcoded GitHub personal token could be used to access private repositories. Even if unused here, its presence is a major red flag.

If you’re building bots or integrations and install new WhatsApp socket libraries, you’re in the blast radius. Always vet new publishers, review postinstall scripts, and scan for network calls to unexpected domains.

  • npm’s security guidance: https://docs.npmjs.com/about-security
  • Configuring npm 2FA: https://docs.npmjs.com/configuring-two-factor-authentication

Supply chain attacks: same playbook, better packaging

Fortinet’s threat research notes that while attacker tactics aren’t radically new, they’re effective: fewer files to evade attention, sneaky install scripts, and quiet exfil to blend in. Meanwhile, obfuscation keeps rising, which means you need to assume your scanners won’t catch everything on day one.

  • Fortinet FortiGuard Labs blog: https://www.fortinet.com/blog/threat-research
  • OWASP Software Supply Chain Security Project: https://owasp.org/www-project-software-supply-chain-security/

The red flags: what to look for right now

You don’t need to reverse engineer malware to catch early signs. Watch for:

  • Suspicious import paths in Go, especially lookalike namespaces and direct GitHub imports from unknown orgs.
  • Obfuscated code, minimal readmes, or repos with few commits but polished branding.
  • Runtime shell execution in Go modules; unexpected use of os/exec.
  • Network calls to .icu and .tech C2-style domains (not proof of malice, but high-signal contextually).
  • On Windows, use of certutil.exe to download binaries outside certificate tasks. See reference for what certutil should do: https://learn.microsoft.com/windows-server/administration/windows-commands/certutil
  • In npm packages, postinstall scripts, spawn of shells, or filesystem-altering commands.
  • New publishers with zero social proof pushing “hot” namespaces like WhatsApp sockets.
  • Hardcoded tokens or API keys in code.
  • Binary blobs in source, especially encrypted or base64 chunks without clear use.

Immediate actions for engineering and security teams

Act as if exposure is possible. Here’s a pragmatic checklist:

1) Freeze builds for high-risk repos
Temporarily halt deployments where these packages might be present. It buys you time to check without creating new blast radius.

2) Search your code and lockfiles
– For Go: search for the listed import paths in go.mod, go.sum, and source. Also scan for os/exec usage added in recent commits. – For npm: grep package.json, package-lock.json, and node_modules for naya-flore and nvlore-hsc.

3) Check CI images and cache layers
Malicious artifacts can sit inside Docker layers or build caches. If you find suspicious packages, rebuild from trusted base images with clean caches.

4) Remove and replace any hits
Delete the malicious dependencies. Replace them with vetted alternatives or revert to known-good versions.

5) Rotate credentials
Assume secrets may have been exposed on machines that built or ran these packages. Rotate API keys, OAuth credentials, and tokens used by CI/CD and developer workstations.

6) Inspect outbound network logs
Look for connections to suspicious .icu and .tech domains during build or dev sessions. Treat hits as indicators requiring deeper investigation.

7) Run endpoint scans and EDR sweeps
Check developer laptops and build servers for anomalous processes, persistence mechanisms, and credential theft activity.

8) Restore affected machines if wiped
If you were hit by a wipe, rebuild from known-good images. Do not restore secrets or SSH keys from potentially compromised backups.

9) Lock down install-time behavior
– For npm, audit postinstall scripts and consider blocking them in CI unless explicitly needed. – For Go, prefer module proxies and sumdb verification instead of direct GitHub imports.

10) Tighten publisher and namespace trust
Create an allowlist for publishers and namespaces your teams can depend on. Require manual review before adopting new modules in critical services.

11) Generate and keep SBOMs
Produce a software bill of materials for every build. It accelerates incident response when these events occur. Consider CycloneDX or SPDX. – CycloneDX: https://cyclonedx.org – SPDX: https://spdx.dev

12) File reports and raise registry takedowns
If you confirmed malicious behavior, report to npm, GitHub, and relevant registries. Early reports help others.

How to harden your pipeline for the long run

Sustainable defense is a program, not a one-off scan. Prioritize:

  • Hermetic builds and minimal egress in CI
  • Deny outbound network by default. Allow only approved registries and artifact stores.
  • Use private mirrors and artifact proxies. Cache vetted dependencies.
  • Strong provenance and verification
  • Adopt SLSA provenance for builds: https://slsa.dev
  • Verify signatures with Sigstore/Cosign for critical artifacts: https://docs.sigstore.dev/cosign/overview/
  • Pinning and reproducibility
  • For Go, pin via go.mod and verify via sumdb. Consider vendoring for high-trust paths.
  • For npm, ensure lockfiles are committed. Use npm ci in CI to avoid surprise updates.
  • Automated dependency risk checks
  • Use OpenSSF Scorecard and repo checks for new dependencies: https://github.com/ossf/scorecard
  • Enable Dependabot and security updates: https://docs.github.com/code-security/dependabot
  • Policy and process
  • Enforce two-person review for new dependencies in critical services.
  • Maintain an approved list of libraries and publishers.
  • Require 2FA for npm and GitHub org members. Enforce this for maintainers of internal packages.
  • Developer training and “trust-but-verify” culture
  • Teach engineers to spot typosquatting, starjacking, and suspicious namespaces.
  • Encourage fast, lightweight dependency reviews before adding something new.
  • Align with industry standards
  • Map your program to NIST SSDF: https://csrc.nist.gov/Projects/ssdf
  • Use OWASP’s guidance for supply chain security: https://owasp.org/www-project-software-supply-chain-security/

Go-specific defenses: dealing with decentralized modules

Go’s design is powerful but requires guardrails.

  • Prefer using the public module proxy and sumdb. They provide integrity checks and caching against supply disruption.
  • Go proxy and auth: https://go.dev/ref/mod#goproxy and https://go.dev/ref/mod#authenticating
  • Avoid direct GitHub imports for unvetted orgs in critical code paths.
  • Vendor dependencies for high-sensitivity services to reduce surprise updates.
  • Consider GOPRIVATE for internal modules and a private proxy for third-party mirroring.
  • Monitor for os/exec usage in dependencies. It’s not always bad, but in libraries it’s a risk flag.
  • Watch for network calls at runtime in packages that shouldn’t need them.

npm-specific defenses: reduce install-time risk

JavaScript ecosystems are flexible—and that’s a double-edged sword.

  • Treat postinstall and preinstall scripts as high risk. Gate them in CI or disable by default outside known-safe packages.
  • Enforce npm 2FA for org publishers. Clean up old tokens and automate rotation.
  • Prefer popular, well-maintained libraries with transparent governance. Popularity isn’t security, but it adds scrutiny.
  • Use npm audit, but don’t stop there. Combine with static code reviews of new libraries and behavior analysis.

What to do if you already installed any of the listed packages

Don’t panic. Do this in order:

1) Disconnect the affected machine from the network.
2) Preserve logs for forensics.
3) Rotate all credentials used on that machine since installation.
4) Rebuild from a known-good image if you see suspicious activity or can’t guarantee cleanliness.
5) Notify your security team. They can coordinate registry reports and broader checks.
6) Document the root cause. Adjust your dependency intake process so this exact pattern can’t recur.

Common attacker tricks you should expect to see more

  • Namespace confusion and lookalike repos that appear first in search.
  • “Helpful” examples or docs copied from legitimate projects to look credible.
  • Commented out exfil functions to test install base before going loud.
  • Hardcoded tokens to pivot into private repos.
  • C2 domains on low‑reputation TLDs like .icu and .tech to churn infrastructure.

Here’s the uncomfortable truth: these are not sophisticated zero-days. They’re good social engineering wrapped in code. That’s why process, provenance, and policy matter so much.

Authoritative references to go deeper

  • Go modules: proxy and verification: https://go.dev/ref/mod#goproxy and https://go.dev/ref/mod#authenticating
  • NIST Secure Software Development Framework (SSDF): https://csrc.nist.gov/Projects/ssdf
  • SLSA supply chain levels: https://slsa.dev
  • Sigstore/Cosign signing: https://docs.sigstore.dev/cosign/overview/
  • npm security and 2FA: https://docs.npmjs.com/about-security and https://docs.npmjs.com/configuring-two-factor-authentication
  • OpenSSF Scorecard: https://github.com/ossf/scorecard
  • OWASP Software Supply Chain Security: https://owasp.org/www-project-software-supply-chain-security/
  • Microsoft certutil reference: https://learn.microsoft.com/windows-server/administration/windows-commands/certutil
  • Fortinet FortiGuard Labs research: https://www.fortinet.com/blog/threat-research
  • Socket security resources: https://socket.dev

FAQ: quick answers to what you’re probably asking

Are these malicious packages still live?
As reported, the two npm packages remained available at the time of discovery and had over 1,110 downloads. Registry status can change quickly, so check current advisories and consider blocking by name in your org regardless.

How can I check if my project uses these packages?
– For Go: search your repos for the exact import paths listed above, and inspect go.mod and go.sum.
– For npm: check package.json, package-lock.json, and node_modules. Your SBOM generator can speed this up.

Are macOS developers affected, or just Windows and Linux?
The Go loaders target Linux and Windows explicitly via bash scripts and certutil.exe. macOS may still be affected indirectly if the loader runs generic logic or exfil routines. Treat any machine that installed the package as suspect.

Does a lockfile protect me from malicious packages?
Lockfiles help you stick to known versions. They don’t prevent you from locking a malicious version in the first place. Pair lockfiles with vetting, proxies, and reputation checks.

Why do attackers use .icu and .tech domains for C2?
They’re cheap, disposable, and less scrutinized. The TLD alone isn’t proof of malice, but it’s often part of the pattern.

What is certutil.exe, and why is it suspicious here?
Certutil is a legitimate Windows tool for certificate management. Attackers abuse it to download files because it’s present by default and may evade naive detection. Context matters: downloads via certutil in a build tool are a red flag.

What about Go’s sumdb and proxy—do they stop this?
They provide integrity and availability guarantees, not intent. The proxy won’t declare a package “malicious” by default. You still need publisher trust policies and human review.

How can I block destructive npm postinstall scripts?
In CI, use npm ci with controlled environments and consider disabling lifecycle scripts for untrusted packages. Gate exceptions via code review. Also, scan new dependencies for scripts and shell spawns before merging.

Should I vendor Go dependencies to be safe?
Vendoring reduces supply chain flux and is a good fit for high-trust services. Combine it with provenance, SBOMs, and private mirrors to strike a balance between security and velocity.

What’s the best first step if I’m resource-constrained?
Start with policy and visibility: enforce 2FA, enable Dependabot, pin versions with lockfiles, generate SBOMs, and restrict CI egress. Then layer in provenance and signing as you mature.

The bottom line

Open source accelerates everything—including attackers. The newly discovered Go and npm packages show how little it takes to land in your build system, steal sensitive data, or even wipe a workstation. The good news: a handful of practical controls—trust policies, dependency vetting, hermetic builds, provenance, and SBOMs—dramatically reduces risk.

If you found this helpful, consider sharing it with your team or subscribing for future breakdowns on supply chain threats and practical defenses. Staying one step ahead is a habit—and we’ll help you build it.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring! 

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

Read more related Articles at InnoVirtuoso

InnoVirtuoso

Hello there! I'm passionate content writer navigating the digital landscape. With a deep love for words and an insatiable curiosity about technology.

With 10 years of experience in IT field, I write mostly about emerging tech, sharing news, informational articles and covering other topics I find interesting.

Let's craft the future of content together – one word at a time!

Browse InnoVirtuoso for more!