Sommario
Le minacce supply chain stanno diventando uno dei vettori più insidiosi nel mondo dello sviluppo software, e l’ecosistema Python non fa eccezione. La scoperta dei pacchetti maligni termncolor e colorinal da parte di Zscaler ThreatLabz il 22 luglio 2025 conferma come gli attaccanti riescano a sfruttare la fiducia riposta nelle librerie open-source per infiltrarsi nelle pipeline di sviluppo. Apparentemente inoffensivo, termncolor si presenta come una semplice utility per la gestione dei colori nel terminale, ma in realtà funge da cavallo di Troia che importa colorinal, responsabile di un’operazione malware multi-stage. La catena d’attacco si basa su sideloading DLL, persistenza tramite registry ed esfiltrazione di dati attraverso un C2 mascherato da traffico Zulip, con l’obiettivo di ottenere esecuzione di codice remoto in ambienti Windows e Unix.
Scoperta dei pacchetti “maligni”
Secondo Zscaler, l’analisi dei database Python ha rivelato l’anomalia il 22 luglio 2025. Termncolor funge da entry point e, una volta installato, importa automaticamente colorinal. Questo pacchetto carica un file apparentemente innocuo, unicode.py, che in realtà innesca la catena di infezione. Lo script utilizza ctypes.CDLL per caricare la DLL terminate.dll, decrittare un payload tramite AES in modalità CBC con la chiave hardcoded xterminalunicode e depositare file legittimi sfruttati per il sideloading. Il malware posiziona infatti un eseguibile legittimo, vcpktsvr.exe, insieme a una versione malevola di libcef.dll, progettata per raccogliere informazioni di sistema ed eseguire shellcode remoti. Questa tecnica sfrutta la fiducia negli eseguibili legittimi per aggirare i controlli di sicurezza. Le analisi hanno rivelato anche varianti Linux, in cui il payload viene gestito tramite il file terminate.so, confermando la natura cross-platform della campagna.
Analisi del primo stage del malware
Il primo stadio del malware si concentra sul caricamento della DLL malevola e sulla creazione della persistenza. Dopo aver decrittato il payload con la chiave xterminalunicode, il codice droppa vcpktsvr.exe e posiziona la DLL alterata. Successivamente, viene creata una chiave di registro sotto HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, con il valore pkt-update che punta all’eseguibile. In questo modo il malware assicura l’avvio automatico a ogni riaccensione del sistema. La variante Linux utilizza invece systemd o cron per garantire la persistenza, replicando la stessa logica. L’uso di file apparentemente legittimi, la cancellazione dei file originali e la capacità di offuscamento rendono questa fase estremamente pericolosa per gli sviluppatori che, convinti di aver installato un modulo banale, ritrovano il loro ambiente compromesso.
L’algoritmo di hashing API in libcef.dll
Uno degli aspetti tecnici più rilevanti della campagna riguarda l’uso di un algoritmo di hashing custom per la risoluzione delle API. La funzione calculate_hash inizializza il valore a 12, itera i caratteri della stringa convertendoli in maiuscolo e calcola un valore tramite operazioni aritmetiche e bitwise, moltiplicando ogni carattere per 0x83 e applicando uno shift a sinistra. Questo metodo permette di richiamare funzioni senza esporre i loro nomi in chiaro, rendendo più difficile il rilevamento basato su firme statiche. Sebbene non particolarmente sofisticata, questa tecnica rappresenta un esempio concreto di come gli attaccanti cerchino soluzioni leggere ed efficaci per evadere le difese tradizionali, e deve essere tenuta in considerazione per la creazione di regole di detection specifiche.
Secondo stage e comunicazione con il C2
Il secondo stadio, gestito da libcef.dll, si occupa della raccolta e trasmissione dei dati al server di comando e controllo. Il malware raccoglie nome del computer, username e versione del sistema operativo, inviando queste informazioni tramite HTTPS verso un’infrastruttura che imita il traffico di Zulip, una piattaforma di chat open-source poco diffusa, scelta proprio per non destare sospetti. Inoltre, la DLL utilizza un algoritmo di hashing custom per le API, che rende più complessa la rilevazione statica, e supporta l’esecuzione di shellcode remoto, consentendo agli attaccanti di prendere il controllo della macchina in maniera completa. La capacità di travestire il traffico malevolo da comunicazione legittima e la possibilità di eseguire comandi arbitrari innalzano notevolmente la gravità dell’attacco.
Somiglianze con pacchetti legittimi e rischi supply chain
Il punto di forza della campagna è l’inganno basato sul typosquatting. Termncolor e colorinal richiamano infatti il nome di colorama, una libreria ampiamente usata per la gestione dei colori ANSI nei terminali. Questa somiglianza induce gli sviluppatori a installare per errore i pacchetti malevoli, credendo di aver digitato correttamente il nome del pacchetto legittimo. Si tratta di una tecnica già vista in altre campagne, che sfrutta la vulnerabilità strutturale degli ecosistemi open-source, dove chiunque può pubblicare un pacchetto senza controlli preliminari approfonditi. Il parallelo con il caso di XZ Utils del 2024, che introdusse backdoor in software critici, mostra come la supply chain sia ormai un terreno privilegiato per campagne sofisticate che puntano a infiltrarsi direttamente nelle pipeline di sviluppo.
Varianti Linux e strategia cross-platform
Le varianti Linux, basate su terminate.so, dimostrano la capacità degli attaccanti di adattare le loro tecniche a diversi ambienti operativi. In questo caso il caricamento della libreria avviene tramite le stesse chiamate a ctypes.CDLL usate nella versione Windows, con la differenza che la persistenza viene garantita attraverso servizi Unix. L’obiettivo è colpire tanto le macchine di sviluppo Windows quanto i server Linux di produzione, aumentando l’efficacia complessiva della campagna. Questo approccio cross-platform indica un livello di pianificazione superiore, con la volontà di colpire l’intero ciclo di vita del software, dalla scrivania dello sviluppatore fino ai sistemi in cloud.
Raccomandazioni e mitigazioni
Gli esperti di Zscaler suggeriscono di adottare un approccio multilivello alla protezione contro le minacce supply chain. Gli sviluppatori devono verificare attentamente i pacchetti prima dell’installazione, controllando numero di download, recensioni e firme digitali. L’uso di ambienti isolati come pipx o container può ridurre i rischi, così come l’implementazione di repository interni che ospitano solo pacchetti verificati. Le aziende sono invitate a integrare strumenti di monitoraggio delle dipendenze e sistemi EDR in grado di rilevare comportamenti anomali, come la creazione di chiavi di registro sospette o il caricamento di DLL non autorizzate. Un’attenzione particolare va rivolta anche al blocco dei domini non utilizzati come Zulip, se non necessari, e all’adozione di framework come SLSA per rafforzare la provenienza e l’integrità del software utilizzato.
Impatto e prospettive future
L’impatto di questa campagna dimostra come gli attacchi alla supply chain software siano diventati una minaccia concreta e in crescita. Oltre al furto di dati e al controllo remoto dei sistemi, tali campagne possono aprire la strada a attacchi ransomware o a ulteriori compromissioni delle pipeline CI/CD. Gli analisti prevedono che, in futuro, gli attaccanti utilizzeranno tecniche ancora più avanzate, come l’uso dell’intelligenza artificiale per generare pacchetti contraffatti sempre più credibili o per identificare automaticamente i nomi dei pacchetti più a rischio di typosquatting. La comunità open-source e le aziende che dipendono da queste librerie sono quindi chiamate a rafforzare i controlli, a promuovere la collaborazione con i vendor di sicurezza e ad adottare processi di verifica costanti.
