In der npm-Registry ist ein bösartiges Paket namens lotusbail aufgefallen, das sich als legitime Bibliothek für die WhatsApp Web API ausgab. Über Monate hinweg wurde das Paket produktiv eingesetzt, während der versteckte Schadcode stille Mitlese‑Funktionen, den Diebstahl von Kontakten und langfristigen Zugriff auf WhatsApp‑Konten der Betroffenen ermöglichte.
Malware in npm: Wie sich lotusbail hinter WhatsApp Web API versteckte
Lotusbail ist ein Fork des weit verbreiteten Open‑Source‑Projekts WhiskeySockets Baileys, das häufig für Integrationen mit WhatsApp Web genutzt wird. Laut Analyse von Koi Security befand sich das Paket mindestens ein halbes Jahr in der npm-Registry und wurde über 56.000‑mal heruntergeladen.
Vollständige WhatsApp-Funktionalität als Tarnkappe
Ein zentrales Merkmal des Angriffs: Lotusbail bot tatsächlich die erwartete Funktionalität eines WhatsApp Web‑Clients. Entwickler erhielten eine scheinbar normale API für Messaging, Kontakte und Medien. Gerade diese funktionale Korrektheit erzeugte den Eindruck von Legitimität und ließ das Paket in CI/CD‑Pipelines, Bot‑Frameworks oder Integrationsdiensten unauffällig wirken.
Technische Analyse: Abgriff von Nachrichten, Kontakten und Tokens
Schadcode als Wrapper um den WebSocket‑Client
Der bösartige Teil von lotusbail war als Wrapper um den legitimen WebSocket‑Client implementiert, der mit den WhatsApp‑Servern kommuniziert. Sämtlicher Datenverkehr zwischen Anwendung und WhatsApp lief dadurch zunächst durch diese zusätzliche Schicht, bevor er an die eigentliche Bibliothek weitergereicht wurde.
Im Rahmen der Anmeldung bei WhatsApp Web interzeptierte der Wrapper Authentifizierungs‑Tokens und Sitzungsschlüssel. Darüber hinaus konnten alle ein‑ und ausgehenden Nachrichten, Kontaktlisten sowie übermittelte Medien und Dokumente gelesen und verarbeitet werden, bevor sie die reguläre Bibliothek erreichten. Anwendungen, die lotusbail eingebunden hatten, wurden so unbemerkt zu Überwachungswerkzeugen für WhatsApp‑Konten ihrer Nutzer.
Verschleierung und Verschlüsselung der exfiltrierten Daten
Die abgegriffenen Daten wurden nicht im Klartext übertragen. Stattdessen kam eine kundenspezifische RSA‑Implementierung, kombiniert mit mehreren Obfuskationsstufen, zum Einsatz. Dazu gehörten Manipulationen mit Unicode‑Zeichen, Kompression per LZString und zusätzliche AES‑Verschlüsselung.
Erst nach dieser Kaskade aus Verschleierung und Verschlüsselung wurden die Informationen an Command‑and‑Control‑Server der Angreifer gesendet. Im Netzwerkmonitoring erschien der Traffic dadurch wie gewöhnlicher verschlüsselter Datenverkehr – eine Situation, die klassische Signature‑basierten Sicherheitslösungen nur schwer erkennen können.
Persistenter Zugriff über das Feature „Verknüpfte Geräte“ von WhatsApp
Besonders kritisch ist, dass lotusbail in der Lage war, ein Gerät der Angreifer über das offizielle Multi‑Device‑Feature („Verknüpfte Geräte“) dauerhaft mit dem Konto des Opfers zu koppeln. Damit erhielten die Angreifer stabilen, langfristigen Zugriff auf Chats – selbst dann, wenn das bösartige npm‑Paket später aus dem Projekt oder der Laufzeitumgebung entfernt wurde.
Solange der Nutzer nicht aktiv den Bereich „Verknüpfte Geräte“ in WhatsApp prüft und unbekannte Einträge entfernt, können Angreifer weiterhin Nachrichten mitlesen, im Namen des Opfers schreiben und neue Sitzungs‑Tokens generieren. Für viele klassische Endpoint‑ oder Netzwerk‑Security‑Lösungen bleibt ein solches, auf Anwendungslogik basierendes Vorgehen unsichtbar.
Warum die npm-Malware so lange unentdeckt blieb
Koi Security berichtet von 27 unterschiedlichen Anti‑Analyse‑Mechanismen im Code, darunter gezielt platzierte Endlosschleifen, die statische und dynamische Analysen erschweren sollten. Solche Anti‑Debugging‑Techniken erhöhen den Aufwand für Reverse Engineering erheblich und blockieren automatisierte Werkzeuge.
Hinzu kommt, dass lotusbail wie ein gewöhnlicher Fork eines etablierten Open‑Source‑Projekts aussah und die Kernfunktionalität zuverlässig bereitstellte. In vielen Entwicklungsorganisationen werden „Infrastruktur‑Bibliotheken“ aus npm oder anderen Repositories nur oberflächlich geprüft, während das Laufzeitverhalten kaum überwacht wird. Branchenberichte zur Software‑Lieferkette – etwa von Sicherheitsanbietern und Initiativen wie OWASP – zeigen seit Jahren einen deutlichen Anstieg von Supply‑Chain‑Angriffen über Paketmanager wie npm oder PyPI.
Empfehlungen für Entwickler und Security-Teams
Sofortmaßnahmen für Organisationen, die lotusbail genutzt haben
Organisationen, die lotusbail in Projekten eingesetzt haben oder dies vermuten, sollten umgehend handeln:
- Sofortige Entfernung des Pakets aus allen Abhängigkeiten, Build‑Pipelines und Laufzeitumgebungen.
- Vollständige Inventarisierung aller Repositories, Branches und Testumgebungen, in denen lotusbail referenziert wurde.
- Prüfung des WhatsApp‑Menüs „Verknüpfte Geräte“ und manuelles Entfernen unbekannter oder verdächtiger Einträge.
- Neuerstellung von Schlüsseln und Tokens, die in Verbindung mit WhatsApp‑Integrationen, Bots oder Automatisierungen verwendet wurden.
Langfristige Härtung der Software-Lieferkette
Um ähnliche Vorfälle künftig zu reduzieren, sollten Entwicklungs‑ und Sicherheitsteams folgende Praktiken etablieren:
- Nicht nur Code‑Review, sondern auch dynamische Analyse in isolierten Umgebungen (Sandboxing), mit Fokus auf Netzwerkverkehr und Dateioperationen.
- Monitoring verdächtiger ausgehender Verbindungen, insbesondere während Authentifizierungsprozessen und bei Integrationen mit Messengern oder anderen sensiblen Diensten.
- Einsatz von Software‑Composition‑Analysis (SCA), SBOMs (Software Bill of Materials), signierten Artefakten und Lockfiles zur Kontrolle der tatsächlichen Abhängigkeitskette.
- Konsequente Anwendung des Least‑Privilege‑Prinzips: Services, die mit externen APIs sprechen, sollten nur die minimal nötigen Rechte und Secrets besitzen.
- Ein formalisierter Freigabeprozess für neue npm‑Pakete, inklusive manueller Prüfung, Reputations‑Check von Autor und Repository sowie kritischer Betrachtung verdächtiger Forks populärer Bibliotheken.
Der Fall lotusbail macht deutlich, dass selbst etablierte Open‑Source‑Bibliotheken im npm‑Ökosystem zum Einfallstor für versteckte Kompromittierungen werden können. Organisationen sollten Abhängigkeiten wie fremden Code mit potenziell vollem Systemzugriff behandeln: durchgehendes Monitoring, sichere Entwicklungsprozesse, Schulungen für Entwickler und ein strukturiertes Supply‑Chain‑Security‑Programm sind inzwischen unverzichtbar. Wer seine Paketabhängigkeiten regelmäßig prüft und sicherheitskritische Integrationen wie WhatsApp gezielt überwacht, reduziert das Risiko erheblich, dass eine scheinbar harmlose Bibliothek unbemerkt zum Werkzeug für Datendiebstahl und Account‑Übernahme wird.
