Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Arile! Scopri di più
Librerie Malevole: Malicious Library (T1204.005)
L'installazione di una libreria malevola da un package manager rappresenta uno dei vettori di esecuzione più insidiosi nel panorama contemporaneo della supply chain software. La tecnica T1204.005 si colloca nella tattica Execution (TA0002): l'avversario punta a far eseguire codice malevolo sul sistema della vittima, sfruttando la fiducia implicita che sviluppatori e utenti ripongono negli ecosistemi di pacchetti come NPM, PyPI o i repository pubblici su GitHub.
Il meccanismo è lineare ma efficace. L'attaccante pubblica un pacchetto malevolo su un registry pubblico, talvolta ricorrendo al typosquatting — registrando nomi quasi identici a librerie popolari — oppure compromettendo direttamente pacchetti esistenti con larga adozione. L'utente esegue un semplice pip install o npm install e, senza rendersene conto, avvia codice ostile che può instaurare persistenza, esfiltrare credenziali o avviare mining di criptovaluta.
La pericolosità risiede nel fatto che il codice viene eseguito nel contesto dell'utente che installa il pacchetto, spesso uno sviluppatore con privilegi elevati sull'ambiente di sviluppo. A differenza di un phishing classico, qui non serve un Initial Access tradizionale: l'utente stesso è il vettore. I dati disponibili indicano 1 gruppo APT attivo su questa tecnica, 3 mitigazioni documentate e rilevamenti specifici per Linux, Windows e macOS, a testimonianza di una superficie d'attacco multi-piattaforma che merita attenzione dedicata.
Simulare un attacco via libreria malevola in laboratorio è un esercizio essenziale per comprendere l'intera catena, dalla pubblicazione del pacchetto fino all'esecuzione del payload. L'obiettivo è dimostrare come un setup.py o un postinstall script possano attivarsi silenziosamente al momento dell'installazione.
Il punto di partenza è creare un pacchetto Python minimale con un setup.py che sfrutti il parametro cmdclass per agganciare codice arbitrario alla fase di installazione. In un ambiente isolato, struttura il pacchetto con una directory contenente setup.py, __init__.py e un modulo Python. All'interno del setup.py, sovrascrivi la classe install di setuptools inserendo nel metodo run una chiamata a subprocess che esegua un comando di callback — ad esempio una reverse shell verso il tuo listener. L'installazione con pip install . dalla directory del pacchetto attiverà il codice durante la fase di build.
Per il mondo Node.js, il meccanismo equivalente sfrutta il campo preinstall o postinstall nel package.json. Inserendo uno script che esegua node -e "require('child_process').exec('...')", il codice scatta automaticamente al termine di npm install. È sufficiente pubblicare il pacchetto su un registry locale come Verdaccio (open source) per simulare l'intero flusso senza coinvolgere registri pubblici.
Per catturare la callback, imposta un listener con Netcat:
nc -lvnp 4444
Oppure usa un Metasploit handler con multi/handler configurato su un payload appropriato. Il punto chiave della dimostrazione è la correlazione temporale: mostrare che l'esecuzione avviene senza alcuna interazione ulteriore da parte dell'utente dopo il comando di installazione.
Per rendere il test realistico, valuta di impiegare GuardDog (open source), un tool di Datadog che analizza pacchetti PyPI e NPM alla ricerca di pattern sospetti come offuscamento, connessioni di rete nel setup script e accesso a variabili d'ambiente sensibili. Lancialo su un pacchetto sospetto con:
guarddog pypi scan
Un altro strumento utile è pip-audit (open source), che verifica le dipendenze installate contro il database di vulnerabilità note:
pip-audit --require-hashes -r requirements.txt
Per il typosquatting, strumenti come PyPI-scan o semplici script che calcolano la distanza di Levenshtein rispetto ai top 1000 pacchetti possono dimostrare quanto sia facile generare nomi confondibili. La simulazione si chiude documentando l'intera kill chain: comando utente → esecuzione setup script → callback C2 → eventuale persistenza.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo