Cosa riferisce Microsoft
Microsoft Threat Intelligence ha pubblicato il rapporto il 5 novembre 2026. Secondo l’azienda, attori malevoli hanno usato un framework agentico per cercare credenziali esposte in repository GitHub pubblici, comprese chiavi applicative e chiavi per l’inferenza AI, quindi analizzare i risultati e avviare attività successive. Microsoft descrive almeno un caso in cui un agente è passato dalla scansione dei repository all’esfiltrazione di dati da Azure Key Vault in cinque minuti. Si tratta del resoconto di incidenti di Microsoft; CherTra News non ha verificato indipendentemente i casi.
Microsoft riferisce inoltre accessi riusciti tramite service principal per alcuni clienti dal 28 ottobre e attività successive di ricognizione delle risorse cloud e accesso a Key Vault e Storage. Alcune credenziali compromesse, secondo il rapporto, provenivano da un’applicazione multitenant di un fornitore, con possibile esposizione a valle tra i clienti. Non significa che ogni segreto pubblico venga automaticamente sfruttato, ma mostra perché cancellare una stringa dal repository non basta.
Una credenziale individuata va considerata compromessa
Se una credenziale compare in codice pubblico, bisogna presumere che possa essere stata copiata anche se il repository è stato reso privato o il commit riscritto rapidamente. Prima si revoca o disabilita la credenziale esposta, poi se ne genera una sostitutiva tramite la procedura approvata del provider. Si aggiornano in sicurezza i servizi dipendenti, si conferma che la vecchia credenziale non funzioni più e si controllano i log per usi in orari, aree, identità o risorse insoliti.
Occorre identificare le autorizzazioni associate e verificare se la credenziale è stata riutilizzata in ambienti diversi. Una chiave di sviluppo non dovrebbe autorizzare anche la produzione. Per un service principal o un fornitore, contattare il provider per stabilire quali tenant o applicazioni condividano l’identità. Conservare le evidenze di audit e coinvolgere il responsabile incident response: una cronologia del repository apparentemente pulita non dimostra che l’esposizione sia terminata.
Ridurre il rischio di nuove esposizioni
Attivare secret scanning e push protection nei repository, inclusa la sorveglianza dei repository pubblici quando il piano lo consente. Conservare le credenziali in un secret store gestito, concedere a ogni identità solo i permessi necessari e preferire, quando pratico, credenziali di breve durata o workload identity. Separare gli ambienti di test e produzione, assegnare un responsabile e una scadenza e generare avvisi per accessi o letture di dati sensibili insoliti.
Controllare anche job automatici, fork, log di build, allegati alle issue e configurazione di deployment, non solo il branch principale. La scansione rileva i formati supportati, ma non può dimostrare che ogni tipo di segreto sia assente. Servono inventario e revisione periodica degli accessi, soprattutto per integrazioni di fornitori e identità macchina.
Checklist di risposta per piccoli team
1) Revocare il segreto esposto. 2) Ruotarlo e aggiornare il servizio legittimo tramite un canale affidabile. 3) Controllare i log di identità e cloud per l’uso della vecchia credenziale e degli account collegati. 4) Limitare o sospendere gli accessi sospetti preservando le evidenze. 5) Cercare copie nei repository e nei sistemi di build controllati. 6) Attivare scansione e push protection, quindi rivedere privilegi e scadenze.
Se potrebbero essere stati consultati dati o ambienti clienti, seguire il processo aziendale per incidenti e notifiche e coinvolgere competenze di sicurezza qualificate. Il post Microsoft contiene indicatori e materiali tecnici destinati ai difensori; questo articolo resta volutamente sul piano della risposta difensiva. La lezione operativa principale è che un segreto rappresenta un’identità: dopo l’esposizione, occorre ruotarla e indagare ciò che poteva raggiungere.
Fonti e approfondimenti
Vuoi segnalare un errore o suggerire una fonte? Contatta la redazione.
