Repository di Codice: Code Repositories (T1213.003)

In un ingaggio di red teaming, la fase di raccolta da repository di codice interni si articola in tre momenti: accesso, enumerazione e harvesting dei segreti. L'accesso presuppone credenziali valide o un token — spesso ottenuto via phishing, session hijacking o abuso di OAuth app con scope eccessivi (pattern osservato in operazioni LAPSUS$).

Una volta dentro un tenant GitHub Enterprise o GitLab self-hosted, l'enumerazione inizia dall'API. Con un Personal Access Token si può elencare i repository accessibili tramite gh repo list --limit 1000 --json name,visibility,url usando la GitHub CLI (open source), oppure interrogare direttamente l'endpoint REST con curl -H "Authorization: token $TOKEN" ... verso il path user/repos. Per GitLab, l'equivalente è il comando glab repo list (open source) o l'API projects.

Il clone massivo è il passo successivo. Uno script bash che itera git clone --mirror su ogni URL è sufficiente: l'opzione --mirror è cruciale perché scarica anche i branch remoti e la reflog, dove spesso vivono commit "rimossi" contenenti segreti. APT41, secondo la documentazione MITRE, ha clonato repository Git delle vittime esattamente con questa logica.

Per l'harvesting delle credenziali su repository clonati localmente, gli strumenti di riferimento sono:

• TruffleHog (open source, versione enterprise a pagamento) — scansiona la storia Git con detector specifici per AWS, GCP, Slack, Stripe e centinaia di altri servizi. Sintassi tipica: trufflehog git file://./repo --only-verified, dove il flag --only-verified riduce drasticamente i falsi positivi validando i token contro le API reali.
• Gitleaks (open source) — più leggero, orientato a integrazione CI/CD: gitleaks detect --source . --report-format json --report-path leaks.json.
• noseyparker (open source) — molto rapido su repository di grandi dimensioni grazie al motore di scansione basato su Hyperscan.

Oltre alle credenziali, in un red team si cercano file di configurazione IaC (Terraform state, Ansible vault, Helm values), notebook Jupyter con connessioni a data warehouse, e workflow YAML di GitHub Actions che referenziano segreti di ambiente. La history dei workflow, accessibile via gh run list, spesso rivela nomi di ambienti di produzione e naming convention utili per movimento laterale.

Un pattern documentato per Scattered Spider è l'enumerazione mirata di repository interni per identificare credenziali ad alto privilegio: in laboratorio si simula creando un tenant GitHub Enterprise di test con seeding controllato di segreti fittizi, così da validare le catene di detection senza rischi.

La detection di T1213.003 ha un baricentro chiaramente SaaS: la maggior parte dell'attività lascia traccia nei log di audit di GitHub, GitLab o della piattaforma equivalente, non sull'endpoint. Il rilevamento DET0263 del framework MITRE si concentra proprio su accessi bulk o anomali a repository privati e definisce come sorgente primaria saas:github.

Gli eventi da monitorare nel log di audit GitHub sono principalmente git.clone, git.fetch, repo.download_zip e repo.access. Su GitLab, l'equivalente si trova negli audit events con action type repository_download_operation. Un pattern ad alto valore è la correlazione tra un login OAuth da geolocalizzazione anomala e un burst di clone entro pochi minuti: soglia utile secondo il tuning suggerito è 10 o più repository clonati in meno di 5 minuti dallo stesso attore.

Gli indicatori comportamentali da alertare sono:

• Account non-developer (HR, sales, manager) che accede a repository taggati come sensibili
• Uso di Personal Access Token appena creati per clone di repository ad alta criticità
• Nuove OAuth App autorizzate con scope repo completo su account privilegiati
• Attivazione di SSH key non registrate precedentemente sull'account
• Chiamate API con User-Agent non standard (es. git/2.x da IP residenziali) verso endpoint api.github.com

Sul fronte preventivo, le mitigazioni M1032 (MFA) e M1018 (User Account Management) sono i controlli cardine: forzare MFA hardware-based per l'accesso ai repository e applicare il principio del minimo privilegio, limitando i permessi admin e maintainer a un numero ristretto di identità. M1047 (Audit) raccomanda scansioni periodiche dei repository per credenziali esposte — integrabili nella pipeline con push protection nativa di GitHub Advanced Security (a pagamento) o con hook Gitleaks (open source) lato server.

I falsi positivi più frequenti derivano da tre scenari: onboarding di nuovi sviluppatori (che clonano molti repository in blocco), attività di CI/CD runner self-hosted che agiscono con service account e possono mascherare comportamenti bulk, e attività di backup automatico o mirror verso registry secondari. Il tuning corretto passa per allow-list di service account noti e per la segmentazione degli alert per repository sensitivity tag: solo i repository classificati come restricted devono generare alert ad alta priorità.

Una dashboard SIEM efficace correla in una singola pivot: identità, geolocalizzazione IP, volume di API call, sensibilità del repository e presenza di token o SSH key create nelle ultime 24 ore. Su splunk o Sentinel, la query si costruisce sull'audit stream GitHub esportato via webhook o via Audit Log API.

L'analisi forense per T1213.003 vive prevalentemente nel dominio SaaS, ma lascia tracce anche sugli endpoint da cui l'attaccante ha operato. La timeline si ricostruisce partendo da tre fonti primarie: audit log della piattaforma di code hosting, artefatti Git locali sulla workstation compromessa, e log di rete o proxy che documentano la sessione HTTPS.

Sul lato piattaforma, l'audit log di GitHub (esportabile dall'organization owner) contiene per ogni evento il timestamp UTC, l'attore, l'IP sorgente, lo User-Agent e il repository target. Gli eventi chiave per T1213.003 sono git.clone (clone completo), repo.download_zip (export archiviato) e pull_request.opened o issue_comment.created quando l'attaccante interagisce per esfiltrare informazioni via commenti. Su GitLab il file di riferimento è audit_events.log, mentre per installazioni self-hosted vanno raccolti anche i log Nginx frontend e i log applicativi Rails.

Sull'endpoint sospetto — la workstation dello sviluppatore compromesso o il jump server dell'attaccante — gli artefatti da preservare sono:

• Il file ~/.gitconfig (Linux/macOS) o %USERPROFILE%.gitconfig (Windows), che rivela identità utente configurate
• La directory ~/.ssh/ con known_hosts aggiornati (evidenzia il primo contatto con l'host Git) e chiavi private eventualmente aggiunte
• Il file ~/.git-credentials o le entry del Windows Credential Manager / macOS Keychain per token cached
• La reflog e la history dei repository clonati: git reflog e i file sotto .git/logs/ documentano operazioni locali con timestamp
• Su Windows, l'Amcache.hve e le ShimCache registrano l'esecuzione di git.exe; su Linux il bash_history e il journal di systemd catturano i comandi

Per la campagna C0024 SolarWinds Compromise, la documentazione MITRE indica che APT29 ha scaricato codice sorgente da repository interni delle vittime. La ricostruzione forense in quel contesto ha richiesto la correlazione tra token OAuth abusati, sessioni originate da infrastruttura di residential proxy e artefatti sui build server SolarWinds. Il pattern comune è la persistenza silenziosa tramite token a lunga scadenza, il che rende essenziale controllare la tabella dei Personal Access Token e delle OAuth App autorizzate al momento dell'incident response.

Per la timeline temporale, è utile incrociare i timestamp Git (author date e committer date dei commit generati dall'attaccante, se ha fatto push) con gli eventi audit e con i log del provider di identità (Okta, Azure AD) relativi ai login MFA. Le discrepanze tra fuso orario dichiarato del commit e IP di origine sono spesso il primo indicatore di attività ostile.

La preservazione va estesa ai fork creati dall'attaccante: APT41 ha utilizzato il clone come vettore primario, ma altri attori creano fork privati per esfiltrazione lenta e a bassa visibilità.

Il panorama degli attori che sfruttano T1213.003 è compatto ma eterogeneo per motivazione e maturità operativa. Tre gruppi risultano documentati nel framework MITRE, coprendo lo spettro dal cybercrime finanziariamente motivato all'espionaggio statuale.

APT41 (G0096) è un gruppo di nexus cinese noto per operazioni ibride tra spionaggio e cybercrime. La documentazione MITRE evidenzia come APT41 abbia clonato repository Git delle vittime durante le intrusioni, comportamento coerente con la doppia natura del gruppo: il codice sorgente serve sia a sviluppare exploit mirati per successive campagne sia a monetizzare tramite furto di proprietà intellettuale. Il target preferenziale include settori tecnologici, videogame, sanità e telecomunicazioni.

LAPSUS$ (G1004) rappresenta un profilo radicalmente diverso: gruppo prevalentemente giovane, motivato da notorietà e denaro, con tecniche relativamente semplici ma efficaci. LAPSUS$ effettua ricerche mirate all'interno delle reti compromesse per identificare istanze GitLab e GitHub interne, con l'obiettivo esplicito di scoprire credenziali ad alto privilegio committate nel codice. Il modus operandi sfrutta social engineering aggressivo verso helpdesk e SIM swap per bypassare MFA, per poi capitalizzare l'accesso attraverso l'harvesting di segreti nei repository.

Scattered Spider (G1015), noto anche per il targeting di piattaforme cloud e SaaS, enumera sistematicamente i dati contenuti in repository interni — in particolare istanze GitHub aziendali. Il gruppo è finanziariamente motivato, spesso operativo come broker di accesso per gruppi ransomware come BlackCat/ALPHV, e utilizza il codice sorgente come mappa dell'infrastruttura target: identificando endpoint API interni, naming convention di risorse cloud e workflow CI/CD, riesce a pianificare movimento laterale mirato.

La campagna C0024 SolarWinds Compromise (agosto 2019 – gennaio 2021), attribuita al servizio di intelligence estera russo SVR tramite APT29 (Cozy Bear, The Dukes), rappresenta il caso di studio più significativo. APT29 ha scaricato codice sorgente da repository interni delle vittime nel contesto di un'operazione di supply chain che ha compromesso il processo di build di SolarWinds Orion. L'accesso al codice ha permesso non solo di iniettare il backdoor ma anche di comprendere in profondità le contromisure di sicurezza dei clienti downstream, rendendo l'attività estremamente difficile da rilevare per mesi.

Il trend osservabile aggrega motivazioni molto diverse — spionaggio, cybercrime opportunistico, hacktivism — attorno a un vettore comune: il repository di codice come magazzino di credenziali e knowledge base infrastrutturale. Il pattern di overlap tra gruppi è quindi funzionale più che tecnologico: tutti convergono sulle stesse piattaforme SaaS (GitHub in primis) perché è lì che le organizzazioni concentrano progressivamente il proprio patrimonio digitale.

MITRE ATT&CK T1213.003 (Code Repositories), tattica TA0009. Gruppi: G0096 (APT41), G1004 (LAPSUS$), G1015 (Scattered Spider). Campagna C0024 (SolarWinds Compromise). Mitigazioni M1017, M1018, M1032, M1047. Detection DET0263 con analytic AN0732 su log saas:github. Parti delle sezioni operative integrano conoscenza professionale verificata su tool open source (TruffleHog, Gitleaks, noseyparker, GitHub CLI, GitLab CLI) e su artefatti forensi standard di ambienti Git.