Non solo codice: come l’attacco alla supply chain ora colpisce sia i router che lo sviluppo .NET

La supply chain non si presenta più con un’unica faccia. A volte entra dal lato “comodo” del lavoro quotidiano, quello delle dipendenze e dei package manager. Altre volte si infila nei dispositivi di rete che nessuno vuole toccare perché “finché funziona, non si cambia”. In mezzo, però, c’è la stessa dinamica: fiducia automatizzata. Fiducia nel pacchetto che compila senza errori e passa la pipeline. Fiducia nel router che sta lì, all’angolo della rete, e fa da ponte tra servizi e persone. Quando questa fiducia viene sfruttata, l’impatto non è solo tecnico. Diventa operativo, economico, reputazionale. Da un lato emergono quattro pacchetti NuGet malevoli che mirano direttamente agli sviluppatori ASP.NET con tecniche rare e difficili da intercettare, come l’hooking del JIT. Dall’altro, Zyxel pubblica un advisory con una costellazione di vulnerabilità che colpiscono diversi modelli di CPE, router ed extender, tra null pointer dereference con impatto DoS e command injection in scenari specifici, spesso legati a configurazioni che molti lasciano abilitate “per comodità”, come UPnP. Insieme, queste due storie descrivono un problema unico: la superficie d’attacco si estende dove il lavoro è più veloce e dove la manutenzione è più trascurata.

Pacchetti NuGet: quando l’attacco entra nel progetto e non nel server

Nel mondo .NET, NuGet è un’infrastruttura culturale prima ancora che tecnica. È la scorciatoia che riduce tempi, errori e duplicazioni. Ed è proprio qui che una campagna di pacchetti malevoli trova il suo vantaggio: non deve bucare un firewall, non deve sfruttare una zero-day del server. Deve soltanto farsi includere, anche per errore, nel posto giusto. Il modello, in apparenza, è quello classico del typosquatting, ma l’esecuzione è più sofisticata. I pacchetti vengono pubblicati da un attore identificato come hamzazaheer, in un arco temporale concentrato, tra il 12 e il 21 agosto 2024, e riescono comunque a macinare oltre 4.500 download prima della rimozione. È un dato che pesa perché mostra quanto sia facile trasformare una svista in un vettore stabile, soprattutto in ecosistemi dove la velocità di delivery è diventata una metrica di business. I nomi indicati dagli analisti sono NCryptYo, DOMOAuth2_, IRAOAuth2.0 e SimpleWriter_. La scelta lessicale non è casuale: richiama librerie legittime, crea prossimità visiva e mentale, e riduce la soglia di sospetto. In un progetto reale, dove esistono decine o centinaia di dipendenze, l’errore non è “scaricare un malware”. È aggiungere un pacchetto che sembra plausibile e che non produce anomalie immediate in build. Questo è il punto più pericoloso della supply chain: l’attacco non si manifesta come incidente, ma come normalità.

Il salto di qualità: JIT hooking e manipolazione del runtime

Il dettaglio che rende questa campagna diversa dal rumore di fondo è l’uso del JIT hooking. In particolare, nel pacchetto che agisce da dropper, NCryptYo, viene descritta una manipolazione del processo di compilazione JIT, con interventi su strutture come la vtable e sulla funzione compileMethod. Tradotto in termini operativi: invece di limitarsi a eseguire codice malevolo “a margine”, l’attaccante cerca di inserirsi in un punto dove può osservare e alterare il comportamento dell’applicazione mentre il codice viene tradotto ed eseguito. È una scelta che punta a due risultati: aumentare la persistenza logica e ridurre l’efficacia delle analisi statiche, perché parte della catena si attiva a runtime. La catena descritta include elementi di offuscamento e protezione, con tecniche associate a strumenti come .NET Reactor, l’uso di attributi come SuppressIldasm, la virtualizzazione dell’IL e controlli anti-manomissione che rendono più faticosa l’ispezione. Anche qui, la lettura corretta non è “hanno offuscato un malware”, ma “hanno costruito una dipendenza che si comporta come un prodotto commerciale difensivo, però al contrario”. È una mossa tipica di chi sa che lo sviluppatore moderno non vive più nel reverse engineering, vive nella pipeline. L’elemento operativo più concreto, in questa campagna, è l’uso di un proxy locale. Viene indicata l’apertura di un endpoint su localhost, su una porta specifica, e un comportamento che suggerisce una logica di tunnel o di instradamento dati. È un trucco efficace perché molte organizzazioni guardano al traffico in uscita verso Internet, ma sottovalutano segnali “locali” che sono invece sintomi di un componente che sta orchestrando una catena più ampia. Quando la backdoor sta dentro l’applicazione, può permettersi di parlare con se stessa, preparare pacchetti, e poi scegliere quando e come esfiltrare.

Il bersaglio vero: ASP.NET Identity e la vita interna delle autorizzazioni

Gli altri pacchetti, DOMOAuth2_ e IRAOAuth2.0, vengono associati a funzioni di esfiltrazione di dati legati all’identità e ai ruoli, con particolare attenzione a ASP.NET Identity. Qui la posta in gioco è più alta di una password rubata. In un’applicazione enterprise, i ruoli e gli identificativi utente sono la mappa del potere. Sapere chi è chi, quali account hanno privilegi, quali ruoli esistono, significa poter costruire attacchi secondari credibili, muoversi lateralmente, o persino alterare logiche autorizzative in modo invisibile. Questo è il punto in cui la supply chain diventa un rischio di governance applicativa. Se un pacchetto può osservare e intercettare informazioni di identità e ruolo, l’impatto non è limitato a “dati trafugati”. È integrità applicativa compromessa. Il rischio più sottile è che qualcuno, dopo l’infezione, possa modificare permessi e controlli in modo tale da far sembrare “legittimo” ciò che non lo è. La backdoor, in questo caso, non deve aprire una shell: può semplicemente cambiare il significato di “autorizzato”. SimpleWriter_, nella descrizione, aggiunge un’ulteriore dimensione: la capacità di scrivere file, mantenere persistenza e avviare processi in modo nascosto. Anche quando un attacco parte “solo” dalla supply chain, la traiettoria naturale è sempre la stessa: trasformare un accesso logico in un accesso operativo. Un componente che scrive file senza adeguata sanitizzazione dei parametri è un ponte verso drop di payload, manipolazione di configurazioni, e persistenze che poi vengono scambiate per “problemi di sistema”.

Il segnale più utile per chi difende: la normalità è l’indicatore

C’è un aspetto che vale più di ogni firma: questi pacchetti funzionano perché richiedono “poco”. Non costringono a configurazioni strane, non impongono dipendenze bizzarre, non bloccano la build. Anzi: la descrizione suggerisce attivazioni che possono avvenire con un semplice uso nel codice, magari in un punto secondario, magari in un helper. Questo è il motivo per cui i consigli più utili, in scenari simili, non sono quelli che promettono “rilevazione certa”, ma quelli che riducono la probabilità di ingestione. In pratica, nel 2026, un progetto .NET che vuole ridurre il rischio supply chain deve trattare le dipendenze come trattava, dieci anni fa, le porte aperte sul firewall. Serve una disciplina che includa blocco versioni, revisione dei publisher, controllo delle date di pubblicazione, e soprattutto una cultura del “perché stiamo includendo questa libreria?”. Quando un pacchetto è appena nato, ha poche dipendenze e un nome troppo simile a qualcosa di noto, è lì che la pipeline dovrebbe fermarsi, non accelerare.

Vulnerabilità Zyxel: il lato hardware della stessa fragilità

Se i pacchetti NuGet mostrano come l’attacco entri nel codice, le vulnerabilità Zyxel mostrano l’altra faccia: l’attacco entra nella rete, e spesso non ha bisogno di exploit “da film”. Ha bisogno di configurazioni reali, credenziali amministrative ottenute o riutilizzate, e di funzioni abilitate per default o lasciate aperte per comodità. Zyxel pubblica un advisory con più CVE che coprono due famiglie di problemi: null pointer dereference che può portare a crash e DoS, e command injection in determinate condizioni. Le vulnerabilità DoS vengono descritte come sfruttabili tramite richieste HTTP craftate su endpoint specifici legati a funzioni di gestione e CGI. La severità, in questi casi, non si misura solo con la parola “DoS”. Si misura con la realtà operativa: un CPE o un router che crasha non è un “disagio”, è un’interruzione di servizio che può bloccare telelavoro, accesso a sistemi aziendali, filiali, impianti, e in molti casi anche il canale VoIP o la connettività di dispositivi industriali. Il DoS, nel 2026, è spesso il preludio a qualcosa di peggio, perché costringe l’operatore a intervenire in fretta e ad aprire finestre di manutenzione improvvisate. Sul fronte command injection, Zyxel segnala scenari che coinvolgono, tra le altre cose, componenti legate a UPnP SOAP e funzioni di download di log o certificati, con condizioni precise che spesso includono la necessità di accesso autenticato o l’abilitazione di feature lato WAN. È un punto essenziale: molte vulnerabilità “non sono remote” sulla carta, ma diventano praticamente remote quando l’ambiente è configurato in modo permissivo, quando le password vengono riutilizzate, o quando un attore riesce a ottenere credenziali tramite phishing, credential stuffing o compromissione di un endpoint interno. Qui la supply chain hardware si intreccia con quella umana. Non basta patchare se la credenziale admin è debole. Non basta disabilitare UPnP se l’accesso remoto è già stato aperto per un’esigenza temporanea e poi dimenticato. Il router, in molte organizzazioni, è l’oggetto meno governato e più centrale allo stesso tempo: nessuno lo considera “applicazione”, eppure decide cosa passa e cosa no.

Perché queste CVE contano anche quando “serve autenticazione”

C’è un riflesso che in molte aziende è ancora radicato: se una vulnerabilità richiede accesso autenticato, viene declassata mentalmente. Nel 2026 questo riflesso è pericoloso, perché l’accesso autenticato è spesso la cosa più facile da ottenere. Non perché gli amministratori siano incompetenti, ma perché l’ecosistema è pieno di credenziali riutilizzate, password salvate, accessi condivisi, e dispositivi esposti in modo non intenzionale. Le campagne di phishing moderne non cercano più di bucare un router con una magia. Cercano di rubare la password di qualcuno che quel router lo gestisce. In questo senso, le vulnerabilità Zyxel hanno un valore sistemico: ricordano che la sicurezza dei dispositivi di rete non può essere trattata come “progetto una tantum”. È manutenzione continua. È gestione delle password. È controllo dell’esposizione WAN. È riduzione delle funzioni “comode” che non sono essenziali. Zyxel, in questo quadro, fa ciò che ci si aspetta da un vendor: pubblica advisory, rilascia patch per firmware supportati e consiglia mitigazioni come la disabilitazione di UPnP e la riduzione dell’accesso remoto. Ma il carico operativo resta sulle organizzazioni: capire quali modelli sono in rete, quali versioni firmware sono installate, quali feature sono abilitate e soprattutto chi possiede davvero l’account admin.

Il punto di contatto tra NuGet e Zyxel: la fiducia invisibile

Sembra che parliamo di due mondi lontani. In realtà il tema è identico: fiducia invisibile. Nel caso NuGet, la fiducia è nel pacchetto che “fa comodo” e viene incluso. Nel caso Zyxel, la fiducia è nel dispositivo che “sta lì” e non viene aggiornato. Entrambi sono punti in cui la governance è debole perché la routine è forte. E gli attori malevoli, nel 2026, non inseguono soltanto vulnerabilità. Inseguono routine. La supply chain moderna è fatta di automatismi. CI/CD automatizza build e deploy. Router e CPE automatizzano connettività e gestione remota. Il risultato è che l’errore non è più un singolo gesto sbagliato: è una serie di scelte “normali” che, sommate, creano un corridoio. La campagna NuGet mostra come questo corridoio possa arrivare fino al runtime e alle identità applicative. Le vulnerabilità Zyxel mostrano come lo stesso corridoio possa arrivare fino all’esecuzione comandi e al controllo del perimetro di rete.

Mitigazione reale: ridurre superficie, rendere verificabile la dipendenza, accorciare i tempi di patch

La risposta efficace, in entrambi i casi, non è una sola. È una combinazione di riduzione superficie e aumento verificabilità. Per i team di sviluppo significa rendere più “costosa” l’introduzione di una dipendenza nuova, non con burocrazia sterile, ma con controlli automatici che fermano l’anomalia prima del merge. Significa proteggere la pipeline dalla seduzione del pacchetto “quasi uguale” e dalla fretta di risolvere un problema con una libreria non verificata. Significa anche monitorare ciò che normalmente non si monitora, come i segnali di hooking e i comportamenti di proxy locali inattesi, perché la difesa moderna è comportamentale prima ancora che basata su firme. Per chi gestisce reti significa inventariare e patchare, ma anche cambiare mentalità: UPnP e accessi WAN non sono feature neutre, sono leve di esposizione. Le credenziali admin non sono un dettaglio, sono il vero perimetro. Il firmware non è “aggiornamento opzionale”, è parte della postura di sicurezza. E quando un advisory parla di command injection, anche se richiede condizioni precise, la domanda corretta non è “quanto è probabile?”, ma “quanto è costoso scoprirlo dopo?”. Nel 2026, questa è la soglia minima di maturità: trattare dipendenze software e dispositivi di rete come parti dello stesso sistema di rischio. Perché lo sono. E quando una campagna riesce a vivere abbastanza da ottenere migliaia di download, o quando un parco router resta indietro di mesi di patching, non è più un problema “tecnico”. È un problema di governance operativa, cioè la materia prima degli incidenti che poi diventano notizia.