L'errore dell'hacker gli ha aperto la porta

Per 22 mesi, Vangelis Stykas ha osservato dall'interno una squadra di hacker statali nordcoreani, e non perché fosse lui a essere penetrato nei loro sistemi, ma perché il loro stesso malware aveva già infettato i loro computer di lavoro. Stykas, direttore tecnico della società di cybersicurezza Kumio, ha raccontato alla conferenza Black Hat di Las Vegas, all'inizio di agosto 2026, che gli operatori si erano infettati da soli, aprendogli così una finestra sui loro canali interni Slack e Discord.

Quell'accesso, arrivato per puro errore altrui, gli ha permesso di osservare in silenzio circa 5 terabyte di dati che il gruppo aveva già rubato alle proprie vittime, oltre a uno sguardo raro sul funzionamento quotidiano dell'operazione, del tutto inosservato dagli hacker stessi.

1.640 aziende, 57 paesi, una dozzina di nomi

Stykas ha dichiarato che il gruppo aveva compromesso 1.640 aziende in 57 paesi nel periodo in cui vi ha avuto accesso. Tra le 700 e le 800 di quelle intrusioni sono state classificate come gravi, cioè gli aggressori erano riusciti a ottenere l'accesso root a server, ad ambienti cloud AWS oppure a portafogli di criptovalute, ben oltre un semplice punto d'appoggio su una singola macchina.

Nella sua presentazione, Stykas ha nominato pubblicamente circa una dozzina delle organizzazioni colpite, tra cui il produttore di smartphone Oppo, Coinbase, Uniswap Labs, il Boston Children's Hospital e diverse agenzie governative che però non ha voluto identificare per nome.

L'ingresso è avvenuto tramite un colloquio di lavoro

A parte la ricerca di Stykas, i team di sicurezza di Elastic Security Labs, Proofpoint e altre società seguono già da tutto il 2026 una campagna nordcoreana attiva nota come Contagious Interview, collegata al gruppo Lazarus. Gli operatori si spacciano per recruiter su piattaforme come LinkedIn, contattano sviluppatori software con quella che sembra un'offerta di lavoro genuina, e poi inviano un test di programmazione ospitato su un repository GitHub.

La trappola si trova nella cartella .githooks del repository, così da attivarsi da sé non appena lo sviluppatore esegue il commit del codice di prova, senza che serva alcun download o doppio clic separato. Altre varianti della stessa campagna hanno nascosto il payload dentro file immagine SVG tramite steganografia, e Proofpoint ha già tracciato oltre 250 email di reclutamento malevole solo tra aprile e maggio 2026, rivolte soprattutto a chi lavora nella tecnologia, nell'istruzione e nella finanza, con particolare attenzione ai ruoli vicini alle criptovalute.

Cosa fa davvero il malware

Le famiglie di malware usate in queste campagne, tra cui OTTERCOOKIE e strumenti correlati, sono pensate per rubare le credenziali del browser, i portafogli di criptovalute e i file, oltre a garantire agli operatori l'accesso remoto al computer infetto. Per uno sviluppatore, quell'accesso finisce spesso proprio all'interno dello stesso ambiente che contiene i repository aziendali, le credenziali cloud e i dati dei clienti.

È qui che si uniscono i due filoni della vicenda. Un gruppo capace di intrusioni su una scala già documentata da Stykas, 1.640 aziende in 57 paesi, ha anche dimostrato di ottenere una parte significativa del proprio accesso attraverso il normale atto dell'assunzione, il che rende questo vettore rilevante per qualsiasi azienda dell'UE o del Regno Unito che assuma sviluppatori o collaboratori da remoto, e per qualsiasi sviluppatore che sia oggi alla ricerca di un lavoro.

Tre controlli prima di clonare quel repository

La difesa pratica è specifica, non un generico consiglio anti-phishing. Verificate l'identità di un recruiter in modo indipendente, tramite la pagina carriere ufficiale dell'azienda o un dipendente già noto, prima di eseguire qualsiasi codice che vi venga inviato. Considerate più sospetto un test di programmazione che richieda di clonare un intero repository con hook e script di configurazione, rispetto a uno erogato tramite una piattaforma isolata e già sandboxata, perché la sandbox toglie proprio il meccanismo da cui dipende il trucco di .githooks.

Considerate una tempistica di assunzione insolitamente rapida e ad alta pressione come un segnale d'allarme maggiore di quanto sarebbe stato un anno fa, e non eseguite mai uno script di configurazione, un npm install o un comando di build a partire da un repository di test prima che quel controllo d'identità sia completo. Nulla di tutto ciò richiede strumenti nuovi, solo una pausa in più prima che il primo comando venga eseguito.

Da leggere ora: La chiamata che aggira l'MFA della vostra azienda  |  Nessun umano ha scelto l'exploit, CISA dà 2 giorni