A well-documented information-stealing malware known as NWHStealer has quietly updated its delivery infrastructure, abandoning familiar disguise tactics in favor of a more technically sophisticated approach: bundling malicious code inside the Bun JavaScript runtime. The shift, documented by researchers at Malwarebytes, signals that the threat actors behind this campaign are actively adapting their methods to outpace detection tools trained on older delivery patterns. For organizations and individuals running Windows systems, the practical risk is unchanged - credential theft, cryptocurrency wallet compromise, and rapid account takeover - but the path to infection has become harder to spot.
Why Bun, and Why Now
Bun is a legitimate, high-performance JavaScript runtime released as a modern alternative to Node.js. It is compact, fast, and designed to bundle application code into a single self-contained executable - a feature that makes it genuinely useful for developers and, as it turns out, equally useful for threat actors. Because Bun is relatively new and not yet heavily associated with malware campaigns, security tools are less likely to flag its executables on sight. That gap in institutional recognition is precisely what attackers are exploiting.
The delivery method begins conventionally enough. Users are tricked into downloading a malicious archive, typically through deceptive lures. Previous NWHStealer campaigns relied on fake Proton VPN installers, spoofed hardware utilities, and trojanized gaming modifications - all formats that carry a degree of social credibility for their target audiences. The malicious ZIP in the current campaign contains an installer executable that embeds heavily obfuscated JavaScript bundled directly with the Bun runtime. A secondary loader is also included as a fallback mechanism, activating if the primary Bun-based loader fails to reach its remote infrastructure. Redundancy of this kind reflects a deliberate engineering decision, not opportunism.
A Two-Stage Payload with Built-In Sandbox Awareness
The JavaScript executed by the Bun runtime is partitioned into distinct functional scripts, each handling a different phase of the infection. The first script is dedicated entirely to evasion. It runs a series of PowerShell commands - drawing on the Windows Management Instrumentation and Common Information Model interfaces - to profile the host environment. Hardware configurations, software signatures, and system characteristics are each assigned a score. If the cumulative score suggests the machine belongs to a security researcher or operates inside a virtual sandbox, the malware halts. This scoring logic is not new in concept, but its implementation within an obfuscated JavaScript bundle running inside a trusted runtime is a meaningful refinement.
If the environment passes those checks, a second script takes over. It establishes encrypted communication with the attacker's command-and-control infrastructure and prepares for payload delivery. Before the stealer itself is deployed, the loader transmits a preliminary intelligence package to the remote server: basic system profile data, the results of the anti-virtualization checks, the victim's public IP address, and a base64-encoded screenshot of the desktop. This pre-deployment reconnaissance serves a clear purpose - it tells the operator exactly what they are about to receive access to before committing the final payload. The C2 servers observed in this campaign include domains operating under silent-harvester[.]cc and silent-orbit[.]cc.
Following that initial transmission, the loader requests a unique seed value from the server. That seed is used to derive an AES encryption key, which governs the download and decryption of the NWHStealer payload itself. Encrypting the final stage in this way adds another layer of resistance against automated analysis tools that scan network traffic for known malware signatures.
What NWHStealer Actually Steals
NWHStealer is written in Rust, a systems programming language that produces compact, fast binaries with memory safety properties that also complicate reverse engineering. Once active on a Windows machine, it targets browser-stored credentials and session cookies, saved passwords, and data associated with cryptocurrency wallets. The combination is particularly damaging. Browser credentials alone can enable account takeovers across email, banking, and enterprise platforms. Cryptocurrency wallet access is typically irreversible - unlike a compromised bank account, there is no dispute process and no insured recovery mechanism for stolen digital assets.
The use of Rust also contributes to the malware's longevity. Rust-compiled binaries behave differently from those written in more commonly analyzed languages, and signature-based detection tools require dedicated work to reliably flag them. The pairing of a Rust-based payload with a Bun-bundled JavaScript loader creates a multi-layered evasion profile that is more than the sum of its parts.
Indicators of Compromise and Defensive Posture
Organizations running endpoint detection tools should update their threat intelligence feeds to include the following indicators associated with this campaign. Domains are intentionally defanged and should only be re-fanged within controlled platforms such as MISP, VirusTotal, or a properly isolated SIEM environment.
- NWHStealer C2 domains: whale-ether[.]pro, cosmic-nebula[.]cc
- Bun Loader C2 domains: silent-harvester[.]cc, silent-orbit[.]cc, support-onion[.]club
Beyond blocking known indicators, the broader defensive implication of this campaign is worth absorbing. The abuse of a legitimate, less-scrutinized runtime like Bun is a reminder that threat actors monitor the security community's detection coverage as closely as researchers monitor malware evolution. Any trusted tool that can carry and execute arbitrary code - especially one that security tools have not yet learned to treat with suspicion - represents a potential vehicle. Endpoint monitoring that focuses on behavioral signals rather than static signatures, combined with restrictions on the execution of unsigned or unexpected runtime environments, will prove more durable than any static blocklist. User education around the source and legitimacy of software installers and archives remains, as ever, the first line of defense that no technical control can fully replace.
