Backdoor nascosta in un'offerta LinkedIn: la trappola per sviluppatori

Un semplice messaggio su LinkedIn, una conversazione apparentemente credibile con una recruiter e una richiesta piuttosto comune per chi lavora nello sviluppo software: analizzare un repository GitHub e verificare alcuni problemi legati a dipendenze obsolete. La catena di eventi descritta dallo sviluppatore Roman Imankulov dimostra quanto le campagne di social engineering rivolte ai professionisti IT stiano diventando sempre più comuni ma, allo stesso tempo, sofisticate.

L’obiettivo non era rubare credenziali attraverso una pagina contraffatta né distribuire malware tramite allegati sospetti. Gli aggressori hanno costruito uno scenario molto più convincente: un falso processo di selezione tecnica progettato per indurre la vittima a eseguire codice malevolo sul proprio sistema.

Da anni gruppi criminali sfruttano offerte di lavoro fittizie per colpire sviluppatori, amministratori di sistema e personale tecnico. Diverse campagne hanno utilizzato LinkedIn come vettore iniziale, sfruttando la naturale fiducia che i professionisti rivestono nella piattaforma. Ciò che rende interessante il caso analizzato da Imankulov è la qualità dell’inganno e il modo in cui il codice dannoso è stato nascosto all’interno di un progetto apparentemente legittimo.

Come una revisione del codice si trasforma in un’infezione malware

Tutto inizia con il contatto da parte di una presunta recruiter: dopo alcuni giorni di conversazione, la professionista invia un repository pubblico su GitHub chiedendo un parere tecnico su alcuni problemi relativi a moduli Node.js non più supportati. Una richiesta che, per un ingegnere software esperto, appare del tutto plausibile.

Imankulov decide però di adottare una precauzione aggiuntiva: invece di clonare il repository GitHub sul proprio computer, egli crea una macchina virtuale temporanea su un provider cloud e analizza il codice in un ambiente isolato.

Il successivo utilizzo di un agente AI in modalità sola lettura ha permesso di individuare quasi immediatamente un elemento sospetto nascosto nel file app/test/index.js.

La struttura del repository simulava una tipica applicazione composta da frontend React e backend Node.js: il codice malevolo non era collocato in una posizione evidente. Gli autori lo avevano inserito all’interno di un presunto file di test, circondandolo da numerose sezioni commentate per confondere eventuali controlli superficiali.

Il meccanismo della backdoor nascosta nel codice

L’elemento più interessante dal punto di vista tecnico riguarda la costruzione dinamica dell’URL utilizzato dalla backdoor. Invece di inserire direttamente l’indirizzo remoto, il codice assemblava protocollo, dominio, percorso e altri parametri attraverso variabili separate: il risultato finale era una connessione verso un server controllato dagli aggressori.

Una volta stabilito il collegamento, il programma scaricava contenuti dal server remoto ed eseguiva localmente quanto ricevuto. In pratica, il repository GitHub conteneva un semplice loader capace di trasformarsi in qualunque cosa gli operatori decidessero di distribuire in un secondo momento: malware, strumenti di accesso remoto, componenti per il furto di credenziali o moduli dedicati all’esfiltrazione di dati.

Il codice non richiedeva alcun intervento specifico dopo l’installazione: gli attaccanti avevano infatti sfruttato una funzionalità legittima di Node.js, utilizzando gli script di lifecycle di npm, ovvero gli script che sono eseguiti automaticamente durante operazioni come l’installazione, l’aggiornamento o la rimozione di un pacchetto.

Perché bastava eseguire npm install per cadere nella trappola

Molti sviluppatori considerano npm install un’operazione innocua e automatica. In realtà il sistema di gestione pacchetti di Node.js permette l’esecuzione di diversi script durante le fasi di installazione, aggiornamento e pubblicazione.

Nel repository analizzato, il file package.json definiva uno script prepare che richiamava a sua volta un componente applicativo. Durante l’esecuzione di npm install, npm avvia automaticamente la fase prepare. Di conseguenza, l’utente non avrebbe dovuto lanciare manualmente il malware: sarebbe bastato installare le dipendenze del progetto per attivare la catena di esecuzione.

Molti strumenti di sicurezza concentrano l’attenzione sugli eseguibili sospetti o sugli allegati ricevuti via email; meno frequente è l’analisi approfondita degli script definiti nei file package.json di un repository che sembra provenire da una fonte affidabile.

Furto di identità e credibilità artificiale

L’operazione non si limitava al codice. Gli attaccanti avevano investito tempo anche nella costruzione della credibilità necessaria per superare i sospetti iniziali.

Analizzando la cronologia del repository, Imankulov scopre che tutti i commit risultavano attribuiti a uno sviluppatore realmente esistente. Il professionista possedeva un profilo LinkedIn autentico, un sito personale e una presenza consolidata su GitHub. Contattato direttamente, l’ingegnere ha confermato di non aver mai lavorato sul progetto e di essere già stato vittima di precedenti tentativi di impersonificazione.

La stessa dinamica emerge dal lato della recruiter. Anche il profilo LinkedIn utilizzato per avviare il contatto apparteneva a una persona reale, una giornalista specializzata in temi culturali senza alcun legame con il settore dello sviluppo software.

Quando la vittima ha iniziato a porre domande tecniche, l’interlocutore ha improvvisamente mostrato competenze avanzate su Node.js, versioni runtime e procedure di installazione, suggerendo chiaramente che l’account fosse stato compromesso o utilizzato abusivamente.

Una minaccia che riguarda qualsiasi sviluppatore

Attacchi di questo tipo sfruttano una combinazione di fattori psicologici e tecnici. Da un lato fanno leva sull’interesse professionale verso nuove opportunità lavorative. Dall’altro utilizzano repository pubblici, strumenti open source e funzionalità standard degli ambienti di sviluppo.

L’intera operazione è stata costruita per apparire credibile agli occhi di professionisti qualificati: una giornata particolarmente intensa, una revisione rapida del codice o una fiducia eccessiva nel mittente avrebbero potuto portare all’esecuzione della backdoor senza particolari sospetti.

Molti incidenti occorsi di recente mostrano come gli aggressori preferiscano colpire strumenti e procedure già presenti nel flusso di lavoro degli sviluppatori invece di distribuire malware tradizionale. Repository GitHub, pacchetti npm, moduli PyPI e dipendenze open source rappresentano oggi uno dei punti di ingresso più efficaci.

La difesa non richiede strumenti particolarmente complessi, ma una disciplina rigorosa. Analizzare repository sconosciuti all’interno di macchine virtuali o container isolati riduce drasticamente il rischio; anche l’ispezione preventiva almeno del file package.json e degli script lifecycle può rivelare attività anomale prima dell’installazione.

Risulta utile verificare l’identità dei contributori, controllare la storia del repository e diffidare di richieste che insistono sull’esecuzione immediata di comandi come npm install, yarn install o script equivalenti. Negli ambienti professionali, sandbox dedicate e workstation sacrificiali rappresentano una misura prudente quando si analizzano progetti provenienti da fonti non completamente verificate.