Compromissione della Supply Chain Software: Compromise Software Dependencies and Development Tools (T1195.001)

In un ingaggio red team autorizzato, la simulazione di T1195.001 richiede un ambiente lab isolato e obiettivi concordati con il cliente. La catena tipica parte dalla ricognizione del target: identificare quali dipendenze interne l'azienda pubblica su registry pubblici, quali GitHub Actions custom mantiene, e quali pacchetti privati potrebbero essere vulnerabili a dependency confusion.

Per il typosquatting su npm in laboratorio, uno script Python che interroga l'API pubblica del registry (endpoint di ricerca standard) permette di generare varianti ortografiche (character swap, homoglyph, scope confusion) dei pacchetti target. Tool come confused (open source, GitHub visma-prodsec/confused) automatizzano l'identificazione di pacchetti candidati alla dependency confusion analizzando package.json, requirements.txt o pom.xml del bersaglio:

confused -l npm package.json

Per la simulazione di malicious package, il payload va inserito negli hook di lifecycle. In un package npm di test si sfrutta preinstall o postinstall nel package.json; in Python il codice arbitrario può risiedere in setup.py durante pip install. In lab, il payload deve limitarsi a un beacon HTTP verso il C2 red team, evitando persistenza reale.

Per la compromissione simulata di GitHub Actions, si costruisce un'action custom in un repository controllato che, quando invocata come uses: in un workflow target, legge variabili d'ambiente (GITHUB_TOKEN, secret esposti) e le esfiltra. Il tool gato (open source, GitHub praetorian-inc/gato) esegue enumerazione di GitHub Actions vulnerabili, injection in workflow e privilege escalation via pull_request_target:

gato enumerate -t organizzazione-target

Per supply chain su ecosistema Python, bandersnatch (open source) permette di mirrorare PyPI in lab per test controllati, mentre pypi-server (open source) simula un registry interno per riprodurre scenari di confusion.

Su macOS, la simulazione XCSSET-like richiede la manipolazione controllata di un progetto Xcode di test: un payload Ruby che itera i file .xcodeproj in una directory sandbox e inietta uno script build phase, senza toccare progetti reali. Per orchestrare l'intera catena, framework come Caldera (open source, MITRE) permettono di codificare abilità T1195.001 in operazioni ripetibili e misurabili.

Documentare ogni pacchetto pubblicato, garantire il takedown post-esercizio e coordinarsi con i registry per evitare impatto su utenti terzi sono requisiti etici non negoziabili.

La detection di T1195.001 si fonda sulla correlazione write → first-exec → egress entro una finestra temporale ristretta (default 90 minuti), applicata agli endpoint di engineering e agli agent CI/CD. Il SOC deve mappare in anticipo quali host sono legittimamente autorizzati a invocare package manager, altrimenti il rumore rende impossibile l'analisi.

Su Windows, con Sysmon (open source) configurato con una policy che monitori node_modules, %AppData%\npm, %UserProfile%.cargo\bin, .nuget, .gradle, .m2, i segnali chiave arrivano dagli eventi Sysmon EID 11 (file create) generati da npm.exe, pip.exe, nuget.exe, dotnet.exe seguiti entro pochi minuti da EID 1 (process create) del componente scritto, spesso con parent node.exe, python.exe o shell powershell.exe/cmd.exe. Il terzo pilastro è EID 3 (network connect) verso destinazioni fuori dalla allow-list dei registry aziendali. Gli eventi Microsoft-Windows-CodeIntegrity/Operational aiutano a intercettare DLL non firmate caricate da processi build.

Su Linux, auditd con regole su execve dei package manager e watch su /usr/local/bin, /opt//bin*, ~/.local/bin, .venv/bin, node_modules/.bin permette di catturare la scrittura seguita da esecuzione di hook. Il pattern discriminante è uno script postinstall che spawna curl o wget verso un host non presente nella allow-list dei mirror interni. journald con filtro sui log dei package manager (apt, yum, dnf) fornisce il contesto della fonte del pacchetto.

Su macOS, Endpoint Security Framework e unified log consentono di tracciare installazioni Homebrew, invocazioni pip/npm, build Xcode. Il segnale ad alto valore è la comparsa di Mach-O non firmati o firmati con Team ID non presenti nella allow-list, seguita da spawn di osascript, sh, zsh con connessioni outbound.

Gli alert vanno costruiti come sequenze correlate, non come singoli eventi. Una query SIEM efficace collega: (process_name IN package_managers) AND file_write IN dev_paths → entro 90 minuti → (process_create WHERE parent = file_written) AND network_connect WHERE dest NOT IN approved_registries.

I falsi positivi principali derivano da: aggiornamenti legittimi di pacchetti popolari, mirror interni non correttamente censiti, sviluppatori che testano pacchetti sperimentali. La tuning si basa su liste di publisher firmati approvati, allow-list di registry (registry.npmjs.org, pypi.org, nuget.org, maven.apache.org, proxy aziendali) e limitazione dell'analitica ai soli host di sviluppo. L'integrazione con OSQuery (open source) o Wazuh (open source) per l'inventario software garantisce visibilità continua sui pacchetti installati.

L'analisi forense di un incidente T1195.001 parte dall'identificazione del pacchetto compromesso e ricostruisce la catena di propagazione a monte (chi lo ha pubblicato, quando, quali maintainer erano coinvolti) e a valle (quali host lo hanno scaricato, quali build lo hanno incorporato, quali artefatti finali lo contengono).

Su Windows, gli artefatti primari risiedono nelle cartelle dei package manager: /node_modules di ogni progetto contiene i file package.json e package-lock.json con hash SHA-512 dei pacchetti installati; il confronto tra hash osservato e hash pubblicato sul registry rivela manomissioni. La cartella %AppData%\npm-cache mantiene i tarball scaricati con metadati temporali utili alla timeline. Per pip, /Lib/site-packages con i file METADATA e RECORD dei pacchetti, insieme al cache in %LocalAppData%\pip\Cache, permette di ricostruire installazioni storiche. Prefetch e Amcache.hve documentano prima esecuzione dei binari droppati, mentre ShimCache conserva evidenze anche dopo la rimozione.

Su Linux, /var/log/dpkg.log, /var/log/apt/history.log e /var/log/yum.log contengono lo storico installazioni di sistema. Per package manager di linguaggio, ~/.npm/_logs, ~/.pip/pip.log e i file .lock nei progetti (package-lock.json, Pipfile.lock, Gemfile.lock, Cargo.lock, go.sum) sono decisivi per identificare quale versione esatta è stata risolta e quando. La cartella ~/.cache/pip e ~/.npm conservano tarball originali analizzabili con oletools o disassemblatori.

Su macOS, il caso XCSSET fornisce un modello: l'analista cerca modifiche non autorizzate nei file target_integrator.rb sotto /Library/Ruby/Gems e nei file project.pbxproj dentro le cartelle .xcodeproj, dove build phase aggiuntive introducono download di script o Mach-O nella cartella del progetto. Unified log (log show --predicate) permette di ricostruire l'esecuzione di xcodebuild, pod install e componenti spawn correlati.

Per BeaverTail distribuito via npm, gli artefatti includono il pacchetto malevolo cached, i file JavaScript offuscati caricati dai worker Node, i log di connessioni outbound verso l'infrastruttura C2 e le tracce di esfiltrazione da wallet crypto e password manager browser.

La timeline finale deve correlare: timestamp di pubblicazione del pacchetto malevolo sul registry (verificabile via API pubbliche del registry stesso e mirror indipendenti), timestamp di installazione sull'host vittima (dai lock file e cache), prima esecuzione (Prefetch, auditd, unified log), prime connessioni C2 (log NSM, netflow). L'analisi statica del pacchetto con strings, jadx per componenti Java, o unpacker JavaScript come de4js permette di estrarre IOC riutilizzabili per la caccia orizzontale sul resto del parco macchine.

I dati MITRE ATT&CK non associano gruppi APT specifici alla tecnica T1195.001, ma documentano due software rilevanti che illustrano archetipi distinti dell'ecosistema di minaccia.

XCSSET (S0658) rappresenta il paradigma della compromissione di ambiente di sviluppo mirata a una piattaforma specifica. Colpisce sviluppatori macOS che usano Xcode, iniettando codice malevolo tramite manipolazione dei file target_integrator.rb di CocoaPods sotto /Library/Ruby/Gems o enumerando le cartelle .xcodeproj per depositare script e binari Mach-O. Il modello di propagazione è a valanga: gli sviluppatori infetti ridistribuiscono inconsapevolmente app compromesse ai loro utenti finali, e i loro progetti pubblicati su repository condivisi diventano vettori secondari. La targettizzazione di CocoaPods dimostra come gli avversari studino gli ecosistemi di dipendenza specifici (non solo npm o PyPI) per massimizzare l'impatto in nicchie verticali.

BeaverTail (S1246) esemplifica invece l'uso di registry pubblici come canale di distribuzione diretto: hostato su code repository e diffuso via pacchetti npm, colpisce sviluppatori JavaScript/Node.js con payload di infostealing (credenziali browser, wallet cryptocurrency, chiavi SSH). Questo pattern si inserisce in una tendenza documentata di campagne che sfruttano finte offerte di lavoro tecniche, con reclutatori fittizi che invitano sviluppatori a clonare progetti "di valutazione" contenenti pacchetti npm malevoli come dipendenze.

Dal punto di vista dei trend, T1195.001 mostra tre traiettorie evolutive. La prima è la crescita quantitativa: i registry pubblici principali (npm, PyPI, RubyGems) rimuovono continuamente migliaia di pacchetti malevoli l'anno, con volumi in aumento. La seconda è la sofisticazione dei meccanismi di consegna: dagli hook lifecycle rumorosi si passa a payload attivati solo in presenza di specifici indicatori d'ambiente (dominio Active Directory della vittima, variabili CI/CD di aziende target), riducendo la superficie di detection sandbox. La terza è lo spostamento verso il layer CI/CD: le GitHub Actions riutilizzate transitivamente permettono di compromettere pipeline di migliaia di organizzazioni tramite una singola action popolare.

Gli obiettivi geografici e settoriali osservabili includono: aziende fintech e crypto (target primario di BeaverTail-like), sviluppatori enterprise software (target di dependency confusion contro pacchetti privati), fornitori di infrastruttura cloud e DevOps tooling (target di secondo ordine per amplificazione).

La priorità intelligence-driven per un CTI officer è mantenere sensor su feed di rimozione pacchetti dei registry principali, monitorare la registrazione di nomi tipo-squattati dei propri package interni e tracciare le comunicazioni degli attori nel sottobosco che offrono accesso a account maintainer compromessi.

MITRE ATT&CK T1195.001 (Compromise Software Dependencies and Development Tools), tattica TA0001. Software: S0658 (XCSSET), S1246 (BeaverTail). Mitigazioni: M1013, M1016, M1033, M1051. Detection analytics: DET0009 (AN0021 Windows, AN0022 Linux, AN0023 macOS). MITRE D3FEND per mapping difensivo. Livello 2 (conoscenza professionale): tool open source citati (Sysmon, auditd, OSQuery, Wazuh, confused, gato, Caldera, bandersnatch) verificati come progetti attivi con repository pubblici.