Team MailSniper
Autore
Stai dormendo tranquillo e il tuo server di build notturno ha appena scaricato un pacchetto npm che sembra legittimo. Due ore dopo, il tuo bucket S3 è vuoto e qualcuno ha esfiltato tutte le credenziali AWS. Non è un incubo: è successo davvero a decine di aziende.
Gli hacker nordcoreani del cluster Contagious Interview (anche noti come Famous Chollima o Hexagon) hanno fatto evolvere le loro campagne. Non mandano più email di phishing banali. Ora usano i tuoi stessi strumenti di sviluppo contro di te.
Il meccanismo è semplice e inquietante:
npm install o pip installIl risultato? Il malware arriva direttamente nella tua supply chain, bypassando i filtri email tradizionali perché non c'è nessuna email da filtrare.
Prima di procedere, assicurati di avere:
/var/log)Se non hai almeno i primi due, passa questo articolo al tuo team di sviluppo e fagli leggere la sezione step-by-step.
Il primo problema è capire se hai già installato qualcosa di infetto. Ecco come fare una verifica rapida:
# Elenca tutti i pacchetti npm installati
npm list --all --depth=0
# Controlla pip
pip list
# Verifica pacchetti con analisi hash (esempio)
npm auditCerca pacchetti con nomi simili a quelli popolari ma leggermente diversi. Ad esempio:
axios vs axio (typo)requests vs requstslodash vs lodasIl problema? I pacchetti malevoli spesso usano nomi completamente nuovi che sembrano utili. Il trucco è controllare chi li ha pubblicati e quando.
Non installare mai ciecamente. Prima di un npm install in produzione:
# Scarica il pacchetto senza installarlo
npm pack <nome-pacchetto>
# Estrai e guarda cosa c'è dentro
tar -xzf <pacchetto>.tgz
cat package/package.json
# Controlla gli script nel pacchetto
cat package/package.json | grep -A 10 '"scripts"'Gli script postinstall sono il cavallo di Troia preferito. Se vedi roba come:
"scripts": {
"postinstall": "node -e 'eval(Buffer.from(\"...base64...\", \"base64\"))'"
}
...vai nel panico. Quello è codice che viene eseguito automaticamente dopo l'installazione, con i tuoi permessi.
Se gestisci un team di sviluppo, non lasciare che gli sviluppatori installino direttamente da npmjs.org. Configura un proxy:
# Esempio con Verdaccio (registry privato)
npm install -g verdaccio
# Configura .npmrc per usare il registry interno
# file: ~/.npmrc
registry=http://tuo-server-interno:4873/Il registry privato ti permette di:
Se qualcosa di male sta succedendo, lo vedrai in rete:
# Monitora con tcpdump (occhio, genera molto output)
sudo tcpdump -i eth0 -w /tmp/install.log &
# Dopo l'installazione, analizza
tcpdump -r /tmp/install.log | grep -E '(external|IP)'
# O usa ss per vedere connessioni sospette
ss -tnp | grep ESTABCerca connessioni verso IP strani, especially verso porte non standard (non 443, non 80).
Questo è il passo che la maggior parte salta e poi si pentono. Separa i tuoi ambienti:
# docker-compose.yml per build isolato
version: '3'
services:
builder:
image: node:18-alpine
volumes:
- ./code:/app
network_mode: "none" # RIATTENZIONE: rete disconnessa
# Ma serve internet per npm install? Allora:
# usa una rete dedicata con proxy filtratoL'ideale è avere una rete dedicata per il build che passa attraverso un proxy che logga tutto. Se il pacchetto cerca di parlare con un server di comando e controllo, lo vedi.
Usa strumenti come Socket o npm audit plus che analizzano il comportamento dei pacchetti:
# Socket analisi statica
npx @socketsecurity/cli analyze
# Output 示例:
# ⚠️ POTENTIAL_SCRIPT_EXECUTION
# Package: suspicious-package
# File: install.js
# Risk: Script eseguito durante installSe sei su GitHub Actions o GitLab CI, aggiungi step di scanning:
- name: Security Audit
run: |
npm audit --audit-level=high
npx @socketsecurity/cli analyzeOra testiamo che le contromisure funzionino. Crea un test semplice:
postinstall che scaricano codice da fonti esterne.# Crea una VM temporanea (non il tuo server di produzione!)
docker run -it node:18-alpine /bin/sh
# Prova ad installare il pacchetto sospetto
npm install <pacchetto-sospetto>
# Controlla i log
cat /var/log/syslog | grep npm# Se hai attivato il monitoraggio, cerca beaconing
tcpdump -r /tmp/install.log | awk '{print $3}' | sort | uniq -c | sort -rnSe vedi connessioni ripetute verso lo stesso IP a intervalli regolari, hai un malware attivo.
npm list di recente?postinstall scripts?Se hai almeno 3 "sì", dormi meglio. Se no, hai lavoro da fare.
D: Il mio antivirus non segnala nulla durante l'installazione. È normale?
Sì, purtroppo. I pacchetti malevoli spesso usano codice legittimo (PowerShell, curl, wget) che non viene riconosciuto come malware. Il problema è il contesto, non il binary.
D: Posso usare npm install --ignore-scripts sempre?
Puoi, ma poi devi fare il build manualmente. Molti pacchetti legittimi usano postinstall per compilare native modules. Se ignori sempre gli script, rompierai qualcosa.
D: Come faccio a sapere se un pacchetto è già stato compromesso nel mio progetto?
Guarda la cronologia git del package-lock.json. Se vedi cambiamenti che non hai fatto tu su dipendenze che non toccavi da mesi, indagano.
D: E pip? Anche pip è vulnerabile?
Assolutamente sì. Lo stesso meccanismo funziona con setup.py e pyproject.toml. Controlla sempre:
pip download <pacchetto>
unzip -l <pacchetto>.whlD: Il mio team si lamenterà se blocco tutto. Come gestisco la friction?
Inizia con il monitoraggio, non con il blocco. Mostra ai dev cosa sta succedendo nei log. Di solito quando vedono il beaconing verso IP strani, capiscono.
Gli attacchi agli strumenti developer sono il nuovo normale. I gruppi come Contagious Interview non mandano email di phishing — iniettano il malware direttamente nel tuo processo di build.
La difesa non è complicata, ma richiede disciplina:
Se hai già un antispam cloud come MailSniper, quello blocca le email di phishing classiche. Ma questi attacchi non passano per email. Servono contromisure a livello di sviluppo e infrastruttura.
Il tuo prossimo passo? Vai sui tuoi server di build stasera e controlla npm list. Adesso. Prima che qualcuno lo faccia per te.
Risorse utili:
Team MailSniper
Team MailSniper
Esperti di sicurezza email e protezione aziendale. Il team MailSniper analizza quotidianamente le minacce informatiche per offrire soluzioni all'avanguardia alle aziende italiane.
Scopri chi siamoUna telefonata apparentemente innocua. Un tecnico che si presenta in ufficio con un badge falso. In pochi minuti, i dati sensibili di decine di aziende americane sono stati esfiltrati e i manager si sono ritrovati con una richiesta di riscatto. È successo davvero, e il caso UNC3753 sta cambiando il modo in cui le aziende pensano alla sicurezza.
LeggiI criminali informatici hanno trovato un nuovo trucco: usano Google DoubleClick per nascondere il malware. Il risultato? Email che sembrano sicure perché arrivano da un dominio fidato, ma che in realtà ti installano un RAT. Ti spiego cosa sta succedendo e come difenderti senza impazzire.
LeggiIl gruppo SideCopy ha colpito il Ministero delle Finanze dell'Afghanistan con Xeno RAT. Se gestisci la posta aziendale, devi sapere come riconoscere questa campagna prima che sia troppo tardi. Ecco cosa cercare e come difenderti.
LeggiRicevi i nostri articoli e consigli direttamente nella tua casella di posta.
Scopri come MailSniper puo' proteggere le tue email aziendali con tecnologia AI di livello enterprise.