(in)sicurezza digitale

2026-06-12 14:00:46

ShinyHunters colpisce le università americane con uno zero-day Oracle PeopleSoft: l’operazione UNC6240 analizzata da Mandiant

Si parla di:
Toggle

Mandiant e Google Threat Intelligence Group (GTIG) hanno pubblicato oggi un rapporto dettagliato su una campagna attiva di compromissione ed estorsione attribuita a UNC6240, meglio noto come ShinyHunters. L’obiettivo: le istituzioni universitarie americane, colpite attraverso uno zero-day critico in Oracle PeopleSoft che ha consentito l’accesso non autenticato a centinaia di sistemi prima ancora che Oracle rilasciasse la patch.

Il vettore d’attacco: CVE-2026-35273, un RCE con CVSS 9.8

Al centro della campagna si trova CVE-2026-35273, una vulnerabilità di remote code execution (RCE) con punteggio CVSS di 9.8 nel componente Environment Management di Oracle PeopleSoft. Il punto di ingresso sfruttato è l’Environment Management Hub (PSEMHUB), un servizio amministrativo spesso esposto direttamente su Internet nelle configurazioni multi-server. L’attività — documentata tra il 27 maggio e il 9 giugno 2026 — ha preceduto l’advisory Oracle del 10 giugno 2026, classificando di fatto l’exploit come zero-day operativo per oltre due settimane.

GTIG ha identificato gli endpoint vulnerabili e avviato notifiche a oltre 100 organizzazioni globali, con una concentrazione geografica negli Stati Uniti. Particolarmente colpito il settore dell’istruzione superiore: il 68% delle organizzazioni notificate sono atenei e college.

Chi sono gli ShinyHunters: da BreachForums a campagne zero-day

ShinyHunters (tracciato da Mandiant come UNC6240) è un gruppo cybercriminale che si è fatto conoscere tra il 2020 e il 2022 per una serie di breach di alto profilo — AT&T, Ticketmaster, Santander, Advance Auto Parts — venduti poi su BreachForums. Il gruppo ha assunto il controllo di BreachForums dopo l’arresto degli amministratori precedenti, consolidando la propria posizione nell’ecosistema del cybercrime anglofono. La campagna attuale segna un’evoluzione tattica: da semplici acquirenti di accesso iniziale a gruppo capace di sviluppare o acquisire exploit zero-day per piattaforme enterprise.

Infrastruttura C2: MeshCentral travestito da Microsoft Azure

L’analisi delle directory aperte sui cinque host di staging (IP sequenziali 142.11.200.186–190) ha rivelato un’infrastruttura C2 basata su MeshCentral, un software open-source di remote management. Gli agenti Windows precompilati erano rinominati per mimare endpoint legittimi di Microsoft Azure:

• meshagent64-azure-ops.exe
• meshagent32-azure-ops.exe
• meshagent64-v2.exe

Tutti gli agenti erano hardcoded per connettersi al server C2 wss://azurenetfiles.net:443/agent.ashx. Il dominio azurenetfiles.net è stato scelto per imitare Microsoft Azure NetApp Files, una tecnica di masquerading volta a confondere i team di sicurezza durante l’analisi dei log di rete. I server di staging eseguivano Python SimpleHTTP sulla porta 8888, inavvertitamente esposti al pubblico — errore OPSEC che ha permesso a Mandiant e ai ricercatori indipendenti di recuperare l’intero corredo di artefatti.

Timeline operativa e reconnaissance

Il file .bash_history — identico su tutti e cinque i server di staging — ha fornito una timeline dettagliata delle operazioni. Il 27 maggio 2026 alle 22:14 UTC gli attaccanti hanno installato MeshCentral (v1.1.59); pochi minuti dopo, alle 22:25 UTC, hanno configurato il client acme-client per l’automazione dei certificati Let’s Encrypt per il dominio di masquerading. La reconnaissance sulle reti interne delle vittime includeva:

• Lettura del file psappsrv.cfg per estrarre hostname e indirizzi IP interni
• Analisi dei mount NFS attivi (mount | grep psoft)
• Lettura del file /etc/hosts per mappare la topologia interna
• Ispezione delle configurazioni WebLogic (config.xml)

Propagazione laterale e script fanout

Una volta ottenuto l’accesso al primo nodo, gli attaccanti hanno utilizzato MeshCentral per distribuire uno script Bash denominato [victim_abbreviation]_fanout.sh, scritto direttamente in /tmp tramite heredoc. Lo script automatizza il credential spraying SSH verso gli host interni, parsing la lista da /etc/hosts, e — una volta ottenuto l’accesso — copia un file di estorsione nelle directory WebLogic e Process Scheduler:

README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT

L’esfiltrazione dei dati è avvenuta tramite compressione con zstd seguita da una connessione SSH in uscita verso 176.120.22.24, IP che ospita il mirror pubblico del ShinyHunters Data Leak Site (DLS). Il 9 giugno 2026, alcune organizzazioni vittime sono apparse sul DLS confermando la compromissione avvenuta con successo.

Indicatori di compromissione (IoC)

# IP di staging C2
142.11.200.186
142.11.200.187
142.11.200.188
142.11.200.189
142.11.200.190

# DLS mirror
176.120.22.24

# Dominio C2
azurenetfiles.net

# Hash SHA-256 artefatti
.bash_history:              2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35
meshagent64-azure-ops.exe:  f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc
meshagent64-v2.exe:         d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f
meshagent32-azure-ops.exe:  c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f
meshagent (Linux):          68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309

# Porte
Python SimpleHTTP: porta 8888
WebSocket C2: wss://azurenetfiles.net:443/agent.ashx

Azioni di remediation prioritarie

Per i team di sicurezza che gestiscono ambienti Oracle PeopleSoft, Mandiant raccomanda azioni immediate:

• Disabilitare EMHub: in configurazioni multi-server, disabilitare il servizio Environment Management Hub; in configurazioni single-server, rimuovere completamente l’applicazione PSEMHUB.
• Blocco perimetrale: bloccare l’accesso esterno agli endpoint /PSEMHUB/* e /PSIGW/HttpListeningConnector a livello firewall — non affidarsi esclusivamente a regole WAF.
• Analisi log: verificare nei log WebLogic richieste POST anomale verso /PSEMHUB/hub da IP esterni.
• Audit filesystem: cercare file .jsp non previsti in PSEMHUB.war/ e directory inattese logs/, persistantstorage/, scratchpad/.
• Monitoraggio NetFlow: rilevare traffico SMB in uscita (porta 445) da host PeopleSoft verso destinazioni internet esterne (indicatore potenziale di cattura hash NetNTLM).

Fonte primaria: Mandiant / Google Cloud Blog, 11 giugno 2026.

ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit | Google Cloud Blog

An active compromise and extortion campaign attributed to ShinyHunters targeting Oracle PeopleSoft with a zero-day exploit.

^{Mandiant (Google Cloud Blog)}

Andre Meister

2026-06-12 08:22:37

Die EU-Institutionen verhandeln zentrale Aspekte der Chatkontrolle. Rat und Parlament streiten, ob Internet-Dienste alle Nutzer freiwillig scannen dürfen oder verdächtige Nutzer verpflichtend scannen müssen. Wir veröffentlichen eingestufte Verhandlungsdokumente. netzpolitik.org/2026/interne-d…

Trilog zur Chatkontrolle geht in entscheidende Phase

^{Andre Meister (netzpolitik.org)}

Spcnet.it

2026-06-12 13:16:46

CVE-2026-44963: RCE critico su Veeam Backup & Replication — aggiornare subito a 12.3.2.4854

Il 9 giugno 2026 Veeam ha rilasciato una patch di emergenza per CVE-2026-44963, una vulnerabilità di esecuzione di codice remoto con CVSS v4 di 9.4 (Critical) che colpisce Veeam Backup & Replication 12.x. La falla consente a un qualsiasi utente autenticato nel dominio Active Directory di eseguire codice arbitrario sul backup server — anche senza privilegi specifici sull’applicazione Veeam stessa. In un ambiente enterprise, questo equivale alla potenziale compromissione dell’intera infrastruttura di disaster recovery.

Cosa permette di fare CVE-2026-44963

Si tratta di una falla di deserializzazione non sicura nel servizio Veeam Backup & Replication. Un utente di dominio può inviare richieste costruite ad hoc all’API interna del backup server e ottenere esecuzione di codice con i permessi del processo Veeam — tipicamente SYSTEM o un account di servizio ad alto privilegio.

Il vettore è di rete, la complessità bassa, non è richiesta interazione utente. L’unica limitazione: il backup server deve essere membro di un dominio Active Directory. I server Veeam in workgroup non sono affetti da questa CVE specifica.

Versioni affette e versione sicura

Versione	Stato
12.3.2.4465 e precedenti (tutta la linea 12.x)	⚠️ Vulnerabile
12.3.2.4854	✅ Patchata
13.x	✅ Non affetta (architettura diversa)

Perché i backup server sono target critici

Un backup server ha accesso privilegiato a tutti i sistemi che protegge: credenziali, snapshot, dati di configurazione. Un attaccante che lo compromette può:

• Esfiltrare dati sensibili dai backup di sistemi critici
• Cifrare o cancellare i backup, rendendo inutile la strategia di disaster recovery
• Usare le credenziali salvate per muoversi lateralmente nell’infrastruttura
• Distribuire ransomware sapendo che il ripristino sarà impossibile

Sina Kheirkhah di WatchTowr, che ha scoperto e segnalato la falla, sottolinea come compromettere il backup server sia l’equivalente di togliere la rete di sicurezza prima che qualcuno cada.

Verificare la versione installata

Da PowerShell sul backup server:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication" |
    Select-Object -ExpandProperty PackageVersion

Oppure via registry:

reg query "HKLM\SOFTWARE\Veeam\Veeam Backup and Replication" /v PackageVersion

In alternativa, dalla Veeam Backup Console: Help → About.

Procedura di aggiornamento a 12.3.2.4854

L’update è disponibile sul portale download Veeam. Prima di procedere:

1. Verificare lo spazio disco: l’installer richiede almeno 3 GB liberi sul volume di sistema.
2. Eseguire un backup manuale dei sistemi più critici come precauzione.
3. Mettere in pausa i job schedulati per evitare conflitti durante l’aggiornamento.
4. Aggiornare i componenti remoti dopo l’update del server principale (proxy, repository, agent). Non ignorare questo passaggio.

# Verificare componenti da aggiornare dopo l'update del server
Add-PSSnapin VeeamPSSnapIn
$currentVer = (Get-VBRVersion).ProductVersion
Get-VBRServer | Where-Object { $_.ComponentsVersion -ne $currentVer }

Mitigazioni se non è possibile aggiornare subito

Se non è possibile applicare la patch immediatamente, queste misure riducono la superficie di attacco:

• Isolare il backup server dalla rete generale: limitare l’accesso alle porte di gestione Veeam (default TCP 9392, 9401) ai soli host autorizzati tramite firewall o ACL.
• Ridurre gli account di dominio con accesso al server Veeam: applicare il principio del minimo privilegio.
• Monitorare i log di autenticazione: cercare autenticazioni anomale verso il Veeam Backup Service in orari inusuali.
• MFA per gli account di gestione Veeam: se il provider di identità lo supporta, abilitare l’autenticazione a più fattori.

Il pattern storico delle vulnerabilità Veeam

Non è la prima volta che Veeam finisce sotto i riflettori per falle critiche. CVE-2023-27532 (CVSS 7.5), CVE-2024-40711 (CVSS 9.8) e ora CVE-2026-44963 mostrano che i backup server sono bersagli sempre più ricercati, specialmente dagli operatori ransomware. Il suggerimento è di trattare i server Veeam come sistemi Tier-0, al pari dei Domain Controller: monitoraggio dedicato, accesso privilegiato minimale, patch urgente e segmentazione di rete.

Conclusione

CVE-2026-44963 non ammette ritardi: qualsiasi utente di dominio può compromettere il backup server e da lì raggiungere tutto il resto. Verificare la versione installata, pianificare l’aggiornamento a 12.3.2.4854 nel più breve tempo possibile e applicare nel frattempo le mitigazioni di rete.

Fonte: The Hacker News — Veeam Backup & Replication RCE Flaw Lets Domain Users Run Remote Code | BleepingComputer — New Veeam vulnerability exposes backup servers to RCE attacks

Veeam Backup & Replication RCE Flaw Lets Domain Users Run Remote Code

Veeam fixes CVE-2026-44963 RCE in 12 builds, blocking authenticated domain users from attacking backup servers.

^{The Hacker News}

Spcnet.it

2026-06-12 13:14:29

IAKerb e LocalKDC su Windows: meno dipendenza da NTLM, più Kerberos

Perché NTLM è ancora vivo (e quanto è difficile eliminarlo)

In ambienti Active Directory, Kerberos è il protocollo di autenticazione preferito da Microsoft da oltre vent’anni. Eppure, NTLM continua a essere presente in quasi ogni infrastruttura Windows perché esistono tre scenari in cui Kerberos non funziona e il sistema ricade inevitabilmente su NTLM:

• Il client non ha visibilità di rete diretta su un Domain Controller (DC)
• L’autenticazione coinvolge un account locale invece di un account di dominio
• L’ambiente è un workgroup o una macchina standalone, senza infrastruttura di dominio

Sono esattamente questi tre gap che Microsoft sta affrontando con IAKerb e LocalKDC, due funzionalità oggi in public preview su Windows Insider (Canary Channel) e previste in disponibilità generale su Windows 11 24H2 e Windows Server 2025 nella seconda metà del 2026.

IAKerb: Kerberos anche senza visibilità sul Domain Controller

IAKerb (Initial and Pass-Through Authentication using Kerberos) è un meccanismo definito nella bozza IETF draft-ietf-kitten-iakerb-03. Si implementa come sotto-meccanismo GSS-API, inserendosi nel protocollo SPNEGO che Windows già utilizza per la negoziazione dell’autenticazione.

Nel flusso Kerberos standard, il client deve contattare direttamente il KDC (Key Distribution Center, il servizio che gira su ogni DC) sulla porta TCP/UDP 88 per ottenere un ticket prima di potersi autenticare su un servizio. Se nessun DC è raggiungibile, Kerberos fallisce e Windows scade su NTLM.

IAKerb risolve questo problema rendendo il server di destinazione un proxy trasparente per i messaggi Kerberos. Il client tunnel i messaggi Kerberos all’interno della connessione esistente verso il server applicativo (ad esempio, sulla porta TCP 445 per SMB), e il server li inoltra al DC per conto del client. Il server non vede mai la password o l’hash: si limita a fare da relay ai messaggi di protocollo.

Il risultato pratico è che l’autenticazione rimane su percorso Kerberos anche quando:

• Il client si trova in una subnet segmentata senza accesso diretto ai DC
• L’accesso avviene via VPN o accesso remoto con routing limitato
• L’architettura cloud restringe la connettività diretta ai controller di dominio

LocalKDC: Kerberos anche per gli account locali

LocalKDC affronta il secondo grande limite: gli account locali. Kerberos richiede un KDC per emettere i ticket, e gli account locali (quelli nel SAM della macchina) non hanno nessun KDC a cui rivolgersi. Di conseguenza, qualunque autenticazione remota che coinvolgesse un account locale era storicamente vincolata a NTLM.

LocalKDC è un KDC leggero integrato direttamente in Windows, che opera esclusivamente sugli account del SAM locale. Emette ticket Kerberos basati su AES per le identità locali, abilitando l’autenticazione Kerberos anche in ambienti workgroup, macchine standalone e qualsiasi scenario con credenziali locali.

Stato attuale e configurazione via registro

Le due funzionalità hanno default diversi nel preview corrente:

• IAKerb: abilitato per default
• LocalKDC: disabilitato per default

La configurazione avviene tramite valori di registro di tipo REG_DWORD:

• DisableIAKerb: impostare a 0 per abilitare, 1 per disabilitare
• DisableLocalKDC: impostare a 0 per abilitare, 1 per disabilitare

Group Policy e gestione tramite MDM (Intune incluso) saranno aggiunti quando le funzionalità usciranno dalla fase di preview.

Prima di testare: auditing NTLM

Prima di attivare IAKerb e LocalKDC in produzione, è fondamentale capire dove NTLM viene ancora usato nell’ambiente. Windows 11 24H2 e Windows Server 2025 includono log operativi NTLM migliorati, accessibili in Event Viewer sotto:

Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Gli Event ID rilevanti sono:

• 4020, 4021: eventi client (includono nome processo, IP di destinazione, codice motivo per cui Kerberos non è stato usato)
• 4022, 4023: eventi server (nome processo e IP client)
• 4030–4033: eventi sui domain controller (dettagli client e server)

I log client sono i più informativi perché riportano il motivo del fallback a NTLM, permettendo di identificare i workload che richiedono intervento prima di pensare a disabilitare NTLM.

L’abilitazione del logging si gestisce via Group Policy:

• Per client e server: Administrative Templates > System > NTLM > NTLM Enhanced Logging
• Per i domain controller: Administrative Templates > System > Netlogon > Log Enhanced Domain-wide NTLM Logs

Limiti attuali e roadmap Microsoft

IAKerb e LocalKDC non eliminano ogni dipendenza da NTLM. Rimangono scenari che continuano a richiedere NTLM:

• Applicazioni con NTLM hardcoded nel codice
• Infrastrutture che assumono NTLM come default nella loro logica di autenticazione
• Alcune interazioni tra account di dominio e account locali sulla stessa macchina

La roadmap Microsoft per la disabilitazione di NTLM si articola in tre fasi:

• Fase 1 (già in produzione): miglioramenti all’auditing NTLM
• Fase 2 (H2 2026): disponibilità generale di IAKerb e LocalKDC
• Fase 3 (~2027–2028): NTLM disabilitato per default nella prossima versione major di Windows Server

Cosa fare adesso

Per un amministratore di sistema che vuole prepararsi al cambiamento in anticipo, il percorso consigliato è: abilitare i log NTLM migliorati oggi (già disponibili su 24H2/Server 2025), analizzare gli event ID nei prossimi mesi per mappare i workload con dipendenza NTLM, e pianificare i test con IAKerb e LocalKDC su ambienti non produttivi non appena la disponibilità generale sarà confermata. Affrontare questa transizione gradualmente è molto più gestibile che trovarsi a fare remediation d’emergenza quando NTLM verrà disabilitato per default.

Fonte originale: Reducing NTLM fallback with IAKerb and LocalKDC in Windows – 4sysops.com

Reducing NTLM fallback with IAKerb and LocalKDC in Windows – 4sysops

Microsoft has introduced two new authentication features, IAKerb and LocalKDC, entering public preview in June 2026 for Windows Insiders in the Canary Channel.

^{IT Experts (4sysops)}

Spcnet.it

2026-06-12 13:14:52

Patch Tuesday Giugno 2026: record di 208 CVE, 6 zero-day e una falla kernel wormable con CVSS 9.8

Il Patch Tuesday di giugno 2026 ha stabilito un nuovo record assoluto: Microsoft ha rilasciato aggiornamenti di sicurezza per ben 208 CVE, superando il precedente record e portando con sé 6 zero-day, di cui uno attivamente sfruttato in attacchi reali. Per i sistemisti, questo ciclo di patch è tra i più critici dell’anno: ci sono falle wormable nel kernel, bypass multipli di BitLocker, RCE su Hyper-V, AKS e DHCP, e una vulnerabilità Exchange già sfruttata in produzione.

Il quadro generale

Delle 208 vulnerabilità corrette, 33 sono classificate Critical. La distribuzione per tipologia:

• 65 Elevation of Privilege
• 55 Remote Code Execution
• 30 Information Disclosure
• 27 Spoofing
• 19 Security Feature Bypass
• 7 Denial of Service

Il conteggio esclude le 360 CVE ereditate da Chromium/Edge e le falle in servizi cloud come Exchange Online e Microsoft Graph, già patchate in precedenza nel mese.

I sei zero-day

CVE-2026-42897 — Exchange Server Spoofing (attivamente sfruttata)

L’unica zero-day già in uso attivo. Un attaccante invia una email costruita ad hoc: se la vittima la apre in Outlook Web Access, viene eseguito JavaScript arbitrario nel browser. Microsoft ha distribuito mitigazioni tramite il servizio Exchange Emergency Mitigation (EEMS). Verificare che EEMS sia abilitato di default; la patch completa è in lavorazione. Azione immediata richiesta.

CVE-2026-45586 — Windows CTFMON GreenPlasma (EoP)

Divulgata da Nightmare Eclipse, permette di ottenere un shell SYSTEM sfruttando una link following errata nel Windows Collaborative Translation Framework. Prima di una serie di zero-day rilasciate dallo stesso ricercatore in protesta contro il bug bounty Microsoft.

CVE-2026-45585 — BitLocker YellowKey (Security Feature Bypass)

Con accesso fisico al dispositivo, un attaccante inserisce file costruiti su USB o partizione EFI e, avviando in WinRE tenendo CTRL, ottiene accesso illimitato al disco cifrato. Colpisce sistemi con BitLocker in modalità TPM-only. Mitigazione: abilitare TPM+PIN.

CVE-2026-50507 — BitLocker bitskrieg (Security Feature Bypass)

Secondo bypass BitLocker, divulgato da Jonas Lykkegaard. La patch potrebbe causare l’errore “A required file couldn’t be accessed because your BitLocker key wasn’t loaded correctly”. Il fix:

reagentc /disable
reagentc /enable

CVE-2020-17103 — Cloud Files Mini Filter Driver Mini-Plasma (EoP)

CVE originariamente del 2020, segnalata da James Forshaw (Google Project Zero). Sembrava già corretta nel dicembre 2020, ma Nightmare Eclipse ha dimostrato che la vulnerabilità era ancora sfruttabile. L’update di giugno 2026 la chiude definitivamente.

CVE-2026-49160 — HTTP/2 Bomb DoS su HTTP.sys

Abusa della compressione degli header HTTP/2 per forzare il server ad allocare quantità sproporzionate di memoria con pochissimi dati in ingresso. Microsoft ha introdotto la chiave di registro MaxHeadersCount per limitare il numero di header accettati (KB5102602):

; HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
; DWORD: MaxHeadersCount = 100

Le CVE Critical più rilevanti per l’infrastruttura

CVE-2026-45657 — Windows Kernel RCE (CVSS 9.8, wormable)

È la vulnerabilità che preoccupa di più. Una use-after-free nel kernel legata all’elaborazione del traffico TCP/IP permette a un attaccante non autenticato di eseguire codice da remoto, senza interazione utente. Il vettore CVSS (AV:N/AC:L/PR:N/UI:N) e la classificazione wormable significa che un exploit funzionante potrebbe autopropag arsi tra macchine sulla stessa rete. Sistemi colpiti: Windows 11 (23H2, 24H2, 25H2, 26H1) e Windows Server 2022/2025 incluso Server Core. I ricercatori stimano la finestra per un exploit pubblico in giorni, non settimane. Priorità assoluta.

CVE-2026-32193 — Azure Kubernetes Service Container Escape (Critical)

Path traversal in AKS che permette a un container configurato con hostNetwork: true di evadere il container e ottenere il controllo del worker node. Chi gestisce cluster AKS deve verificare aggiornamenti disponibili:

az aks upgrade --resource-group myRG --name myCluster --kubernetes-version latest

CVE-2026-44815 — DHCP Client Service RCE (Critical)

RCE nel client DHCP di Windows, sfruttabile da un attaccante che controlla un server DHCP malevolo in rete. Rischio elevato in ambienti con BYOD o reti ospiti non segregate.

CVE-2026-45641 / CVE-2026-47652 — Hyper-V RCE (Critical)

Due falle di esecuzione di codice in Hyper-V. Su hypervisor il patching è prioritario: una compromissione può portare all’escape delle VM e alla compromissione dell’host.

CVE-2026-45648 — Active Directory Domain Services RCE (Critical)

RCE nei Domain Controller. Qualunque falla RCE su DC va trattata con la massima urgenza: una compromissione equivale a quella dell’intero dominio.

CVE-2026-47291 — HTTP.sys RCE (Critical)

RCE nel driver HTTP.sys, separata dalla HTTP/2 Bomb. Colpisce tutti i sistemi che espongono servizi HTTP inclusi IIS e applicazioni che usano direttamente HTTP.sys.

Strategia di deployment

Con 208 CVE e sei zero-day, non c’è spazio per ritardi. Alcune linee guida pratiche:

1. Controllare ADV990001: verificare che il Servicing Stack Update (SSU) sia installato. È il prerequisito per l’installazione corretta di tutti gli altri aggiornamenti.
2. Exchange prima: CVE-2026-42897 è attivamente sfruttata. Applicare le mitigazioni EEMS immediatamente.
3. Domain Controller: CVE-2026-45648 su AD DS è Critical. Test in ambiente non-prod, poi deployment rapido su DC.
4. BitLocker — leggere le release notes: CVE-2026-50507 può richiedere il fix manuale con reagentc. Testare prima del rollout su larga scala.
5. Hotpatch su Azure VM: Microsoft ha reso generalmente disponibile l’hotpatching per Azure VM (Linux e Windows Server), che applica le patch kernel senza riavvio. Nei workload Azure, è la modalità preferita per ridurre i downtime.

Conclusione

Il Patch Tuesday di giugno 2026 non è un mese da rimandare. La CVE-2026-45657 (kernel wormable CVSS 9.8), la zero-day Exchange in produzione, i doppi bypass BitLocker e la falla AKS compongono un quadro che richiede azione rapida e pianificata. Scaricare gli update, verificare l’SSU, prioritizzare Exchange e DC, e monitorare per eventuali regressioni post-patch, specialmente per il caso BitLocker/reagentc.

Fonte: BleepingComputer — Microsoft June 2026 Patch Tuesday fixes 6 zero-days, 200 flaws | Zero Day Initiative — June 2026 Security Update Review

Zero Day Initiative — The June 2026 Security Update Review

I’ve made it through Pwn2Own Berlin, had a little vacation, and now I’m back for Patch Tuesday. Microsoft and Adobe didn’t disappoint. In fact, they have heralded my return with the largest Patch Tuesday release ever.

^{Dustin Childs (Zero Day Initiative)}