Avvelenamento della Pipeline CI/CD: Poisoned Pipeline Execution (T1677)

Un esercizio red team su T1677 parte dalla ricognizione della superficie CI/CD del target. Il primo passo è enumerare i workflow esposti nel repository, cercando trigger pericolosi. Su GitHub Actions il comando grep -r "pull_request_target" .github/workflows/ rivela immediatamente workflow potenzialmente vulnerabili. Il tool gato (open source, GitHub Actions Attack Toolkit di Praetorian) automatizza questa fase: analizza organizzazioni intere identificando repository con self-hosted runner e trigger sfruttabili.

Per la variante Public Pipeline Execution, la catena tipica consiste nel forkare il repository target, modificare uno script richiamato dal workflow (ad esempio un file di test JavaScript o un Makefile), e aprire una pull request. Se il workflow usa pull_request_target combinato con un checkout esplicito del ramo della PR, il codice del forkatore viene eseguito con accesso ai segreti del repository originale. Un payload minimale per esfiltrare i segreti si riduce a poche righe che leggono le variabili d'ambiente e le trasmettono a un endpoint controllato dall'attaccante tramite curl.

Per la Direct Pipeline Execution il presupposto è aver ottenuto credenziali di sviluppatore con permessi di push. Modificando gitlab-ci.yml o .github/workflows/build.yml si può aggiungere uno step che stampa in log codificati in base64 i valori di env — utile in laboratorio per dimostrare l'esfiltrazione via artifact download.

Strumenti utili in laboratorio includono Chain-bench (open source, di Aqua Security) per audit di supply chain conformi al framework CIS, Checkov (open source) e KICS (open source) per identificare misconfigurazioni nei workflow prima di sfruttarle, Legitify (open source, di Legit Security) per enumerare posture GitHub/GitLab. Per la simulazione di runner compromessi, Gitleaks (open source) rileva segreti hardcoded che possono essere spostati durante il post-exploitation.

Una catena d'attacco completa in ambiente lab prevede: (1) enumerazione workflow con gato, (2) identificazione di uno step che esegue codice utente (build npm, esecuzione test), (3) fork e submission di PR con payload nel file richiamato, (4) cattura dei segreti dal log della workflow run, (5) uso dei token GitHub esfiltrati per pivotare verso altri repository dell'organizzazione tramite l'API con curl -H "Authorization: token $TOKEN". Se il runner è self-hosted, il post-exploitation include reverse shell verso il segmento di rete interno, dimostrando l'impatto di lateral movement.

Tutte le attività vanno condotte esclusivamente su repository di proprietà o con autorizzazione scritta esplicita, preferibilmente in organizzazioni GitHub dedicate al testing.

La detection di Poisoned Pipeline Execution ruota attorno ai log delle piattaforme SaaS che ospitano le pipeline, come indicato nella strategy DET0533 e nell'analytic AN1473. Le fonti primarie sono gli audit log di GitHub, GitLab, Bitbucket e Azure DevOps: nello specifico gli eventi workflow_run, workflow_job, PullRequestEvent e i metadata delle PR.

Il primo indicatore comportamentale è l'esecuzione di workflow innescati da fork esterni con trigger sensibili. Un alert efficace correla eventi in cui il campo event è pull_request_target con head.repo.fork = true e con un delta temporale molto ridotto tra creazione della PR ed esecuzione del workflow — pattern tipico di attacco automatizzato. La finestra temporale suggerita è configurabile in base al baseline dell'organizzazione, ma anomalie sotto i 60 secondi meritano triage prioritario.

Un secondo segnale è l'accesso anomalo ai segreti durante una singola workflow run. Il tuning include soglie sul numero di segreti referenziati e sulla frequenza di chiamate all'API di secret management. Correlare questi eventi con connessioni di rete uscenti verso destinazioni non incluse nella baseline (in particolare pastebin, servizi di webhook come webhook.site o requestbin, IP di VPS commerciali) fornisce alta fedeltà.

L'entropia degli artefatti generati dalle workflow run è un indicatore utile: payload esfiltrati vengono spesso codificati in base64 o compressi, elevando l'entropia rispetto ai normali build artifact (log testuali, binari compilati). Uno script batch che calcola l'entropia di Shannon sui file scaricati dall'API artifacts di GitHub, integrato in un SIEM, permette di flaggare valori superiori a 7.0 su file di piccole dimensioni.

Dal punto di vista della prevenzione (mitigazioni M1054 e M1018), i controlli SOC dovrebbero verificare periodicamente: assenza di pull_request_target in combinazione con checkout esplicito del ref della PR, disabilitazione dei self-hosted runner sui repository pubblici, applicazione del principio del privilegio minimo ai token generati da GITHUB_TOKEN, presenza di required reviewers per approvare workflow provenienti da first-time contributor.

Tool utili per la detection includono Falco (open source, con plugin GitHub) per streaming degli audit log, Panther (freemium) e Wiz (a pagamento) per detection cloud-native, Legitify (open source) per posture assessment continuo. Su GitHub Enterprise, l'esportazione degli audit log verso Splunk o Elastic tramite l'API audit-log/stream consente ricerche retrospettive.

I falsi positivi frequenti includono workflow legittimi che processano PR da contributor esterni in progetti open source, build automatizzati da bot Dependabot o Renovate, e pipeline di integration testing che deliberatamente accedono a molti segreti. Una whitelist basata su identità del bot e su repository specifici riduce il rumore.

L'analisi forense di un incidente T1677 si sviluppa su due piani paralleli: la ricostruzione dell'attività nella piattaforma SaaS e l'analisi degli host dei runner, soprattutto quando self-hosted.

Sul lato SaaS, la fonte primaria è l'audit log della piattaforma. Su GitHub, l'API GET /orgs/{org}/audit-log espone eventi persistenti per 180 giorni (Enterprise Cloud) contenenti workflow_run_created, workflow_run_completed, pull_request_opened con attore, timestamp, repository, ref, e ID della run. Correlando gli ID workflow run è possibile ricostruire la sequenza esatta: apertura PR dal fork, trigger del workflow, download degli artifact. Il download degli artifact stessi rimane disponibile per 90 giorni di default e può contenere il payload esfiltrato o log di esecuzione.

Elementi chiave della timeline includono: (1) timestamp di creazione dell'account attaccante o del fork, (2) timestamp di push del commit malevolo nel branch della PR, (3) ora di apertura della PR, (4) start ed end del workflow job, (5) chiamate API successive con i token esfiltrati. Su GitLab l'equivalente sono gli audit_events e la tabella ci_pipelines accessibile via API amministrativa.

Quando il runner è self-hosted, gli artefatti classici da acquisire sul filesystem sono la directory _work del runner (contiene checkout del codice della PR malevola), i log in _diag che registrano ogni step eseguito, e la configurazione in .runner e .credentials. Su Linux, il journal di systemd per l'unità del runner (journalctl -u actions.runner..service*) preserva stdout completo delle esecuzioni. Su Windows, gli eventi in Microsoft-Windows-PowerShell/Operational e Sysmon EventCode 1 (Process Creation) permettono di ricostruire i processi lanciati dal runner con parent chain risalente al servizio del runner stesso.

Se è stato distribuito un secondo stadio sul runner (reverse shell, miner, tool di lateral movement), gli artefatti includono connessioni di rete anomale rilevabili in Sysmon EventCode 3 o nei log auditd Linux con syscall connect, file creati nella directory temporanea, e persistenza tramite cron job o servizi. Il tool Velociraptor (open source) è particolarmente adatto per triage remoto di flotte di runner grazie alle sue artifact definitions estensibili.

Per l'analisi del payload malevolo, il commit stesso rimane preservato nel database Git anche dopo la chiusura o cancellazione della PR: il comando git fetch origin pull/ID/head recupera i ref della PR, e git log --all --full-history permette di trovare oggetti orfani. Sul lato downstream, se la compromissione si è propagata a package pubblicati, l'analisi va estesa ai registry (npm, PyPI, Maven Central) tramite hash dei tarball. Tool come OSV-Scanner (open source, di Google) aiutano a correlare versioni compromesse con dipendenze downstream.

Il framework MITRE ATT&CK non associa attualmente gruppi APT, software o campagne specifiche a T1677. Questa assenza formale non riflette però la rilevanza reale del vettore CI/CD, che nella pratica documentata da vendor di threat intelligence rappresenta una delle superfici più bersagliate degli ultimi anni, in particolare per attacchi di tipo supply chain.

Dal punto di vista della postura strategica, un TI officer deve considerare T1677 come un moltiplicatore di impatto piuttosto che come tecnica standalone. Un attaccante che ottiene esecuzione in una pipeline non compromette un singolo sistema: acquisisce potenzialmente il controllo su ogni artefatto che quella pipeline produce, con effetti a cascata su clienti, partner e utenti finali. Questa asimmetria — sforzo contenuto e impatto elevato — spiega perché la tecnica sia particolarmente attraente per attori sia state-sponsored sia motivati finanziariamente.

I pattern di targeting osservabili nell'ecosistema suggeriscono tre categorie preferite di vittima: organizzazioni che pubblicano librerie open source ampiamente adottate (target di supply chain compromise verso downstream), aziende SaaS con pipeline che deployano direttamente in produzione (target di sabotaggio o esfiltrazione dati), e fornitori di software enterprise con clientela ad alto valore (target di intrusione a doppio salto). La geografia dei bersagli riflette la concentrazione dell'industria software: Nord America ed Europa occidentale rappresentano la maggior parte dei casi pubblicati.

Sul piano del tool overlap, gli attori che sfruttano T1677 tendono a convergere su strumenti open source di ricognizione come gato, Legitify o script custom in Python che interrogano l'API GitHub. La fase di post-exploitation vede spesso il riutilizzo di tecniche consolidate: esfiltrazione tramite servizi legittimi (Discord webhook, Telegram bot API, GitHub Gist stessi) per bypassare controlli di egress filtering che permettono queste destinazioni.

Le due mitigazioni ATT&CK — M1018 (User Account Management) e M1054 (Software Configuration) — sintetizzano l'approccio difensivo: limitare permessi dei token pipeline al minimo necessario, restringere il numero di utenti con write access ai repository interni, evitare pull_request_target dove possibile, non trattare input controllati dall'utente (come nomi di branch) come trusted, e non usare self-hosted runner su repository pubblici.

Il trend osservabile nella comunità difensiva è la crescente adozione di framework come SLSA (Supply-chain Levels for Software Artifacts) e di soluzioni di provenance signing basate su Sigstore. Per un TI officer, il monitoraggio delle campagne dovrebbe includere sorveglianza su repository package pubblici alla ricerca di typosquatting e dependency confusion, che spesso precedono o accompagnano l'avvelenamento di pipeline downstream. La collaborazione con team AppSec e DevSecOps interni è essenziale per tradurre l'intelligence in requisiti concreti di hardening.

MITRE ATT&CK: T1677 (Poisoned Pipeline Execution), tattica TA0002. Mitigazioni M1018, M1054. Detection strategy DET0533 con analytic AN1473 su fonti saas:github, saas:RepoEvents, saas:PRMetadata. MITRE D3FEND per mapping artefatti difensivi. Il contenuto tecnico su comandi, tool (gato, Legitify, Checkov, KICS, Chain-bench, Gitleaks, Velociraptor, OSV-Scanner, Falco) e procedure operative si basa su conoscenza professionale di cybersecurity con tool verificabili tramite repository pubblici e documentazione ufficiale.