Una conversazione che parte da LinkedIn può trasformarsi in qualcosa di molto più insidioso di un semplice messaggio promozionale. Lo dimostra la vicenda raccontata dallo sviluppatore Roman Imankulov, che si è ritrovato bersaglio di una backdoor camuffata da innocua revisione del codice. Tutto è partito da un contatto apparentemente normale: una recruiter, qualche giorno di chiacchiere e poi la richiesta di dare un’occhiata a un repository GitHub per sistemare alcune dipendenze obsolete. Niente di strano, per chi lavora nello sviluppo software. Eppure dietro quella richiesta si nascondeva una trappola ben congegnata.
L’obiettivo degli aggressori non era rubare le credenziali con una pagina falsa o piazzare un allegato infetto in una mail. La strategia era più raffinata: costruire un finto colloquio tecnico per spingere la vittima a eseguire codice malevolo direttamente sul proprio sistema. Da anni i gruppi criminali sfruttano offerte di lavoro inesistenti per colpire programmatori e amministratori di sistema, e LinkedIn è spesso il punto di partenza, perché i professionisti si fidano della piattaforma. Quello che rende interessante questo caso è la cura con cui il codice dannoso è stato infilato dentro un progetto dall’aspetto del tutto legittimo.
Come funziona la trappola dietro npm install
Imankulov, prima di toccare quel repository, ha preso una precauzione intelligente. Invece di clonare tutto sul proprio computer, ha creato una macchina virtuale temporanea su un provider cloud e ha analizzato il codice in un ambiente isolato. Con l’aiuto di un agente AI in modalità sola lettura ha individuato quasi subito qualcosa di sospetto nel file app/test/index.js. La struttura simulava una classica applicazione con frontend React e backend Node.js, ma il codice malevolo non stava in bella vista. Era nascosto in un presunto file di test, circondato da sezioni commentate per ingannare un controllo veloce.
Il dettaglio tecnico più curioso riguarda l’URL usato dalla backdoor. Invece di scrivere l’indirizzo del server in chiaro, il codice lo costruiva pezzo per pezzo, assemblando protocollo, dominio e percorso da variabili separate. Una volta stabilita la connessione, il programma scaricava contenuti dal server remoto e li eseguiva sul posto. In pratica un loader pronto a trasformarsi in qualsiasi cosa: malware, strumenti di accesso remoto, furto di credenziali, esfiltrazione di dati. E qui sta il punto che dovrebbe far drizzare le antenne a chiunque scriva software. Il file package.json conteneva uno script prepare, uno di quegli script di lifecycle che npm avvia in automatico. Significa che bastava lanciare npm install per attivare l’intera catena. Nessun click sospetto, nessun comando strano da digitare. Solo l’installazione delle dipendenze, un gesto che la maggior parte degli sviluppatori considera banale e innocuo. Molti strumenti di sicurezza guardano gli eseguibili o gli allegati, ma raramente vanno a scavare negli script di un package.json che sembra arrivare da una fonte affidabile.
Identità rubate per rendere tutto più credibile
L’inganno non si fermava al codice. Gli attaccanti avevano lavorato anche sulla credibilità. Guardando la cronologia del repository, Imankulov ha scoperto che tutti i commit erano attribuiti a uno sviluppatore reale, con profilo LinkedIn autentico, sito personale e una presenza solida su GitHub. Contattato, quell’ingegnere ha confermato di non aver mai messo mano al progetto e di essere già finito nel mirino di tentativi di impersonificazione. Stessa storia per la recruiter: l’account apparteneva a una giornalista specializzata in temi culturali, niente a che vedere con lo sviluppo software. Quando la vittima ha iniziato a fare domande tecniche, però, l’interlocutore ha sfoderato all’improvviso competenze avanzate su Node.js e procedure di installazione, segno evidente che l’account era stato compromesso o usato in modo abusivo.