Spcnet.it

2026-06-03 19:49:42

Windows 365 for Agents: Cloud PC per l’automazione AI in azienda

Cosa sono i Windows 365 for Agents?

Microsoft ha annunciato in public preview Windows 365 for Agents, una nuova offerta che estende la piattaforma Cloud PC per supportare l’automazione basata su agenti AI. L’idea di fondo è semplice ma potente: invece di assegnare un Cloud PC a un utente umano, lo si mette a disposizione di un agente AI che ne ha bisogno per completare un’attività che richiede l’interazione con un’interfaccia grafica — un browser, un’applicazione legacy, un portale web senza API.

Il servizio è attualmente disponibile in anteprima pubblica esclusivamente negli Stati Uniti, quindi prima di pianificare un’implementazione conviene verificare la disponibilità del tenant.

Perché un Cloud PC per un agente AI?

La domanda legittima è: perché un agente AI dovrebbe aver bisogno di un Cloud PC? Molti workflow di automazione si completano già tramite API, connettori o strumenti MCP. Ma esistono scenari reali in cui questo non è possibile:

• Applicazioni legacy che non espongono API
• Portali web che richiedono interazione manuale con elementi UI
• Processi che dipendono da software desktop non modernizzato
• Task che richiedono la gestione di file locali tramite interfaccia grafica

In questi casi, l’agente ha bisogno di un ambiente desktop reale su cui operare — e Windows 365 for Agents fornisce esattamente questo, con un modello di sicurezza, identità e governance pensato per le organizzazioni enterprise.

Architettura: pool e check-out/check-in

Il meccanismo centrale è il Cloud PC agent pool: un insieme condiviso di Cloud PC pre-provisionati con proprietà comuni (piano di billing, regione geografica, numero di istanze, immagine). Gli agenti non hanno un Cloud PC dedicato — usano un modello di check-out/check-in:

1. L’agente prenota un Cloud PC disponibile nel pool
2. Esegue il proprio task
3. Restituisce il Cloud PC al pool
4. Il Cloud PC viene resettato prima del riutilizzo

Microsoft descrive quattro piani operativi per l’architettura degli agenti:

• Computer-Create: provisioning e manutenzione dei pool
• Computer-Get: prenotazione e rilascio dei Cloud PC
• Computer-Do: invio di azioni (click, digitazione, ecc.)
• Computer-See / Computer-TakeControl: osservazione e controllo manuale da parte di un operatore umano

La superficie di controllo in-session usa il Model Context Protocol (MCP), lo stesso protocollo che permette agli agenti AI di scoprire e chiamare strumenti esterni in modo standardizzato.

Modello di sicurezza e identità

I Cloud PC for Agents sono Microsoft Entra-joined e Intune-enrolled. Ogni agente opera con una propria identità dedicata in Microsoft Entra — non viene riutilizzata o impersonata l’identità di un utente umano. Questo è un punto importante per la governance: ogni azione dell’agente è tracciabile e attribuibile a un’identità specifica.

Il supporto attuale alle Conditional Access per le identità agente include il controllo Block access, ma Microsoft chiarisce che non è ancora un sostituto completo per tutti i pattern di Conditional Access usati con gli utenti umani. Da tenere in considerazione prima di portare in produzione scenari critici.

Come configurare Windows 365 for Agents

Il processo di configurazione richiede alcuni prerequisiti:

• Una licenza Windows 365 o Agent 365 nel tenant
• Un piano di billing Windows 365 for Agents attivo
• Opzionalmente, utenti agente in Agent 365

Passo 1: creare la Billing Policy

Nel Microsoft 365 admin center, andare su Billing & usage → Billing policies. Selezionare una sottoscrizione Azure, un resource group e una regione, quindi abilitare Windows 365 for Agents sotto Pay-as-you-go services.

Passo 2: creare la Provisioning Policy per agenti

Nel Microsoft Intune admin center, navigare su Devices → Provision Cloud PCs → Provisioning policies (Agents) → Create policy. La procedura guidata richiede:

• Nome della policy
• Piano di billing
• Numero di Cloud PC always-available (da 1 a 200)
• Area geografica
• Agenti assegnati
• Immagine e impostazioni di lingua

Nota: i gruppi utente non sono attualmente supportati per l’assegnazione degli agenti. Il provisioning richiede circa 20-30 minuti.

Monitoraggio e costi

I Cloud PC for Agents sono visibili in Intune admin center sotto Devices → All devices. Si riconoscono dal prefisso CPCA- nel nome, dal modello Cloud PC for Agents e dal profilo di enrollment che riporta il nome della provisioning policy.

Per monitorare la capacità del pool: Devices → Provision Cloud PCs → Provisioning policies (Agents), selezionare una policy e verificare le sessioni attive e disponibili.

Sul fronte dei costi (area US):

• Pay-as-you-go: $0,40 per ora (arrotondato all’ora intera successiva)
• Always-available Cloud PC: $5 per Cloud PC al mese, in aggiunta al billing a consumo

I costi sono tracciabili in Azure Cost Management filtrando per il tag Windows365foragents.

Quando usarlo — e quando no

Windows 365 for Agents è utile principalmente quando un agente deve interagire con un’interfaccia utente: workflow basati su browser, applicazioni legacy senza API affidabili, o software desktop non modernizzato. Se invece il workflow può essere completato tramite API o connettori, Microsoft stesso raccomanda di usare Agent 365 direttamente, senza passare per Windows 365 for Agents.

Dato che la documentazione operativa è ancora limitata — soprattutto sui dettagli di troubleshooting avanzato — Microsoft consiglia di trattare le prime implementazioni come controlled pilot piuttosto che come rollout di produzione su larga scala.

Conclusione

Windows 365 for Agents rappresenta un’evoluzione logica della piattaforma Cloud PC verso il mondo dell’automazione agentiva. Per gli amministratori IT che gestiscono ambienti ibridi con applicazioni legacy, offre un percorso strutturato per integrare agenti AI senza sacrificare la governance di identità e sicurezza. Vale la pena monitorarne l’evoluzione, in particolare quando la preview si estenderà alle region europee.

Fonte: Windows 365 for Agents: Cloud PCs for AI automation — 4sysops

Windows 365 for Agents: Cloud PCs for AI automation – 4sysops

Windows 365 for Agents is a public preview service that gives AI agents Cloud PCs for running tasks in Windows environments. A Cloud PC is a virtual Windows des

^{IT Experts (4sysops)}

Spcnet.it

2026-06-03 13:45:34

CVE-2026-42945 (NGINX Rift): vulnerabilità critica attivamente sfruttata — aggiornare subito

Il 13 maggio 2026 il team di ricerca di Depthfirst ha reso pubblici i dettagli tecnici di CVE-2026-42945, una vulnerabilità critica nel modulo ngx_http_rewrite_module di NGINX, immediatamente ribattezzata NGINX Rift. Appena tre giorni dopo la divulgazione, i sistemi canary di VulnCheck hanno rilevato tentativi di sfruttamento attivo in the wild. Con oltre 5,7 milioni di istanze NGINX esposte su Internet che eseguono versioni potenzialmente vulnerabili, questo CVE richiede attenzione immediata da parte di tutti gli amministratori di sistema.

Cos’è e come funziona la vulnerabilità

CVE-2026-42945 è una vulnerabilità di memory corruption (heap-based buffer overflow) che risiede nel modulo di riscrittura URL di NGINX. Il problema nasce da un errore nel calcolo del buffer di destinazione quando vengono usate capture non nominati (i riferimenti $1, $2, ecc.) nelle direttive rewrite.

Il bug si manifesta quando sono presenti tutte e tre queste condizioni nella configurazione di NGINX:

1. Una direttiva rewrite con capture non nominati (es. $1, $2)
2. Una stringa di sostituzione che contiene un punto interrogativo (parametri GET)
3. Un’ulteriore direttiva rewrite, if, o set successiva

In questa configurazione, NGINX calcola la dimensione del buffer usando un insieme di assunzioni sull’escape dei caratteri, ma poi scrive nel buffer con assunzioni diverse. Il risultato è una scrittura oltre i limiti del buffer allocato — un classico heap overflow. La cosa particolarmente insidiosa è che i byte scritti oltre il buffer sono determinati dall’URI dell’attaccante, rendendo la corruzione controllabile e quindi molto più pericolosa di un semplice crash casuale.

Esempio di configurazione vulnerabile

Ecco un pattern di configurazione che espone l’istanza NGINX all’exploit:

server {
    listen 80;
    server_name example.com;

    location / {
        # Configurazione VULNERABILE: capture non nominato ($1) + "?" nella sostituzione
        rewrite ^/vecchio/(.*)$ /nuovo/?id=$1 last;
        
        # La presenza di questa seconda direttiva aggrava il problema
        rewrite ^/nuovo/(.*)$ /index.php?path=$1 last;
    }
}

La versione sicura usa capture nominati:

server {
    listen 80;
    server_name example.com;

    location / {
        # Configurazione SICURA: uso di capture nominati
        rewrite ^/vecchio/(?P<slug>.*)$ /nuovo/?id=${slug} last;
        rewrite ^/nuovo/(?P<path>.*)$ /index.php?path=${path} last;
    }
}

Impatto: DoS garantito, RCE possibile

L’impatto della vulnerabilità dipende dalla configurazione del sistema operativo:

• Denial of Service (DoS): ottenibile su qualsiasi configurazione NGINX vulnerabile. Richieste HTTP ripetute mantengono i worker process in un crash loop, degradando la disponibilità di tutti i virtual host serviti dall’istanza.
• Remote Code Execution (RCE): teoricamente possibile, ma richiede che l’Address Space Layout Randomization (ASLR) sia disabilitata sul server target. Su sistemi Linux moderni con ASLR abilitata (la configurazione predefinita), il RCE è significativamente più difficile da ottenere.

Il proof-of-concept pubblico rilasciato da Depthfirst dimostra il DoS in modo affidabile e ripetibile.

Versioni affette

La vulnerabilità colpisce:

• NGINX Open Source: versioni dalla 0.6.27 alla 1.30.0 inclusa
• NGINX Plus: versioni dalla R32 alla R36
• Prodotti F5 che incorporano NGINX: NGINX Ingress Controller, F5 WAF for NGINX, F5 DoS for NGINX e altri

Come verificare la propria esposizione

Prima di aggiornare, è utile capire se la propria configurazione è effettivamente sfruttabile. Non basta avere una versione vulnerabile: è necessario che sia presente il pattern di configurazione critico.

Cerca nelle tue configurazioni il pattern problematico:

# Cerca direttive rewrite con $1, $2, ecc. seguite da "?"
grep -rn 'rewrite.*\$[0-9].*?' /etc/nginx/

# Verifica la versione installata
nginx -v

Su sistemi Debian/Ubuntu puoi controllare se il pacchetto è già stato aggiornato:

apt-cache policy nginx
apt-cache policy nginx-full

Patch e mitigazioni disponibili

F5 ha già rilasciato le versioni corrette:

• NGINX Open Source 1.31.0 (versione mainline) e 1.30.1 (versione stable)
• NGINX Plus R36 P4 e R32 P6
• F5 WAF for NGINX v5.13.0
• F5 DoS for NGINX v4.9.0

Le principali distribuzioni Linux stanno rilasciando pacchetti aggiornati:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade nginx

# AlmaLinux/RHEL/CentOS
sudo dnf update nginx

# Verifica la versione dopo l'aggiornamento
nginx -v && nginx -t

Se non è possibile aggiornare immediatamente, la mitigazione ufficiale di F5 consiste nel convertire tutti i capture non nominati in capture nominati nelle direttive rewrite, come mostrato nell’esempio di configurazione sicura sopra.

Considerazioni operative

Alcuni aspetti pratici da tenere a mente durante la risposta a questo incidente:

L’aggiornamento di NGINX su sistemi in produzione richiede tipicamente un graceful reload (nginx -s reload) che non interrompe le connessioni esistenti. Tuttavia, se si installa una nuova versione del pacchetto, potrebbe essere necessario un riavvio del processo:

# Reload della configurazione (zero-downtime)
nginx -s reload

# Oppure tramite systemd
systemctl reload nginx

# Riavvio completo (se necessario dopo aggiornamento del binario)
systemctl restart nginx

Per ambienti containerizzati con NGINX come base image, è necessario ricostruire e ridistribuire i container aggiornando la versione base dell’immagine. Se si usa NGINX Ingress Controller su Kubernetes, aggiornare il deployment del controller.

Conclusione

CVE-2026-42945 è una vulnerabilità seria che merita risposta rapida. Sebbene non tutte le istanze NGINX siano sfruttabili (dipende dalla configurazione delle direttive rewrite), il DoS è ottenibile su qualsiasi sistema vulnerabile con il pattern critico e lo sfruttamento attivo è già confermato. La patch è disponibile, la migrazione alla versione 1.30.1 o 1.31.0 è il percorso consigliato. In alternativa, la conversione ai capture nominati nelle configurazioni rewrite offre una mitigazione efficace nell’immediato.

Fonti: Help Net Security, Depthfirst Security Research, F5 Security Advisory K000161019, VulnCheck

Attackers are exploiting critical NGINX vulnerability (CVE-2026-42945) - Help Net Security

A critical NGINX vulnerability (CVE-2026-42945) that was disclosed last week is being exploited by attackers, according to VulnCheck.

^{Zeljka Zorz (Help Net Security)}

Spcnet.it

2026-06-03 13:38:15

Linux Network Bonding: configurare la ridondanza e il bilanciamento del carico delle interfacce di rete

Cos’è il Network Bonding su Linux?

Il network bonding (detto anche NIC bonding, link aggregation o NIC teaming) è una tecnica che consente di unire due o più interfacce di rete fisiche in un’unica interfaccia logica. Il risultato? Maggiore larghezza di banda, ridondanza contro i guasti, o entrambi — a seconda della modalità scelta.

Il kernel Linux gestisce tutto questo tramite il modulo bonding, disponibile di default in quasi tutte le distribuzioni moderne. L’interfaccia bond appare al sistema operativo e alle applicazioni come una singola NIC: tutto il traffico la attraversa in modo trasparente.

Importante: il bonding non è la stessa cosa del bridging. Un bridge connette segmenti di rete separati; il bonding aggrega più interfacce in una sola. Scopo diverso, configurazione diversa. Inoltre, le interfacce Wi-Fi generalmente non sono compatibili con il bonding — i driver wireless non supportano la modalità promiscua e la manipolazione dei MAC address che il bonding richiede. Usate esclusivamente NIC Ethernet cablate.

Le 7 modalità di bonding

La scelta della modalità è la decisione più importante nell’intera configurazione. Ecco una panoramica pratica:

Mode 0 — Round-Robin (balance-rr)

I pacchetti vengono trasmessi in sequenza su tutte le interfacce. Offre bilanciamento del carico e tolleranza ai guasti, ma richiede una configurazione di static link aggregation sullo switch. Senza di essa si verificano pacchetti fuori sequenza e prestazioni scadenti.

Mode 1 — Active-Backup

Una sola interfaccia è attiva alla volta. Se quella attiva cade, subentra immediatamente una di riserva. Non richiede configurazione sullo switch: è la modalità più sicura e compatibile. Usatela se il vostro obiettivo è la pura ridondanza.

Mode 4 — 802.3ad (LACP)

Link Aggregation dinamica secondo lo standard IEEE 802.3ad. Richiede uno switch gestito con LACP abilitato. È la modalità più usata in ambienti enterprise: se il vostro switch lo supporta, questa è la scelta per la produzione.

Mode 6 — Balance-ALB

Bilancia sia il traffico in uscita sia quello in entrata tramite negoziazione ARP. Non richiede configurazione sullo switch: ottima scelta per home lab o server senza switch gestiti.

Per home lab senza switch gestito: Mode 1 (failover) o Mode 6 (load balancing). Per server di produzione con switch gestito: Mode 4 (LACP).

Prerequisiti

Prima di iniziare, verificate di avere:

• Due o più NIC fisiche (o virtuali, in una VM)
• Accesso root o sudo
• Il modulo bonding del kernel (incluso nella maggior parte delle distribuzioni)

Verificate che il modulo sia disponibile:

modinfo bonding

Caricatelo immediatamente se necessario:

sudo modprobe bonding

Identificate le vostre interfacce prima di toccare qualsiasi configurazione:

ip link show

Sui sistemi moderni vedrete nomi come enp3s0, enp4s0 oppure eth0, eth1. Annotateli.

Metodo 1: NetworkManager con nmcli (desktop e server moderni)

Se usate Ubuntu, Fedora, Debian con NetworkManager o qualsiasi distribuzione desktop, questo è l’approccio più diretto. NetworkManager supporta il bonding in modo nativo da anni.

Creare prima l’interfaccia bond:

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

Aggiungere le interfacce fisiche come slave del bond:

sudo nmcli con add type ethernet slave-type bond con-name bond0-slave1 ifname enp3s0 master bond0
sudo nmcli con add type ethernet slave-type bond con-name bond0-slave2 ifname enp4s0 master bond0

Assegnare un indirizzo IP statico al bond:

sudo nmcli con modify bond0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1 ipv4.method manual

Oppure usare DHCP:

sudo nmcli con modify bond0 ipv4.method auto

Attivare la connessione:

sudo nmcli con up bond0

Verificare che il bond funzioni:

cat /proc/net/bonding/bond0

L’output mostrerà l’interfaccia slave attiva, lo stato MII, velocità e duplex di ogni NIC. Questo file è il vostro migliore alleato per il troubleshooting.

Metodo 2: systemd-networkd (server e installazioni minimali)

Per server senza NetworkManager, systemd-networkd gestisce il bonding in modo pulito. Adatto a Ubuntu Server, Debian minimale e configurazioni snelle.

Creare il file netdev per il bond:

sudo nano /etc/systemd/network/10-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms
UpDelaySec=200ms
DownDelaySec=200ms

Configurare la rete per l’interfaccia bond:

sudo nano /etc/systemd/network/20-bond0.network

[Match]
Name=bond0

[Network]
DHCP=yes

Creare un file per ogni interfaccia slave (uno per NIC):

sudo nano /etc/systemd/network/30-bond0-slave1.network

[Match]
Name=enp3s0

[Network]
Bond=bond0

Riavviare il servizio e verificare:

sudo systemctl restart systemd-networkd
cat /proc/net/bonding/bond0

Metodo 3: Netplan (Ubuntu Server 18.04+)

Ubuntu Server usa Netplan come layer di configurazione di rete predefinito. Modificate il file di configurazione (di solito /etc/netplan/01-netcfg.yaml):

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
    enp4s0:
      dhcp4: no
  bonds:
    bond0:
      interfaces:
        - enp3s0
        - enp4s0
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
      parameters:
        mode: active-backup
        mii-monitor-interval: 100
        primary: enp3s0

Applicare la configurazione:

sudo netplan apply

Consiglio: su macchine remote, usate sudo netplan try prima di applicare definitivamente. Il comando applica la configurazione temporaneamente e la ripristina automaticamente dopo 120 secondi se non viene confermata — una rete di sicurezza preziosa.

Test del failover

Una volta configurato il bond, testate che il failover funzioni davvero. Con il bond attivo, simulate il guasto di una NIC scollegando fisicamente il cavo o disabilitando l’interfaccia via software:

sudo ip link set enp3s0 down

Il traffico dovrebbe continuare a fluire sull’interfaccia secondaria senza interruzioni percepibili. Verificate:

cat /proc/net/bonding/bond0

Il campo Currently Active Slave mostrerà la NIC di backup ora attiva.

Comandi utili per il monitoraggio

# Stato dettagliato del bond
cat /proc/net/bonding/bond0

# Statistiche di traffico per interfaccia
ip -s link show bond0

# Link failure count per slave
grep -A2 "Slave Interface" /proc/net/bonding/bond0

Problemi comuni e soluzioni

L’interfaccia bond non ha IP dopo il reboot: verificate che le connessioni NetworkManager siano impostate su autoconnect, oppure che i file systemd-networkd siano nel percorso corretto (/etc/systemd/network/).

Un solo slave risulta attivo anche in modalità round-robin o LACP: lo switch non è configurato correttamente per il LAG. Controllate la configurazione delle porte sullo switch.

I ping drop durano più del previsto durante il failover: aumentate il valore di UpDelaySec/DownDelaySec — un valore troppo basso può causare flapping. Valori tipici: 200ms per il down, 0ms per l’up.

Conclusione

Il network bonding su Linux è una soluzione matura, stabile e sorprendentemente semplice da configurare su distribuzioni moderne. Che vogliate ridondanza per un server critico o maggiore throughput per trasferimenti locali, i tre metodi descritti — nmcli, systemd-networkd e Netplan — coprono la quasi totalità degli scenari reali. Iniziate con Mode 1 (active-backup) se siete alle prime armi: non richiede switch gestito ed entra in produzione in pochi minuti.

Fonte: Linux Network Bonding: Combine Network Interfaces — LinuxBlog.io

Linux Network Bonding: Combine Network Interfaces | LinuxBlog.io

Two network interfaces are better than one. With Linux network bonding (also known as NIC bonding or link aggregation), you can combine multiple NICs into

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-06-03 12:48:12

DriveSurge e il sistema zTDS: migliaia di siti dirottati per distribuire ClickFix e FakeUpdates su Windows e macOS

Si parla di:
Toggle

Un gruppo di cybercriminali tracciato come DriveSurge ha costruito un’infrastruttura di distribuzione malware su scala industriale, dirottando migliaia di siti web legittimi per veicolare campagne ClickFix e FakeUpdates. Dietro l’operazione si cela il sistema di distribuzione del traffico zTDS, che seleziona dinamicamente la trappola più efficace per ciascuna vittima. Il target: qualunque utente Windows o macOS che visiti un sito compromesso.

Chi è DriveSurge e cosa fa zTDS

DriveSurge è un threat actor di tipo malware-as-a-service specializzato nella distribuzione massiva di payload attraverso siti web compromessi. La sua infrastruttura operativa si regge sul Traffic Distribution System zTDS, un sistema sofisticato che analizza i visitatori in tempo reale — sistema operativo, geolocalizzazione, browser, orario di accesso — e li reindirizza verso la trappola ottimale, scelta tra due filoni principali: ClickFix o FakeUpdates.

I ricercatori di SilentPush hanno documentato la campagna, rilevando che DriveSurge gestisce attivamente una rete di traffic broker che monetizzano il traffico dai siti compromessi indirizzandolo verso le campagne di distribuzione. Si tratta di un modello di business criminale consolidato: chi compromette i siti raccoglie il traffico e lo vende; DriveSurge compra quel traffico e lo converte in infezioni.

ClickFix: il trucco psicologico che bypassa l’antivirus

La tecnica ClickFix si basa su un principio di social engineering brutalmente efficace: mostrare all’utente un messaggio di errore fasullo — tipicamente un avviso del browser o di un’applicazione — che invita a “risolvere il problema” incollando ed eseguendo manualmente un comando nella console PowerShell o nel terminale.

Il vantaggio per gli attaccanti è che l’utente diventa il vettore di infezione: non serve exploit, non serve privilege escalation — è la vittima stessa a lanciare il payload con i propri privilegi. Il comando incollato è solitamente una lunga stringa offuscata che scarica ed esegue il malware direttamente dalla memoria, senza scrivere file su disco che possano essere rilevati dall’antivirus.

Nella versione DriveSurge, i lure ClickFix impersonano avvisi di Google Chrome, Microsoft Edge o applicazioni enterprise, con messaggi localizzati nella lingua del visitatore. Il comando finale tipicamente esegue uno script PowerShell che:

• Scarica un payload cifrato da un dominio compromesso o da un CDN legittimo abusato
• Lo decifra in memoria ed esegue il dropper
• Installa un infostealer (Lumma Stealer, Vidar, o varianti custom) o un RAT
• Aggiunge persistenza tramite scheduled task o chiavi di registro

FakeUpdates: il classico che non tramonta

Il secondo filone, FakeUpdates (noto anche come SocGholish), simula un prompt di aggiornamento del browser: una pagina sovrapposta al sito legittimo mostra un finto avviso di aggiornamento critico per Chrome, Firefox o Edge, invitando a scaricare un file .zip o .js che contiene il dropper.

La novità documentata da SilentPush nella campagna DriveSurge è l’estensione a macOS: oltre ai target Windows classici, il sistema zTDS identifica i visitatori Apple e li reindirizza verso una variante della campagna che distribuisce script JavaScript malevoli ottimizzati per l’ecosistema macOS, scaricando payload .dmg o .pkg firmati con certificati sviluppatore ottenuti fraudolentemente.

Infrastruttura e scala dell’operazione

La campagna sfrutta migliaia di siti web WordPress, Joomla e Magento compromessi come stager di primo livello: il codice iniettato nel sito vittima è minimo e difficile da rilevare — spesso poche righe di JavaScript offuscato aggiunte a file tema o plugin — che si limita a interrogare l’infrastruttura zTDS per decidere se mostrare o meno il lure al visitatore.

Questa architettura “many-to-one” offre a DriveSurge una resilienza elevata: anche se decine di siti vengono ripuliti, l’infrastruttura centrale rimane intatta e la campagna continua su altri domini. Il sistema zTDS applica anche un meccanismo di frequency capping: lo stesso indirizzo IP non riceve il lure più di una volta in una finestra temporale definita, riducendo il rischio che ricercatori di sicurezza o sistemi automatizzati di crawling identifichino i siti compromessi.

Implicazioni per i difensori

La campagna DriveSurge richiede un approccio difensivo stratificato, poiché aggira molti controlli tradizionali:

• Blocco delle esecuzioni PowerShell da clipboard: configurare Windows Defender Application Control (WDAC) o AppLocker per limitare l’esecuzione di PowerShell non firmato lanciato interattivamente riduce drasticamente l’efficacia di ClickFix.
• Proxy DNS con blocco dei redirect sospetti: i sistemi zTDS usano catene di redirect multi-hop; una soluzione DNS filtering (Cisco Umbrella, Cloudflare Gateway) che blocchi i redirect a dominio nuovo può interrompere la catena prima che la vittima veda il lure.
• Awareness degli utenti: il vettore ClickFix è efficace perché convincente — investire in training specifico su “nessun sito legittimo ti chiede mai di aprire PowerShell e incollare comandi” ha un ROI alto.
• Monitoraggio dei processi figli di browser: un browser che lancia powershell.exe, cmd.exe o wscript.exe come processo figlio è un segnale forte di ClickFix in esecuzione — aggiungere questa detection nelle regole EDR.
• Hardening dei CMS: verificare regolarmente l’integrità dei file JavaScript dei propri siti WordPress/Joomla/Magento — i propri siti potrebbero essere già usati come stager di DriveSurge a insaputa degli amministratori.

DriveSurge dimostra che ClickFix e FakeUpdates non sono tecniche in declino: l’adozione di un TDS sofisticato come zTDS e l’espansione a macOS segnalano un investimento operativo continuo e una struttura criminale in crescita. La semplicità del vettore — fare in modo che sia l’utente a eseguire il malware — lo rende uno degli attacchi più difficili da bloccare con soli controlli tecnici.

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