Spcnet.it

2026-06-09 14:05:21

CVE-2026-20245 e CVE-2026-41089: zero-day Cisco SD-WAN e RCE su Netlogon sotto attacco attivo

Questa settimana il panorama della sicurezza infrastrutturale è segnato da due vulnerabilità critiche in sfruttamento attivo: un zero-day su Cisco Catalyst SD-WAN Manager e un buffer overflow nel protocollo Netlogon di Windows. Entrambe riguardano componenti centrali nelle architetture enterprise e richiedono attenzione immediata da parte degli amministratori di sistema.

CVE-2026-20245: Zero-day su Cisco Catalyst SD-WAN Manager

Cisco ha divulgato la vulnerabilità CVE-2026-20245, una privilege escalation critica che colpisce Cisco Catalyst SD-WAN Manager. La caratteristica più preoccupante è che, al momento della divulgazione, non è disponibile alcuna patch.

Secondo Cisco, sono stati osservati casi di sfruttamento attivo in cui l’attaccante è riuscito a modificare configurazioni e a propagarle verso i dispositivi edge della rete SD-WAN. Questo tipo di accesso è particolarmente pericoloso perché consente potenzialmente di alterare il routing del traffico, intercettare comunicazioni o isolare segmenti di rete.

Il contesto: il gruppo UAT-8616

L’attività non è isolata. Il threat actor noto come UAT-8616 ha già sfruttato in precedenza vulnerabilità simili di authentication bypass su sistemi SD-WAN Cisco. Il pattern operativo del gruppo prevede:

• Sfruttamento di falle di autenticazione per accedere al management plane
• Modifica delle configurazioni degli edge device per ottenere persistenza o pivoting laterale
• Campagne mirate a infrastrutture enterprise con SD-WAN distribuita geograficamente

Mitigazioni temporanee

In assenza di patch, Cisco raccomanda di:

• Limitare l’accesso alla management interface di SD-WAN Manager esclusivamente a indirizzi IP fidati tramite ACL
• Abilitare il logging avanzato per rilevare accessi anomali o modifiche di configurazione non autorizzate
• Monitorare i cambiamenti alla configurazione degli edge device con sistemi di change management
• Isolare il piano di gestione (out-of-band management) dalla rete dati

Verificare costantemente la pagina degli advisory di sicurezza Cisco per l’uscita della patch.

CVE-2026-41089: RCE nel protocollo Netlogon di Windows

Parallelamente, è in corso lo sfruttamento attivo di CVE-2026-41089, una vulnerabilità di tipo stack-based buffer overflow nel protocollo Netlogon di Windows. La falla consente l’esecuzione di codice remoto (RCE) senza necessità di autenticazione preventiva.

Il protocollo Netlogon è fondamentale nell’ecosistema Active Directory: gestisce l’autenticazione dei computer membri del dominio, la sincronizzazione delle password degli account macchina e la comunicazione sicura tra domain controller. Un attaccante che sfrutti questa vulnerabilità può eseguire codice arbitrario direttamente su un domain controller, compromettendo di fatto l’intera infrastruttura Active Directory.

Perché è critica

I domain controller rappresentano il cuore pulsante di ogni infrastruttura Windows enterprise:

• Gestiscono tutte le autenticazioni Kerberos e NTLM
• Ospitano il catalogo globale e le policy di gruppo (GPO)
• Controllano i permessi e i privilegi di tutta la rete

Una compromissione del DC equivale tipicamente a un compromesso totale del dominio: l’attaccante può creare account privilegiati, modificare policy, accedere a segreti Kerberos (Golden Ticket) e muoversi lateralmente verso ogni sistema del dominio.

Azioni immediate

Se non già fatto, è essenziale applicare le patch del Patch Tuesday di giugno 2026 che correggono questa vulnerabilità. Fino all’applicazione della patch:

# Verificare se il servizio Netlogon è esposto su interfacce non necessarie
netstat -ano | findstr :135
netstat -ano | findstr :49152

# Controllare gli accessi recenti ai domain controller
Get-EventLog -LogName Security -InstanceId 4624,4625 -Newest 500 | 
  Where-Object {$_.EntryType -eq 'FailureAudit'} | 
  Select-Object TimeGenerated, Message | 
  Format-Table -AutoSize

È inoltre consigliabile verificare che il traffico Netlogon (RPC su porte dinamiche) sia limitato tramite firewall a soli sistemi del dominio e non esposto verso reti non fidate.

Contesto più ampio: giugno 2026, un mese critico per la sicurezza

Le due CVE sopra descritte si inseriscono in un contesto di patch Tuesday giugno 2026 che conta oltre 120 CVE corrette da Microsoft su Windows 10 e Windows 11. Nello stesso periodo:

• Palo Alto GlobalProtect VPN: rilevati tentativi limitati di sfruttamento di un authentication bypass
• Android (CVE-2025-48595): Google ha rilasciato l’aggiornamento di sicurezza di giugno 2026 per correggere una vulnerabilità di alta severità nel framework, probabilmente già usata in attacchi mirati
• Miasma worm: nei giorni precedenti, un worm ha colpito 73 repository GitHub di Microsoft in un supply chain attack

Checklist per gli amministratori

• ✅ Applicare il Patch Tuesday di giugno 2026 su tutti i domain controller il prima possibile
• ✅ Verificare se l’ambiente usa Cisco Catalyst SD-WAN Manager e implementare le mitigazioni temporanee
• ✅ Abilitare audit logging su DC per rilevare accessi anomali tramite Netlogon
• ✅ Controllare che l’accesso al management plane SD-WAN sia ristretto via ACL
• ✅ Monitorare i bollettini Cisco per la disponibilità della patch CVE-2026-20245

---

Fonti: 4sysops, Help Net Security, SecurityWeek

Cisco SD-WAN zero-day and Windows Netlogon RCE face active exploitation – 4sysops

Cisco has disclosed a critical privilege escalation vulnerability, CVE-2026-20245, affecting Catalyst SD-WAN Manager for which no patch is currently available.

^{IT News (4sysops)}

(in)sicurezza digitale

2026-06-09 13:59:13

PulseRAT: il RAT .NET che usa Google Sheets come C2 e sfrutta il partenariato India-EAU come esca geopolitica

Si parla di:
Toggle

Un ISO caricato dagli Emirati Arabi con dentro un Remote Access Trojan inedito, progettato per nascondersi come servizio Windows legittimo e ricevere comandi da un semplice foglio Google Sheets: è PulseRAT, la nuova minaccia documentata il 6 giugno 2026 dal ricercatore DmpDump. L’esca geopolitica — la settimana della partnership strategica India-EAU, annunciata dal governo Modi nel maggio 2026 — e la catena d’infezione curata ne fanno un sample di forte interesse per la threat intelligence.

Il contesto geopolitico come vettore

Il campione è stato individuato il 19 maggio 2026, caricato su VirusTotal da un indirizzo UAE. Il file si chiama UAE-India_Strategic_Partnership_Week.iso ed è progettato per sembrare documentazione correlata alla visita di stato del Premier indiano Modi negli Emirati Arabi, durante la quale India e UAE hanno firmato accordi nel settore della difesa e dell’energia. Questo tipo di lure geopolitico — sfruttare eventi diplomatici reali per mascherare malware — è una tattica consolidata di gruppi APT, e suggerisce un operatore con sufficiente consapevolezza del contesto politico regionale per costruire un inganno credibile.

Al momento della pubblicazione dell’analisi, l’attribuzione resta aperta: il ricercatore nota analogie con artefatti legati a un host chiamato desktop-526nitv, ma non formula attribuzioni definitive a gruppi noti.

La catena d’infezione

L’ISO contiene due file:

• UAE-India_Strategic_Partnership-Week.lnk — un collegamento Windows che esegue il secondo file tramite cmd.exe. I metadati del file LNK rivelano che è stato creato su una macchina denominata desktop-526nitv.
• Document_11052026-03578240540350-93.exe — un dropper .NET compilato l’11 maggio 2026, il cui nome originale è FinalTool.exe.

Il dropper esegue le seguenti operazioni:

• Crea la directory %LOCALAPPDATA%\Microsoft\Vault\
• Estrae due risorse embedded: il payload principale (vaultsvc.exe) e un “decoy PDF” da 0 byte
• Registra un Scheduled Task denominato WindowsVaultSyncService tramite l’interfaccia COM del Task Scheduler di Windows (non via riga di comando, riducendo la visibilità nei log)
• Si auto-elimina dopo il setup

Il nome scelto per il servizio — WindowsVaultSyncService — è una tecnica classica di masquerading: nomi plausibili per processi di sistema Windows riducono la probabilità che un analista o un tool automatico sollevino un alert.

Il RAT: Google Sheets come C2

Il payload finale è un RAT .NET con una caratteristica architetturale notevole: utilizza un foglio Google Sheets come canale di command-and-control. Questa tecnica — nota come Living off Trusted Sites (LoTS) — è sempre più diffusa tra gli attori avanzati perché il traffico verso i servizi Google è raramente bloccato a livello di firewall o proxy aziendale e si confonde facilmente col traffico legittimo.

Il funzionamento documentato dal ricercatore:

• Il RAT genera un UID vittima a partire da nome utente e nome macchina
• Crea un mutex GlobalWinSync_ per evitare esecuzioni multiple
• Raccoglie informazioni di sistema tramite PowerShell in-process (systeminfo)
• Scrive i risultati e i log dei comandi eseguiti nel foglio Google Sheets dell’attaccante
• Legge i comandi dal foglio e li esegue tramite PowerShell base64-encoded
• Le stringhe critiche del RAT sono offuscate con una combinazione di base64 e XOR, decodificate a runtime dal metodo JIT

MITRE ATT&CK mapping

La catena copre diverse tecniche MITRE: T1204.002 (esecuzione file malevolo tramite LNK), T1059.001 (PowerShell), T1053.005 (Scheduled Task per persistenza), T1071.001 e T1102.001 (C2 via web service Google Sheets), T1027 (offuscamento stringhe), T1070.004 (auto-delete del dropper).

Indicatori di compromissione (IoC)

# File names
UAE-India_Strategic_Partnership_Week.iso
Document_11052026-03578240540350-93.exe
UAE-India_Strategic_Partnership-Week.lnk
vaultsvc.exe
# SHA-256 hashes
1ba67bb1cfad42446880cca53cbd05fe66d7514b2bb139b48e5c63adff14be7b  (ISO)
2cc7c2d8653c98e5bac32fcaf5e45b861efb4bb87df3b3f96285edb475e75bba  (dropper)
62d62950ff7a0e43550a5d0ba55d32d5083b9de5538e0f012e406b6d951e16aa  (RAT)
# Google Sheets C2
Spreadsheet ID: 1Lb5BEIsehbCGe8p1jkfWf5Mw1dBAcw5RHWFdga5gFq8
Service account: [redacted]@insicurezza-lab.iam.gserviceaccount.com
# Host artifact
Hostname: desktop-526nitv
# Mutex
GlobalWinSync_
# Scheduled Task
WindowsVaultSyncService

Due righe per i difensori

PulseRAT è un campione che illustra una tendenza crescente: l’abuso di infrastrutture cloud legittime (Google, OneDrive, GitHub, Slack) per il C2. Dal punto di vista difensivo, bloccare questo tipo di traffico è complesso perché si sovrappone al traffico produttivo aziendale. Alcune contromisure pratiche:

• Monitorare creazioni anomale di Scheduled Task tramite l’interfaccia COM (Event ID 4698 nei log Windows Security, con particolare attenzione a task non firmati o con path in %LOCALAPPDATA%).
• Implementare regole YARA o EDR per rilevare dropper .NET che si auto-eliminano dopo aver scritto payload in directory utente.
• Considerare il blocco o il monitoraggio stretto delle API di Google Sheets in uscita da endpoint non autorizzati a usarle.
• Bloccare il mount automatico di file ISO da fonti esterne tramite Group Policy.
• Aggiungere i hash SHA-256 riportati alle threat intel feed aziendali.

Il ricercatore DmpDump ha reso disponibile l’analisi completa sul suo blog, con screenshot del codice decompilato e della struttura del foglio Google Sheets usato come C2. La ricerca resta aperta sull’attribuzione: se hai visto sample simili, il ricercatore accetta segnalazioni per aggiornare il nome e i riferimenti alla famiglia malware.

Spcnet.it

2026-06-09 07:36:06

WSL Container: i contenitori Linux nativi su Windows senza Docker Desktop

Al Microsoft Build 2026, Microsoft ha annunciato WSL Container, una nuova funzionalità integrata nel Windows Subsystem for Linux (WSL) che consente di eseguire container Linux OCI-compatibili direttamente su Windows, senza la necessità di installare Docker Desktop o altri strumenti di terze parti.

Si tratta di un cambiamento significativo per sviluppatori e amministratori di sistema che lavorano in ambienti misti Windows/Linux, e che fino ad oggi dovevano fare affidamento su Docker Desktop (a pagamento per le organizzazioni sopra una certa dimensione) o su soluzioni alternative più complesse.

Perché WSL Container cambia le regole del gioco

Eseguire container Linux su Windows è da sempre un’operazione che richiede un livello di indirezione: Docker Desktop, ad esempio, avvia una macchina virtuale Linux in background e su di essa esegue i container. Questo approccio funziona bene, ma porta con sé costi di licenza, overhead di configurazione e una gestione centralizzata separata dalla piattaforma Windows stessa.

WSL Container integra questo meccanismo direttamente nel sistema operativo, eliminando la dipendenza da software di terze parti. Il risultato è una pipeline di sviluppo e operativa più snella, completamente gestibile tramite strumenti nativi Windows.

Come funziona tecnicamente

WSL Container esegue i container OCI all’interno di una macchina virtuale Hyper-V dedicata, separata dalle distribuzioni Linux WSL 2 tradizionali. La comunicazione tra il processo Windows e la VM avviene tramite Hyper-V socket, un canale a bassa latenza ottimizzato per la comunicazione host-guest in ambienti virtualizzati.

La configurazione predefinita della VM prevede:

• 2 vCPU
• 2.000 MB di RAM
• 32 GB di disco virtuale ad espansione dinamica

Questi parametri sono personalizzabili tramite l’SDK C# esposto dal pacchetto NuGet ufficiale.

Il CLI: wslc.exe

Il nuovo strumento da riga di comando wslc.exe sarà distribuito con il prossimo aggiornamento stabile di WSL. Microsoft ha scelto deliberatamente una sintassi analoga a Docker, così chi già conosce Docker non deve imparare nulla di nuovo:

# Avvia un container interattivo e rimuovilo all'uscita
wslc run --rm -it ubuntu:latest bash -c "echo Ciao da WSL Container!"

# Elenca le immagini disponibili localmente
wslc image ls

# Avvia un web server nginx in background, esponendo la porta 8080
wslc run -it --rm -d -p 8080:80 --name webserver nginx

# Elenca i container in esecuzione
wslc container ps

# Ferma il container
wslc container stop webserver

# Accesso a registry privati
wslc registry login registry.example.com
wslc registry logout registry.example.com

La portabilità dei comandi rispetto a Docker è intenzionale: permette di adottare WSL Container senza riscrivere script o pipeline esistenti.

Modalità di rete supportate

WSL Container supporta tre modalità di rete a livello di VM:

• none: nessuna connettività di rete
• NAT: il traffico della VM viene tradotto attraverso la rete dell’host Windows
• virtio-proxy: interfaccia di rete paravirtualizzata, con traffico più diretto e minore overhead

A livello di singolo container, si può scegliere tra bridge, host, none oppure condividere il namespace di rete di un altro container. Il publish delle porte, al momento, inoltro solo connessioni TCP su localhost.

API per sviluppatori Windows

Per chi sviluppa applicazioni Windows, WSL Container espone un’API programmatica via NuGet che include:

• Una libreria C nativa (wslcsdk.dll)
• Una proiezione WinRT (la moderna superficie API di Windows)
• Bindings C# per integrazione .NET

Tramite l’API è possibile: scaricare immagini, creare e avviare container, gestire stdin/stdout, pubblicare porte, montare volumi e abilitare il pass-through GPU. Microsoft cita come scenari d’uso principali i workload AI locali, le pipeline di test e l’elaborazione basata su Linux, anche se i dettagli tecnici specifici sono ancora limitati data la fase di preview.

Controllo enterprise con Group Policy

Per gli ambienti aziendali, WSL Container introduce un’impostazione di Group Policy chiamata WSLContainerRegistryAllowlist. Questa policy limita i registry da cui gli utenti possono scaricare immagini: se un utente tenta di fare pull da un registry non in lista, l’operazione fallisce con l’errore WSLC_E_REGISTRY_BLOCKED_BY_POLICY.

La policy viene applicata a livello di servizio e vale sia per il CLI, sia per l’API, sia per eventuali plugin. Non è aggirabile chiamando l’SDK direttamente. Si tratta di un controllo importante per le organizzazioni che devono garantire la provenienza delle immagini container usate dai team di sviluppo.

Stato attuale e limitazioni

Come chiarito dalla documentazione Microsoft Learn, WSL Container è ancora in sviluppo attivo al momento della scrittura di questo articolo (giugno 2026). Non è ancora disponibile in una release stabile di WSL. Per seguire l’avanzamento del progetto, Microsoft rimanda al repository open-source microsoft/wsl su GitHub.

Tra le informazioni non ancora pubblicate: la versione minima di Windows richiesta, le specifiche di compatibilità hardware, e la roadmap per la disponibilità generale (GA).

Perché è rilevante per sistemisti e DevOps

L’integrazione nativa dei container Linux in Windows apre scenari interessanti:

• Riduzione dei costi di licenza: nessun Docker Desktop a pagamento per le organizzazioni grandi
• Gestione centralizzata via Group Policy: controllo degli allowlist di registry già nei tool di amministrazione esistenti
• Pipeline CI/CD semplificate: possibilità di eseguire container Linux in ambienti Windows senza dipendenze esterne
• Workload AI locali: esecuzione di modelli o pipeline ML su macchine Windows di sviluppo con pass-through GPU

Vale la pena monitorare l’evoluzione di questa funzionalità, specialmente per i team che lavorano su Windows e hanno bisogno di compatibilità con l’ecosistema container Linux.

---

Fonte: 4sysops – WSL container: Linux containers built into Windows | Microsoft Build 2026

WSL container: Linux containers built into Windows – 4sysops

WSL container is a new feature coming to the Windows Subsystem for Linux (WSL), announced at Microsoft Build 2026. It provides a built-in way to run OCI-compati

^{IT Experts (4sysops)}