846 pacchetti npm dannosi: perché la campagna Flooding Dropper è pericolosa per i team di scraping

```html

Il 5 agosto 2026, i ricercatori di Sonatype hanno registrato in npm una campagna chiamata Flooding Dropper: 846 componenti dannosi pubblicati da decine di account usa e getta. Dopo una settimana, il numero è aumentato: nei dati aggiornati di OpenSourceMalware, che monitora la stessa campagna con il nome WEL1DROPPER, figurano già 1033 pacchetti confermati. All'interno c'è un loader multipiattaforma che scarica la seconda fase su Windows, macOS e Linux e cancella dal computer dello sviluppatore tutto ciò che riesce a raggiungere: variabili d'ambiente, credenziali, sessioni.

Per i team che vivono di parsing e automazione, non è "un'altra notizia su npm". Lo stack di scraping è proprio npm: Playwright, Puppeteer, Crawlee, wrapper per agenti proxy, parser HTML, code. E sulla stessa macchina dove tutto questo viene installato da un solo team, di solito c'è un .env con login e password per il pool di proxy, un cookie-jar per le sessioni e profili di browser anti-detect. Analizziamo cosa è successo esattamente e quali sono le implicazioni pratiche.

Cosa si sa della campagna

Sonatype sta conducendo una campagna con l'identificativo sonatype-2026-005660 con una valutazione CVSS di 8.7 e classificazione CWE-506 (codice dannoso incorporato). I segni distintivi che hanno portato i ricercatori a raggruppare i pacchetti sono:

• Generazione automatica dei nomi. I nomi vengono creati tramite l'interpolazione di termini ripetitivi: nel rapporto figurano "bigops" e "bnpl", esempi come bigops-api e lunghe concatenazioni come dolyame-boxy-desktop-bnpl-card-gallery. OpenSourceMalware descrive questo come "AI slop squatting" — massiccio type-squatting con nomi generati casualmente invece di una falsificazione accurata di un pacchetto popolare.
• Versioni di un unico intervallo. Le release si raggruppano attorno a 35.x.y — numeri anomali per pacchetti senza storia.
• Distribuzione su più account. Ogni account pubblica un piccolo lotto di pacchetti, quindi il blocco di un editore non compromette l'operazione.

La meccanica di attivazione è descritta in modi diversi, e questa differenza è importante. Sonatype scrive che il codice si attiva "alla installazione o all'importazione" del pacchetto. OpenSourceMalware specifica: alcuni campioni si avvalgono di metodi che non utilizzano i classici lifecycle hooks e richiedono che lo sviluppatore colleghi manualmente il pacchetto tramite require(). La conclusione pratica è una: fare affidamento solo su --ignore-scripts non vi salverà — se la dipendenza viene realmente importata nel codice, il payload verrà eseguito.

Come viene consegnata la seconda fase

Il loader scarica il payload tramite HTTPS da un host casuale di una lista incorporata — secondo The Hacker News, i punti di consegna erano tre domini su Cloudflare Workers. Se il download diretto fallisce, si attiva un canale di riserva: il payload viene assemblato da record DNS TXT del dominio wel1.ru con sottodomini di piattaforma (sdk.dl, ext.dl, pkg.dl, net.dl). Ciò significa che il filtro in uscita per i domini HTTP viene aggirato da normali richieste DNS — e queste nella rete aziendale vengono bloccate da pochi.

Successivamente, per le piattaforme:

• Windows: patching di ETW e AMSI (cioè silenziamento della telemetria e controllo antivirus degli script), persistenza tramite chiavi di avvio automatico nel registro e attività pianificate, file in AppData.
• macOS: gli stessi metodi di evasione, persistenza tramite LaunchAgent. Nel payload per macOS, i ricercatori hanno trovato domini di servizi finanziari russi (tcsbank.ru, cloudpayments.ru) — segno di un interesse mirato alle sessioni bancarie degli utenti di lingua russa.
• Linux: un binario ELF UPX impacchettato, che distribuisce un agente del framework Sliver — questo è già un canale C2 completo, non una semplice sottrazione.

In aggiunta, un set standard: verifica della sandbox e del debugger, identificazione dell'architettura, lettura delle variabili d'ambiente, processi in background disconnessi (sopravvivono alla chiusura del terminale) e riflessione del payload in memoria, per non lasciare file sul disco.

Perché colpisce proprio i team di parsing

L'infostiler non distingue tra "importante" e "non importante" — raccoglie tutto ciò che sembra un segreto. Per un utente normale, si tratta di password del browser e portafogli crittografici. Per una persona che si occupa di raccolta dati, il bottino è diverso e, a dire il vero, più appetitoso:

• Variabili d'ambiente e .env — qui ci sono quasi sempre l'host del proxy, login, password e parametri di sessione (paese, città, identificatore sticky). L'exfiltrazione delle variabili d'ambiente è esplicitamente menzionata nell'analisi della campagna.
• Cookie e token di sessione. Una sessione rubata è un bypass dell'MFA: il cookie è di per sé una prova che la seconda verifica è già stata superata. I log con token validi per servizi di lavoro vengono venduti su mercati oscuri a partire da $5.
• Profili di browser anti-detect — una combinazione di "cookie + impronta + proxy", quindi un account di lavoro pronto all'uso, che non deve essere riscaldato.
• Token CI/CD, npm e cloud — accesso non solo alla vostra macchina, ma anche al pipeline, da cui è possibile inviare già le vostre build.

La scala del fenomeno ha smesso di essere di nicchia. SpyCloud nel rapporto del 2026 ha contato 18,1 milioni di chiavi API e token esposti, ottenuti proprio dai log di malware. Secondo Recorded Future e Flashpoint, nel 2025 gli infostiler hanno infettato 11,1 milioni di macchine e hanno fornito 3,3 miliardi di account rubati. E nel rapporto di Sonatype sulla situazione della supply chain software per il 2026 figurano oltre 454.600 nuovi pacchetti dannosi in un solo anno 2025 e accumulativamente oltre 1,233 milioni bloccati — un aumento del 75% anno su anno. Flooding Dropper non è un'anomalia, ma un episodio ordinario del flusso.

Cosa perde il proprietario dell'account proxy

Voglio sottolineare separatamente ciò che nelle analisi di sicurezza di solito non viene scritto, perché gli autori non lavorano con i proxy. Le credenziali proxy trapelate non sono una "perdita di password", ma tre problemi contemporaneamente:

1. Traffico pagato. Il traffico residenziale e mobile viene tariffato per gigabyte. Un parser estraneo sui vostri crediti significa il vostro conto, e ci si può accorgere di esso molto tempo dopo rispetto a quanto si vorrebbe.
2. Reputazione altrui sui vostri IP. L'attaccante ha bisogno di un'uscita "pulita" residenziale affinché la sua attività appaia come quella di un normale utente domestico. I vostri siti target vedranno comportamenti sospetti nella vostra stessa sessione — e arriveranno ban sugli account che avete riscaldato per anni.
3. Chiarimenti con il provider. Dal punto di vista di qualsiasi provider normale, il traffico proveniva dal vostro account, e dovrete spiegarvi.

Cosa fare: minimo pratico

1. Separare gli ambienti. Lo stack di scraping deve essere installato in un container o in una VM separata — non sulla macchina dove si trovano i cookie personali, la mail di lavoro e i token di produzione. Questa è l'unica misura che funziona anche contro un pacchetto di cui ancora nessuno sa.
2. Rimuovere le credenziali proxy dal .env vicino al codice. I segreti devono andare nel gestore dei segreti o nelle variabili d'ambiente del runner, e non in un file nella radice del progetto che può essere letto da qualsiasi modulo importato.
3. Abilitare l'autenticazione per IP dove possibile. Legare l'accesso al vostro server svaluta la coppia rubata di login/password: da un indirizzo estraneo non funzionerà semplicemente. Come funziona e in quali scenari è adatto, è stato trattato nel materiale su whitelist di indirizzi IP per proxy. Le regole generali per la conservazione degli accessi sono nel guida su conservazione sicura delle credenziali proxy.
4. Credenziali separate per ogni progetto e limiti di traffico. Se per ogni script viene creato un accesso con un tetto di gigabyte, la perdita di uno non svuota tutto il saldo e si localizza in pochi minuti.
5. Monitorare i consumi. Un'improvvisa impennata del consumo di GB senza un aumento delle attività è il rilevatore di compromissione più precoce e più economico che avete.
6. Disciplina delle dipendenze. npm ci secondo il lock-file invece di un libero install, quarantena per nuove versioni (7–14 giorni), controllo dell'età del pacchetto e della storia dell'editore, mirror interno con allowlist. Un pacchetto con versione 35.x.y, zero storia e nome composto da parole concatenate è un motivo per fermarsi, non per installare.

Se sospettate di essere già stati compromessi

Le raccomandazioni di Sonatype qui sono estremamente specifiche e l'ordine in esse è fondamentale: considerare l'host completamente compromesso; cercare i meccanismi di persistenza descritti (chiavi di avvio automatico e attività pianificate in Windows, LaunchAgent in macOS); ruotare le credenziali — npm, GitHub, cloud, CI/CD — dopo aver ripulito la macchina, e non prima, altrimenti i nuovi segreti seguiranno lo stesso percorso; controllare i lock-file, le cache delle dipendenze e i mirror interni per eventuali copie salvate; prima di reinstallare, confrontare i nomi dei pacchetti carattere per carattere.

A questo elenco aggiungete il vostro: cambio delle password di accesso proxy, revoca delle sessioni attive nel browser anti-detect e controllo della storia del consumo di traffico nelle ultime due settimane. Se il traffico viene acquistato per gigabyte — proxy residenziali o proxy mobili — il report sui consumi è il vostro registro di accesso.

Conclusione

Flooding Dropper è interessante non per la sua sofisticazione, ma per l'economia: mille pacchetti usa e getta, nomi generati, account in blocco — è una catena di montaggio progettata affinché qualcuno installi una dipendenza senza guardare. Alcune campagne impiegheranno settimane per ripulire il registro, ma il flusso non si fermerà: i numeri di Sonatype dell'anno scorso non lasciano illusioni.

La conclusione pratica per chi raccoglie dati è semplice. La macchina dello sviluppatore è il punto in cui convergono tutti i vostri accessi: proxy, account, sessioni, pipeline. Isolate lo stack, legate gli accessi all'IP, distribuite le credenziali tra i progetti e monitorate il grafico del consumo di traffico. Nessuno di questi passi richiede di aspettare che una nuova campagna venga indicizzata.