Vai al contenuto
Offerte

GitHub, token dormiente per 95 giorni: colpiti 472 repository

In questo articolo Indice dei contenuti 2 sezioni

Gli attacchi informatici a velocità macchina stanno cambiando le regole della difesa aziendale. Entro 15 minuti dall’accesso a un ambiente, chi attacca è già in grado di mappare le risorse o di portare via dati, mentre gli strumenti che avrebbero dovuto intercettarlo spesso restano in silenzio. L’analisi condotta da Exaforce individua tre schemi ricorrenti: i token rubati agli sviluppatori, le esche ClickFix legate agli strumenti di intelligenza artificiale e il vishing che imita l’help desk. Per riconoscerli serve un rilevamento basato su dati e comportamenti. Per fermarli serve una risposta autonoma.

Il caso più emblematico parte a marzo. Uno sviluppatore installa GitHub Desktop, effettua l’accesso e smette di usarlo il giorno stesso. Il token OAuth creato dall’applicazione resta nel portachiavi del Mac per 95 giorni, finché il 19 giugno qualcun altro comincia a sfruttarlo. In circa 15 secondi vengono scaricati 76 repository attraverso proxy residenziali sparsi in più di due dozzine di città europee. GitHub non genera alcun avviso perché nessuna sua funzione controlla come vengono usati i token. La piattaforma Exaforce segnala l’anomalia entro cinque minuti e la classifica entro dieci, gli analisti MDR confermano l’esfiltrazione e avvisano il cliente pochi minuti dopo. Quando però si interviene davvero, l’aggressore ha già sottratto dati da 472 dei 638 repository.

Token dormienti e finte installazioni di Claude Code

La compromissione è emersa sommando segnali deboli su una singola sessione GitHub. Gli accessi arrivavano da reti e città mai viste prima, gli archivi ZIP venivano scaricati a ritmo automatico e lo user agent indicava Windows su un account che aveva sempre lavorato con macOS. Ogni dettaglio, preso da solo, poteva avere una spiegazione innocua. Messi insieme raccontavano un’altra storia.

I token delle app OAuth con prefisso gho non scadono e GitHub li revoca in autonomia solo dopo un anno. Nei test effettuati non comparivano nemmeno nella pagina SSO dell’organizzazione, risultando visibili soltanto tramite riga di comando. Disattivare lo sviluppatore nel provider di identità non basta e, senza SCIM, la piattaforma continua ad accettare il token GitHub finché qualcuno non lo revoca o non rimuove l’utente. A peggiorare il quadro c’è l’abitudine di chi programma con strumenti di intelligenza artificiale di installare pacchetti npm e collegare server MCP tutto il giorno, quasi sempre fuori dai flussi sorvegliati. Alcuni worm setacciano la macchina alla ricerca di credenziali appena viene installato un pacchetto avvelenato, prima ancora di qualsiasi commit. Controllare i repository, quindi, non è sufficiente.

Anche le esche ClickFix si sono adattate. Un dipendente in cerca delle istruzioni per installare Claude Code è finito su una conversazione Claude condivisa contenente un comando di una sola riga. Quel comando caricava un malware per macOS che simulava una richiesta di password delle Preferenze di Sistema e poi copiava portachiavi, cookie del browser, password salvate e credenziali cloud. Dato che è la vittima stessa a lanciarlo, filtri della posta e controlli sui download vengono aggirati. La difesa più efficace resta una soluzione di rilevamento sugli endpoint, seguita da un’analisi completa di tutte le credenziali generate dall’utente.

Vishing, sessioni rubate e azioni automatiche

Nei casi di vishing analizzati quest’anno, l’aggressore ha registrato un proprio dispositivo MFA e avviato uno script di download massivo fra 2,5 e 7 minuti dopo l’approvazione della notifica da parte della vittima. In un episodio sono stati portati via 140.000 file, con successiva richiesta di riscatto. Il copione ricalca quello del gruppo Scattered Spider: un finto tecnico IT indirizza il dipendente verso una pagina di accesso con il nome dell’azienda nell’indirizzo. Un kit smontato, ospitato su oskeysetup[.]com, era stato scritto da zero e sfuggiva quindi ai controlli pensati per Evilginx e per gli altri kit pubblici. In un furto di sessione di luglio, Microsoft aveva segnalato come rischioso il primo accesso, salvo poi considerare il rischio risolto perché l’utente aveva superato l’MFA. Exaforce ha invece collegato gli accessi Okta e Microsoft, notando il primo login in assoluto dagli Stati Uniti, da un dispositivo Linux e tramite un provider domestico mai usato.

La proposta è classificare le azioni di risposta in base all’attrito. Revocare sessioni, eliminare un metodo MFA registrato nella sessione sospetta o disattivare una chiave riattivabile sono interventi a basso impatto, eseguibili in automatico davanti a un riscontro affidabile. Reset delle password, disattivazione degli account e cancellazioni definitive richiedono invece l’approvazione umana. Revocare la sessione nell’identity provider, poi, non chiude i token già emessi da Microsoft 365, Google Workspace o GitHub. Nei casi studiati l’esfiltrazione è proseguita da 44 minuti a 3 ore dopo la revoca e in un episodio le regole della casella di posta create dall’aggressore sono sopravvissute al cambio password. Per questo conviene preparare in anticipo le azioni di revoca per ogni applicazione, partendo dai servizi con i dati più critici, perché è già capitato di vedere una risposta fallire a metà incidente con un errore 403 per mancanza dei permessi necessari.

Fonte: TecnoAndroid

Condividi:
200 Condivisioni