Settantatré secondi. È il tempo che la pipeline di pubblicazione automatica di Ethersphere, il progetto dietro la rete di storage decentralizzato Swarm, ha impiegato per trasformare una release malevola in un pacchetto npm pubblico, provvisto di provenienza valida e pronto per essere scaricato. Un attacco alla supply chain che ha colpito contemporaneamente una libreria JavaScript e un’applicazione desktop, con l’obiettivo dichiarato di rubare chiavi di wallet Ethereum e installare backdoor persistenti su Windows, macOS e Linux.

Due superfici, un solo account compromesso

Ethersphere sviluppa bee-js, la libreria JavaScript che fa da collante tra le applicazioni e i nodi della rete Swarm, e Swarm Desktop, l’app che permette di eseguire un nodo Swarm direttamente dal proprio computer. Il 9 novembre gli attaccanti hanno usato l’automazione di release del progetto — non una falla nel codice, ma l’account di servizio bee-worker stesso — per pubblicare due versioni compromesse: bee-js 13.3.0 su npm e Swarm Desktop 0.56.2, distribuita tramite l’updater integrato dell’app. Secondo Socket, gli attaccanti avrebbero avuto accesso sia all’account bee-worker sia a quello di un maintainer di lunga data del progetto; non è ancora chiaro come le credenziali siano state sottratte.

Nessuna delle due pubblicazioni è passata attraverso una pull request o una firma manuale. Per bee-js, una GitHub release ha attivato automaticamente il workflow di pubblicazione su npm, che non richiedeva alcuna approvazione: in 73 secondi il pacchetto era online, completo di provenienza valida — un dettaglio importante, perché la provenienza attesta solo dove un pacchetto è stato costruito, non che il suo codice sia stato revisionato. Per Swarm Desktop, gli attaccanti hanno avviato manualmente un workflow di build usando i certificati di firma Apple e Windows del progetto, anche in questo caso senza bisogno di approvazione. L’app macOS risultante era regolarmente notarizzata, al punto che il sistema ha mostrato solo il normale avviso di primo avvio, senza alcun segnale di allarme.

Un contratto Ethereum come centralina di comando

Ventinove minuti prima che il codice malevolo venisse inserito in bee-js, gli attaccanti avevano già aggiornato un contratto Ethereum che custodisce l’indirizzo del server di comando e controllo — una scelta progettuale che permette di cambiare l’infrastruttura di C2 in qualsiasi momento senza dover ripubblicare il malware. Il loader, poche righe di codice che scaricano ed eseguono ulteriore codice dal domino api.frameworkmetrics[.]xyz, si attiva in momenti diversi secondo il veicolo: in bee-js gira come script postinstall al momento dell’installazione (bastava quindi installare il pacchetto, non era necessario nemmeno importarlo), mentre in Swarm Desktop si riattiva a ogni avvio dell’applicazione.

Furto del wallet e backdoor su misura per ogni sistema operativo

Il payload scaricato cerca due file specifici nella cartella dati di Swarm Desktop: config.yaml e data-dir/keys/swarm.key. Il secondo è un keystore Ethereum cifrato, ma la password che lo protegge è conservata in chiaro proprio dentro config.yaml — una combinazione che consegna agli attaccanti l’accesso completo ai fondi del wallet del nodo: token xDAI e xBZZ, fondi dei chequebook e stake.

Oltre al furto delle chiavi, il codice installa backdoor differenziate per piattaforma:

• Linux e macOS: una remote shell scritta in Go, soprannominata evjawbreaker, nascosta nella cartella ~/.solidity/. Viene eseguita come servizio systemd utente su Linux e come LaunchAgent su macOS, e legge l’indirizzo del proprio server di comando direttamente da uno smart contract Ethereum, così gli attaccanti possono cambiarlo in qualunque momento senza aggiornare il malware installato.
• Windows: il codice installa un client ScreenConnect legittimo, firmato digitalmente da ConnectWise, configurato come servizio di sistema collegato a un relay controllato dagli attaccanti. Se l’utente ha privilegi di amministratore, il malware applica una tecnica nota di bypass dello User Account Control, aggiunge un’esclusione a Microsoft Defender e installa il client senza alcuna interazione visibile. In caso contrario, continua a riproporre la richiesta di elevazione dei privilegi fino a ottenerla.

Un filo che porta a SleepyDuck

La cartella ~/.solidity/ non è un dettaglio casuale. Secondo Pluto Security, i payload di questa campagna condividono infrastruttura e convenzioni di naming con estensioni malevole per Open VSX diffuse nel settembre 2026, a loro volta collegate “con alta confidenza” al gruppo responsabile di SleepyDuck, il trojan diffuso nel novembre 2025 attraverso una falsa estensione VS Code per Solidity che usava proprio uno smart contract Ethereum come canale di comando di backup. Socket attribuisce l’attacco a Swarm allo stesso gruppo. Se confermato, si tratterebbe della terza ondata nota di attacchi alla supply chain dello sviluppo software condotta dallo stesso attore in poco più di un anno, con un filo conduttore tecnico coerente: usare la blockchain come infrastruttura di comando resiliente alla rimozione.

Cronologia dell’incidente (UTC, 9 novembre 2026)

• 00:09 — bee-js 13.3.0 pubblicato su npm.
• 00:36 — Swarm Desktop 0.56.2 pubblicato su GitHub; l’updater integrato poteva proporlo agli utenti entro circa 10 minuti.
• 01:25 — bee-js 13.3.0 non è più la versione più recente su npm.
• ~09:00 — Swarm Desktop 0.56.2 viene ritirato, circa 8 ore e mezza dopo la pubblicazione.
• Stesso giorno — Ethersphere pubblica Swarm Desktop 0.56.3 (il codice della 0.56.1, firmato con un nuovo certificato Developer ID) e il team implementa un controllo di approvazione DevOps per i job di firma, eseguibili ora solo dal branch principale.

Secondo le stime di Socket, bee-js 13.3.0 è stato scaricato circa 10 volte, mentre Swarm Desktop 0.56.2 ha raggiunto 65 download entro le 08:27 UTC — numero che include probabilmente anche i ricercatori che stavano già analizzando l’incidente. Numeri contenuti, ma che non riducono la gravità per chi ha effettivamente eseguito il codice: la compromissione del wallet e l’installazione delle backdoor avvengono indipendentemente dal volume complessivo di download.

Cosa fare ora

Per chi utilizza bee-js: verificare lockfile, cache, registri interni e log CI per riferimenti a @ethersphere/bee-js@13.3.0, anche come dipendenza indiretta; tornare alla 13.2.0; trattare come compromessa qualunque macchina o runner CI che abbia installato la 13.3.0 con gli script di installazione attivi, anche in assenza di errori visibili, e ruotare da una macchina pulita tutte le credenziali che l’utente o il job di installazione potevano leggere.

Per chi usa Swarm Desktop: controllare il file bee-desktop.log per la stringa “Bee Desktop version: 0.56.2 (production)” e aggiornare immediatamente alla 0.56.3. Se la 0.56.2 è stata eseguita anche solo una volta, chiave e password del nodo vanno considerate compromesse: da una macchina pulita occorre spostare fondi, chequebook e stake su una nuova chiave.

Su qualsiasi macchina dove il codice sia stato eseguito, va rimossa manualmente la cartella ~/.solidity/ insieme al servizio systemd, al LaunchAgent macOS o al servizio Windows ScreenConnect installati dal malware: aggiornare, reinstallare o disinstallare l’applicazione non elimina questi componenti. Dove possibile, la soluzione più sicura resta la reinstallazione completa del sistema da un’immagine fidata, piuttosto che una pulizia manuale.

Indicatori di compromissione

Dominio C2:        api.frameworkmetrics[.]xyz
Path loader:       /v1/analytics (bee-js) | /v1/electron (Swarm Desktop)
                    /v1/assets/ (payload aggiuntivi) | /v1/swarm/report (esfiltrazione wallet)
Header HTTP:        X-Ethersphere: 1
IP:porta backdoor:  193[.]57[.]9[.]155:4912 (evjawbreaker, Linux/macOS)
                    185[.]232[.]84[.]169:8041 (relay ScreenConnect, Windows)
Smart contract C2:  0xf8a900Db50b3331be6B768bA460BB59f3E40C344
Path/servizio:      ~/.solidity/
                    systemd: solidity-langsupport-runner.service
                    LaunchAgent: com.solidity.langsupport.runner
                    Windows service: ScreenConnect Client (5cbe79c9c25524df)

SHA-256:
linux_amd64    9b73e7cd4e1425e770392549d8df46c706139ef476f4f7b9ac405165dc8d9696
linux_arm64    b601776817363b96295119f7221338a122d5247a35a77a64b04f286e1bbcc565
darwin_amd64   80d2672e2599732d3c0ae2a4cd0d1e3fe4d555a60273ce33feb99db3f34d250f
darwin_arm64   fae61f31f00988fdc5cc9e7272b51e08af2e245d81003237875415930fd27358
invoke.ps1     37d14bff30762ca701e9c1f8bc6c57c065bb20ae3a2208cb7411a6530610f08e
app.msi        7527e86d70e7c9493db4356f1c3775380431b310000f2602c1e993cf435d01da