Quando la scorsa settimana alcuni hacker hanno compromesso i pacchetti npm, il settore si è affrettato ad analizzare come fosse successo e quale codice fosse stato iniettato. Ma l'exploit in sé non è l'unica cosa da considerare.
Che il punto di ingresso sia un manutentore vittima di phishing, una dipendenza non autorizzata o un fornitore terzo, la compromissione iniziale è solo il primo passo. Ciò che accade dopo è altrettanto importante. Una volta che il codice dannoso viene eseguito all'interno del vostro ambiente, gli aggressori utilizzano tale accesso per muoversi lateralmente, aumentare i privilegi, sottrarre dati o preparare il terreno per il ransomware.
Per i team SOC, individuare il codice dannoso è importante, ma altrettanto fondamentale è rilevare i comportamenti degli aggressori che seguono l'esecuzione del codice dannoso.
Come si è sviluppato l'exploit npm
Il recente exploit non è derivato da una vulnerabilità di npm stesso. È invece iniziato con un classico caso di ingegneria sociale. Gli aggressori hanno inviato phishing ai gestori più noti di npm, fingendo di essere il supporto ufficiale e sollecitandoli a "rivalidare" i propri account. Un amministratore, responsabile di diversi pacchetti ampiamente utilizzati, ha inserito sia le credenziali che un codice 2FA monouso nel portale falso degli aggressori. Ciò ha consentito agli aggressori di ottenere il pieno controllo dell'account, nonostante l'autenticazione a due fattori fosse abilitata.
Una volta ottenuto l'accesso, l'autore della minaccia ha rapidamente pubblicato nuove versioni di pacchetti affidabili come chalk, debug, supports-color e altri. Questi pacchetti sono elementi fondamentali per innumerevoli applicazioni e vengono scaricati miliardi di volte ogni settimana. Gli aggiornamenti compromessi contenevano codice JavaScript offuscato progettato per essere eseguito all'interno dei browser web.
Il payload dannoso agiva come un attacco man-in-the-browser. Si agganciava alle API del browser, monitorava le richieste di rete e intercettava le transazioni dei portafogli crittografici. Se un utente tentava di inviare criptovaluta, il malware sostituiva malware l'indirizzo del destinatario con uno controllato dall'autore dell'attacco. Il risultato finale era il furto di fondi, mentre la transazione appariva normale alla vittima.
Sebbene le versioni dannose siano state disponibili solo per un breve periodo, l'ampia diffusione delle dipendenze npm ha fatto sì che l'impatto si propagasse rapidamente. I sistemi di compilazione automatizzati nelle pipeline CI/CD hanno scaricato gli aggiornamenti compromessi quasi immediatamente, costringendo migliaia di sviluppatori e organizzazioni ad attivare la modalità di risposta agli incidenti.
Dallo sfruttamento all'esecuzione: perché il primo passo non definisce l'attacco
Nel caso di npm, il codice iniettato era stato ottimizzato per dirottare le transazioni di criptovaluta. Ma questo obiettivo limitato non significa che il rischio fosse limitato. Una volta che il codice dannoso è in esecuzione all'interno di un ambiente, gli aggressori possono fare molto di più che scambiare indirizzi di portafogli.
Con lo stesso livello di accesso, potrebbero:
- Rubare credenziali e aumentare i privilegi.
- Passare lateralmente ai sistemi cloud di identità.
- Crea persistenza tramite regole della casella di posta, app OAuth o account ridondanti.
- Esfiltrare dati o preparare ransomware.
Attori malintenzionati come Scattered Spider dimostrano quanto velocemente l'accesso possa essere trasformato in un'arma: passando alle piattaforme cloud SaaS, manipolando le autorizzazioni delle caselle di posta, creando relazioni di fiducia backdoor e sondando i carichi di lavoro critici. Da lì, gli aggressori si spostano lateralmente per raggiungere i dati sensibili e sottrarli. Questo è il vero pericolo a cui i team SOC devono prepararsi: non solo l'impianto, ma la cascata di comportamenti degli aggressori che ne consegue.
Perché i team SOC dovrebbero interessarsene
Per i team SOC, l'exploit npm è un promemoria del fatto che le compromissioni della catena di fornitura non sono solo una preoccupazione degli sviluppatori. Gli strumenti di prevenzione e le scansioni SCA svolgono un ruolo importante nell'identificazione di pacchetti vulnerabili o dannosi, ma si fermano al punto dell'analisi del codice. Ciò che non sono in grado di fornire è la visibilità su come gli aggressori utilizzano tale accesso una volta che il codice dannoso è in esecuzione.
Questa responsabilità ricade interamente sul SOC. La sfida non consiste solo nel comprendere che si è verificata una violazione, ma anche nell'individuare come questa modifica i flussi di lavoro degli aggressori nel proprio ambiente. Ciò significa prestare attenzione ai comportamenti che gli strumenti di prevenzione non riescono a rilevare: persistenza stabilita nei sistemi di identità, credenziali utilizzate in modo improprio per accedere a cloud SaaS e cloud o attività di rete che segnalano lo staging e l'esfiltrazione dei dati.
Che il punto di ingresso sia npm, PyPI,3CX,MOVEit o il prossimo fornitore di terze parti, l'exploit è solo l'inizio. L'impatto è determinato dalla rapidità con cui è possibile individuare e rispondere ai comportamenti che si manifestano in seguito.
Colmare il divario di sicurezza con Vectra AI
L'exploit npm dimostra quanto velocemente la fiducia nelle catene di fornitura del software possa ritorcersi contro di voi. Anche se l'obiettivo iniziale era il furto di criptovalute, lo stesso accesso avrebbe potuto essere utilizzato per rubare credenziali, aumentare i privilegi o sottrarre dati. Ecco perché i team SOC hanno bisogno di difese che non si limitino ad analizzare il codice, ma monitorino costantemente il comportamento degli aggressori una volta che questi sono entrati nel sistema.
La Vectra AI offre questa visibilità. Monitorando in tempo reale cloud di identità, rete e cloud , Vectra AI i comportamenti su cui fanno affidamento gli avversari per espandere la loro presenza e raggiungere i loro obiettivi. Che il codice dannoso arrivi attraverso un pacchetto infetto, un phishing dell'account SaaS o un fornitore terzo compromesso, Vectra AI le azioni dell'aggressore e fornisce ai team SOC il contesto necessario per rispondere prima che il danno si aggravi.
Esplora la nostra demo autoguidata per scoprire come Vectra AI il divario e garantisce che, quando la prevenzione fallisce, il rilevamento e la risposta siano pronti.