Come un finto colloquio di lavoro può far eseguire malware: la nuova frontiera degli attacchi informatici

Un messaggio su LinkedIn, un’azienda reale, un progetto di test in React e Node.js: tutto sembrava legittimo. Eppure, dietro quel “colloquio tecnico” si nascondeva un’operazione di hacking sofisticata, progettata per sfruttare la fiducia e le abitudini dei programmatori.

L’esperienza raccontata da David Dodda rivela un nuovo e pericoloso vettore d’attacco, battezzato “fake coding interview scam”, una trappola che utilizza l’infrastruttura e l’apparenza di reali processi di selezione per indurre le vittime a eseguire codice malevolo.

Come funziona la trappola

Dodda riferisce di aver ricevuto un contatto diretto da quello che sembrava a tutti gli effetti uno dei responsabili di una vera azienda, con un profilo LinkedIn completo, migliaia di connessioni e una pagina aziendale autentica.

Il messaggio è professionale: parla di un progetto blockchain nel settore immobiliare, flessibilità, collaborazione part-time. Nessun segnale d’allarme.

Come parte del processo, al candidato è richiesto di completare un “progetto di test” su un repository Bitbucket con codice React/Node.js e documentazione accurata. Questi tipi di prove sono comuni nelle attività di selezione di nuovo personale: tutto, almeno in apparenza, non destava alcun sospetto.

L’agghiacciante scoperta: codice offuscato che richiama JavaScript malevolo

Sotto pressione per una chiamata imminente con l’azienda intenzionata ad assumerlo, Dodda decide di ispezionare rapidamente il codice del progetto condiviso. Lo fa senza usare né una sandbox né un container isolato, un’eccezione alla sua abituale prudenza.

Prima di eseguire l’applicazione, però, lo sviluppatore chiede a un agente AI (Cursor, in questo caso) di analizzare il codice alla ricerca di eventuali comportamenti sospetti.

E qui emerge la verità. In un file JavaScript integrato nel “progetto di test” si nascondeva un frammento di codice offuscato. Una volta decodificato, Dodda ha potuto estrarre l’URL dell’endpoint remoto utilizzato per scaricare ed eseguire dinamicamente ulteriore codice JavaScript.

Nello specifico, si trattava di un payload pericolosissimo capace di accedere a file di sistema, variabili d’ambiente, credenziali, portafogli crypto e database.

L’URL, attivo solo per 24 ore, dimostrava l’esistenza di un’infrastruttura automatizzata per cancellare le tracce e impedire analisi forensi approfondite.

Un’operazione professionale, in grande stile

Non si tratta di un tentativo dilettantistico. Gli attaccanti hanno costruito un intero ecosistema per acquisire credibilità e far cadere in trappola i candidati meno attenti.

L’attacco si fonda infatti su quattro leve psicologiche che poggiano sul senso di urgenza (“Completa il test prima della call”), di autorità (profilo aziendale verificato e ruoli dirigenziali), familiarità (i test tecnici sono routine nel recruiting IT) e convalida sociale (azienda con follower e dipendenti reali).

In questo modo, la vittima abbassa le difese, convinta di trovarsi in un processo legittimo.

Perché i criminali informatici adesso prendono di mira gli sviluppatori

La vera arma difensiva sono stati la curiosità e il sospetto di un singolo sviluppatore, coadiuvati da un assistente AI capace di individuare schemi anomali nel codice di programmazione.

Una semplice analisi preventiva ha evitato la compromissione di un intero sistema e, potenzialmente, di molte altre risorse. Sì, perché se Dodda avesse eseguito il codice senza verifiche, il payload remoto avrebbe potuto immediatamente eseguire comandi con i privilegi dell’app Node.js e scaricare ulteriori moduli malevoli, leggendo file sensibili e variabili d’ambiente, esfiltrando token, chiavi SSH e segreti CI/CD.

Da lì gli attaccanti avrebbero potuto muoversi lateralmente verso servizi cloud e repository, impiantare backdoor nel sistema, compromettere pipeline di deploy, installare ransomware o cryptominer e infine cancellare tracce per ostacolare l’analisi forense, con conseguenze che vanno dalla perdita di dati e interruzione dei servizi fino a costi legali e finanziari.

Gli sviluppatori hanno accesso a chiavi API, repository privati e credenziali di produzione: per questo sono entrati nel mirino degli aggressori. Una singola esecuzione di codice malevolo in locale può compromettere progetti e ambienti cloud interconnessi.

Un attacco riuscito di questo tipo può valere milioni di euro in dati, asset digitali e informazioni riservate. Ed è quasi scontato che i criminali informatici scelgano con sempre maggiore attenzione i developer da bersagliare, selezionandoli ad esempio attraverso LinkedIn sulla base dell’esperienza e delle collaborazioni in essere.

Come difendersi

1. Isolare sempre il codice sconosciuto. Usare Docker, VM o ambienti virtuali per ogni repository non verificato.
2. Analizzare il codice con strumenti AI o scanner statici. Bastano pochi secondi per rilevare comportamenti anomali.
3. Verificare le identità. Una pagina LinkedIn autentica non garantisce l’autenticità della persona.
4. Diffidare della fretta. Nessun recruiter serio impone scadenze immediate per l’esecuzione di codice.

In un’epoca in cui l’automazione è sempre più protagonista, l’AI può essere anche uno strumento di sicurezza proattiva, utile a identificare codice potenzialmente malevolo in tempo reale.

L’incidente occorso a Dodda non è solo un aneddoto: è un campanello d’allarme per tutta la comunità tech. Gli hacker non puntano più solo agli utenti distratti, ma ai professionisti che custodiscono infrastrutture critiche e dati sensibili. In un mondo in cui la fiducia digitale è falsificabile, la prudenza diventa sempre più spesso la primissima (ed efficace) linea di difesa.