Esfiltrazione su Repository di Codice: Exfiltration to Code Repository (T1567.001)

In un ingaggio red team, l'esfiltrazione verso code repository si costruisce in tre fasi: preparazione dell'account di destinazione, staging locale dei dati, upload via HTTPS. La superficie è ampia e va simulata su tutti i sistemi operativi target.

Su Windows, il vettore più realistico usa PowerShell con l'API REST di GitHub. Dopo aver generato un Personal Access Token dedicato all'esercizio, il flusso tipico prevede staging con Compress-Archive -Path C:\Users\victim\Documents* -DestinationPath $env:TEMP\loot.zip, seguito da encoding Base64 e chiamata a Invoke-RestMethod con metodo PUT verso l'endpoint contents dell'API. Empire (S0363) (open source) integra nativamente moduli per usare GitHub come canale di esfiltrazione, ed è il riferimento pubblico per riprodurre questa TTP in laboratorio. Sul framework moderno Starkiller (open source), il modulo equivalente è disponibile nel modulo di exfiltration.

Su Linux, il pattern è più snello. La sequenza classica è tar czf /tmp/loot.tar.gz /home/user/sensitive/ seguita da git init, git remote add verso il repository controllato e git push. In alternativa, un one-liner con curl (open source) verso l'API contents di GitHub, con il payload codificato via base64 -w0, evita di lasciare tracce di configurazione git. Per staging opachi si può usare age (open source) per cifrare il tarball prima dell'upload.

Su macOS, lo scenario più credibile è un payload consegnato via documento Office con macro o AppleScript che lancia curl verso api.github.com. La particolarità è che l'applicazione parent (Word, Excel) genera traffico verso un dominio developer-oriented — anomalia utile in fase di detection ma anche in fase di simulazione per validare la telemetria.

Su ESXi, la superficie è ridotta ma esiste: dopo compromissione dell'host, un attaccante può usare la shell BusyBox e wget o curl per pushare dump da datastore verso repository esterni. Per il red team è utile dimostrare che il traffico egress dagli host di virtualizzazione, spesso non filtrato, consente questo abuso.

Strumenti utili in laboratorio includono Gitjacker (open source) per esplorare repository esposti, truffleHog (open source) per validare cosa emerge dal push, e Sliver (open source) come C2 moderno che supporta trasporti custom simulabili come exfil channel. Tutte le prove vanno condotte su account e repository dedicati all'ingaggio, mai su infrastrutture di produzione.

La detection di T1567.001 richiede di distinguere il traffico legittimo di sviluppo dall'abuso malevolo, senza generare tempeste di falsi positivi negli ambienti dove GitHub è uno strumento quotidiano. La chiave è la correlazione multi-segnale, non il blocco cieco del dominio.

Su Windows, la telemetria di riferimento è Sysmon (open source) con configurazione derivata dal template di SwiftOnSecurity o Olaf Hartong. Gli eventi cardine sono EventID 1 (process creation) e EventID 3 (network connection). L'alert base incrocia processi non-developer — powershell.exe, cmd.exe, wscript.exe, mshta.exe, binari da %TEMP% o %APPDATA% — che aprono connessioni verso api.github.com, api.gitlab.com, api.bitbucket.org o raw.githubusercontent.com. Un secondo layer correla EventID 11 (file create) di archivi .zip/.7z/.rar in directory temporanee con connessioni successive verso quegli endpoint nella stessa sessione utente entro pochi minuti.

Su Linux, auditd con regole su execve per git, curl, wget e python3 permette di catturare la catena tar → push. La telemetria di rete via Zeek (open source) o Suricata (open source) fornisce il campo SNI TLS che, pur non decifrando il payload, consente di misurare volumi outbound verso repository domain e attivare soglie. Un pattern ad alto valore è il rapporto outbound/inbound bytes superiore a 10:1 su sessioni HTTPS verso repository API — coerente con push massivi di dati, incoerente con clone o pull normali.

Su macOS, lo Unified Log (comando log stream / log show) permette di filtrare eventi di rete correlati a processi non-developer. La regola ad alto segnale è: applicazione Office o Preview che apre connessioni verso github.com, con volume outbound significativo. Il tuning richiede una whitelist degli IDE effettivamente in uso (VS Code, JetBrains, Xcode).

Su ESXi, i log hostd e vmkernel mostrano sessioni HTTPS iniziate dai processi vmx o hostd verso domini esterni: un host di virtualizzazione non dovrebbe mai parlare con api.github.com, e la baseline è così stretta che anche una singola connessione merita triage.

Lato prevenzione, la mitigazione M1021 si concretizza con proxy web (Zscaler, Netskope, Squid con SSL bump — mix commerciale e open source) che applicano policy differenziate: sviluppatori possono raggiungere repository API, gli altri ruoli no. DNS filtering con Pi-hole (open source) o servizi come Cloudflare Gateway (freemium) blocca a livello risoluzione. I falsi positivi tipici includono pipeline CI/CD, backup di configurazioni verso repository interni e sync di dotfiles.

L'analisi forense di un'esfiltrazione verso code repository ricostruisce due catene parallele: la preparazione del pacchetto sul sistema compromesso e il canale di trasporto verso l'esterno. Gli artefatti sono ricchi ma vanno raccolti in fretta perché molti sono volatili o soggetti a rotazione.

Su Windows, i punti di partenza sono i Prefetch in *C:\Windows\Prefetch* per attestare l'esecuzione di powershell.exe, git.exe, curl.exe. Il ShimCache e Amcache.hve confermano la presenza storica di binari git portable eventualmente droppati dall'attaccante. I log PowerShell Operational (Microsoft-Windows-PowerShell/Operational, EventID 4104) contengono lo script block della logica di esfiltrazione, spesso con URL API e token in chiaro se non offuscati. La console history in %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt è una miniera. Sul file system, cerca archivi anomali in %TEMP%, %APPDATA%\Local\Temp e nella recycle bin dell'utente. Se git è stato usato, la directory .git nascosta contiene config con l'URL remoto — spesso l'unico puntatore diretto all'account attaccante — e logs/HEAD con timeline dei commit.

Su Linux, auditd in auditd.log fornisce esecuzioni con timestamp precisi. La ~/.bash_history (o zsh_history) mostra la sequenza di comandi; se cancellata, i file aperti da shell attive possono essere recuperati con lsof nel triage live. Il file ~/.gitconfig rivela username e email configurati per i commit, spesso lasciati come default dall'attaccante frettoloso. In /var/log/audit/ le syscall connect e sendto verso IP di GitHub (range documentati nel meta endpoint) delimitano la finestra temporale.

Su macOS, l'Unified Log conserva eventi di rete per periodi variabili; il comando log show --predicate filtrato per processo e finestra temporale ricostruisce le connessioni. I file .DS_Store nelle directory di staging e le entry in ~/Library/Preferences/com.apple.recentitems.plist aiutano a mappare cosa è stato toccato prima dell'upload. FSEvents in /.fseventsd/ documenta modifiche al file system utili per la timeline.

Su ESXi, i log /var/log/hostd.log e /var/log/shell.log registrano comandi eseguiti in shell e attività dell'agent; qualsiasi curl o wget qui è per definizione sospetto.

La timeline consolidata si costruisce con Plaso/log2timeline (open source), incrociando prefetch, event log, filesystem MFT e log di rete. Lato threat intel di supporto, se il repository di destinazione è ancora accessibile, l'API pubblica di GitHub consente di enumerare timestamp dei commit, che vanno confrontati con la timeline endpoint per confermare l'attribuzione dell'azione. Empire (S0363) lascia artefatti caratteristici nei nomi di modulo caricati in memoria, rilevabili con memory forensics via Volatility 3 (open source).

Il dataset MITRE per T1567.001 riporta un unico software mappato, Empire (S0363), e nessun gruppo APT associato in modo esplicito. Questa scarsità di attribuzione formale non riflette la rarità della tecnica — che è invece diffusa — ma la difficoltà di attribuirla con evidenza pubblica: quando l'esfiltrazione avviene su repository privati, la telemetria resta interna alle vittime e raramente entra in report open source.

Empire è un post-exploitation framework nato in ambito red team e successivamente adottato in operazioni malevole. La sua funzione di esfiltrazione via GitHub sfrutta la Contents API per fare commit di dati codificati Base64 come file testuali dentro repository controllati dall'operatore. La caratteristica interessante è la doppia natura: strumento legittimo per esercizi offensivi e, allo stesso tempo, componente osservato in intrusioni reali. Nel panorama attuale, Empire è mantenuto dal progetto BC-Security come fork attivo, e il suo codice è la miglior fonte pubblica per capire l'implementazione concreta di questa TTP.

Il pattern strategico che rende T1567.001 attraente è la fiducia implicita che le organizzazioni ripongono nei domini di code hosting. Nella maggior parte dei perimetri, github.com e gitlab.com sono categorizzati come business-critical e whitelistati sui proxy. Questo trasforma il canale in un'autostrada per l'esfiltrazione, particolarmente efficace quando l'azienda ospita team di sviluppo che generano rumore di fondo indistinguibile.

Un secondo pattern è l'abuso di Personal Access Token e Deploy Key rubati durante fasi precedenti dell'intrusione. Credenziali GitHub ottenute da password manager compromessi, dumps LSASS o repository locali configurati permettono all'attaccante di autenticarsi legittimamente, evitando anche i controlli comportamentali di GitHub stesso su login anomali. La detection di questa variante richiede audit lato GitHub Enterprise, non solo lato endpoint.

Un terzo trend riguarda l'uso di Gist e snippet GitLab come drop point per esfiltrazioni piccole ma sensibili (credenziali, chiavi, configurazioni). L'API dei Gist consente creazione anonima o autenticata di frammenti che, se resi pubblici o privati con URL non enumerabile, funzionano da dead drop.

Dal punto di vista della priorità di threat modeling, T1567.001 va considerata alta per organizzazioni con proprietà intellettuale digitale, codice proprietario o dati regolamentati, e per ambienti dove esiste un ecosistema developer maturo. La difesa richiede una policy differenziata per ruolo, audit degli account developer, monitoraggio dei repository esterni che citano l'organizzazione (usando GitHub Secret Scanning freemium o truffleHog open source su feed pubblici), e integrazione tra telemetria endpoint e log dei proxy web per correlare staging locale e upload esterno.

MITRE ATT&CK: T1567.001 (Exfiltration to Code Repository), tattica TA0010, software S0363 (Empire), mitigazione M1021 (Restrict Web-Based Content), detection strategy DET0318 con analytics AN0895–AN0898. MITRE D3FEND per mapping difensivo delle tecniche di outbound traffic filtering e network traffic analysis.

Parti di questo documento — comandi operativi, riferimenti a tool di detection e forensica, dettagli implementativi — derivano da conoscenza professionale consolidata di cybersecurity, non da dati MITRE, e sono verificabili tramite documentazione ufficiale dei singoli tool citati.