Direct naar de inhoud
Beveiligingsnieuws

WeaselBiscuit stealer via 13 npm-pakketten

WeaselBiscuit stealer

Cybersecurityonderzoekers hebben een nieuwe JavaScript stealer ontdekt die via npm-pakketten verspreid wordt. De malware krijgt de naam WeaselBiscuit stealer en valt op door zijn eenvoud: het pakket heeft minder “zware” functionaliteit dan andere families waarmee het overlapt, maar het kan wél gevoelige data verzamelen uit de opslag van Chrome-extensies.

In dit artikel lees je wat onderzoekers precies zagen, hoe de infectieketen werkt, welke data wordt buitgemaakt en welke praktische maatregelen je vandaag nog kunt nemen om dit type software supply chain-risico te beperken.

Wat is de WeaselBiscuit stealer?

De WeaselBiscuit stealer wordt geleverd via een cluster van 13 npm-pakketten. Volgens onderzoekers gaat het om een “smallere” en “lichtere” variant: veel uitgebreide functies uit andere, vergelijkbare malwarefamilies ontbreken juist. De naam is een verwijzing naar het idee dat een wezel kleiner is dan een otter, en “biscuits” minder uitbundig zijn dan “cookies”.

Onderzoekers signaleren functionele overlap met twee malwarelijnen die gekoppeld worden aan de DPRK-campagne “Contagious Interview”: BeaverTail en OtterCookie. Tegelijk benadrukken ze dat WeaselBiscuit zich anders gedraagt door zijn beperkte set mogelijkheden.

Verspreiding: van npm-import naar uitvoering in geheugen

Een van de meest opvallende onderdelen is de manier waarop de WeaselBiscuit stealer start. De malware wordt getriggerd via een npm import. Daarna haalt de loader (“loader.js”) de hoofdcode op vanaf een externe “dead drop” en voert die direct uit in memory.

Onderzoekers noemen daarbij dat de loader de instellingen voor command-and-control (C2) niet in het pakket zelf lijkt te bewaren, maar ophaalt via een aparte Npoint-URL. Vervolgens profileert de malware de gecompromitteerde host en begint met het verzamelen van data.

Welke npm-pakketten horen erbij?

De onderzochte set bestaat uit deze pakketten/varianten:

  • @biz44/id10-client
  • @biz44/id12-client
  • @biz44/id44-client
  • @biz44/id79-client
  • @biz44/id95-client
  • @biz44/id99-client
  • @biz44/process-runtime-utils
  • @biz44/runtime-utils
  • engin1
  • id79-client
  • process-lhpm
  • process-mite
  • process-tailwind

Dat meerdere kleine packages dezelfde malafide keten ondersteunen, maakt dit extra relevant voor teams die automatisch afhankelijkheden installeren of lockfiles massaal hergebruiken.

Wat steelt WeaselBiscuit?

De kern van de WeaselBiscuit stealer ligt in het oogsten van Chrome extension storage. Dat geldt voor Windows, macOS en Linux. De malware uploadt “elke leesbare en niet-lege” file onder de directory Local Extension Settings.

Volgens onderzoekers is dat een raw LevelDB key/value store. Met andere woorden: de stealer zoekt gericht naar de lokale opslag die extensies gebruiken en neemt die gegevens mee, zonder te wachten op een tweede payload.

Extra functionaliteit op Windows

Op basis van instructies van de operator (geleverd via de C2-server) kan de malware aanvullende logging uitvoeren op Windows. Onderzoekers noemen specifiek het loggen van klembordinhoud en het vastleggen van toetsaanslagen.

Hoewel WeaselBiscuit niet draait met dezelfde “wallet-draining” code als grotere familieleden, is deze extensiegerichte aanpak financieel nog steeds relevant. Een wallet-extensie of andere gevoelige extensie kan namelijk exact in die Local Extension Settings informatie opslaan die waardevol is voor aanvallers.

Wat ontbreekt er juist? (belangrijke nuance)

Een groot verschil met zwaardere verwanten is dat de WeaselBiscuit stealer niet lijkt te beschikken over meerdere componenten die je bij andere campagnes vaker tegenkomt. In de observaties ontbreekt onder meer:

  • remote access (dus geen directe commando-uitvoering op afstand zoals bij sommige families)
  • persistence-mechanismen zoals het hardnekkig blijven na herstart
  • crypto wallet draining-functionaliteit
  • het kunnen leveren van secondary payloads zoals de in de bron genoemde InvisibleFerret

Toch is juist die focus op één duidelijke datacategorie (Chrome extensies) een reden waarom je dit type malware niet moet onderschatten: eenvoud verlaagt de kans op detectie en maakt de aanvalketen vaak direct uitvoerbaar zodra de malafide afhankelijkheid wordt geïnstalleerd.

Tradecraft-signalementen en mogelijke toeschrijving

Onderzoekers plaatsen de vondst in de bredere context van Contagious Interview. Tegelijk geldt: er is geen definitief bewijs om WeaselBiscuit ondubbelzinnig toe te schrijven aan specifieke actoren. Wel zijn er signalen die aansluiten op patronen die eerder bij DPRK-gelieerde tooling zijn gezien.

Concreet worden onder meer deze punten genoemd:

  • Gebruik van Npoint.io, een lichtgewicht JSON-opslagservice. NVISO had Npoint.io in november 2025 gelinkt aan Contagious Interview.
  • Gebruik van geneste publieke-IP en geolocatie-checks via api.ipify.org en ip-api.com.
  • Overeenkomsten in de C2-architectuur met delen die overlap vertonen met OtterCookie.
  • Een numerieke campaign ID (10, 12, 44, 79, 95, 99) die elk installatieprofiel labelt. Dat patroon lijkt op eerdere waarnemingen rond PolinRider.

De bron noemt daarnaast als C2-voorbeeld een serveradres zoals 103.170.217:8787.

Waarom dit binnen software supply chain beveiliging extra belangrijk is

WeaselBiscuit is een typisch voorbeeld van hoe de supply chain kan worden misbruikt zonder dat er meteen een “volwaardig” malwareplatform nodig is. Als ontwikkelteams of build-omgevingen automatisch npm-dependencies installeren, kan een malafide pakket de deur openen naar runtime-executie.

Wat dit soort incidenten lastig maakt, is dat het kwaad meestal niet zichtbaar is in je eigen code. Het zit in de afhankelijkheden die je toevoegt of lockt, en de uitvoering kan vervolgens gebeuren met een loader die het echte werk ophaalt.

Als je meer wilt weten over de achtergrond van aanvallen die op die manier via softwarecomponenten binnenkomen, is dit gerelateerd: Supply chain aanval: malware op 100.000 sites.

Praktische maatregelen tegen npm-gestuurde stealers

Je kunt dit type risico niet in één stap “wegpoetsen”, maar er zijn wel maatregelen die direct helpen. Hieronder staan aanpakken die passen bij de observaties rond de WeaselBiscuit stealer.

1) Beperk welke npm-pakketten je toestaat

Werk met een “allowlist” of minimaal met scherpe regels rond interne en externe packages. Kijk ook naar dubbele of verdachte namen in combinatie met bekende namespaces. In deze zaak gaat het om meerdere varianten die inhoudelijk naar dezelfde keten leiden.

2) Controleer afhankelijkheden vóór installatie

Maak dependency scanning onderdeel van je CI/CD. Combineer dat met beleid rond lockfiles: voorkom dat ontwikkelaars ongecontroleerd wijzigingen doorvoeren die nieuwe packages introduceren.

3) Monitor afwijkend gedrag tijdens build en runtime

Omdat de loader code kan ophalen en in memory uitvoert, is runtime monitoring waardevol. Let op onverwachte netwerkverzoeken naar externe endpoints en op procesgedrag dat afwijkt van normale ontwikkeling.

4) Besteed aandacht aan browserextensie-data

Veel organisaties denken bij datadiefstal aan bestanden en systemen, maar hier ligt de focus op Chrome extension storage. Denk aan aanvullende endpoint- en user-data monitoring, zeker als je medewerkers extensies gebruiken die gevoelige functies hebben.

Voor teams die al bezig zijn met “bewijsvoering” rond kwetsbaarheden en misbruik, kan dit conceptueel helpen: Continue controle: bewijzen of een CVE echt te misbruiken is. Het vertaalt dezelfde filosofie naar supply chain: niet alleen weten wat er mogelijk is, maar ook kunnen aantonen wat er werkelijk gebeurt.

Conclusie

De WeaselBiscuit stealer laat zien hoe moderne malware zich kan verstoppen in ogenschijnlijk normale npm-afhankelijkheden. Met 13 pakketten wordt een loader getriggerd via npm-import, waarna de malware in memory draait en gericht Chrome-extensieopslag oogst. Op Windows kan het bovendien klembordinhoud en toetsaanslagen verzamelen.

Ook al ontbreekt remote access en “zware” payload-functionaliteit, de impact kan groot zijn omdat extensie-opslag vaak gevoelige toestandsdata bevat. Door dependency governance, scanning en gedragstoezicht te combineren, maak je dit soort aanvallen aanzienlijk moeilijker.

Bron: https://thehackernews.com/2026/09/weaselbiscuit-stealer-spreads-via-13.html