Saccheggiare i Repository di Codice: Data from Information Repositories – Code Repositories (T1213.003)

Quando un avversario ottiene un punto d'appoggio nella rete di un'organizzazione, una delle prime mosse ad alto rendimento è esplorare i repository di codice interni. La tecnica T1213.003 descrive proprio questo scenario: l'attaccante accede a piattaforme come GitHub Enterprise, GitLab self-hosted, Bitbucket Server o analoghe, per raccogliere codice sorgente proprietario, credenziali hard-coded, token API, chiavi SSH e qualunque altro segreto sepolto nei commit.

Questa tecnica si colloca nella fase di Collection (TA0009), il momento in cui l'attaccante ha già compromesso account o segmenti di rete e passa a raccogliere dati di valore strategico. Il bottino è duplice: da un lato il codice sorgente fornisce la mappa logica dell'applicazione — superfici d'attacco, vulnerabilità, dipendenze — dall'altro le credenziali scoperte nei file di configurazione o nella cronologia dei commit aprono porte laterali attraverso Valid Accounts.

L'impatto operativo è rilevante. Dai dati disponibili, 3 gruppi APT documentati sfruttano questa tecnica, 1 campagna di alto profilo (la SolarWinds Compromise, C0024) la include nel proprio playbook, e il framework difensivo prevede 4 mitigazioni dedicate. Il fatto che gruppi con motivazioni e sponsor diversi convergano tutti sui repository di codice conferma che si tratta di un bersaglio universale: chi controlla il codice, controlla il prodotto.

La simulazione di questa tecnica in un esercizio red team si articola in tre fasi: scoperta dei repository, estrazione massiva e ricerca di segreti. L'obiettivo è dimostrare al cliente quanto sia semplice, una volta ottenuto un account valido, saccheggiare l'intero patrimonio software.

Fase 1 — Enumerazione dei repository. Dopo aver compromesso un account con accesso alla piattaforma Git interna, il primo passo è mappare tutti i repository visibili. Su GitHub Enterprise si sfrutta l'API REST autenticata:

curl -s -H "Authorization: token <PAT>" "/orgs//repos?per_page=100" | jq '.[].clone_url'

Su GitLab self-hosted il comando equivalente usa l'API v4:

curl -s --header "PRIVATE-TOKEN: " "/projects?membership=true&per_page=100" | jq '.[].ssh_url_to_repo'

Questi comandi restituiscono l'elenco completo dei repository a cui l'account ha accesso, compresi quelli privati. La paginazione va gestita iterando sui parametri page per coprire organizzazioni con centinaia di repository.

Fase 2 — Clonazione massiva. Una volta ottenuta la lista, uno script Bash può clonare tutti i repository in parallelo. Un approccio minimal:

for repo in $(cat repo_list.txt); do git clone "$repo" & done

Per operazioni più controllate, il tool ghorg (open source) consente di clonare un'intera organizzazione GitHub o GitLab con un singolo comando:

ghorg clone --token <PAT> --scm github

Fase 3 — Ricerca di segreti. Qui entra in gioco il vero valore dell'operazione. TruffleHog (open source) scansiona l'intera cronologia dei commit alla ricerca di credenziali, token e chiavi:

trufflehog git file:// --only-verified

Il flag --only-verified tenta la validazione attiva delle credenziali trovate, restituendo solo quelle effettivamente funzionanti. In alternativa, Gitleaks (open source) offre un'analisi rapida con regole personalizzabili:

gitleaks detect --source --report-format json --report-path findings.json

Un aspetto spesso trascurato è la scansione dei file di configurazione CI/CD — pipeline YAML di GitHub Actions, GitLab CI o Jenkins — che frequentemente contengono variabili d'ambiente con credenziali in chiaro o riferimenti a vault mal configurati.

Per il report, documentate il numero di repository accessibili, il volume di codice scaricabile e la quantità di segreti validi trovati. Queste metriche sono estremamente efficaci nel comunicare il rischio al management.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo