(in)sicurezza digitale

2026-06-03 12:47:05

Gamaredon sfrutta CVE-2025-8088 in WinRAR per distribuire GammaWorm e GammaSteel contro l’Ucraina

Si parla di:
Toggle

Il gruppo russo Gamaredon, legato all’FSB (Federalnaya Sluzhba Bezopasnosti), ha intensificato le sue operazioni contro l’Ucraina sfruttando una vulnerabilità recentemente scoperta in WinRAR per distribuire una sofisticata catena di malware multi-stadio. La campagna, osservata dai ricercatori di Sekoia nel gennaio 2026, utilizza una sequenza di payload denominati GammaPhish, GammaLoad, GammaWorm e GammaSteel — strumenti progettati per persistenza a lungo termine, propagazione laterale e esfiltrazione massiva di dati sensibili.

La vulnerabilità sfruttata: CVE-2025-8088

Il vettore iniziale di compromissione è la CVE-2025-8088, un path traversal flaw in WinRAR che consente l’estrazione di file in percorsi arbitrari del filesystem, incluse directory di avvio e cartelle di sistema. L’exploit si concretizza attraverso archivi RAR appositamente costruiti che, all’apertura, rilasciano silenziosamente un file HTA (HTML Application) denominato GammaPhish. La scelta di WinRAR come vettore non è casuale: il software è praticamente onnipresente negli ambienti governativi e militari ucraini, e Gamaredon ha già in passato sfruttato archivi RAR malevoli come vettore principale delle proprie campagne di spear-phishing.

La catena d’infezione: da GammaPhish a GammaSteel

Una volta eseguito, GammaPhish lancia GammaLoad, un downloader scritto in VBScript con tre funzioni primarie: fingerprinting del sistema host, aggiornamento della configurazione di rete nel registro di Windows tramite dead drop resolver (DDR), e recupero ed esecuzione di payload VBScript aggiuntivi dai server C2 dell’attaccante.

Da GammaLoad si biforcano i principali payload operativi. Il primo è GammaWorm, un worm VBScript progettato per garantire persistenza e propagazione laterale: stabilisce scheduled task come meccanismo di persistenza, poi individua le condivisioni di rete e i drive USB connessi al sistema infetto, ne nasconde le directory legittime e le sostituisce con file LNK (Windows Shortcut) malevoli. Quando una vittima nella rete clicca su uno di questi shortcut, viene scaricato ed eseguito codice arbitrario dal C2. Per risolvere l’indirizzo del server di comando, GammaWorm effettua una GET request tramite curl verso un canale Telegram pubblico hard-coded, sfruttando la legittimità della piattaforma per evadere i controlli di rete. I moduli core del worm vengono nascosti tramite NTFS Alternate Data Streams (ADS), rendendoli invisibili ai tool standard di ispezione del filesystem.

Il secondo payload principale è GammaSteel, un infostealer modulare che cattura file corrispondenti a specifiche estensioni (documenti Office, PDF, archivi, configurazioni) ed esfiltrate verso un bucket Amazon Web Services S3 controllato dagli attaccanti, con un server di fallback alternativo. La flessibilità dell’architettura permette anche la distribuzione di GammaWipe (GamaWiper), un componente distruttivo attivabile selettivamente a seconda degli obiettivi operativi.

Chi è Gamaredon e perché rappresenta una minaccia persistente

Gamaredon (noto anche come Primitive Bear, ACTINIUM, Armageddon, UAC-0010) è un APT attribuito ufficialmente all’FSB russo, specificamente al suo Centro 18 operante dalla Crimea. Attivo dal 2013, il gruppo si concentra quasi esclusivamente su target ucraini — enti governativi, militari, forze dell’ordine, organizzazioni del settore energetico — con campagne quasi ininterrotte che combinano spear-phishing tramite allegati RAR malevoli, malware custom VBScript e PowerShell, e tecniche di living-off-the-land. A differenza di gruppi più furtivi come APT29 o Turla, Gamaredon privilegia volume e persistenza, aggiornando costantemente i propri tool per sfuggire al rilevamento. L’analisi di Sekoia descrive questa architettura come “resiliente, massiva e altamente offuscata”: la capacità di aggiornare le configurazioni on the fly tramite Telegram DDR rende estremamente difficile bloccare le comunicazioni C2.

Campagne parallele: il fronte ucraino sotto attacco multiplo

La campagna Gamaredon si inserisce in un panorama di minacce concorrenti. UAC-0184 continua a colpire obiettivi militari ucraini con lure LNK che distribuiscono PassMark BurnInTest come carrier per payload malevoli. UAC-0247 (ex UAC-0244) ha preso di mira gli operatori di droni FPV, distribuendo dropper HTA via archivi ZIP con backdoor a reverse shell. Separatamente, ricercatori di ExaTrack hanno documentato l’evoluzione di PixyNetLoader, attribuito ad APT28, che sfrutta CVE-2026-21509 su Microsoft Office per rilasciare un implant COVENANT Grunt — varianti rilevate fino al 15 aprile 2026.

Due righe per i difensori

• Patching immediato di WinRAR all’ultima versione disponibile (CVE-2025-8088 è patchata)
• Blocco esecuzione HTA tramite Group Policy Object (GPO) e regole AppLocker
• Restrizione VBScript: disabilitare wscript.exe e cscript.exe dove non necessario
• Monitoraggio NTFS ADS su endpoint critici con Sysmon EventID 15
• Regole SIEM/YARA per curl verso endpoint Telegram in contesti non aziendali
• Blocco in uscita verso bucket AWS S3 sconosciuti e monitoraggio DNS per endpoint Telegram anomali
• Segmentazione USB: policy di blocco o controllo accessi ai supporti rimovibili

Indicatori di compromissione (IoC)

## Tecniche MITRE ATT&CK
T1566.001 – Spearphishing Attachment (archivi RAR malevoli)
T1204.002 – User Execution: Malicious File (GammaPhish HTA)
T1059.005 – Command and Scripting Interpreter: VBScript (GammaLoad/GammaWorm)
T1053.005 – Scheduled Task/Job (GammaWorm persistence)
T1091    – Replication Through Removable Media (GammaWorm USB spread)
T1027    – Obfuscated Files/Information: NTFS Alternate Data Streams
T1102.001 – Web Service: Dead Drop Resolver (Telegram per risoluzione C2)
T1041    – Exfiltration Over C2 Channel (GammaSteel → AWS S3)
T1485    – Data Destruction (GammaWipe, attivato selettivamente)

## Vulnerabilità sfruttata
CVE-2025-8088 – WinRAR path traversal
Soluzione: aggiornare WinRAR all'ultima versione

## Infrastruttura C2
- Canali Telegram pubblici (hard-coded nei sample GammaWorm per DDR)
- Bucket AWS S3 attaccante-controllati (esfiltrazione GammaSteel)
- Server fallback attaccante-controllati

## Fonte primaria della ricerca
Sekoia – FSBS Matryoshka 1.3:
https://blog.sekoia.io/fsbs-matryoshka-1-3-gamaredons-gifts-that-keeps-unpacking-gammaphish-and-gammaworm/

(in)sicurezza digitale

2026-06-03 13:05:28

Ciao Carola

Ci sono notizie che arrivano come un pugno nello stomaco.

Quella della morte di Carola Frediani è una di quelle.

Per chi vive e lavora nel mondo della cybersecurity italiana, Carola non era semplicemente una giornalista. Era una presenza costante. Una delle poche persone capaci di osservare il nostro settore con lucidità, spirito critico e una rara capacità di distinguere il rumore dai fatti.

In un’epoca in cui tutto deve essere urgente, allarmistico e spettacolare, Carola aveva scelto una strada diversa: quella della comprensione.

Leggevo con attenzione la sua newsletter, seguivo i suoi articoli, i suoi approfondimenti, il suo modo di raccontare la tecnologia e la sicurezza informatica senza mai cedere alla superficialità. Riusciva a parlare tanto agli addetti ai lavori quanto a chi si avvicinava per la prima volta a questi temi, senza mai banalizzare la complessità.

Ricordo ancora con orgoglio una circostanza che mi aveva particolarmente colpito: quando citò un articolo pubblicato sul mio blog all’interno di uno dei suoi approfondimenti (la newsletter Guerre di rete sul caso SIAE) dedicati a un caso nazionale. Un gesto probabilmente normale per chi fa giornalismo con serietà, ma che per me rappresentò un riconoscimento importante. Non tanto perché proveniva da una figura autorevole del settore, quanto perché arrivava da una persona che aveva costruito la propria credibilità sulla competenza e sull’onestà intellettuale.

Negli anni, Carola è stata una delle voci che hanno contribuito a definire il dibattito italiano sulla sorveglianza digitale, sul cybercrime, sulla sicurezza delle infrastrutture, sui diritti digitali e sulle implicazioni sociali delle tecnologie che utilizziamo ogni giorno.

Ha insegnato a molti di noi che la cybersecurity non riguarda soltanto malware, ransomware e vulnerabilità. Riguarda soprattutto persone. Riguarda libertà, informazione, potere e responsabilità.

Forse è proprio questo che rende oggi così difficile accettare questa notizia.

Perché quando scompare una persona come Carola, non perdiamo soltanto una professionista. Perdiamo una voce autorevole, indipendente e profondamente necessaria.

In un settore che spesso premia chi urla più forte, lei ha dimostrato che si può lasciare un segno anche parlando con calma, documentandosi con rigore e mantenendo sempre uno sguardo umano sulle storie che raccontava.

Oggi la comunità italiana della cybersecurity è un po’ più povera.

E molti di noi si sentono improvvisamente più soli.

Grazie, Carola, per tutto quello che hai scritto, spiegato e raccontato.

Grazie per aver contribuito a costruire una cultura della sicurezza informatica più matura, più consapevole e più umana.

Ci mancherai.

Guerre di Rete - Dell'attacco a SIAE

Facebook tra metaversi, nomi e liste. Guerra ai ransomware. Disinfo statale.

^{Carola Frediani (Guerre di Rete)}

(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.

Spcnet.it

2026-06-01 19:31:26

Microsoft Entra ID: da settembre 2026 solo metodi registrati per il reset password self-service

Cosa sta cambiando nel reset password di Entra ID

Microsoft ha annunciato una modifica sostanziale al funzionamento del portale Self-Service Password Reset (SSPR) di Microsoft Entra ID — il servizio di identity management un tempo noto come Azure Active Directory. A partire dal 7 settembre 2026, gli utenti potranno reimpostare la propria password solo tramite metodi di autenticazione ufficialmente registrati e verificati, non più attraverso semplici attributi di contatto presenti nel profilo.

Per gli amministratori IT, questo cambiamento richiede un’azione preventiva: verificare lo stato di registrazione degli utenti e comunicare la scadenza prima che l’enforcement entri in vigore.

La situazione attuale e il problema di sicurezza

Oggi Entra ID permette agli utenti di usare per l’SSPR dati come numero di telefono o email alternativa anche se questi non sono stati verificati tramite il flusso ufficiale di registrazione MFA/autenticazione. In pratica, un numero di telefono inserito nel profilo utente da un amministratore o importato da un sistema HR viene accettato come metodo valido di reset, senza che l’utente l’abbia mai confermato come proprio.

Questo approccio crea un vettore di attacco: se un attaccante riesce a modificare questi attributi del profilo (tramite compromissione di un account con privilegi di directory write), può dirottare il reset password verso un numero o un’email sotto il proprio controllo.

La nuova policy: solo metodi registrati e verificati

Dal 7 settembre 2026, SSPR accetterà esclusivamente metodi che l’utente ha registrato attivamente attraverso il portale aka.ms/mysecurityinfo o tramite il flusso combinato di registrazione MFA. I metodi validi includono:

• App di autenticazione (Microsoft Authenticator o TOTP compatibili)
• Telefono/SMS verificato tramite registrazione attiva
• Email alternativa verificata tramite registrazione attiva
• FIDO2 security key
• Windows Hello for Business

Gli attributi di contatto non verificati nel profilo utente (come mobilePhone o otherMails non passati attraverso il flusso di registrazione) non saranno più considerati metodi validi.

Timeline e notifiche

Microsoft attiverà una campagna di notifiche agli utenti a partire dal 6 luglio 2026, invitandoli a registrare almeno un metodo prima della scadenza. L’enforcement completo scatterà il 7 settembre 2026: da quella data, gli utenti senza metodi registrati non potranno più usare l’SSPR autonomamente e dovranno rivolgersi all’helpdesk.

Secondo i dati Microsoft, circa l’86% degli utenti risulta già conforme. Il restante 14% rappresenta il gruppo a rischio su cui concentrare le azioni correttive.

Come verificare lo stato di conformità degli utenti

L’Entra admin center offre report specifici per verificare chi ha metodi registrati. Il percorso è:

Entra admin center → Protezione → Metodi di autenticazione → Attività di registrazione

È possibile esportare i dati o consultarli via Microsoft Graph API. Ad esempio, per ottenere gli utenti senza metodi di autenticazione registrati:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails
$filter=isMfaRegistered eq false and isSsprRegistered eq false

In alternativa, con PowerShell e il modulo Microsoft.Graph:

Connect-MgGraph -Scopes "Reports.Read.All"

Get-MgReportAuthenticationMethodUserRegistrationDetail `
  -Filter "isSsprRegistered eq false" |
  Select-Object UserPrincipalName, IsMfaRegistered, IsSsprRegistered |
  Export-Csv "utenti_senza_sspr.csv" -NoTypeInformation

Azioni raccomandate per gli amministratori

Prima del 6 luglio (inizio campagna di notifiche Microsoft) è opportuno:

1. Eseguire il report sullo stato di registrazione dei metodi di autenticazione
2. Identificare gli account critici — specialmente quelli con accesso privilegiato — che non hanno metodi registrati
3. Comunicare proattivamente agli utenti la necessità di accedere ad aka.ms/mysecurityinfo e registrare almeno un metodo
4. Configurare le Conditional Access policies per il flusso di registrazione combinato se non già attive, facilitando la registrazione guidata al primo accesso
5. Verificare i Service Account: gli account non interattivi non usano SSPR, ma è buona pratica escluderli esplicitamente dalle policy SSPR per evitare false anomalie nei report

Come abilitare la registrazione combinata

Se non ancora abilitata, la registrazione combinata MFA + SSPR si attiva da:

Entra admin center → Identità → Panoramica → Proprietà
→ Gestisci impostazioni di sicurezza predefinite (oppure)

Entra admin center → Protezione → Metodi di autenticazione → Criteri
→ Abilitare "Registrazione combinata delle informazioni di sicurezza"

Con la registrazione combinata, la prima volta che un utente accede viene guidato nella configurazione di tutti i metodi richiesti, riducendo l’attrito e aumentando la compliance.

Conclusione

La modifica al SSPR di Entra ID è un passo logico verso un modello di autenticazione più rigoroso: garantire che ogni metodo usato per il reset della password sia stato effettivamente verificato dall’utente riduce significativamente il rischio di account takeover via social engineering o directory poisoning. Il 14% di utenti non conformi rappresenta comunque un numero da non sottovalutare in organizzazioni di grandi dimensioni, e il lavoro di remediation va pianificato con anticipo rispetto alla scadenza di settembre.

Fonte: 4sysops.com

Microsoft mandates registered authentication for Entra ID password resets – 4sysops

Microsoft Entra ID, the identity management system formerly known as Azure Active Directory, is implementing stricter security for its Self-Service Password Res

^{IT News (4sysops)}

Spcnet.it

2026-06-01 19:31:15

Visual Studio Code 1.123: Agents window, Electron 42 e nuovi workflow AI

Cosa c’è di nuovo in Visual Studio Code 1.123

Microsoft ha rilasciato Visual Studio Code 1.123, l’aggiornamento di fine maggio 2026 che porta novità significative sia sul fronte dell’AI agentica che sull’architettura interna dell’editor. Questa versione consolida il lavoro delle ultime iterazioni e introduce funzionalità pensate per chi usa VS Code come ambiente di sviluppo con assistenti AI attivi.

Aggiornamento del motore: Electron 42, Chromium 148 e Node.js 22

Il cambiamento più strutturale di questa release riguarda l’aggiornamento di Electron alla versione 42, che porta con sé Chromium 148 e Node.js 22.x. Si tratta di un passaggio importante per la stabilità, la sicurezza e le performance dell’editor, soprattutto in ambienti enterprise dove le versioni precedenti di Chromium potevano rappresentare un rischio per le vulnerability note. Node.js 22 introduce miglioramenti alle performance V8 e alle API native, con impatti positivi sull’estensibilità e sui Language Server Protocol.

La finestra Agents diventa il centro di controllo AI

La funzionalità più rilevante per gli sviluppatori che lavorano con workflow AI agentici è la possibilità di trasferire una sessione di chat da VS Code alla finestra standalone Agents. Questo significa che una conversazione avviata nell’editor può continuare in un’esperienza dedicata, ottimizzata per la gestione di sessioni multiple.

La finestra Agents introduce anche:

• Un layout a griglia per la visualizzazione delle sessioni attive
• Risposte threaded per il feedback su azioni specifiche dell’agente
• Batching delle notifiche terminale: quando un agente esegue più comandi in parallelo, le notifiche di completamento vengono raggruppate in un unico messaggio invece di generare un turno separato per ogni processo

Quest’ultimo punto è particolarmente utile in scenari DevOps dove un agente può avviare build, test e deployment in contemporanea: la chat rimane leggibile e non viene inondata da notifiche atomiche.

Miglioramenti all’interazione con Copilot e modelli AI

VS Code 1.123 introduce la possibilità di inviare richieste a Copilot o ad altri modelli AI allegando solo file o immagini, senza testo aggiuntivo. Questo semplifica i flussi in cui si vuole analizzare un’immagine o un documento senza dover scrivere un messaggio esplicativo.

Nel browser integrato è ora possibile selezionare un’area della pagina tramite screenshot e aggiungerla direttamente come contesto nella chat. Una funzione utile per chi debugga interfacce web e vuole mostrare all’AI un componente specifico senza dover descrivere il problema a parole.

Fix critico per CLI su Windows

Per chi usa VS Code da riga di comando su Windows, viene risolto un bug fastidioso: i flag --folder-uri e --file-uri fallivano silenziosamente se non posizionati come ultimo argomento, o se combinati con --wait. Il fix garantisce che questi flag funzionino correttamente indipendentemente dall’ordine degli argomenti:

# Prima del fix, questo poteva fallire silenziosamente su Windows:
code --folder-uri vscode-remote://ssh-remote+myserver/home/user/project --wait

# Con VS Code 1.123 il comportamento è ora prevedibile e corretto

Altre novità degne di nota

Tra i fix minori ma utili nella pratica quotidiana:

• Copilot Cloud tasks ora mostra lo stesso formato visivo (tool card, diff, output terminale) delle sessioni CLI locali, uniformando l’esperienza tra cloud e locale
• Il comando /doc in Python non inserisce più la docstring prima dei decorator ma correttamente all’interno del corpo della funzione
• I modelli BYOK (Bring Your Own Key) come quelli di OpenRouter e DeepSeek non generano più errori HTTP 400 dopo le tool call
• I sottocomandi dei file prompt possono ora essere invocati con uno spazio invece dei due punti: /chronicle tips invece di /chronicle:tips
• L’editor delle impostazioni di personalizzazione AI ora usa una header compatta per un look più pulito
• Le impostazioni relative al browser integrato sono ora organizzate in una sezione dedicata

Come aggiornare

VS Code si aggiorna automaticamente, ma per forzare l’aggiornamento o verificare la versione corrente è sufficiente aprire la palette dei comandi (Ctrl+Shift+P su Windows/Linux, Cmd+Shift+P su macOS) e digitare Check for Updates. In ambienti con aggiornamenti gestiti centralmente, l’installer è disponibile direttamente su code.visualstudio.com.

Conclusione

VS Code 1.123 è un aggiornamento solido che consolida il posizionamento dell’editor come piattaforma AI-first. L’aggiornamento a Electron 42 risolve debiti tecnici accumulati, mentre le nuove funzionalità degli Agents window mostrano la direzione verso cui Microsoft vuole portare il workflow degli sviluppatori: sessioni AI persistenti, multitasking parallelo e un’interfaccia sempre più integrata tra editor, terminale e assistente.

Fonte: 4sysops.com — Note ufficiali di rilascio VS Code 1.123

Visual Studio Code 1.123 updates AI agent workflows and core engine – 4sysops

Visual Studio Code 1.123 introduces significant updates to its integrated AI capabilities and underlying platform architecture. The editor now runs on Electron

^{IT News (4sysops)}