- L'inondazione di npm su larga scala legata alle ricompense in token TEA ha raggiunto oltre 150 pacchetti, evolvendosi dalle precedenti ondate di decine di migliaia.
- I pacchetti di spam utilizzavano script dormienti, nomi strutturati e reti di dipendenze per eludere i comuni scanner.
- La risposta coordinata di Amazon Inspector e OpenSSF ha assegnato i MAL-ID e mappato la campagna.
- Incidente separato: sette pacchetti mascherati da Adspect hanno reindirizzato le vittime a siti a tema crittografico.
In mezzo al crescente controllo delle catene di fornitura open source, il registro npm è stato scosso da due minacce distinte: un'ondata di pacchetti in espansione, guidata da incentivi, legata ai premi dei token TEA e un insieme più piccolo di pacchetti di reindirizzamento mascherati che prendono di mira selettivamente le vittime. Entrambe le campagne si basano su automazione e sottigliezza, dimostrando con quanta rapidità gli opportunisti possano sfruttare l'ecosistema JavaScript più utilizzato al mondo.
Mentre lo sforzo di inondazione si è gonfiato a più di 150,000 pacchi segnalati su più account, i reindirizzatori mascherati si sono affidati a tattiche anti-ricerca per nascondersi in bella vista. Insieme, evidenziano lacune persistenti in governance del registro, igiene delle dipendenzee strategie di rilevamento che si concentrano troppo sui comportamenti tradizionali del malware in fase di installazione.
All'interno del diluvio di pacchetti IndonesianFoods
La campagna, informalmente soprannominata "IndonesianFoods", ha utilizzato uno schema di denominazione strutturato, abbinando nomi propri indonesiani comuni a termini alimentari e varianti numeriche, per coniare migliaia di confezioni dall'aspetto plausibile. Le misurazioni precedenti hanno identificato circa Voci 43,000 legati allo sforzo; rapporti successivi ne citarono più di 100,000 e successive retate scoprirono oltre 150,000 attraverso il registro.
Sebbene molti pacchetti sembrassero legittimi, alcuni addirittura spedivano versioni funzionanti Modelli Next.js—hanno nascosto il codice dormiente (ad esempio, auto.js o publishScript.js). Quando lanciato manualmente, quello script randomizzava le versioni, generava nuovi nomi e pubblicava nuovi pacchetti in loop, con picchi osservati a intervalli di pochi secondi e affermazioni che una singola esecuzione avrebbe potuto spingere Oltre 17,000 pacchi al giorno.
Questa produzione di massa era raramente isolata; le singole voci spesso dichiaravano da otto a dieci dipendenze che puntavano ad altri pacchetti spam, creando un reticolo autoreferenziale. L'effetto netto era una diffusione a catena senza fare affidamento sui tipici ganci post-installazione o comportamenti palesemente dannosi, che hanno tenuto in silenzio molti scanner.
Gli incentivi finanziari sembrano aver alimentato lo sforzo. I ricercatori hanno scoperto tea.yaml File in pacchetti controllati dagli aggressori che fanno riferimento a specifici account e wallet di criptovalute, apparentemente mirati a incrementare i punteggi di impatto TEA e a ottenere ricompense in token. Le analisi indicano un'evoluzione graduale: un'ampia base di spam nel 2023, segnali di monetizzazione TEA nel 2024 e un flusso di lavoro di replica altamente automatizzato nel 2025.
Vale la pena notare che alcune ricerche hanno successivamente chiarito che la replicazione è non completamente autonomo; il payload deve essere attivato. Ciononostante, una volta avviato, il ciclo di pubblicazione e la denominazione basata su pattern amplificano enormemente il volume e il rumore di registro.
Rilevamento, risposta e portata dell'inquinamento del registro
I ricercatori di Amazon Inspector hanno implementato nuove regole abbinate all'intelligenza artificiale a fine ottobre e hanno rapidamente segnalato attività sospette legate a tea.xyz. Nel giro di pochi giorni, il team ha identificato migliaia di voci; a metà novembre, ha coordinato il lavoro con Fondazione per la sicurezza open source ha portato all'assegnazione di MAL-ID a ritmo serrato, spesso entro circa 30 minuti, mappando infine 150k+ pacchetti legato alla campagna.
Altri team di sicurezza hanno osservato effetti a catena su larga scala. I sistemi di dati sono stati messi a dura prova dal volume di avvisi generati e le piattaforme che si basano su feed di vulnerabilità hanno segnalato ondate di nuove voci correlato allo spam. I ricercatori hanno descritto l'evento come di dimensioni senza precedenti, avvertendo che l'elevato livello di automazione e coordinamento tra account rende la risposta e la pulizia più complesse rispetto ai tipici compromessi una tantum.
Anche senza furto di credenziali o backdoor, i rischi sono tangibili: persistenti inquinamento del registro che oscura i pacchetti legittimi, il consumo inutile di infrastrutture e larghezza di banda e un precedente pericoloso che premia il volume rispetto al valore. Questa tattica crea anche spazio per gli autori delle minacce per infiltrarsi successivamente in mezzo al rumore di fondo.
Perché gli scanner non l'hanno rilevato e cosa sta cambiando
La maggior parte degli strumenti di sicurezza enfatizza i segnali d'allarme in fase di installazione, come script post-installazione, beacon di rete o operazioni sospette sui file. In questo caso, i file dormienti non erano referenziati da alcun percorso di codice, quindi gli scanner li trattavano spesso come inerti. Una mancanza di limitazione della velocità, un controllo debole dei metadati e un rilevamento limitato dei modelli per gli artefatti pubblicati in massa hanno permesso che accadessero due cose: i caricamenti ad alto rendimento non venivano controllati e i cluster coordinati rimanevano fuori dal radar.
I ricercatori affermano che l'episodio segna un cambiamento verso la manipolazione a livello di ecosistema guidata da incentivi monetariInvece di compromettere un singolo pacchetto popolare, gli aggressori sono incentivati ad aumentare la propria influenza su molte piccole voci, oscurando i segnali ed erodendo la fiducia. Questo sta spingendo a richiedere policy di registro più severe, analisi comportamentali più complete e un migliore coordinamento della community.
- Bloccare la pubblicazione: limitare la pubblicazione di npm a CI/CD e ai manutentori autorizzati; richiedere controlli di identità più rigorosi per attività su larga scala.
- Migliorare la copertura SCA: segnala file dormienti, schemi ripetuti e reti di dipendenze circolari; preferisci strumenti che evidenziano rischi non correlati all'installazione.
- Limita il raggio di esplosione: aggiungere versioni, gestire SBOM e isolare CI/CD; aggiungere limiti di velocità e CAPTCHA per invii di massa a livello di registro.
- Eseguire un audit continuo: rimuovere i pacchetti di bassa qualità e non funzionali; monitorare nomi anomali, cambi di versione e clustering degli account.
Emergono pacchetti di reindirizzamento mascherati da Adspect
Un incidente npm separato ha coinvolto sette pacchetti pubblicati da un utente noto come dino_rinato tra settembre e novembre 2025. Sei voci trasportavano un payload compatto, di circa 39 kB, che rilevava le impronte digitali dei visitatori e utilizzava un servizio di mascheramento del traffico chiamato Adspect per filtrare i ricercatori, mentre "signals-embed" fungeva da esca.
- segnali-incorporamento (342 download)
- dsidospsodlks (184 download)
- applicationooks21 (340 download)
- applicazione-phskck (199 download)
- integrator-filescrypt2025 (199 download)
- integrator-2829 (276 download)
- integratore-2830 (290 download)
Il codice dannoso viene eseguito immediatamente quando caricato in un ambiente browser tramite un Espressione di funzione immediatamente richiamata (IIFE). Ha raccolto un'impronta digitale del sistema, ha tentato di bloccare gli strumenti degli sviluppatori per ostacolare l'analisi e ha consultato un endpoint proxy per decidere se mostrare un CAPTCHA falso che alla fine reindirizzavano le vittime verso siti web a tema crittografico che impersonavano servizi come StandX. Se il visitatore sembrava un ricercatore, veniva visualizzata una semplice pagina bianca, completa di riferimenti a una falsa entità chiamata Offlido.
Adspect si propone come una piattaforma antifrode basata su cloud con "cloaking a prova di proiettile", offerta tramite piani di abbonamento a più livelli. La sua presenza all'interno di pacchetti di supply chain è insolita e i ricercatori sostengono che l'integrazione della logica di Adspect con i moduli npm abbia creato un controllo autonomo del traffico toolkit: distribuzione tramite un canale di sviluppo, esecuzione nel browser ed esposizione selettiva del payload reale solo alle probabili vittime.
Passaggi pratici per team e registri
Per i team di sviluppo, le mosse immediate più sicure sono quelle di rafforzare i controlli di pubblicazione, preferendo rilevatori che catturano artefatti dormientie selezionare i pacchetti sospetti dagli alberi delle dipendenze. Per gli amministratori del registro, aggiungere limitazioni di invio, migliorare l'analisi dei metadati e integrare il rilevamento delle anomalie per i modelli di denominazione e clustering tra account dovrebbe alzare l'asticella per i potenziali spammer.
In mezzo a incentivi mutevoli e tattiche sempre più industrializzate, i difensori di npm affrontano un diverso tipo di sfida: quando gli aggressori possono guadagnare inondare piuttosto che infettare, il confine tra fastidio e rischio si assottiglia e vigilanza, collaborazione e controlli più intelligenti diventano le uniche risposte sostenibili.
