Spcnet.it

2026-07-15 18:08:01

RoguePlanet (CVE-2026-50656): la race condition in Microsoft Defender che regala privilegi SYSTEM

Il 9 luglio 2026 Microsoft ha rilasciato la correzione per RoguePlanet, una vulnerabilità zero-day nel Malware Protection Engine di Microsoft Defender che permetteva a un attaccante con accesso locale di ottenere privilegi SYSTEM su qualsiasi macchina Windows 10 o Windows 11 completamente aggiornata. Il dettaglio che rende questo bug particolarmente istruttivo per chi amministra flotte Windows non è tanto la gravità – con un CVSS 4.0 di 7.8 non è la falla più critica dell’anno – quanto il fatto che a essere vulnerabile sia proprio il componente che dovrebbe proteggere il sistema, e che il proof-of-concept pubblico funzioni indipendentemente dallo stato della protezione in tempo reale.

Cos’è RoguePlanet (CVE-2026-50656)

RoguePlanet è tracciata come CVE-2026-50656 ed è una vulnerabilità di elevazione dei privilegi locale nel Microsoft Malware Protection Engine, il motore di scansione condiviso da Defender e da altri prodotti Microsoft di sicurezza. La causa tecnica è una improper link resolution before file access, in pratica una race condition simile alle classiche TOCTOU (time-of-check to time-of-use): il motore di scansione risolve un percorso o un link simbolico/junction in un momento diverso da quello in cui accede effettivamente al file, e questa finestra temporale può essere sfruttata per far operare il processo, che gira con privilegi SYSTEM, su un file diverso da quello previsto.

Il ricercatore che ha scoperto e divulgato pubblicamente il bug, noto con lo pseudonimo Chaotic Eclipse (in alcune fonti riportato come Nightmare-Eclipse), ha pubblicato dettagli tecnici e codice exploit già a giugno 2026, prima che Microsoft rilasciasse una patch, nel contesto di una disputa pubblica con l’azienda sulle tempistiche di risposta alle segnalazioni di vulnerabilità. Questo ha reso RoguePlanet una vulnerabilità “N-day pubblica” per diverse settimane, con Microsoft che ha classificato lo sfruttamento come “Exploitation More Likely” sul proprio Exploitability Index.

Perché disattivare Defender non è una mitigazione valida

Un dettaglio operativo importante per chi ha dovuto gestire l’incidente: il proof-of-concept pubblicato funziona indipendentemente dal fatto che la protezione in tempo reale sia attiva o meno. Questo significa che la contromisura “tampone” spesso adottata in scenari di zero-day – disattivare temporaneamente il modulo vulnerabile finché non arriva la patch – non era efficace in questo caso, perché il motore di scansione resta comunque presente e invocabile sul sistema anche a protezione realtime disattivata.

Come funziona l’attacco in pratica

RoguePlanet è un exploit post-compromise: non è una falla che consente l’accesso iniziale a un sistema, ma serve ad ampliare i privilegi una volta che l’attaccante ha già ottenuto un punto d’appoggio, ad esempio tramite credenziali rubate, malware, phishing o un’altra vulnerabilità. Lo schema tipico è:

• L’attaccante ottiene accesso come utente standard (senza privilegi amministrativi) su un endpoint Windows.
• Sfrutta la race condition nel Malware Protection Engine per far scrivere, sostituire o manipolare un file in un percorso controllato dall’attaccante mentre il motore opera con privilegi SYSTEM.
• Ottiene l’esecuzione di codice arbitrario con privilegi SYSTEM, uscendo di fatto dal sandbox dei permessi utente.
• Da lì può disabilitare protezioni, esfiltrare dati, installare impianti persistenti o muoversi lateralmente nella rete.

È lo schema classico che trasforma una compromissione limitata (un singolo account utente) in una compromissione totale della macchina, ed è per questo che le vulnerabilità di questo tipo vengono trattate con priorità alta anche quando il CVSS non è altissimo: il vettore di attacco (locale, bassa complessità, nessuna interazione utente richiesta) le rende un tassello estremamente efficiente nelle catene di attacco moderne, specie quelle assistite da AI dove le fasi di privilege escalation e lateral movement vengono automatizzate.

Cosa fare subito

La buona notizia è che la correzione è già disponibile e, trattandosi di un aggiornamento del motore antimalware, viene distribuita automaticamente tramite gli aggiornamenti regolari delle definizioni, senza richiedere un intervento manuale sugli endpoint. La versione corretta del Malware Protection Engine è la 1.1.26060.3008 o successiva. Ecco però una checklist di verifica utile in ambienti gestiti:

# Verifica la versione del Malware Protection Engine su un endpoint Windows
Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, AntivirusSignatureLastUpdated

# Forza un aggiornamento immediato delle definizioni e del motore
Update-MpSignature -UpdateSource MicrosoftUpdateServer

# In ambienti con Configuration Manager / WSUS, verifica la data
# dell'ultimo aggiornamento delle definizioni su tutta la flotta
Get-MpComputerStatus | Select-Object ComputerID, AMEngineVersion |
    Export-Csv -Path C:\Reports\defender-engine-status.csv -NoTypeInformation

Se gestisci endpoint tramite Microsoft Defender for Endpoint, puoi verificare la copertura a livello di flotta dal portale Security, sezione Reports > Microsoft Defender Antivirus, filtrando per versione del motore. In ambienti air-gapped o con aggiornamenti WSUS ritardati, questo è il momento di controllare che la cadenza di distribuzione delle definizioni non stia introducendo un ritardo superiore a qualche giorno rispetto al rilascio Microsoft.

Indicatori di compromissione da monitorare

Per chi sospetta un possibile sfruttamento avvenuto prima della patch, Microsoft e i ricercatori indipendenti suggeriscono di dare priorità ai seguenti segnali in fase di threat hunting:

• Processi SYSTEM anomali generati da MsMpEng.exe o da altri componenti del Malware Protection Engine, specialmente se seguiti dall’avvio di una shell (cmd.exe, powershell.exe).
• Modifiche non pianificate alle impostazioni o ai servizi di Microsoft Defender, incluse disattivazioni temporanee della protezione in tempo reale non riconducibili a policy note.
• Creazione di attività pianificate (scheduled task) sospette nella stessa finestra temporale di scansioni antimalware.
• Nuovi meccanismi di persistenza (servizi, chiavi di avvio, WMI event subscription) creati con privilegi SYSTEM da processi non abituali.

Al di là del singolo CVE, RoguePlanet è un buon promemoria di un principio generale di hardening: restringere i privilegi standard degli utenti, limitare l’esecuzione di codice non autorizzato tramite AppLocker o Windows Defender Application Control, e mantenere una cadenza di patching aggressiva restano le difese più efficaci contro l’intera classe di vulnerabilità di elevazione dei privilegi, indipendentemente dal componente specifico coinvolto.

Conclusione

RoguePlanet dimostra ancora una volta che anche i componenti di sicurezza non sono immuni da vulnerabilità e possono, paradossalmente, diventare essi stessi superficie d’attacco. Per i sistemisti la buona notizia è che la correzione è già in distribuzione automatica: il compito principale è verificare che la propria flotta stia effettivamente ricevendo gli aggiornamenti del motore in tempi ragionevoli e, per gli ambienti a rischio più elevato, effettuare una verifica retrospettiva degli indicatori di compromissione descritti sopra.

Fonte: Petri IT Knowledgebase – Microsoft Patches Zero-Day RoguePlanet Defender Flaw

Microsoft Patches Zero-Day RoguePlanet Defender Flaw

Microsoft has released a fix for the RoguePlanet zero-day vulnerability in Defender, addressing a flaw that could allow SYSTEM-level access.

^{Rabia Noureen (Petri IT Knowledgebase)}

Spcnet.it

2026-07-15 18:07:47

Passkey come default in Microsoft Entra ID: guida alla migrazione da SMS e voce entro il 2027

Il 13 luglio 2026 Microsoft ha annunciato un cambiamento che riguarda praticamente ogni amministratore Entra ID: a partire da settembre, le passkey diventeranno il metodo di autenticazione predefinito per i nuovi accessi, mentre SMS e voce – i metodi di verifica più diffusi negli ultimi quindici anni – verranno progressivamente dismessi come servizio nativo, con ritiro definitivo fissato per il 1 febbraio 2027. Non è un annuncio isolato: è la formalizzazione di una traiettoria che Microsoft persegue da tempo, ma con date precise che ogni tenant dovrà rispettare, volenti o nolenti.

Perché Microsoft accelera proprio ora

La motivazione dichiarata da Microsoft nel post ufficiale sul Security Blog non è generica. Il Microsoft Threat Intelligence ha osservato campagne di phishing assistite da AI con tassi di click-through fino al 54%, contro il circa 12% delle campagne tradizionali. A questo si aggiunge la crescente accessibilità di tecniche come il SIM swapping e il bypass dell’autenticazione multifattore, che rendono SMS e voce – entrambi basati su segreti condivisi trasmessi su canali intercettabili – sempre meno affidabili come secondo fattore. Le passkey, basate su crittografia a chiave pubblica anziché su segreti condivisi, sono phishing-resistant per costruzione: non esiste un codice da rubare o da far digitare su un sito civetta, perché la chiave privata non lascia mai il dispositivo dell’utente.

Cosa cambia concretamente: la timeline

Per pianificare la migrazione senza sorprese, questi sono i passaggi principali comunicati da Microsoft:

• 1 settembre 2026 – Tutti gli utenti già abilitati per SMS o voce vengono automaticamente iscritti e sollecitati a registrare una passkey al successivo accesso con autenticazione multifattore.
• 18 settembre 2026 – Microsoft pubblica i dettagli su provider di telecomunicazioni supportati, prezzi e condizioni commerciali per chi deve continuare a usare SMS/voce tramite terze parti.
• 30 ottobre 2026 – Gli amministratori possono selezionare e configurare un provider telecom di terze parti tramite il Microsoft Security Store.
• 1 febbraio 2027 – Microsoft ritira il servizio nativo di autenticazione SMS e voce in Entra ID. Da questa data, chi non ha configurato un provider terzo o una passkey dovrà necessariamente registrarne una prima di poter accedere: non è previsto alcun opt-out.

Il punto da evidenziare per chi pianifica: l’auto-enrollment parte a settembre, ma la scadenza reale – quella che rompe l’accesso per chi non si è mosso – è a febbraio 2027. Sono circa sette mesi di finestra, che possono sembrare tanti ma si riducono rapidamente se il tenant ha migliaia di utenti, dispositivi eterogenei o processi di change management lenti.

Quali tipi di passkey supporta Entra ID

Entra ID distingue due famiglie di passkey, ed è una distinzione operativa rilevante per la policy da adottare:

• Passkey sincronizzate (synced): memorizzate in un gestore di credenziali a livello di piattaforma e sincronizzate tra i dispositivi dell’utente, ad esempio tramite iCloud Keychain o Google Password Manager. Comode per utenti finali, ma con un livello di attestazione hardware inferiore.
• Passkey vincolate al dispositivo (device-bound): legate a un singolo dispositivo o chiave fisica, ad esempio le passkey di Microsoft Authenticator, le Entra passkey su Windows (basate su Windows Hello for Business) e le chiavi di sicurezza FIDO2 hardware. Offrono garanzie di attestazione più solide, adatte a account amministrativi o a scenari con requisiti di compliance stringenti.

Le passkey FIDO2 sono disponibili in tutte le edizioni di Entra ID, inclusa quella Free, senza licenze aggiuntive: un dettaglio non scontato che elimina l’alibi del costo per rimandare l’adozione.

Come prepararsi: guida pratica per amministratori

1. Mappa chi usa ancora SMS o voce

Il primo passo è puramente ricognitivo: individuare quali utenti o gruppi sono ancora configurati su SMS o voce come metodo di autenticazione. Con Microsoft Graph PowerShell:

# Connessione a Microsoft Graph con i permessi necessari
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","Policy.Read.All"

# Elenca gli utenti con metodo di autenticazione telefonico configurato
$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName
foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationPhoneMethod -UserId $u.Id -ErrorAction SilentlyContinue
    if ($methods) {
        [PSCustomObject]@{
            User  = $u.UserPrincipalName
            Phone = ($methods.PhoneNumber -join ", ")
        }
    }
}

2. Configura i passkey profile

Da qualche mese Entra ID supporta i passkey profile, che permettono configurazioni granulari per gruppo anziché un’unica impostazione a livello di tenant: puoi definire requisiti di attestazione, tipo di passkey ammesso (device-bound vs synced) e restrizioni per AAGUID (l’identificativo del modello di authenticator) differenziando, ad esempio, gli amministratori – per cui puoi imporre solo chiavi FIDO2 hardware con attestazione verificata – dal resto del personale, per cui le passkey sincronizzate sono sufficienti. La configurazione si effettua da Entra admin center > Protection > Authentication methods > Passkey (FIDO2), oppure via Graph API sull’endpoint /policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2.

3. Attiva una registration campaign

Per portare gli utenti alla registrazione senza dover organizzare sessioni di onboarding manuali, Entra ID offre le registration campaign: durante un normale accesso MFA, l’utente viene invitato a registrare una passkey in modo contestuale. Si abilitano da Authentication methods > Registration campaign, specificando quale metodo promuovere (in questo caso, passkey) e per quali gruppi.

4. Valuta l’enforcement con Conditional Access

Per i ruoli più sensibili, non basta rendere le passkey disponibili: conviene richiederle esplicitamente. Le authentication strength policy di Conditional Access permettono di imporre l’uso di metodi phishing-resistant (passkey, FIDO2, Windows Hello for Business) per l’accesso a risorse critiche, indipendentemente dal fatto che l’utente abbia ancora SMS configurato come fallback.

5. Se devi mantenere SMS o voce per obblighi regolatori

Non tutti i contesti possono abbandonare SMS/voce immediatamente per vincoli normativi o tecnici (ad esempio utenti privi di smartphone aziendale). In questo caso, il percorso è: documentare i segmenti di utenti interessati, attendere l’apertura del catalogo provider il 18 settembre, configurare un provider supportato tramite il Microsoft Security Store dal 30 ottobre, e testare la configurazione su un gruppo pilota prima del rollout esteso.

Conclusione

La transizione a passkey-by-default non è una feature opzionale da valutare con calma: ha una data di rottura precisa, il 1 febbraio 2027, dopo la quale gli utenti ancora legati a SMS o voce senza un provider terzo configurato saranno bloccati in accesso finché non registrano una passkey. Per i team IT il consiglio pratico è iniziare subito con la ricognizione degli utenti a rischio e l’attivazione di una registration campaign pilota, così da arrivare a settembre con un processo già collaudato invece di gestire l’auto-enrollment massivo come un’emergenza.

Fonte: Microsoft Security Blog – Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID

Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID | Microsoft Security Blog

Starting September 1, 2026, passkeys will become the default authentication experience in Microsoft Entra. Read more about how to prepare.

^{Nadim Abdo (Microsoft Security Blog)}