Er is een serieuze supply-chain aanval gemeld die zich richt op het Ethersphere-ecosysteem rondom Swarm. In plaats van een klassieke hack van een server, maakten aanvallers gebruik van het eigen release- en automatiseringsproces om kwaadaardige versies van bee-js 13.3.0 en Swarm Desktop 0.56.2 te verspreiden. Het doel was helder: walletdiefstal via supply chain door wallet-sleutels en bijbehorende wachtwoorden te stelen, plus het installeren van een backdoor.
De releases zijn later ingetrokken en er is een schone update uitgerold, maar dat betekent niet dat slachtoffers automatisch beschermd zijn. Wie de getroffen versies installeerde en/of uitvoerde, moet rekening houden met compromis. Hieronder lees je wat er precies is gebeurd, hoe de aanval werkt en welke stappen je nu kunt nemen.
Wat is er misgegaan bij Ethersphere?
Volgens de beschikbare incidentanalyse kwam de besmette software uit het automatiseringskanaal van het project. De aanvallers konden twee pakketten/programma’s in het distributiepad krijgen:
- bee-js 13.3.0 (JavaScript library achter Swarm Desktop en een CLI-tool)
- Swarm Desktop 0.56.2 (desktopapp die een Swarm-node lokaal draait en privésleutels bewaart)
Beide releases bevatten code die wallet-gerelateerde informatie probeert te bemachtigen. Daarnaast installeert de malware een backdoor op Windows, macOS en Linux.
De getroffen releases zijn inmiddels van de distributiebronnen gehaald. Dat verkleint nieuwe schade, maar het voorkomt helaas niet dat al geïnstalleerde of uitgevoerde kopieën nog door de malware zijn beïnvloed.
Welke versies waren besmet?
De timing van de publicatie lijkt beperkt, maar genoeg voor installaties via automatisering en updatekanalen.
- bee-js 13.3.0: de versie stond ongeveer 75 minuten als laatste release op npm voordat deze weer werd teruggetrokken.
- Swarm Desktop 0.56.2: deze kwam op GitHub terecht en was een periode beschikbaar; de app-updater kon sommige systemen binnen korte tijd een upgrade aanbieden.
Belangrijk detail: de pakketten kenden distributiepaden via bestaande versiebereiken in andere onderdelen van het ecosysteem. Daardoor kon een frisse installatie binnen het “window” van de besmette versie automatisch naar de boosaardige release leiden.
Hoe werkt de walletdiefstal via supply chain?
De kern van het probleem zit in de manier waarop de besmette code wordt gestart.
bee-js: code via postinstall
De bee-js-package draait de aanvallende logica als een postinstall script. npm voert dergelijke install-scripts meestal automatisch uit tijdens installatie, tenzij install-scripts bewust zijn uitgeschakeld. In de gemelde aanval hoefde een project de library niet eens expliciet “te importeren”; het distributiemechanisme zorgt er in dit geval voor dat de code toch draait.
Swarm Desktop: code bij het opstarten
Bij Swarm Desktop loopt de loader opnieuw op momenten dat de app start. Daardoor kan de aanval ook na installatie actief blijven zolang de getroffen versie in gebruik is.
Wat wordt er gestolen?
De malware controleert in de dataomgeving van Swarm Desktop of twee specifieke bestanden aanwezig zijn: een configuratiebestand (config.yaml) en een pad naar een sleutellocatie (data-dir/keys/swarm.key). Wanneer beide er zijn, stuurt de malware de informatie door naar de aanvallers.
Volgens de analyse gaat het om het wallet-gerelateerde deel dat nodig is om de node te misbruiken. Het scenario gaat verder dan alleen credentials: er wordt ook een backdoor geïnstalleerd, zodat de aanvallers langduriger toegang kunnen opbouwen.
Welke backdoorcomponenten komen erbij?
Naast het verzamelen van walletbestanden installeert de payload een vorm van remote toegang.
- Linux en macOS: er wordt een Go-remote shell geplaatst in een verborgen map (~/.solidity), en deze draait als user service of LaunchAgent.
- Windows: de code installeert een Remote Access Client die is ondertekend door een bekende maker. Die client wordt als systeemservice uitgevoerd en vormt de verbinding richting de aanvallers.
Voor het aansturen van de backdoor wordt gebruik gemaakt van een koppeling die via een smart contract adresbaar is, zodat de aanvallers hun infrastructuur kunnen blijven wijzigen.
Waarom is dit zo lastig te detecteren?
De gemelde incidentanalyse benadrukt dat installeren of updaten niet genoeg is. De malware kan zijn eigen netwerkproblemen maskeren, waardoor install logs soms geen duidelijke fout tonen. Daarmee wordt het eenvoudiger om te denken dat “alles goed ging”, terwijl er toch code is uitgevoerd.
Bovendien is het verwijderen of updaten van de app/pakket niet automatisch een garantie dat de backdoorcomponenten worden verwijderd. In het bericht wordt expliciet aangegeven dat een schone update niet per definitie reeds geïnstalleerde backdoors wegneemt.
Wat moeten gebruikers en beheerders nu doen?
Het advies is om getroffen systemen te behandelen als volledig gecompromitteerd als de relevante versie is geïnstalleerd en/of is uitgevoerd. Met andere woorden: neem dit serieus, ook als er geen directe aanwijzingen zijn van misbruik.
Gebruik bee-js? Check dit direct
- Zoek in lockfiles, package caches, interne registries en CI install logs naar @ethersphere/bee-js@13.3.0, inclusief kopieën die via andere packages zijn meegekomen.
- Pin terug naar 13.2.0 en verwijder/clear cached exemplaren van 13.3.0—ook in npm-mirrors.
- Als 13.3.0 is geïnstalleerd met install-scripts ingeschakeld: behandel ook de CI-runner of machine als gecompromitteerd.
- Vanaf een “clean” systeem: rotate alle wachtwoorden, tokens en keys die door het installatieproces konden worden gelezen.
Gebruik je Swarm Desktop? Pak de app-log en versie aan
- Controleer in bee-desktop.log op regels zoals Bee Desktop version: 0.56.2 (production). Dit wordt bij elke start gelogd vóór de kwaadaardige code draait.
- Installeer Swarm Desktop 0.56.3. Op Linux is handmatig vervangen nodig.
- Als 0.56.2 ooit gedraaid heeft: beschouw de node-sleutel en wachtwoord als gestolen. Verplaats funds en stake naar een nieuwe sleutel via een schone opzet.
Verwijder de sporen die niet vanzelf teruggaan
Volgens de analyse moet je op systemen waarop de code liep de volgende onderdelen verwijderen. Let op: enkel updaten/verwijderen van de app of het package haalt de backdoor niet automatisch weg.
- Verwijder op Linux/macOS de map ~/.solidity en bijbehorende service/agent (zoals een user service of LaunchAgent).
- Verwijder op Windows de ScreenConnect Client-service met het genoemde identifier-achtige kenmerk.
- Waar mogelijk: rebuild de machine vanuit een vertrouwde basisimage in plaats van “cleaning in place”.
Wil je de aanpak van incidentrespons en supply-chain verificatie verder aanscherpen? Lees dan ook eens hoe eerdere compromissen via externe toegang zijn gelopen, bijvoorbeeld in Qubole: misbruik Trusted AWS toegang.
Indicatoren om te zoeken (IOCs)
Voor detectie en triage kun je in logs en op endpoints zoeken naar de in de analyse genoemde signalen. Hieronder staan voorbeelden van de meest relevante indicatoren:
- Domein: api.frameworkmetrics[.]xyz
- URL paths (o.a. loadercomponenten): /v1/analytics (bee-js loader), /v1/electron (Swarm Desktop loader), en /v1/assets en /v1/swarm/report
- HTTP header: X-Ethersphere: 1
- Linux/macOS backdoorpad: ~/.solidity/
- Services/agents: solidity-langsupport-runner.service en com.solidity.langsupport.runner
- Windows component: ScreenConnect Client (5cbe79c9c25524df)
- Specifieke IP:port endpoints voor de control/relay kanalen zoals in de analyse genoemd
Omdat IOc’s altijd contextafhankelijk zijn (en aanvallers soms variëren), is het beste gebruik dat je ze combineert met bestandschecks, versiecontroles en loganalyse.
Hoe kon dit gebeuren? Misbruik van CI en signing
De incidentnote wijst op het diefstal van CI-credentials en geheimen. Er zijn aanwijzingen dat twee GitHub-accounts betrokken waren bij het proces waaruit de releases voortkwamen. De besmette releases zijn vervolgens verspreid via bestaande automatiseringen: voor bee-js werd de npm-publishingflow gestart, en voor Swarm Desktop werd een buildflow geactiveerd die signingcertificaten gebruikte.
Opvallend is dat provenance (waar “waar gebouwd is” wordt geregistreerd) niet automatisch betekent dat de inhoud ook echt veilig is; het helpt vooral bij herleidbaarheid, niet bij inhoudelijke code-reviews.
Dit soort incidenten passen in een breder patroon van supply-chain aanvallen waarbij de “weg naar distributie” wordt misbruikt. Als je meer wilt lezen over hoe aanvallers eerder in ecosystemen toeslaan, bekijk dan PapRAT backdoor: nieuwe dreiging voor cyberespionage, dat laat zien hoe snel een besmetting kan escaleren zodra toegang eenmaal binnen is.
Wat betekent dit voor jou vandaag?
De boodschap is hard, maar praktisch: als je bee-js 13.3.0 of Swarm Desktop 0.56.2 had, ga er dan vanuit dat je systeem niet meer betrouwbaar is. Niet omdat je “te laat” bent, maar omdat de malware juist is ontworpen om na installatie en uitvoering door te pakken.
Vervang de getroffen versies door de schone release, controleer CI- en installsporen, rotate credentials vanaf een clean omgeving en verwijder backdoorcomponenten volgens de aanwijzingen. Alleen dan verlaag je de kans dat walletinformatie alsnog wordt misbruikt.
Zo voorkom je dat walletdiefstal via supply chain beperkt blijft tot één korte window—en zorg je dat je omgeving weer in control komt.
Bron: https://thehackernews.com/2026/11/hackers-compromise-etherspheres-bee-js.html
