Pipeline sotto assedio: come i threat actor nation-state stanno compromettendo la software supply chain

Dall’intervento di Francesco Schifilliti, Cyber Investigation & Threat Intelligence Advisor, alla 14ª Cyber Crime Conference (Roma, 6-7 maggio 2026)

Negli ultimi cinque anni gli attacchi alla supply chain software sono cresciuti di circa il 400%, secondo una stima che incrocia i dati di Sonatype ed ENISA, e nello stesso periodo si è aperta una forbice che è oggi il nodo centrale per chi difende: solo il 9% delle organizzazioni li considera una minaccia prioritaria, mentre il 31% li indica come la categoria di attacco effettivamente subìta.

Su questo scarto fra percezione e realtà operativa Francesco Schifilliti ha costruito l’intervento alla 14ª Cyber Crime Conference, dedicato alla compromissione della pipeline software da parte di attori nation-state. Una riflessione che intreccia teoria dell’attacco, casistica forense e letture difensive, organizzata attraverso quattro paradigmi operativi distinti: 3CX, SolarWinds, Volt Typhoon e XZ Utils.

Cos’è un attacco alla supply chain: due vittime, una sola fiducia tradita

Un attacco alla supply chain si distingue da qualunque altro vettore per una caratteristica strutturale: non esiste una sola vittima, ne esistono almeno due. La prima è la vittima primaria, tipicamente il produttore del software (vendor), che subisce la compromissione iniziale e mantiene visibilità tecnica sull’evento. La seconda è la vittima secondaria, cioè l’organizzazione cliente che riceve il payload attraverso una relazione di fiducia legittima con il vendor, e che non ha alcuna visibilità sulle fasi upstream della catena. Una remediation che non consideri entrambe le classi di vittima è incompleta per definizione.

Il secondo elemento distintivo è che un attacco alla supply chain è sempre, in ultima analisi, un attacco al trust. Mentre tutti gli altri vettori lavorano su una debolezza tecnica, umana o di configurazione della vittima, qui l’attaccante ribalta la logica: utilizza le difese del bersaglio finale come vettore di compromissione. Il software è verificato, il certificato è valido, il canale di aggiornamento è quello ufficiale: il confine di fiducia viene attraversato prima ancora che la vittima possa accorgersene. Esempi affini di attacchi al trust fuori dal perimetro della supply chain sono il DNS poisoning, gli attacchi tramite vettori hardware e le tecniche Golden SAML.

Percezione contro realtà: il bias del 9%

Il dato che meglio fotografa la situazione è quello della survey Kaspersky richiamata in apertura. Interrogate sulla classificazione delle minacce per livello di pericolosità, solo il 9% delle organizzazioni globali colloca gli attacchi alla supply chain in cima alla lista; eppure, quando si guarda alla frequenza realmente sperimentata, la stessa categoria raggiunge il 31% delle compromissioni rilevate.

La spiegazione, ha osservato Schifilliti, sta in un bias cognitivo elementare: si tende a sovrastimare ciò che si conosce e a sottostimare ciò che non si conosce a fondo. La conseguenza operativa è grave: l’81% delle organizzazioni che oggi non considera prioritaria questa minaccia, qualora fosse stata compromessa negli ultimi mesi, con ogni probabilità non se ne sarebbe accorta e non avrebbe attivato alcuna contromisura.

La timeline 2015-2025 e il posizionamento Gartner

Il decennio 2015-2025 ha disegnato una traiettoria nitida. A partire dal 2017 il numero di campagne supply chain documentate è cresciuto in modo marcato, e la quota attribuibile a gruppi nation-state ha assunto un peso strutturale rispetto a quella crime o non attribuita. Le campagne pienamente documentate nel periodo superano la trentina, e il conto esclude il sommerso non attribuito o non disclosurato pubblicamente.

Il posizionamento proposto da Gartner nel Threatscape 2025 è altrettanto eloquente: gli attacchi alla supply chain sono collocati al centro della matrice, nella categoria Threat Advantage. Si tratta di minacce per le quali esiste già una letteratura tecnica matura, sono ampiamente documentate dai principali vendor di cyber threat intelligence (basti citare i report 2026 di CrowdStrike, Mandiant/Unit 42, Group-IB, Kaspersky, Red Canary, Dataminr, World Economic Forum), e per le quali esistono contromisure note. Ciò nonostante, le organizzazioni restano sistematicamente in ritardo nell’adottarle: è proprio questa asimmetria fra disponibilità di conoscenza e maturità delle difese a generare il vantaggio strategico degli attaccanti.

La classificazione MITRE ATT&CK: T1195 e le sue tre declinazioni

Nel framework MITRE ATT&CK la supply chain compromise è codificata come tecnica T1195, all’interno della tattica Initial Access. Tre sotto-tecniche specificano il vettore concreto.

T1195.001 (Compromise Software Dependencies and Development Tools) descrive la compromissione a monte di librerie di terze parti, framework, package manager (npm, PyPI, Maven) o strumenti di sviluppo integrati nella pipeline CI/CD; il codice malevolo viene iniettato upstream, prima che lo sviluppatore lo incorpori nel prodotto finale. Casi tipici: type squatting, dependency confusion.

T1195.002 (Compromise Software Supply Chain) descrive lo scenario in cui l’avversario altera direttamente il software distribuito da un vendor legittimo: modifica di binari, installer o aggiornamenti automatici prima della consegna agli utenti finali. È la modalità più frequente, e include la compromissione dei processi di build e del code signing.

T1195.003 (Compromise Hardware Supply Chain) descrive la manomissione fisica di componenti hardware (schede di rete, firmware, BIOS/UEFI) durante la fabbricazione, il trasporto o la distribuzione. È il vettore più difficile da rilevare proprio perché la compromissione avviene a un livello inferiore al sistema operativo.

I vettori d’attacco: dal Software Update Mechanism all’Operazione Pager

Dall’analisi statistica delle campagne 2015-2025 emerge un dato non sorprendente: il vettore più utilizzato è il Software Update Mechanism, con l’11,5% delle compromissioni documentate; tutti gli altri sedici vettori censiti si distribuiscono in modo sostanzialmente uniforme intorno al 5,9% ciascuno, fra package repository open source (npm, PyPI), CI/CD pipeline, Managed File Transfer, compromissione MSP/IAM e altri.

Prima di entrare nel meccanismo software, Schifilliti ha richiamato un caso emblematico di compromissione hardware: l’Operazione Pager del 17-18 settembre 2024, attribuita all’intelligence israeliana e diretta contro operativi Hezbollah in Libano.

L’operazione ha causato 37 morti e oltre 2.900 feriti, e secondo la ricostruzione giornalistica ha richiesto una pianificazione di oltre quindici anni. Il modus operandi è istruttivo: non è stato compromesso il produttore originale (la taiwanese Gold Apollo), bensì è stata interposta una società intermediaria (BAC Consulting, con sede in Ungheria, apparente licenziataria del brand per la produzione regionale), attraverso la quale sono stati consegnati circa 5.000 pager AR-924 modificati.

Ogni dispositivo conteneva 3-5 grammi di PETN nel vano batteria, con un detonatore non metallico invisibile agli scanner aeroportuali, attivabile remotamente sfruttando l’assenza di autenticazione del protocollo POCSAG. Un esempio che mostra plasticamente l’effort temporale e l’investimento di intelligence che possono caratterizzare un’operazione supply chain di livello strategico.

La pipeline del Software Update Mechanism: sei fasi, una sola frontiera di visibilità

Lo schema del Software Update Mechanism si articola in sei fasi distribuite su due stream operativi.

Fasi upstream (1-3), interne all’infrastruttura del vendor:

1. Reconnaissance & Initial Access: ricognizione del build server e dell’ambiente DevOps, seguita dall’accesso iniziale tramite spear phishing mirato verso il personale con privilegi sull’ambiente di build, oppure tramite credenziali compromesse. L’obiettivo è arrivare il più rapidamente possibile all’endpoint di build.
2. Build Server Compromise: compromissione dell’ambiente di compilazione e swap del sorgente durante la build, con ripristino post-build per evitare tracce nei sistemi di versionamento (è il pattern del loader SUNSPOT usato in SolarWinds).
3. Payload Injection: iniezione del payload nel binario prima della firma; il code signing legittimo del vendor appone così la firma autentica anche sul codice malevolo.

Confine di visibilità: tutto ciò che avviene fino a questo punto è invisibile alla vittima finale. La detection è possibile solo all’interno del perimetro del vendor.

Fasi downstream (4-6), nell’infrastruttura della vittima:

1. Distribuzione: l’aggiornamento firmato viene trasmesso via canale ufficiale HTTPS e installato automaticamente sugli endpoint dei clienti (18.000 organizzazioni nel caso SolarWinds, oltre un milione nel caso ASUS).
2. Dormancy: il payload rimane inattivo per un periodo configurabile (giorni o settimane), separando temporalmente causa ed effetto e vanificando le sandbox e l’analisi comportamentale a breve termine.
3. C2 & Post-exploitation: attivazione della comunicazione command and control (tipicamente via DGA) e azione successiva, che può includere Golden SAML, DCSync e lateral movement con tool come Cobalt Strike.

Il punto cruciale è che l’attaccante opera su due infrastrutture distinte (quella del vendor e quella della vittima) usando set di tecniche differenti. La detection nelle fasi upstream dipende interamente dal vendor; nelle fasi downstream entra in gioco la difesa della vittima, con EDR, NDR, SIEM e behavioral analytics.

Evasion e dwell time: una relazione che dipende dall’obiettivo

Un secondo snodo metodologico riguarda la correlazione fra tecniche di evasion e dwell time (il tempo intercorso fra l’inizio dell’attacco e la sua rilevazione). La regola generale è semplice: più sofisticata è la tecnica di evasione, maggiore è il dwell time. Ma la relazione dipende in modo strutturale dall’obiettivo dell’attaccante.

Le campagne con obiettivo di espionage o pre-positioning hanno bisogno di persistere il più a lungo possibile e adottano tecniche di evasion molto raffinate, come il Living off the Land (Volt Typhoon, dwell time circa 30 mesi), il social engineering di lungo periodo nelle comunità open source (XZ Utils, 29 mesi) o l’iniezione direttamente nella build pipeline (SolarWinds, 14 mesi). Le campagne con finalità financial gain o destructive (NotPetya, dwell time inferiore a un giorno) accettano invece di lasciare rumore, perché l’obiettivo è massimizzare il danno prima del patching.

Perché i nation-state scelgono la supply chain: tre vantaggi strategici

Schifilliti ha sintetizzato in tre punti la convenienza che un threat actor nation-state trae dall’investire in operazioni supply chain.

Vantaggio operativo (rapporto sforzo/impatto). Invece di colpire n target uno alla volta, l’attaccante compromette un singolo vendor e da lì raggiunge potenzialmente migliaia di vittime downstream contemporaneamente. Il rapporto è invertito rispetto agli attacchi tradizionali: una sola azione, blast-radius globale.

Vantaggio strategico (selezione posticipata). L’attaccante non è obbligato ad avere le idee chiare sui target finali al momento della compromissione. Può distribuire ampiamente il payload e attivarlo solo successivamente, sui soli bersagli che diventano strategicamente rilevanti. Nel frattempo, il payload resta dormiente all’infinito. Un’organizzazione può quindi essere tecnicamente compromessa senza che l’attaccante abbia ancora deciso di agire: una posizione difensivamente peggiore di quella di chi è sotto attacco attivo, perché l’avversario ha tempo illimitato per osservare e scegliere il momento ottimale.

Vantaggio di attribuzione. La catena interpone una distanza significativa fra l’azione finale e l’attaccante: l’attribuzione diventa sensibilmente più complessa.

Quattro paradigmi a confronto: 3CX, SolarWinds, Volt Typhoon, XZ Utils

L’analisi comparativa delle quattro campagne scelte da Schifilliti restituisce quattro filosofie operative profondamente diverse, riconducibili a quattro threat actor distinti.

3CX (Lazarus / UNC4736, DPRK, marzo 2023)

È il primo caso pubblicamente documentato di doppia supply chain: il fornitore di software finanziario Trading Technologies viene compromesso per attaccare uno sviluppatore di 3CX, e tramite 3CX si raggiungono i clienti finali, con un focus selettivo sul settore crypto.

La catena è quindi a tre livelli: produttore originario, distributore intermedio, utilizzatore finale. La 3CXDesktopApp trojanizzata (v18.12.416 per Windows e macOS) è stata distribuita via canale di auto-update ufficiale a circa 600.000 organizzazioni e 12 milioni di utenti. Da notare la scelta del command and control: il dead drop di primo stadio era ospitato direttamente su GitHub, in file ICO che apparivano come immagini ma contenevano URL cifrati in AES-256-GCM steganografati nei metadati EXIF. La detection è avvenuta nel marzo 2023 grazie agli alert comportamentali dell’EDR di CrowdStrike, che ha rilevato come 3CXDesktopApp.exe eseguisse operazioni inusuali per un’applicazione VoIP. Dwell time stimato: circa 3 mesi.

SolarWinds / SUNBURST (APT29 / NOBELIUM, Russia, 2019-2020)

È il caso che ha definito il paradigma moderno della build pipeline injection. Il loader SUNSPOT, deployato sui build server di SolarWinds nel febbraio 2020, agiva intercettando MsBuild.exe durante la compilazione di Orion: sostituiva il sorgente con la versione contenente la backdoor SUNBURST, attendeva la fine della build e ripristinava il file originale.

Nessuna traccia nel repository Git. La DLL malevola veniva firmata legittimamente da SolarWinds Worldwide LLC e distribuita via update ufficiale a oltre 18.000 organizzazioni. L’OpSec post-distribuzione era altrettanto curata: dormancy randomizzata 12-14 giorni, C2 via DGA su avsvmcloud.com con geo-fencing, selezione manuale di circa 100 vittime high-value (agenzie governative USA, Microsoft, FireEye, CISA) per il post-sfruttamento.

Sulle vittime selezionate è stato eseguito un attacco Golden SAML tramite la chiave privata del certificato ADFS, che ha consentito di forgiare token SAML validi per qualsiasi utente del tenant, garantendo accesso a Microsoft 365 anche dopo il reset delle password. La detection è avvenuta nel dicembre 2020 per un caso fortuito: FireEye notò che qualcuno aveva registrato un secondo dispositivo MFA sull’account VPN di un dipendente, e contattando l’interessato scoprì che non era stato lui. Dwell time: circa 9 mesi.

Volt Typhoon (PLA, Cina, dal 2021)

Volt Typhoon ha alzato una nuova soglia di furtività. Il gruppo, attribuito alla PLA cinese, opera contro infrastrutture critiche statunitensi (energia, telecomunicazioni, acqua, trasporti) senza utilizzare alcun malware custom, alcun exploit zero-day e alcuna backdoor proprietaria.

Il modus operandi si fonda su due elementi: lo sfruttamento di exploit n-day su dispositivi di rete perimetrali poco patchati (router SOHO Cisco RV320/325, Fortinet, Netgear, ASUS, DrayTek) e la creazione di un’infrastruttura proxy decentralizzata, la KV-Botnet, che fa transitare il traffico C2 attraverso router compromessi sul territorio statunitense. All’interno della vittima, l’attività post-compromissione si basa esclusivamente su tecniche Living off the Land: wmic, netsh, ntdsutil, certutil, PsExec tramite Impacket.

Le azioni sono indistinguibili da quelle di un amministratore di sistema legittimo. Non esiste in Volt Typhoon una detection nel senso tradizionale: la disclosure di maggio 2023 da parte di Microsoft e CISA non è derivata da un alert tecnologico in una vittima, ma da un’indagine intelligence governativa proattiva avviata per cercare specificamente infrastrutture cinesi pre-posizionate. Sono stati i governi a notificare le vittime, non viceversa. Dwell time: fino a 5 anni.

XZ Utils (Jia Tan / JiaT75, attribuzione sconosciuta, 2021-2024)

Il caso XZ Utils ha aperto una dimensione inedita: la supply chain umana come superficie di attacco. L’attaccante, noto solo con lo handle Jia Tan (JiaT75), ha creato un account GitHub nell’ottobre 2021 e ha lavorato per oltre due anni come contributor legittimo di XZ Utils, accumulando oltre 546 commit autentici su molteplici progetti, traduzioni, manutenzione CI/CD. Ha partecipato a un’orchestrazione di sock puppet (Jigar Kumar, krygorin4545, Dennis Ens, misoeater91) che ha esercitato pressione sul maintainer originale Lasse Collin (in burnout) per ottenere privilegi di co-maintainer.

Nel dicembre 2022 il repository è stato trasferito sotto la sua organization GitHub. Tra il gennaio 2023 e il febbraio 2024 ha preparato l’iniezione: ha disabilitato la security feature Landlock di OSS-Fuzz, ha inserito macro M4 malevole che estraevano codice cifrato da file binari di test (.xz), e ha sfruttato il meccanismo IFUNC di glibc per sostituire a runtime la funzione RSA_public_decrypt di OpenSSH.

La backdoor attivava la Remote Code Execution pre-autenticazione come root solo per un attaccante in possesso di una specifica chiave privata Ed448 (non un exploit pubblico). Il targeting era estremamente selettivo: solo sistemi x86-64 con glibc, GCC, dpkg/rpm e systemd; in pratica le distro server enterprise Debian/Fedora. La detection è avvenuta per puro caso il 29 marzo 2024: Andres Freund, ingegnere Microsoft che lavora al progetto PostgreSQL, notò 500 millisecondi di latenza anomala nelle autenticazioni SSH sulla propria Debian Sid e decise di investigare invece di attribuire il fenomeno a rumore di sistema. La CVE-2024-3094 è stata assegnata con CVSS 10.0. Dwell time: circa 27 mesi.

La detection: quando avviene per caso

Il dato che attraversa i quattro casi è la fragilità dei meccanismi di rilevazione. In tre casi su quattro la detection non è avvenuta attraverso il proprio stack di sicurezza: SolarWinds è stato scoperto grazie a un secondo dispositivo MFA registrato per errore visibile; XZ Utils per una latenza di 500 ms su SSH notata da un singolo ingegnere; Volt Typhoon per un’indagine governativa proattiva, non per allerta interne alle vittime. Solo 3CX è stato individuato in tempo utile grazie agli alert comportamentali dell’EDR.

Questo dato sostiene una conclusione operativa: gli IOC tradizionali (hash, IP, domain) vengono neutralizzati entro ore dalla disclosure e hanno una shelf-life limitata. Il valore reale per chi difende risiede nella mappatura delle TTP stabili: pattern di DLL sideloading, dormancy strutturate, abuso del code signing, Living off the Land. La detection moderna richiede behavioral baseline per ambiente, UEBA e process ancestry, e l’estensione del threat modeling anche al monitoraggio dei maintainer OSS delle dipendenze critiche.

Targeted o volumetrico: entrambi, in fasi diverse

Una delle domande con cui Schifilliti ha chiuso l’analisi è se un attacco supply chain sia targeted o volumetrico. La risposta è doppia: entrambi, ma in fasi diverse. La distribuzione iniziale del payload è quasi sempre generalista (18.000 vittime SolarWinds, 600.000 vittime 3CX, oltre un milione ASUS); l’attivazione successiva è invece chirurgica, manuale, riservata a un sottoinsieme molto ristretto di target ad alto valore.

Questa separazione strutturale fra distribuzione ampia e attivazione mirata è la caratteristica che rende l’attacco alla supply chain la forma più sofisticata di minaccia latente del panorama contemporaneo: un’organizzazione può essere tecnicamente compromessa senza che l’attaccante abbia ancora deciso di fare nulla, in una posizione difensivamente peggiore di quella sotto attacco attivo, perché l’attivazione resta subordinata a una decisione (spesso geopolitica) che potrebbe non verificarsi mai, o verificarsi domani.

Mitigazione: la pipeline software e i framework di riferimento

La difesa, per essere efficace, va costruita lungo l’intera pipeline software (sorgente → CI/CD → build → artifact registry → delivery → target), e non solo sull’endpoint della vittima finale. Schifilliti ha richiamato i framework di riferimento oggi disponibili:

• SLSA (Supply-chain Levels for Software Artifacts), che definisce quattro livelli progressivi di resistenza alla manomissione, con requisiti su provenance firmata, build attestation, artifact signing e release gate;
• NIST SP 800-218 (SSDF), che codifica le pratiche del Secure Software Development Framework nelle quattro famiglie Prepare the Organization, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities;
• NIST SP 800-161r1 e i modelli CISA per il Cybersecurity Supply Chain Risk Management (C-SCRM), centrati su SBOM, attestazioni del fornitore e controlli di acquisizione contrattuali.

L’integrazione di questi framework copre porzioni complementari della pipeline: SLSA presidia build e artifact, SSDF presidia il processo di sviluppo, C-SCRM presidia la relazione di fiducia fra acquirente e vendor. Restano gap residui su identità OSS, doppia supply chain e hardware/firmware (TPM), che richiedono presidi specifici.

Tre proprietà strutturali, tre cambi di mindset

Il messaggio conclusivo dell’intervento si è articolato su tre proprietà strutturali della supply chain come superficie di attacco.

Fiducia compromessa. L’attaccante non forza un perimetro: si nasconde in un artefatto che l’organizzazione stessa installa e firma come legittimo. Il confine di fiducia è già attraversato prima che la vittima possa accorgersene.

Scalabilità dell’impatto. Un singolo punto di compromissione raggiunge migliaia di vittime downstream simultaneamente, senza necessità di exploit diretto.

Invisibilità strutturale. Il payload opera con le stesse credenziali, gli stessi privilegi e gli stessi percorsi di rete del software legittimo: non esiste un hash malevolo da bloccare, finché il comportamento post-esecuzione non devia dalla baseline.

Da qui il cambio di paradigma proposto: la detection non può più fondarsi sulla distinzione binaria fra entità trusted e untrusted, perché è proprio nella relazione di fiducia che si annida il vettore. Va invece adottato un modello di monitoraggio comportamentale che si applica a tutti i soggetti, inclusi quelli ritenuti affidabili, su tutta la pipeline. In altre parole: la difesa non è più una questione di perimetro, ma di osservazione continua del comportamento attraverso confini di fiducia che non sono più garantiti dall’identità del firmatario.