Qubole ed Ethersphere sotto attacco: segreti AWS rubati e software ufficiale infettato

🛡️ Executive Summary

• Un attaccante sfrutta le credenziali di un account AWS associato a Qubole per accedere agli ambienti cloud dei clienti. Wiz documenta attività tra il 14 e il 26 ottobre 2026, con furto di segreti, raccolta di credenziali ed esfiltrazione di dati da Amazon S3.
• Ethersphere subisce una compromissione della propria distribuzione software. Le versioni @ethersphere/bee-js 13.3.0 e Swarm Desktop 0.56.2 vengono pubblicate attraverso infrastrutture ufficiali, ma contengono codice malevolo capace di sottrarre informazioni e distribuire ulteriori payload.
• I due incidenti mostrano come identità e processi legittimi possano diventare vettori di attacco. Nel primo caso vengono abusati ruoli IAM concessi a un fornitore; nel secondo, l’infrastruttura GitHub Actions produce pacchetti compromessi accompagnati da attestazioni e firme autentiche.

Due compromissioni indipendenti riportano al centro della cybersecurity il problema della fiducia concessa a fornitori, identità cloud e processi di distribuzione software. Il 9 novembre 2026, Wiz Research ha documentato una campagna contro clienti della piattaforma Qubole, raggiunti attraverso credenziali associate a un account AWS già autorizzato ad accedere alle loro infrastrutture. L’attaccante ha utilizzato questa posizione per raccogliere segreti da AWS Secrets Manager, configurazioni Lambda, parametri SSM e dati conservati in Amazon S3. Nella stessa giornata, Socket ha ricostruito una diversa compromissione dell’ecosistema Ethersphere, nella quale versioni malevole di bee-js e Swarm Desktop sono state distribuite attraverso i normali processi di pubblicazione. Le due campagne non risultano collegate, ma condividono una caratteristica decisiva: gli aggressori non hanno dovuto convincere le vittime a fidarsi di un soggetto sconosciuto, perché hanno sfruttato relazioni di fiducia già esistenti.

Qubole, le credenziali del fornitore aprono gli account AWS dei clienti

La prima operazione riguarda Qubole, piattaforma di elaborazione e analisi dei dati appartenente al gruppo Idera, utilizzata da organizzazioni che gestiscono infrastrutture cloud. L’indagine di Wiz Research, condotta con il contributo di Sentra e Mandiant, identifica attività sospette tra il 14 e il 26 ottobre 2026, quando un aggressore ha utilizzato credenziali appartenenti a un account AWS associato al servizio Qubole per ottenere accesso agli ambienti dei clienti. Il funzionamento dell’integrazione spiega la gravità dell’incidente. Per permettere a Qubole di operare sulle proprie risorse, un’organizzazione crea un ruolo AWS Identity and Access Management (IAM) e configura una relazione di fiducia con l’account del fornitore. Il ruolo autorizza l’utilizzo della funzione STS AssumeRole, che genera credenziali temporanee per eseguire le operazioni consentite. In questo caso, l’account Qubole identificato dagli investigatori è 805246085872.

L’attaccante non ha avuto bisogno di violare direttamente le credenziali amministrative di ogni cliente. Una volta ottenuta la possibilità di utilizzare l’identità del fornitore, ha potuto richiedere l’assunzione dei ruoli che continuavano ad autorizzarla. Wiz sottolinea che molti ruoli coinvolti non erano utilizzati normalmente dai rispettivi clienti, ma rimanevano attivi e conservavano le autorizzazioni originarie. La compromissione è stata quindi amplificata da relazioni di fiducia obsolete che nessuno aveva revocato.

External ID non è una password e non protegge una credenziale già compromessa

Ogni richiesta di accesso osservata dagli investigatori conteneva un External ID valido. Questo parametro viene normalmente utilizzato per ridurre il rischio che una relazione tra un cliente AWS e un fornitore venga sfruttata in modo improprio, ma non costituisce una credenziale segreta né sostituisce i controlli sull’identità che richiede l’accesso. Nel caso Qubole, tutte le richieste riconducibili all’attaccante sono state accettate perché provenivano da un’identità autorizzata e presentavano il parametro previsto dalla configurazione. Il punto debole non era quindi una vulnerabilità del servizio AssumeRole, ma l’utilizzo criminale di credenziali valide all’interno di un modello autorizzativo configurato per fidarsi del fornitore.

Una volta raggiunti gli account delle vittime, l’aggressore ha condotto attività di ricognizione e raccolta delle informazioni. Attraverso le autorizzazioni disponibili, ha letto variabili d’ambiente delle funzioni Lambda, segreti conservati in Secrets Manager e parametri archiviati nel Systems Manager Parameter Store. Il materiale comprendeva credenziali AWS, segreti applicativi di Microsoft Entra ID e informazioni di autenticazione Okta. Per verificarne la validità, l’attaccante ha impiegato TruffleHog, strumento normalmente utilizzato dagli specialisti di sicurezza per individuare credenziali esposte. L’operazione ha interessato anche Amazon S3. Secondo Wiz, gli aggressori non cercavano soltanto documenti selezionati, ma esploravano i bucket accessibili attraverso i ruoli compromessi, arrivando in alcuni casi a scaricarne l’intero contenuto. Il numero complessivo delle organizzazioni colpite e il volume esatto delle informazioni sottratte non sono stati resi pubblici.

CloudTrail identifica gli accessi anomali, ma non sempre permette di ricostruire il furto

L’analisi evidenzia alcuni indicatori utili alle organizzazioni che hanno collegato Qubole ai propri account AWS. Wiz raccomanda di controllare i log CloudTrail dal 1° ottobre 2026, cercando richieste AssumeRole provenienti dall’account 805246085872 e da indirizzi IP esterni alle normali infrastrutture AWS utilizzate dal servizio. Fra gli indicatori segnalati figurano gli identificativi IAM AIDA3W7DIFLYOLTK63SFS e AIDAJYRRH5Y3A7AAJM2HW, sessioni con prefisso quiam- e connessioni da indirizzi associati a infrastrutture OVH e al servizio VPN Mullvad. La presenza di un indirizzo VPN, da sola, non dimostra una compromissione, ma la sua correlazione con l’identità Qubole e le operazioni svolte permette di individuare sessioni meritevoli di approfondimento.

Un limite significativo riguarda la visibilità sugli oggetti S3. CloudTrail registra gli eventi amministrativi e l’assunzione dei ruoli, ma non documenta automaticamente ogni lettura dei singoli file. Per ricostruire i dati effettivamente consultati servono gli S3 data events o altri log di accesso specifici. Alcuni clienti esaminati non avevano abilitato queste registrazioni, impedendo agli investigatori di determinare precisamente quali informazioni fossero state prelevate. Il problema delle credenziali cloud eccessivamente privilegiate era già emerso nell’analisi degli attacchi JADEPUFFER contro le identità applicative di Azure. Le tecniche e gli obiettivi sono differenti, ma la criticità comune riguarda la possibilità di utilizzare identità formalmente autorizzate per eseguire operazioni ostili. Wiz segnala inoltre attività sospette precedenti, tra l’8 e l’11 ottobre, nelle quali sarebbero state utilizzate chiavi AWS appartenenti direttamente ai clienti e presumibilmente destinate a integrazioni Qubole. Non è stato dimostrato un collegamento tra quelle intrusioni e la successiva campagna AssumeRole, così come rimane sconosciuto il metodo con cui l’attaccante ha ottenuto inizialmente le credenziali del fornitore.

Ethersphere, bee-js e Swarm Desktop distribuiscono malware attraverso release ufficiali

Il secondo incidente riguarda Ethersphere, progetto collegato alla rete decentralizzata Swarm, e coinvolge due componenti software: la libreria JavaScript @ethersphere/bee-js e l’applicazione Swarm Desktop. La ricerca originale pubblicata da Socket documenta la distribuzione di bee-js 13.3.0 attraverso npm e di Swarm Desktop 0.56.2 attraverso GitHub, entrambe contenenti codice malevolo. Il primo pacchetto è rimasto disponibile nel registry npm per circa 75 minuti, mentre la release compromessa dell’applicazione desktop è rimasta pubblica per circa otto ore e mezza. L’aspetto più grave è la modalità con cui gli aggressori hanno introdotto il codice: non hanno creato semplicemente un pacchetto fasullo che imitava Ethersphere, ma hanno utilizzato i processi autentici di rilascio del progetto. Socket ha individuato attività riconducibili alla compromissione di due identità GitHub, nugaon e bee-worker, utilizzate per modificare il codice e avviare i workflow di pubblicazione. Il 6 novembre erano già stati osservati tentativi di sottrarre segreti dalle pipeline CI/CD, senza evidenze sufficienti di esfiltrazione riuscita. Il 9 novembre, invece, gli aggressori hanno ottenuto la distribuzione effettiva dei componenti contaminati.

Nel pacchetto bee-js 13.3.0, il file scripts/generate-version.cjs è stato modificato per recuperare codice JavaScript da un server controllato dall’attaccante. Il comando è stato collegato a un hook postinstall, facendo eseguire il loader durante l’installazione della dipendenza. L’esecuzione avveniva anche nella pipeline ufficiale di pubblicazione, dove il codice ha potuto operare all’interno dell’ambiente GitHub Actions. Il precedente delle cinque release ufficiali di OVHcloud CLI compromesse su GitHub aveva già dimostrato come un account autorizzato possa trasformare i canali di distribuzione di un’azienda in una fonte di software malevolo.

Firme autentiche e attestazioni SLSA non impediscono la distribuzione del malware

Il caso Ethersphere introduce un elemento particolarmente significativo: il pacchetto bee-js disponeva di un’attestazione di provenienza autentica, prodotta attraverso il sistema di trusted publishing. Socket ha verificato la validità della catena crittografica, delle attestazioni e dei riferimenti al workflow GitHub. La firma non era stata falsificata: il problema era che il processo legittimo stava pubblicando codice modificato dall’attaccante. Una dinamica analoga ha interessato Swarm Desktop. Gli installer della versione 0.56.2 sono stati generati dalla pipeline ufficiale e il pacchetto macOS risultava firmato con il certificato Developer ID del progetto e notarizzato da Apple. Questo rendeva il software apparentemente attendibile per i controlli ordinari della piattaforma.

La compromissione ha raggiunto anche il sistema di aggiornamento automatico dell’applicazione. Le versioni macOS per Apple Silicon e Windows x64 potevano essere proposte ai client attraverso il normale servizio di update, senza che gli utenti dovessero scaricare manualmente un eseguibile da un sito sconosciuto. Il caso conferma il limite delle attestazioni di provenienza: dimostrare che un pacchetto proviene da una determinata pipeline non significa dimostrare che il codice presente nella pipeline sia sicuro. Proprio questa distinzione è al centro delle nuove regole di GitHub e npm sul trusted publishing, progettate per ridurre il rischio che un’automazione compromessa possa pubblicare software senza ulteriori controlli.

SleepyDuck ritorna attraverso Ethereum e colpisce gli sviluppatori Swarm

Il payload distribuito nelle release Ethersphere non si limitava a eseguire codice remoto. Secondo Socket, gli stadi successivi cercavano informazioni relative ai nodi Swarm, comprendenti config.yaml e il file swarm.key. Il primo può contenere in chiaro la password necessaria a decifrare il secondo, esponendo così il wallet Ethereum utilizzato dal nodo. L’infrastruttura malevola riutilizzava inoltre uno smart contract Ethereum per recuperare gli indirizzi dei server di comando e controllo. Questo meccanismo introduce un collegamento tecnico con SleepyDuck ed EtherDuck, malware già individuati in campagne contro sviluppatori Solidity attraverso estensioni pubblicate su Open VSX.

La continuità è sostenuta dal riutilizzo dello stesso contratto, degli stessi indirizzi operativi e di componenti riconducibili alla precedente infrastruttura. SleepyDuck era già stato documentato nell’analisi sulle estensioni malevole per sviluppatori Solidity. La novità è il passaggio da estensioni fraudolente a software distribuito direttamente attraverso un progetto autentico. Gli impianti individuati comprendono backdoor sviluppate in Go per macOS e Linux e componenti di accesso remoto basati su ScreenConnect per Windows. La rete Ethereum viene utilizzata come archivio di configurazione per gli indirizzi C2: modificando il contenuto dello smart contract, l’operatore può cambiare infrastruttura senza dover necessariamente distribuire nuovi eseguibili. Il numero effettivo di sistemi compromessi non è stato stabilito. Socket segnala download delle release malevole, ma precisa che tali conteggi comprendono anche ricercatori e sistemi automatici, e non possono essere interpretati come un numero certificato di vittime.

La difesa passa dalla revoca dei ruoli AWS alla verifica delle versioni software

I due incidenti richiedono contromisure differenti. Per Qubole, le organizzazioni devono verificare la presenza di ruoli IAM ancora autorizzati ad accettare richieste dall’account del fornitore, controllare gli eventi AssumeRole e riesaminare tutti i segreti accessibili attraverso le sessioni sospette. La sola rotazione delle credenziali non revoca automaticamente le sessioni temporanee già emesse: occorre invalidare gli accessi attivi e rimuovere le relazioni di fiducia non più necessarie. Le policy dovrebbero inoltre limitare il perimetro delle risorse accessibili e, quando supportato, vincolare l’origine delle richieste ai sistemi e agli indirizzi documentati dal fornitore.

Per Ethersphere, è necessario individuare eventuali installazioni di @ethersphere/bee-js 13.3.0, controllare lockfile, cache e registry interni e sostituire la versione contaminata con una release pulita. Gli utenti di Swarm Desktop 0.56.2 devono verificare l’installazione effettiva della versione malevola e passare alla successiva versione correttiva 0.56.3, esaminando anche le credenziali, le chiavi e gli ambienti accessibili al processo compromesso. La rimozione della release da GitHub o npm non elimina automaticamente il codice già eseguito sui dispositivi. Il problema era già stato evidenziato nell’analisi dei pacchetti npm capaci di utilizzare Ethereum come infrastruttura di comando e controllo: bloccare un singolo percorso di distribuzione non è sufficiente quando gli aggressori possono spostare il payload tra installazione, runtime e aggiornamenti software.

Qubole ed Ethersphere mostrano due modalità differenti di abuso della fiducia digitale. Nel primo caso un account di servizio autorizzato diventa il ponte verso gli ambienti cloud dei clienti; nel secondo una pipeline ufficiale trasforma codice malevolo in software apparentemente legittimo. In entrambi gli scenari, la capacità di difesa dipende dalla possibilità di verificare continuamente identità, autorizzazioni, codice e comportamenti effettivi, anche quando appartengono a sistemi già considerati attendibili.