Security Blog

634 password in 56 secondi

#93

October 2, 2026 · By Marketing team

← All posts

Uno sviluppatore ha sostenuto due round di colloqui con un'azienda inesistente. Sito web reale, volti reali, conversazioni tecniche reali. Poi hanno assegnato la challenge di programmazione. In meno di un minuto, tutte le password di Chrome, il portachiavi di macOS e i dati del wallet crypto sono andati persi.

Uno sviluppatore — esperto, attento alla sicurezza, qualcuno che cerca attivamente le truffe — ha sostenuto un processo selettivo multiplo con un'azienda inesistente. Colloquio con le HR. Colloquio tecnico con due ingegneri. Sito web reale con foto del team. Profili LinkedIn reali. Settimane di costruzione della relazione.

Poi gli è stato chiesto di eseguire una piccola challenge di programmazione durante una condivisione dello schermo.

56 secondi dopo, gli attaccanti avevano le 634 password salvate in Chrome, il file del portachiavi di macOS (che contiene la chiave per decifrarle) e i dati del wallet MetaMask.

Come funzionava l'attacco

La repo GitHub sembrava pulita. Qualche file backend, niente di sospetto. Ma una dipendenza — winston-middleware, un pacchetto di logging dal nome innocuo — aveva a sua volta una dipendenza: next-runtimejs.

Lì si nascondeva l'arma.

Nel momento in cui è stato eseguito npm install, uno shell script si è attivato in silenzio. Nessuna richiesta, nessun avviso. Ha scaricato un backdoor scritto in Go e l'ha registrato per l'avvio automatico a ogni boot.

Non era uno strumento da script kiddie. Protocollo C2 personalizzato con cifratura RC4. Comandi per l'esecuzione di shell, il furto di file, l'estrazione delle password di Chrome, l'esfiltrazione del portachiavi e il targeting dei wallet crypto. Realizzato in modo professionale.

Il backdoor è partito alle 16:16:37. Le password di Chrome sono state lette alle 16:17:33. Lo sviluppatore ha notato un popup di macOS relativo a una connessione in uscita e ha disattivato il WiFi entro un minuto — ma il danno era già fatto.

Perché il colloquio era determinante

Questo attacco fallirebbe come email a freddo. "Esegui questa repo" proveniente da uno sconosciuto viene ignorato.

Ma dopo due round di colloqui? Dopo aver riso insieme di quante truffe di false offerte di lavoro colpiscano gli sviluppatori? Dopo che uno dei colloquianti aveva detto con un sorriso "Si pure a cercare eventuali backdoor"?

È in quel momento che le difese calano. La fiducia è l'exploit. Il malware è solo il payload.

Lo sviluppatore l'ha detto meglio di chiunque: "Se è successo a me, può succedere a chiunque nel suo team."

Cosa significano davvero le password di Chrome

Chrome cifra le password salvate con AES. La chiave di decifratura è conservata nel portachiavi di macOS. Gli attaccanti hanno rubato entrambi i file in meno di un minuto.

Ogni password salvata — banking, email, GitHub, console cloud — era leggibile dalla loro parte. Il file del portachiavi può essere violato offline, senza limiti di tentativi. Lo sviluppatore ha dovuto ruotare tutte le credenziali.

Questo è il lato scomodo delle password salvate nel browser: sono cifrate con una chiave che risiede sulla stessa macchina. Se la macchina è compromessa, la "cifratura" è decorazione.

Lo schema ricorrente DPRK

Lo sviluppatore ha raccontato che anche l'azienda precedente era stata violata dalla Corea del Nord tre mesi prima. Si tratta della campagna "Contagious Interview": attaccanti sponsorizzati dallo Stato della DPRK che conducono finti colloqui di lavoro per installare malware sulle macchine degli sviluppatori.

Non è casuale. Prendono di mira gli sviluppatori per ciò a cui hanno accesso: credenziali di produzione, chiavi di firma, infrastruttura cloud e — sempre più spesso — token di agenti AI con accessi ancora più ampi.

La scala è industriale. Aziende inesistenti con volti generati. Siti web curati. Processi selettivi di più settimane. Investono perché il ROI c'è.

"I password manager non servono"

Lo sviluppatore ha avanzato un'affermazione interessante nel thread: "I password manager non servono se hanno accesso al computer tramite un backdoor come questo, perché possono trasmettere qualsiasi file in un secondo momento, costruire un exploit su misura, keylogger, screenshot."

L'affermazione è in parte corretta e in parte errata.

Un password manager che conserva il proprio vault sul disco locale, sbloccato da una master password digitata — sì, un backdoor con keylogging e accesso ai file può comprometterlo.

Ma un password manager con chiavi vincolate all'hardware — dove la chiave di decifratura è derivata da un autenticatore fisico e non esiste mai come file su disco — è una questione completamente diversa. Il backdoor può rubare file, registrare i tasti premuti, acquisire screenshot. Ma non può estrarre una chiave che esiste solo all'interno di un modulo di sicurezza hardware durante un'interazione fisica.

Le 634 password di Chrome sono state rubate perché sia i dati cifrati sia la chiave di decifratura erano file sul filesystem. Se la chiave di decifratura richiede il possesso fisico di un dispositivo, rubare file consente di ottenere solo blob cifrati.

Cosa fare

  • Non esegua mai codice di colloquio sulla sua macchina principale. Usi una VM o un dispositivo separato.
  • Esegua npm install --ignore-scripts su qualsiasi repo sconosciuta prima di eseguire il codice
  • Usi un firewall in uscita (Little Snitch, LuLu) che segnali le nuove connessioni
  • Smetta di salvare le password in Chrome. Punto.
  • Conservi le crypto su hardware wallet, non su estensioni del browser
  • Tratti ogni challenge di programmazione ricevuta da un recruiter come potenzialmente ostile, indipendentemente da quanti colloqui abbia sostenuto

Lo sviluppatore è sopravvissuto perché un popup di macOS ha intercettato in tempo la connessione in uscita. La maggior parte delle persone avrebbe cliccato su Consenti senza pensarci due volte.

56 secondi. Bastano solo questi.