TL; DR
Tra il 1° maggio e il 6 maggio 2026, un singolo editore npm, alone5511, ha spinto otto pacchetti senza dipendenze che sembrano mirare Microsoft Spazi dei nomi dei pacchetti interni in stile Azure.
I pacchetti utilizzati hanno nomi come cosmos-explorer, ms.analytics-web, icons.generated, latency-tracking-internal, carbonite-internale carboniteappDiverse versioni hanno utilizzato valori semver elevati come 99.9.0 and 99.9.13, che è una tattica comune di confusione delle dipendenze progettata per superare in priorità i pacchetti interni privati.
Tutti e otto i pacchetti correlati erano già stati rimossi da npm dall'editore tra il 1° e il 6 maggio 2026. I metadati del registro diretto hanno confermato che i file tarball ora restituiscono un errore HTTP 404 dalla CDN di npm.
Tuttavia, il cluster rimane importante.
Il carico utile nei campioni canonici, carbonite-internal:99.9.0 and carboniteapp:99.9.0, viene eseguito al momento dell'installazione tramite un preinstall hook. Raccoglie i dati dell'impronta digitale dell'host, recupera l'IP pubblico della macchina da api.ipify.org, crea un falso “RAPPORTO DI INTELLIGENCE DI LIVELLO PROFESSIONALE”, contrassegna l’ospite come RCE VERIFIEDe invia il report a un bot di Telegram tramite l'API di Telegram Bot.
Malware Early Warning (MEW) di Xygeni Il sistema ha classificato i campioni canonici come probabilmente dannosi con un punteggio superiore a 91/100.
Stiamo monitorando questa attività come una campagna interna di Microsoft volta a creare confusione nelle dipendenze dei nomi, tramite l'identificazione dell'host in fase di installazione e l'esfiltrazione dei beacon di Telegram.
Il Cluster: otto pacchetti, un unico editore.
L'account dell'editore alone5511 è stato utilizzato il seguente indirizzo email:
raistargaming703@gmail.com
L'account non aveva email verificata, no SCM verifica e un punteggio di reputazione npm pari a 2.
Un'identità GitHub di riferimento, alonebeast002/beastcrypt, è apparso anche nel contesto del cluster.
L'editore ha rilasciato otto pacchetti correlati nell'arco di sei giorni. Tutti i pacchetti non avevano dipendenze e seguivano lo stesso schema generale: pacchetto di piccole dimensioni, script di installazione, identificazione dell'host e beaconing di Telegram.
| # | CONFEZIONE | Versione Maligna | Creato, UTC | Inedito, UTC | Carico utile confermato | Installa Hook |
|---|---|---|---|---|---|---|
| 1 | esploratore del cosmo | 1.1.3 | 2026-05-01T18:26Z | 2026-05-01T19:01Z | Dedotto, stesso editore/cluster | preinstallazione, presunta |
| 2 | signalsdk-web | 1.0.0, 10.0.0 | 2026-05-04T13:57Z | 2026-05-04T18:51Z | inferito | preinstallazione, presunta |
| 3 | ms.analytics-web | 99.0.0, 99.9.13 | 2026-05-04T18:47Z | 2026-05-05T10:07Z | inferito | preinstallazione, presunta |
| 4 | icone.generate | 99.9.13 | 2026-05-05T10:02Z | 2026-05-05T12:57Z | inferito | preinstallazione, presunta |
| 5 | tracciamento della latenza | 99.9.0 | 2026-05-05T11:57Z | 2026-05-05T12:57Z | inferito | preinstallazione, presunta |
| 6 | tracciamento della latenza interna | Versioni rimosse dal record di registro | 2026-05-06T06:02Z | 2026-05-06T08:35Z | inferito | preinstallazione, presunta |
| 7 | carboniteapp | 99.9.0 | 2026-05-06T05:49Z | 2026-05-06T08:35Z | Sì, flusso di codice completo dello scanner | preinstallazione: node index.js |
| 8 | carbonite-interno | 99.9.0 | 2026-05-06T06:14Z | 2026-05-06T08:36Z | Sì, flusso di codice completo dello scanner | preinstallazione: node index.js |
Numero totale di tuple di versioni dannose nell'intero cluster: 9+.
Alcuni record di pacchetti correlati hanno subito la rimozione di versioni dopo la loro depubblicazione, il che limita la ricostruzione esatta basata esclusivamente sui dati del registro pubblico.
Perché i nomi sono importanti
I nomi dei pacchetti sono l'indizio più forte.
Sembrano pacchetti interni per SDK, telemetria, generazione di icone, esplorazione o monitoraggio della latenza:
cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteapp
Non si tratta di una denominazione casuale. Sembra calibrata per confusione di dipendenza.
Diversi pacchetti successivi hanno utilizzato numeri di versione elevati:
99.0.0
99.9.0
99.9.13
10.0.0
Questo è importante perché gli attacchi basati sulla confusione delle dipendenze spesso si fondano sul fatto che i pacchetti pubblici abbiano versioni più elevate rispetto ai pacchetti interni registrati in registri privati. Se un sistema di compilazione è configurato in modo errato, il gestore dei pacchetti potrebbe scegliere la versione pubblica di npm anziché quella interna prevista.
Anche l'editore sembra intensificare le sue azioni nel tempo.
I primi pacchetti utilizzavano versioni dall'aspetto normale, come 1.1.3 and 1.0.0. I pacchetti successivi sono stati spostati in 99.x.x and 99.9.xTale cambiamento è coerente con l'ipotesi che un attore stia ottimizzando la campagna in base al comportamento interno di risoluzione dei pacchetti.
Cosa succede al momento dell'installazione?
I campioni canonici, carbonite-internal:99.9.0 and carboniteapp:99.9.0, dichiarare un preinstall gancio:
{
"scripts": {
"preinstall": "node index.js"
}
}
Ciò significa che il payload viene eseguito prima che npm abbia terminato l'installazione delle dipendenze.
Questo è il punto di partenza più precoce possibile in fase di installazione. Lo sviluppatore non ha bisogno di importare il pacchetto. La compilazione non ha bisogno di eseguire il codice dell'applicazione. L'installazione stessa è sufficiente.
Il carico utile è di piccole dimensioni, circa 2.4 KB, e non ha altra funzione se non quella di inviare un segnale.
Comportamento del carico utile
Migliori index.js Il file esegue quattro azioni principali.
Per prima cosa chiama api.ipify.org per recuperare l'indirizzo IP pubblico dell'host:
https://api.ipify.org
In secondo luogo, raccoglie dati di base per l'identificazione dell'host utilizzando le API del sistema operativo Node.js:
os.userInfo()
os.hostname()
os.platform()
os.networkInterfaces()
os.uptime()
In terzo luogo, formatta i dati raccolti in un report multilinea con un banner ben visibile:
PRO-LEVEL INTELLIGENCE REPORT
Il rapporto si conclude con:
Status: 🟢 RCE VERIFIED
In quarto luogo, invia il rapporto a Telegram tramite un sendTelegram(report) funzione, utilizzando l'endpoint API del bot di Telegram:
https://api.telegram.org/bot<token>/sendMessage
Il token esatto del bot Telegram è conservato all'interno degli archivi tar non pubblicati e dovrebbe essere recuperabile dalla memoria interna di npm.
Perché il banner “RCE VERIFIED” è importante
Il letterale RCE VERIFIED L'indicatore è operativamente significativo.
Il payload non installa una backdoor. Non è persistente. Non ruba direttamente le credenziali cloud. Piuttosto, conferma che l'esecuzione del codice è avvenuta durante l'installazione del pacchetto.
Questo è sufficiente per una campagna di prova di esecuzione basata sulla confusione delle dipendenze.
Se l'attaccante riceve un messaggio Telegram da un ambiente target, sa che il pacchetto npm pubblico è stato risolto ed eseguito all'interno di un host reale, un runner CI, una workstation di sviluppo o un ambiente di build.
In altre parole, il malware non si limita a raccogliere metadati dell'host. Verifica se la risoluzione dei pacchetti del target è sfruttabile.
Classificazione Xygeni MEW
Xygeni MEW ha classificato i campioni canonici come probabilmente malevolo, con un punteggio superiore a 91/100.
I rilevamenti includevano:
| Gravità | Tipo di rilevamento | Significato |
|---|---|---|
| critico | esfiltrazione di dati sensibili | req.write(data) trasporta il report dell'impronta digitale dell'host in una richiesta POST di Telegram in uscita |
| Alto | script di installazione dannosi | preinstallazione: node index.js attiva il beacon al momento dell'installazione |
| Basso | richiesta_sospetta | Rilevamento di indirizzi IP pubblici tramite api.ipify.org |
| Basso | richiesta_sospetta | Endpoint in uscita dell'API del bot di Telegram |
| Basso | pacchetto banale | Il pacchetto non ha alcuno scopo significativo oltre a quello di segnalare |
| Info | enumerazione dei dati sensibili | Vengono elencati i dettagli dell'host, come il tempo di attività, le informazioni sull'utente e il nome host. |
Entrambi i progetti editoriali di carbonite-internal:99.9.0 and carboniteapp:99.9.0 avevano payload identici, incluso lo stesso ID del flusso di codice e gli stessi script di installazione equivalenti in byte.
L'indice MEW publisher-projects ha contrassegnato tutti e otto i pacchetti come parte dello stesso cluster publisher/payload.
Perché il modello di auto-cancellazione è importante
Tutti e otto i pacchetti relativi ai fratelli sono stati ritirati dalla casa editrice nel giro di pochi minuti o ore dalla pubblicazione.
Quel comportamento è importante.
I manutentori legittimi a volte rimuovono i pacchetti dalla loro pubblicazione, ma in questo caso la tempistica sembra indicare un'operazione di pulizia da parte di un aggressore. I pacchetti sono apparsi, hanno eseguito il loro payload in fase di installazione se risolto da un sistema di destinazione, e poi sono scomparsi dall'accesso pubblico al registro.
Ciò crea due problemi per i difensori.
Innanzitutto, i metadati pubblici di npm diventano incompleti dopo la rimozione della pubblicazione. Alcuni record di versione potrebbero essere stati eliminati o risultare più difficili da ricostruire.
In secondo luogo, i sistemi di difesa che si basano sullo stato attuale del registro di sistema potrebbero non rilevare pacchetti presenti durante il periodo di vulnerabilità ma non più installabili.
Per questo motivo, npm dovrebbe conservare internamente i file tar non pubblicati a scopo di analisi forense. Il bot di Telegram I token presenti all'interno degli archivi tar potrebbero aiutare a enumerare il canale di ricezione e a ricostruire le possibili vittime.
Indicatori di compromissione e rilevamento
Editore e account
| Settore | Valore |
|---|---|
| nome utente npm | alone5511 |
| e-mail dell'editore npm | raistargaming703@gmail.com |
| reputazione npm | 2 |
| email verificata | Nodo |
| SCM verificato | Nodo |
| Identità GitHub di riferimento | alonebeast002/beastcrypt |
Nomi dei pacchetti interessati
cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteapp
Modelli di versione sospetti
10.0.0
99.0.0
99.9.0
99.9.13
Queste versioni di alto livello sono particolarmente rilevanti nelle indagini sulla confusione delle dipendenze perché possono avere una priorità maggiore rispetto alle versioni private dei pacchetti.
Endpoint di rete
| Tipo | Valore |
|---|---|
| Indagine sulla proprietà intellettuale pubblica | https://api.ipify.org |
| Lavabo di decantazione | https://api.telegram.org/bot<token>/sendMessage |
| Metodo di esfiltrazione | POST dell'API del bot di Telegram |
Marcatori di carico utile
Cerca queste stringhe negli script di installazione:
PRO-LEVEL INTELLIGENCE REPORT
Status: 🟢 RCE VERIFIED
sendTelegram(
Segnala anche questo schema di manifestazione:
{
"scripts": {
"preinstall": "node index.js"
}
}
Soprattutto se abbinato a:
- Zero dipendenze
- Dimensioni della confezione ridotte
- nome del pacchetto dall'aspetto interno
- Versione ad alta semantica
- API di fingerprinting dell'host
- Traffico API del bot di Telegram
API di identificazione dell'host
Il payload canonico utilizza:
os.userInfo()
os.hostname()
os.platform()
os.networkInterfaces()
os.uptime()
Si rivolge inoltre a:
https://api.ipify.org
per acquisire l'indirizzo IP pubblico dell'host.
Note di rilevamento
Diverse regole possono intercettare questa campagna e chiudere le varianti.
Innanzitutto, monitora gli script npm install che contattano Telegram:
api.telegram.org
Uno script di installazione di un pacchetto non dovrebbe quasi mai inviare richieste POST a Telegram. Consideratelo un attacco, a meno che non vi sia un'eccezione chiara e ben documentata.
Secondo, bandiera preinstall script in piccoli pacchetti senza dipendenze con nomi che sembrano interni.
La combinazione di un pacchetto di piccole dimensioni, una versione semver elevata e un nome in stile namespace interno è un forte segnale di confusione nelle dipendenze.
In terzo luogo, segnalate i nomi dei pacchetti che sembrano moduli di ingegneria privati pubblicati da account npm pubblici con scarsa reputazione.
Tra gli esempi appartenenti a questo gruppo si annoverano:
ms.analytics-web
latency-tracking-internal
carbonite-internal
icons.generated
In quarto luogo, cercate i riferimenti ai file di blocco relativi agli otto nomi di pacchetto nei sistemi CI e nelle workstation degli sviluppatori.
Ricerca:
package-lock.json
yarn.lock
pnpm-lock.yaml
npm-shrinkwrap.json
Qualsiasi corrispondenza dovrebbe attivare una revisione della confusione di dipendenza.
Azioni di registro suggerite
Questo cluster non era già stato pubblicato al momento della stesura del rapporto. Tuttavia, la rimozione dalla pubblicazione non elimina il rischio.
Azioni consigliate lato npm:
- Confermare se le rimozioni dalla pubblicazione siano state effettuate da un utente malintenzionato per ripulire il sistema, piuttosto che per una legittima azione del responsabile della manutenzione.
- Sospendere o bannare l'account dell'editore
alone5511. - Aggiungi l'editore, l'indirizzo email, i nomi dei pacchetti e i marcatori del payload alle liste di blocco per abusi e problemi della catena di fornitura.
- Conservare i file tar non pubblicati in un archivio interno per le analisi forensi.
- Estrai il token del bot Telegram dai file tar archiviati.
- Collaborare con Telegram, ove possibile, per identificare il canale di ricezione e ricostruire i dati telemetrici di potenziali vittime.
Lista di controllo per la risposta al compromesso
Se uno qualsiasi dei pacchetti interessati è comparso nei file di blocco, nei log di compilazione, nella cache dei pacchetti o nella cronologia di installazione CI durante il periodo di esposizione, consideralo come un evento di esecuzione dovuto a confusione di dipendenze.
Risposta consigliata:
- Identifica la posizione in cui è stato installato il pacchetto: workstation locale, runner CI, agente di build o immagine container.
- Conserva i file di blocco, la cache npm, i log di compilazione, la cronologia della shell e l'output del gestore di pacchetti.
- Controllare i registri di rete in uscita per
api.telegram.organdapi.ipify.orgdurante la finestra di installazione. - Verifica se l'installazione è stata eseguita in un ambiente con variabili sensibili, credenziali o accesso alla rete interna.
- Ruota i token esposti all'ambiente di installazione se l'host era un runner CI con privilegi o una workstation di sviluppo.
- Configurazione della risoluzione del pacchetto di audit per la confusione tra registro pubblico e privato.
- Applicare l'ambito ai pacchetti privati e al blocco del registro di sistema.
- Blocca i pacchetti pubblici non approvati che corrispondono a modelli di denominazione interni.
- Aggiungi guardrails per gli script di installazione, in particolare
preinstall,installepostinstall.
Cosa dovrebbero imparare i difensori
Questa campagna non è tecnicamente complessa. Ed è proprio per questo che è importante.
Il payload è piccolo, diretto e facile da eseguire. L'attaccante non necessita di persistenza o malware avanzati. Gli basta un percorso di risoluzione dei pacchetti configurato in modo errato.
Il rischio reale è la confusione tra le dipendenze.
Un pacchetto con un nome interno familiare, un numero di versione elevato e un preinstall il gancio può girare un normale npm install trasformandolo in un faro dall'interno del tuo ambiente.
Per DevSecOps Per i team, la lezione è chiara: i nomi dei pacchetti interni sono risorse sensibili. Trattateli come una superficie di attacco.
Segnalato a npm per l'applicazione delle restrizioni a livello di account, l'inserimento nella lista nera e la conservazione dei file tar non pubblicati.
