(in)sicurezza digitale

2026-06-02 17:17:28

Miasma colpisce Red Hat: 33 pacchetti npm avvelenati per rubare credenziali cloud e segreti CI/CD

Trentatré pacchetti npm appartenenti al namespace ufficiale @redhat-cloud-services di Red Hat sono stati compromessi in quello che i ricercatori hanno battezzato la campagna Miasma — una variante evoluta del worm Shai-Hulud già visto colpire l’ecosistema npm. L’attacco ha già contaminato 309 repository GitHub e si è dimostrato capace di sottrarre credenziali di sviluppatori, segreti CI/CD, chiavi SSH e token cloud in modo silenzioso e automatizzato.

Contesto: il worm Shai-Hulud e la famiglia Miasma

Shai-Hulud è emerso come uno dei più sofisticati worm per l’ecosistema npm: combina esecuzione automatica al momento dell’installazione, furto di credenziali multi-target ed esfiltrazione crittografata. La campagna Miasma ne eredita interamente il modus operandi, con alcune innovazioni tecniche — in particolare l’abuso dell’infrastruttura di GitHub e dei servizi Anthropic per staging e fallback di esfiltrazione.

Secondo i ricercatori di Socket, che hanno identificato la campagna, l’attore avrebbe compromesso l’account GitHub di un dipendente Red Hat per pubblicare versioni avvelenate di pacchetti legittimi già ampiamente usati nella toolchain interna di Red Hat Cloud Services. Red Hat ha confermato la rimozione dei pacchetti, precisando che l’impatto era limitato agli strumenti di sviluppo interni — ma la contaminazione di 309 repository GitHub suggerisce una diffusione ben più ampia.

Catena di infezione: dall’npm install alla sottrazione silenziosa

Il meccanismo di innesco è elegante nella sua semplicità: il file package.json dei pacchetti compromessi contiene un hook "preinstall": "node index.js", il che significa che il payload malevolo viene eseguito automaticamente prima che l’installazione del pacchetto si completi — prima ancora che lo sviluppatore possa rendersi conto di cosa sta succedendo.

Il loader di primo stadio utilizza una serie di tecniche di offuscamento: array di char-code, trasformazioni ROT-style e blob cifrati con AES-128-GCM. Una volta deoffuscato, il codice decifra e deposita il payload principale in /tmp/p*.js, lo esegue attraverso Bun (runtime JavaScript ad alte prestazioni) — scaricando silenziosamente Bun da GitHub se non è presente sul sistema.

Il malware esegue quindi una raccolta sistematica di credenziali sensibili, includendo:

• Segreti GitHub Actions e token npm (~/.npmrc)
• Credenziali cloud AWS (~/.aws/credentials), GCP, Azure
• Materiale Kubernetes e HashiCorp Vault
• Chiavi SSH private (~/.ssh/id_rsa, ~/.ssh/id_ed25519)
• Credenziali Git (~/.git-credentials, ~/.netrc)
• Token GitHub CLI via gh auth token

I dati sottratti vengono codificati in Base64, cifrati e inviati via HTTPS POST a un endpoint di esfiltrazione. In caso di fallimento, il malware utilizza un meccanismo di fallback basato su commit GitHub, scrivendo file results–.json in un repository controllato dall’attore — una tecnica dead-drop che sfrutta l’infrastruttura legittima di GitHub per eludere il filtraggio del traffico di rete.

Dettagli tecnici distintivi

Tra gli elementi più caratteristici dell’attacco:

• Anti-analisi per sistemi russi: il malware verifica la locale di sistema e modifica il comportamento su macchine con lingua russa, suggerendo un attore non russo o comunque attento a evitare incidenti diplomatici.
• Esfiltrazione verso api.anthropic.com: il traffico di esfiltrazione è mascherato come chiamata alle API Anthropic sulla porta 443, rendendo il traffico praticamente indistinguibile da quello legittimo in ambienti che usano LLM.
• Commit marker univoco: il codice include la stringa IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner e il messaggio di commit Miasma: The Spreading Blight, probabilmente un segno di sfida agli analisti.
• Tentativo di escalation su CI runner: il malware tenta esecuzione privilegiata via sudo su runner CI, espandendo l’accesso sugli ambienti di build.

Indicatori di compromissione (IoC)

# Pacchetti npm compromessi
@redhat-cloud-services/chrome (v2.3.1 e altre versioni)
@redhat-cloud-services/* (oltre 30 pacchetti nel namespace)

# Artefatti su filesystem
/tmp/p*.js                        # payload principale
/tmp/tmp.0987654321.lock          # file di lock del daemon
b.zip, bun, bun.exe               # runtime scaricato

# File di esfiltrazione fallback
results–.json
results/results–.json

# Endpoint di rete
api.anthropic[.]com:443/v1/api    # esfiltrazione mascherata
api.github[.]com/graphql          # fallback dead-drop
github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/  # staging Bun

# Hash SHA-256
88896d478986d453f5da79b311de39d9b4b1bea95c21af1d8ef181b0f4e52fe9
21b6409a7b84446310daca5409ad6112ac60a1e4bef97736e53fff5f63bfdef4

Attribuzione e collegamento a TeamPCP

L’attribuzione rimane incerta. La disponibilità pubblica del tooling Shai-Hulud ha abbassato la soglia d’ingresso per più attori, rendendo difficile l’attribuzione univoca. I ricercatori notano tuttavia sovrapposizioni tattiche con il gruppo TeamPCP, già collegato ad attività su BreachForums, e con la campagna Mini Shai-Hulud documentata separatamente nello stesso periodo. La scelta di Red Hat come target — un vendor open-source con un ecosistema di sviluppatori ampio e credenziali cloud spesso ad alto privilegio — suggerisce un interesse specifico per l’accesso alle pipeline DevOps enterprise.

Cosa devono fare i difensori

Per i team di sicurezza che gestiscono ambienti con dipendenze npm, le azioni prioritarie sono:

• Audit immediato di tutti i pacchetti @redhat-cloud-services/* installati nell’ultimo mese, verificando gli hash contro le versioni ufficiali ripristinate.
• Rotazione preventiva di tutte le credenziali accessibili dagli ambienti di build: npm tokens, chiavi SSH, credenziali AWS/GCP/Azure, segreti GitHub Actions.
• Blocco dei lifecycle hook npm in ambienti CI/CD tramite la configurazione ignore-scripts=true in .npmrc — questa misura da sola avrebbe impedito l’esecuzione automatica del payload.
• Monitoraggio anomalo del traffico verso api.anthropic.com e api.github.com da processi node/bun inattesi.
• Revisione degli hook preinstall in tutti i pacchetti npm di terze parti nel registro privato aziendale.

La campagna Miasma rappresenta un salto qualitativo nell’ingegneria degli attacchi supply chain npm: non si limita a iniettare payload semplici, ma costruisce un’intera infrastruttura di persistenza, esfiltrazione ridondante e anti-analisi che rende difficile sia il rilevamento che la remediation completa.

(in)sicurezza digitale

2026-06-01 19:27:49

Operazione Olanda: smantellata la botnet Asocks da 17 milioni di dispositivi — ma il lavoro non è finito

Le autorità olandesi hanno smantellato una delle botnet più grandi mai documentate in Europa: 17 milioni di dispositivi compromessi in 163 paesi, controllati da oltre 200 server ospitati nei Paesi Bassi. Il servizio in questione era Asocks, una piattaforma di proxy residenziali che vendeva l’accesso alle macchine infette — computer, smartphone, router, dispositivi IoT domestici — ad altri criminali informatici per mascherare traffico malevolo come normale navigazione casalinga. Un caso che illumina il modello di business del proxy-as-a-crime del cybercrime contemporaneo.

L’operazione: polizia e NCSC agiscono di Concerto

L’intervento, eseguito tra il 28 e il 29 maggio 2026, è stato condotto dalla Politie olandese in collaborazione con il National Cyber Security Centre (NCSC). Gli agenti hanno fisicamente sequestrato un sottoinsieme dei server di backend da un provider di hosting nei Paesi Bassi che aveva fornito l’infrastruttura alla piattaforma. Il provider ha quindi proceduto a portare offline l’intera rete botnet una volta appurato il suo utilizzo per finalità criminali.

Secondo la dichiarazione dell’NCSC, la rete aveva silenziosamente compromesso 17 milioni di dispositivi attraverso 163 paesi. La composizione era eterogenea: computer desktop e laptop, tablet, smartphone Android, router domestici, smart home gadget e altri dispositivi IoT. Nessuna categoria di device connessa era immune: se accessibile, diventava un potenziale nodo della rete.

Asocks: il modello di business del proxy residenziale criminale

Il quotidiano locale NL Times ha identificato il servizio come Asocks, una piattaforma commerciale di proxy residenziali. Asocks non era solo uno strumento di hacking — era un servizio con un modello di business strutturato. Il sito pubblicizzava proxy aziendali, residenziali e mobili con abbonamenti mensili compresi tra $5 e $15, con sconti del 5-15% per acquisti bulk da 10 a 100 proxy.

La logica è semplice quanto efficace: se un criminale vuole condurre un attacco, una frode, uno scraping aggressivo o un test di credential stuffing, farlo dal proprio indirizzo IP è pericoloso. Se lo fa dall’IP di un appartamento a Rotterdam o da uno smartphone in Indonesia, il traffico appare come normale attività domestica. I difensori devono distinguere il legittimo dal malevolo in un mare di indirizzi residenziali puliti — un compito enormemente più difficile.

I proxy residenziali hanno usi legittimi: aggirare restrizioni geografiche, privacy personale, test di geolocalizzazione per aziende. Ma l’ecosistema ha un lato oscuro documentato: molti provider, come Asocks, costruiscono le loro reti infettando dispositivi a insaputa dei proprietari. In aprile 2024, il team Satori Threat Intelligence di HUMAN aveva già identificato una campagna denominata PROXYLIB che coinvolgeva dispositivi Android infetti con proxyware di LumiApps e Asocks.

Il problema che persiste: sito online, dispositivi ancora infetti

L’operazione presenta un limite strutturale fondamentale che le autorità stesse non nascondono: il sito web di Asocks è rimasto accessibile dopo il sequestro, e ogni singolo dispositivo compromesso è ancora infetto. Questo è il paradosso intrinseco delle operazioni contro le botnet basate su proxy residenziali: l’infrastruttura centrale è stata neutralizzata, ma i 17 milioni di endpoint infetti sparsi in tutto il mondo rimangono con il malware installato, pronti a essere reintegrati in una nuova rete di comando non appena l’operatore ricostruisca l’infrastruttura o venda l’accesso a un nuovo gestore.

Il caso ricorda operazioni precedenti contro reti analoghe: la disruzione di SocksEscort (marzo 2026), l’intervento contro BADBOX 2.0 che aveva infettato un milione di dispositivi (2025), e lo smantellamento di IPIDea (gennaio 2026) da parte di Google. Il pattern è ricorrente: le autorità colpiscono l’infrastruttura, ma la re-infezione dei dispositivi vulnerabili è questione di tempo se i proprietari non prendono contromisure attive.

Come funziona l’infezione e come difendersi

Come spiegato dall’NCSC, i dispositivi diventano parte di una botnet quando sono accessibili ad attori malevoli. Dopo aver ottenuto l’accesso, gli attaccanti installano malware che permette il controllo remoto del dispositivo, integrandolo nella rete usata per attività criminali. I vettori di infezione più comuni includono: app Android scaricate da store non ufficiali con proxyware nascosto, router domestici con credenziali di default o firmware obsoleto, dispositivi IoT con password di fabbrica mai cambiate, e exploit di vulnerabilità note in dispositivi edge non aggiornati.

L’NCSC raccomanda un insieme di misure difensive di base che, se applicate sistematicamente, riducono drasticamente la superficie di attacco. Per i singoli utenti: mantenere i sistemi operativi aggiornati, installare app solo da fonti attendibili, usare password robuste e uniche per ogni dispositivo, abilitare l’autenticazione a due fattori dove disponibile, cambiare le password predefinite su router e dispositivi IoT, proteggere le reti Wi-Fi con WPA2 o WPA3. Per le organizzazioni: mantenere visibilità sui dispositivi edge come router e firewall, monitorare il traffico in uscita per pattern anomali, segmentare la rete IoT da quella aziendale, e implementare sistemi di rilevamento delle anomalie che identifichino picchi insoliti di traffico uscente.

Il contesto: un’industria del proxy residenziale da regolamentare

L’operazione olandese si inserisce in un dibattito più ampio su come trattare il settore dei proxy residenziali. La linea tra servizi legittimi e infrastruttura criminale è spesso sottile: alcuni provider costruiscono reti con consenso esplicito degli utenti, che vengono compensati per condividere la loro larghezza di banda; altri come Asocks costruiscono le loro reti infettando dispositivi senza alcun consenso. Dal punto di vista del difensore, la distinzione è quasi irrilevante: il traffico malevolo che arriva da un proxy residenziale “consensuale” è indistinguibile da quello che usa un dispositivo compromesso.

Questa operazione è un segnale importante delle forze dell’ordine europee nella direzione di trattare i provider di proxy residenziali costruiti su dispositivi compromessi come infrastruttura criminale diretta, non come semplici facilitatori passivi. La prossimità geografica — i server erano fisicamente nei Paesi Bassi — ha reso possibile l’azione legale che operazioni distribuite globalmente rendono molto più complessa.

Fonti: The Hacker News, BleepingComputer, NL Times, NCSC Olanda — maggio 2026.

(in)sicurezza digitale

2026-06-01 19:30:08

Cyber Isnaad Front: l’IRGC sabota un impianto alimentare israeliano con malware GRAT e attacco OT ai compressori CO2

Durante una tregua dichiarata, le macchine di un impianto alimentare israeliano hanno cominciato a scaldarsi. Non era un guasto: era sabotaggio pianificato. Il gruppo Cyber Isnaad Front, una persona operativa dell’IRGC iraniano, aveva già compromesso sia la rete IT che i controllori OT industriali, preparandosi a distruggere compressori e cancellare dati con un singolo comando. Il rapporto Profero di maggio 2026 svela un’operazione che ridefinisce la minaccia ibrida IT/OT nel contesto del conflitto Iran-Israele.

La guerra tra le guerre

Il sistema strategico israeliano ha un nome per la competizione a bassa intensità che prosegue nelle pause tra i conflitti dichiarati: la campagna tra le guerre. Il cyber è diventato uno di questi domini. Dopo gli scambi cinetici tra Israele e Iran a metà 2025 e la pausa instabile che ne è seguita, il ritmo delle operazioni cyber non è calato. È aumentato. Gli operatori iraniani trattano un cessate il fuoco non come una pausa, ma come copertura: l’attenzione cala, i difensori abbassano la guardia, e il costo politico di un’intrusione nella rete è di gran lunga inferiore al costo di un missile.

Il primo segnale non fu un alert di sicurezza. Fu una lettura di temperatura anomala. Gli ingegneri di un impianto di produzione alimentare vennero chiamati perché le celle frigorifere si stavano riscaldando. Si aspettavano quello che trovano di solito: un compressore guasto, una valvola che perde, una protezione scattata. Arrivarono pronti a riparare una macchina. Trovarono invece che qualcuno era già stato dentro quella macchina, e l’aveva modificata di proposito.

Chi è Cyber Isnaad Front: una facciata per l’IRGC

Profero attribuisce questa attività a Cyber Isnaad Front, una persona cyber diretta dallo Stato iraniano emersa nel giugno 2025. Il nome, dall’arabo, si traduce come “Fronte di Supporto Cyber”, e la persona si presenta come un collettivo hacktivist arabo indipendente. Non è indipendente, e non è hacktivismo in nessun senso significativo.

Profero valuta con alta confidenza che Cyber Isnaad Front sia gestita da o insieme ad Aria Sepehr Ayandehsazan (ASA), il successore affiliato all’IRGC di Emennet Pasargad — l’entità sanzionata dal Tesoro americano per operazioni di influenza cyber contro le elezioni presidenziali USA del 2020. ASA gestisce un cast rotante di persone contro obiettivi israeliani: quando un marchio viene esposto, gli operatori lo ritirano e ne lanciano uno nuovo. La macchina non cambia. Il gruppo ha rivendicato appaltatori della difesa legati ai principali programmi d’arma israeliani, circa cinque terabyte da un fornitore nazionale di logistica carburante, e accessi che hanno colpito più di 160 clienti di data center telecom. Le rivendicazioni pubbliche sono spesso esagerate — fanno parte del prodotto. Ma gli accessi reali sono documentati.

GRAT: il malware che indossa il badge di Microsoft

Sul lato Windows dell’impianto, i responder di Profero hanno recuperato una famiglia di malware denominata GRAT (Go Remote Access Toolkit). Non sembra gran che: è un singolo eseguibile che lavora duramente per sembrare noioso. Nei campioni analizzati, si è trovato come SpellChecker.exe, Checker.exe.exe e WindowsUpdater.exe, in esecuzione da directory scrivibili dall’utente come C:\Users\[user]\AppData\Roaming\Microsoft\Spelling\. Persiste attraverso un task schedulato denominato “OneDrive Update” che lo riavvia ogni minuto e ad ogni boot, nascosto e al massimo privilegio.

Dietro quell’esterior banale si nasconde un binario singolo che raggruppa undici sottosistemi separati. GRAT può enumerare un host fino al suo stato antivirus e BitLocker, gestire processi, riscrivere il registro, manipolare i servizi Windows, eseguire un server VNC completo con iniezione sintetica di tasti, esfiltrare file verso cloud storage controllato dall’attaccante. Include un modulo di cifratura per il riscatto chiamato “BigBang”. E può cancellare completamente i dischi: con un singolo comando, GRAT sovrascrive il disco fisico e poi distrugge la partition table. Una variante multi-pass usa syscall dirette per un’operazione di zero, random e 0xFF. Un host che riceve quel comando non torna indietro — non resta nulla da cui recuperare.

Il C2 usa un’architettura dual-channel: i comandi arrivano tramite RabbitMQ incapsulato in TLS sulla porta 7878, e i risultati ritornano attraverso un canale Redis plain-text sulla porta 9988, entrambi diretti allo stesso server 84[.]201[.]6[.]131. Ogni parametro di connessione è cifrato AES-256 all’interno del binario, e la chiave ruota con ogni build — firma di un builder: un campione codificato per target, così che craccare uno non compromette gli altri.

L’attacco OT: sabotaggio calcolato ai sistemi di refrigerazione CO2

L’impianto operava due sistemi di refrigerazione industriale, uno vecchio e uno nuovo, entrambi costruiti su CO2 (R-744) come refrigerante. L’attaccante li ha trattati diversamente, e la differenza è istruttiva.

Sul sistema vecchio, l’attaccante ha modificato solo parametri: setpoint, soglie di protezione, limiti di allarme. Pericoloso, ma recuperabile nella stessa serata. Sul sistema nuovo è andato molto più in profondità: ha cancellato e ripristinato l’intera configurazione programmatica del controller — input digitali e analogici mappati ai sensori di temperatura e pressione, output digitali che avviano i compressori, output analogici per valvole motorizzate e ventole, input di fault. Tutto azzerato. Il recupero non era “reimposta un valore”: era re-ingegnerizzare il controller da zero, tracciando ogni cavo nel quadro elettrico contro lo schema, identificandolo nel programma, e ridefinendolo nel controller. Un lavoro di giorni.

La mossa finale ha trasformato una modifica di configurazione in distruzione fisica. Le valvole motorizzate che gestiscono la pressione del gas sono state impostate in modalità manuale e bloccate permanentemente aperte. L’intento era specifico: mantenere il refrigerante in movimento senza nulla per contenerlo. In un sistema CO2, il liquido che raggiunge i compressori causa danni catastrofici — il liquido non è comprimibile. Un pistone che tenta di comprimere una sacca di liquido si rompe. Il CO2 liquido poi, riscaldandosi, aumenta la pressione in modo esponenziale; le valvole di sicurezza si aprono e sfiatano il refrigerante nell’atmosfera, svuotando l’impianto.

Quando gli ingegneri hanno cercato di riavviare il sistema, tre compressori erano stati distrutti. Il recupero ha richiesto diversi giorni: sostituzione di compressori, valvole, filtri, pressostati e altri componenti, poi test di pressione, test di vuoto e ricarica con R-744. Un compressore sostitutivo era ancora in attesa dal produttore all’estero. Nessun malware aveva girato sui controllori OT — l’attaccante aveva bisogno solo di setpoint, modalità delle valvole, e una comprensione profonda della termodinamica del refrigerante. La distruzione era stata eseguita nel linguaggio nativo dell’impianto.

Indicatori di Compromissione (IoC)

## NETWORK INDICATORS
C2 command channel:  84[.]201[.]6[.]131:7878  (RabbitMQ over TLS)
C2 results channel:  84[.]201[.]6[.]131:9988  (Redis plain TCP)
Infrastruttura associata (confidenza minore):
  146[.]103[.]40[.]190
  193[.]29[.]104[.]5
  45[.]82[.]66[.]163
  84[.]201[.]6[.]128 / 84[.]201[.]6[.]129
  85[.]137[.]56[.]9
  85[.]17[.]55[.]232
## FILE HASHES (SHA-256)
Checker.exe.exe:        6f5f427d96656ae51405e6a5e65253759db45ea0a17da2d70f881404a4ed717b
WindowsUpdater.exe:     0ad128e813314e4562489478e6def8c6dfcc251e006d7f55b24273e93d3bc7fb
SpellChecker.exe:       c4909b2d7a7f813b5a3d729fe64535033e716ae89dc39c402a6cb8ccbccaadca
WindowsUpdater.exe(2):  86194eb5c5abcfe763899aaad7eb64894c71e816dd7d27427c8bac4ab280533d
## PERSISTENCE
Scheduled Task:  "OneDrive Update" (ogni minuto + boot)
File paths:
  C:\Users\[user]\AppData\Roaming\Microsoft\Spelling\SpellChecker.exe
  C:\ProgramData\WindowsUpdater.exe
Registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\OneDrive Update
## DETECTION
Microsoft detection name:  DoS:Win32/GigaWiper.A!dha
File size:                 10,416,128 bytes (tutti i campioni analizzati)
Topic-exchange prefix:     topicArgs:1562578125

Due righe per i difensori

Lato IT: Cercare task schedulati che eseguono binari non firmati da %APPDATA% o C:\ProgramData, specialmente task con nomi di prodotti Microsoft. Allertarsi su traffico verso 84[.]201[.]6[.]131 e su connessioni AMQPS o Redis verso le porte 7878 e 9988. Il canale Redis risultati è plain TCP: la cattura passiva di traffico RPush con chiavi task:{task_id} conferma un’infezione attiva. Bloccare gli hash indicati e trattare qualsiasi host con rilevamento DoS:Win32/GigaWiper.A!dha come compromesso: isolarlo e conservare un’immagine del disco prima della remediation. Applicare patch a sistemi VPN, edge e SharePoint esposti su Internet, vettori di accesso iniziale abituali per questo attore.

Lato OT: Segmentare le reti di controllo dall’IT. Rimuovere o mediare strettamente l’accesso remoto ai controller centrali, con credenziali univoche, monitorate e recuperabili attraverso un percorso che l’attaccante non possa bloccare. Allarmarsi su modifiche fuori banda a setpoint e modalità operative — non solo sui valori di processo — perché in questo incidente gli allarmi stessi erano stati resintonizzati. Conservare backup offline con controllo di versione dei programmi controller: il recupero da un controller cancellato deve essere un ripristino, non un esercizio di reverse-engineering. E fare drill: un esercizio tabletop che simuli un’intrusione IT-to-OT end-to-end vale più di qualsiasi singolo prodotto.

Fonte primaria: Profero Threat Intelligence — “The War Between Wars” (maggio 2026). La regola YARA completa e il mapping MITRE ATT&CK per ICS sono disponibili nel report originale su profero.io.