The lotusbail npm package presents itself as a WhatsApp Web API library - a fork of the legitimate @whiskeysockets/baileys package. With over 56,000 downloads and functional code that actually works as advertised, it's the kind of dependency developers install without a second thought. The package has been available on npm for 6 months and is still live at the time of writing.
Behind that working functionality: sophisticated malware that steals your WhatsApp credentials, intercepts every message, harvests your contacts, installs a persistent backdoor, and encrypts everything before sending it to the threat actor's server.
What gets captured:
- Authentication tokens and session keys
- Complete message history (past and present)
- Full contact lists with phone numbers
- Media files and documents
- Persistent backdoor access to your WhatsApp account
How It Works
The Cover Is Real
Most malicious npm packages reveal themselves quickly - they're typosquats, they don't work, or they're obviously sketchy. This one actually functions as a WhatsApp API. It's based on the legitimate Baileys library and provides real, working functionality for sending and receiving WhatsApp messages.
Obvious malware is easy to spot. Functional malware? That gets installed, tested, approved, and deployed to production.
The social engineering here is brilliant: developers don't look for malware in code that works. They look for code that breaks.
The Theft and Exfiltration
The package wraps the legitimate WebSocket client that communicates with WhatsApp. Every message that flows through your application passes through the malware's socket wrapper first.
When you authenticate, the wrapper captures your credentials. When messages arrive, it intercepts them. When you send messages, it records them. The legitimate functionality continues working normally - the malware just adds a second recipient for everything.
All your WhatsApp authentication tokens, every message sent or received, complete contact lists, media files - everything that passes through the API gets duplicated and prepared for exfiltration.
But the stolen data doesn't get sent in plain text. The malware includes a complete, custom RSA implementation for encrypting the data before transmission:
Why implement custom RSA? Because legitimate WhatsApp libraries don't need custom encryption - WhatsApp already handles end-to-end encryption. The custom crypto exists for one reason: to encrypt stolen data before exfiltration so network monitoring won't catch it.
The exfiltration server URL is buried in encrypted configuration strings, hidden inside compressed payloads. The malware uses four layers of obfuscation: Unicode variable manipulation, LZString compression, Base-91 encoding, and AES encryption. The server location isn't hardcoded anywhere visible.
The Backdoor
Here's where it gets particularly nasty. WhatsApp uses pairing codes to link new devices to accounts. You request a code, WhatsApp generates a random 8-character string, you enter it on your new device, and the devices link together.
The malware hijacks this process with a hardcoded pairing code. The code is encrypted with AES and hidden in the package:
This means the threat actor has a key to your WhatsApp account. When you use this library to authenticate, you're not just linking your application - you're also linking the threat actor's device. They have complete, persistent access to your WhatsApp account, and you have no idea they're there.
The threat actor can read all your messages, send messages as you, download your media, access your contacts - full account control. And here's the critical part, uninstalling the npm package removes the malicious code, but the threat actor's device stays linked to your WhatsApp account. The pairing persists in WhatsApp's systems until you manually unlink all devices from your WhatsApp settings. Even after the package is gone, they still have access.
They Really Didn't Want You Looking
The package includes 27 infinite loop traps that freeze execution if debugging tools are detected:
These traps check for debuggers, inspect process arguments, detect sandbox environments, and generally make dynamic analysis painful. They also left helpful comments in their code marking the malicious sections - professional development practices applied to supply chain attacks. Someone probably has a Jira board for this.
Final Thoughts
Supply chain attacks aren't slowing down - they're getting better. We're seeing working code with sophisticated anti-debugging, custom encryption, and multi-layer obfuscation that survives marketplace reviews. The lotusbail case isn't an outlier. It's a preview.
Traditional security doesn't catch this. Static analysis sees working WhatsApp code and approves it. Reputation systems see 56,000 downloads and trust it. The malware hides in the gap between "this code works" and "this code only does what it claims."
Catching sophisticated supply chain attacks requires behavioral analysis - watching what packages actually do at runtime. When a WhatsApp library implements custom RSA encryption and includes 27 anti-debugging traps, those are signals. But you need systems watching for them.
This writeup was authored by the research team at Koi Security. We built Koi to detect threats that pass traditional checks but exhibit malicious behavior at runtime.
Book a demo to see how behavioral analysis catches what static review misses.
Stay safe out there.