Fra dicembre 2025 e luglio 2026 un gruppo nordcoreano ha infettato almeno 30.000 computer in più di 100 paesi. Non con uno zero-day: con un compito di programmazione da scaricare ed eseguire per un colloquio di lavoro. I bersagli principali erano web designer, ingegneri e specialisti di criptovalute, blockchain e Web3, cioè persone che quel file lo aprono per mestiere. Dalla campagna sono stati sottratti fondi o credenziali da oltre 7.000 wallet di criptovalute, per almeno 1,7 miliardi di yen, circa 10,71 milioni di dollari.

I numeri arrivano dall’avviso congiunto del 18 settembre 2026 firmato dalla polizia nazionale giapponese e dall’ufficio giapponese per la cibersicurezza, dall’FBI, dal DC3 del Dipartimento della Difesa statunitense, dall’ACSC australiano e dai servizi tedeschi BND e BfV. Il gruppo è tracciato come WaterPlum, più noto come «Contagious Interview»: si presenta come recruiter di aziende AI, crypto o NFT, chiede un test tecnico e fa scaricare pacchetti npm con dentro BeaverTail, InvisibleFerret, OtterCookie, OtterCandy o StoatWaffle. Dopo il download entrano i RAT, che restano sulla macchina anche dopo la fine del finto colloquio e servono da testa di ponte verso altri sistemi.

Il criterio del confronto

La domanda operativa non è «come riconosco un finto recruiter». È una sola, e torna ogni settimana anche senza nordcoreani: dove eseguo il codice che non ho scritto io. Le due opzioni sono la macchina di lavoro, magari con antivirus e una lettura veloce dei file prima di lanciare, oppure una macchina virtuale usa e getta.

Il criterio con cui le confronto non è quanto sono sicure in astratto, ma cosa resta in piedi dopo che il codice è partito. Perché la buona volontà lì non entra: si esegue prima che tu abbia letto la prima riga.

Opzione A: la macchina di lavoro

Il vantaggio è reale e va detto: costo zero e tempo zero. Node, PHP, l’editor, le credenziali dei progetti, il database locale, tutto è già configurato. Un test di assunzione con scadenza a 48 ore lo chiudi in un pomeriggio, e nessuno ti paga per allestire un ambiente.

Il problema è che la revisione manuale arriva sempre tardi. npm install esegue gli script postinstall dei pacchetti prima che tu legga una riga. E una cartella aperta in VS Code può eseguire da sola il task che trova in .vscode/tasks.json, se quel task ha "runOn": "folderOpen" e tu hai dichiarato attendibile la cartella. È esattamente la condizione che l’advisory chiede di rompere: rispondere «No» al prompt sulla fiducia negli autori dei file e restare in Restricted Mode. Da lì in poi il payload cerca appunti, sequenze di tasti, wallet e credenziali.

E su una macchina di lavoro le credenziali non sono un’astrazione: ci sono le Application Password di WordPress dei clienti, le chiavi SSH, i token Git, le sessioni aperte del pannello di hosting. L’avviso è esplicito su cosa succede dopo: le macchine compromesse diventano la strada verso i sistemi delle aziende per cui la vittima già lavora, e le credenziali rubate servono a esfiltrare dati «dai datori di lavoro, dai clienti o dalle controparti contrattuali» della vittima.

Opzione B: la VM usa e getta

Una macchina virtuale con uno snapshot pulito non ti rende più bravo a leggere il codice. Cambia una cosa sola, che però è quella che conta: il raggio dell’incidente. Nella VM non ci sono le tue chiavi, i tuoi wallet, i tuoi token. Dopo il test ripristini lo snapshot e in dieci secondi la macchina è come prima.

Il costo vero è l’allestimento iniziale: mezz’ora con UTM o VirtualBox, gratuiti, più il tempo di installare il minimo indispensabile. Dalla seconda volta sono due minuti, perché riparti sempre dallo stesso snapshot. È la stessa logica per cui l’advisory dice di eseguire codice sconosciuto «solo dentro una sandbox o una macchina virtuale».

I limiti, perché non è una bacchetta magica. Se il test richiede credenziali vere — una chiave API, un account del committente — e tu le metti dentro la VM, la VM protegge il portatile, non quell’account. Un container Docker che monta la tua home con -v non è isolamento, è una cartella condivisa con un processo ostile. E la VM va buttata davvero: se la tieni «così è già pronta», al terzo test è diventata una seconda macchina di lavoro, con le stesse credenziali dentro.

I tre criteri che decidono

  • Tempo di messa in opera: macchina di lavoro zero, VM circa trenta minuti la prima volta e due minuti a test. La macchina di lavoro resta a zero per sempre: quella mezz’ora non la spendi per andare più veloce, la spendi per rischiare meno.
  • Cosa vedi prima di eseguire: nulla, in entrambi i casi. Postinstall e tasks.json partono da soli. Questo criterio non distingue le due opzioni, e chi lo usa per giustificare la prima si sta raccontando una storia.
  • Costo dell’incidente: nella VM è un ripristino. Sulla macchina di lavoro è quello che l’advisory prescrive davvero — dare per scontato che i dati siano già usciti, reinstallare il sistema operativo da zero, creare un nuovo wallet su un dispositivo diverso con la seed phrase offline, ruotare ogni credenziale toccata. Più la telefonata ai clienti.

La stessa domanda, su WordPress

Il colloquio è solo il caso di cronaca. La decisione identica si presenta con lo ZIP di un plugin preso da un marketplace, con il tema che ti passa il cliente, con il repo di un collaboratore nuovo. Un chiarimento che vedo saltare spesso: Local e Docker non sono la stessa cosa, e nessuno dei due è una VM. Local gira sull’host con il tuo utente: non c’è nessun confine, il PHP di un plugin ostile legge ~/.ssh e i wp-config.php di tutti gli altri progetti. Docker un confine ce l’ha davvero — namespace separati, e su macOS pure una VM sotto — ma lo apri tu: un volume montato sulla home, il socket Docker esposto dentro il container, --privileged, o root nel container senza user namespace su Linux. Per provare un plugin di dubbia provenienza servono una VM o uno staging sacrificabile sull’hosting, non la cartella accanto ai siti dei clienti. È lo stesso ragionamento che vale quando si sceglie se far girare un agente AI in una sandbox gestita o su un server proprio, e la stessa disciplina con cui oggi si decide quando applicare la patch di un plugin WordPress.

La take

Il confronto è chiuso da un pezzo, e non dalla paura: dalla matematica del recupero. La VM non ti rende sicuro, ti rende recuperabile, e contro un attacco che ruba credenziali e lascia un accesso persistente la recuperabilità è quasi tutto quello che puoi comprare. Trenta minuti una volta contro una reinstallazione completa e la rotazione di ogni segreto che hai.

La parte scomoda è un’altra, e vale per chi assume: se sei tu a mandare un test di programmazione via ZIP o via repo privato da clonare, stai chiedendo al candidato esattamente il gesto che l’FBI gli dice di non fare. Il test tecnico serio nel 2026 gira su una piattaforma o su un repo pubblico leggibile prima di essere eseguito, oppure è una sessione condivisa dove il codice lo si scrive insieme.

Cosa fare adesso

Crea oggi una VM minima e salvane lo snapshot pulito: è l’unico pezzo di lavoro che non farai più. Metti VS Code in Restricted Mode di default e smetti di marcare come «trusted» le cartelle in cui scarichi roba altrui. E se negli ultimi mesi hai eseguito un test ricevuto da un recruiter che non hai verificato, trattalo come una compromissione avvenuta: reset del sistema, credenziali ruotate, wallet nuovo su un altro dispositivo.

Fonti