(in)sicurezza digitale

2026-07-16 11:07:50

Le telecamere spia di Mosca: come l’intelligence russa sorveglia le rotte NATO verso l’Ucraina

Non servono droni, satelliti spia o infiltrati sul campo: bastano un videocitofono smart lasciato con la password di fabbrica e una connessione a Internet. Le agenzie di intelligence olandesi AIVD (General Intelligence and Security Service) e MIVD (Military Intelligence and Security Service) hanno rivelato che hacker legati allo stato russo hanno compromesso migliaia di telecamere IP e sistemi di videocitofonia lungo le rotte logistiche usate dalla NATO e dall’Ucraina per il trasporto di aiuti militari occidentali, trasformando dispositivi domestici e commerciali in una rete di sorveglianza capillare sul territorio europeo.

Un’operazione di OSINT armata su scala industriale

Secondo quanto riportato inizialmente dal Telegraph e ripreso da Kyiv Post, Pravda e diverse testate di settore, l’obiettivo dell’operazione russa era raccogliere intelligence in tempo reale sui tipi e sui volumi di armamenti inviati a Kyiv dagli alleati occidentali. A differenza delle tradizionali tecniche di sorveglianza satellitare o tramite drone, questa campagna sfrutta dispositivi IoT di consumo già presenti sul territorio: telecamere di sicurezza, citofoni smart e sistemi di videosorveglianza commerciale posizionati, spesso per puro caso logistico, lungo strade e valichi utilizzati per i convogli di aiuti militari.

Le due agenzie olandesi hanno confermato che un numero limitato di telecamere situate direttamente lungo le rotte logistiche nei Paesi Bassi risultava compromesso, e che le organizzazioni proprietarie dei dispositivi sono state avvisate per adottare contromisure. Il fenomeno, però, non si limita al territorio olandese: secondo l’advisory, la campagna ha interessato più Paesi membri della NATO e la stessa Ucraina, delineando un quadro di sorveglianza distribuita su tutta la catena di rifornimento occidentale verso il fronte.

Le tecniche: niente exploit sofisticati, solo superficie d’attacco enorme

Il dato più inquietante emerso dall’advisory congiunto non riguarda la sofisticazione tecnica — che qui è minima — ma la scala e la facilità dell’operazione. “Quando una telecamera IP viene identificata, un attaccante può provare ad accedervi via Internet: spesso è relativamente facile, perché molte telecamere connesse alla rete sono insufficientemente protette”, si legge nel rapporto delle agenzie olandesi. Gli operatori russi si sono affidati sistematicamente a password di default lasciate dal produttore, firmware obsoleti e mai aggiornati, e configurazioni di fabbrica mai modificate dagli utenti finali.

Molti dei dispositivi compromessi sono telecamere IP economiche di produzione cinese, in particolare modelli Hikvision e Dahua — marchi già oggetto in passato di segnalazioni per vulnerabilità di sicurezza e per preoccupazioni geopolitiche legate al loro utilizzo in infrastrutture sensibili. Una volta ottenuto l’accesso, gli aggressori hanno impiegato software di riconoscimento immagini per analizzare automaticamente i flussi video alla ricerca di veicoli militari e per identificarne il carico, automatizzando quello che altrimenti avrebbe richiesto osservazione umana costante.

Il contesto più ampio: la guerra ibrida contro la logistica occidentale

Questa campagna di compromissione delle telecamere si inserisce in un pattern più ampio di iniziative russe volte a mappare, disturbare o neutralizzare i vantaggi tecnologici che sostengono lo sforzo bellico ucraino. Un’inchiesta congiunta di The Insider, Der Spiegel e Le Monde, citata da Kyiv Post, ha rivelato che Russia e Cina hanno discusso segretamente, nell’ambito del terzo Forum di cooperazione tecnico-militare Cina-Russia tenutosi a Guangzhou, piani per neutralizzare la costellazione satellitare Starlink, da cui l’Ucraina dipende fortemente per comunicazioni e intelligence in tempo reale sul campo di battaglia.

Le slide trapelate, attribuite alla China Aerospace Science and Technology Corporation (CASC), delineavano un approccio multi-dominio contro Starlink: mezzi fisici per distruggere satelliti in orbita bassa, jamming elettromagnetico dei segnali e operazioni cyber pensate per caricare payload malevoli attraverso i terminali utente. Il documento proponeva inoltre una vera e propria “alleanza di sicurezza” tra Pechino e Mosca, con condivisione di intelligence e collaborazione su tecnologie chiave per contrastare il dominio strategico statunitense nello spazio.

Letta in questo contesto, la compromissione delle telecamere IP appare come un tassello a basso costo ma ad alto valore informativo di una strategia più ampia: se Starlink rappresenta il bersaglio ad alta quota della guerra ibrida russa, le migliaia di dispositivi IoT scarsamente protetti lungo le rotte logistiche europee rappresentano il fronte a bassa quota, silenzioso e diffuso, della stessa battaglia per la superiorità informativa.

Due righe pratiche per i difensori

Per i team di sicurezza, in particolare in ambito enterprise, logistico e delle infrastrutture critiche, questa vicenda è un promemoria brutale di quanto i dispositivi IoT di consumo restino l’anello debole della catena, specialmente quando dislocati in prossimità di asset sensibili o rotte strategiche. Le raccomandazioni delle agenzie olandesi, applicabili anche al contesto italiano ed europeo in generale, si concentrano su igiene di base della sicurezza IoT piuttosto che su contromisure avanzate:

• Cambiare immediatamente le password di default su tutte le telecamere IP, videocitofoni smart e dispositivi di videosorveglianza connessi a Internet.
• Aggiornare il firmware dei dispositivi IoT con regolarità, verificando la disponibilità di patch presso il produttore.
• Segmentare la rete in modo che le telecamere IP non abbiano accesso diretto a Internet né alla rete aziendale principale, utilizzando VLAN dedicate.
• Per le organizzazioni logistiche che operano lungo rotte sensibili, effettuare un censimento dei dispositivi IoT esposti pubblicamente tramite piattaforme come Shodan o Censys.
• Segnalare alle autorità nazionali competenti (in Italia, CSIRT-Italia) eventuali dispositivi sospetti o comportamenti anomali di rete rilevati su telecamere aziendali.
• Valutare con attenzione l’adozione di dispositivi IoT di produttori con precedenti riscontrati di vulnerabilità sistemiche, specialmente in contesti a rischio geopolitico elevato.

La vicenda dimostra ancora una volta che l’intelligence russa non ha bisogno di zero-day costosi o di infrastrutture offensive sofisticate quando l’anello debole è semplicemente la scarsa igiene di sicurezza di milioni di dispositivi IoT di consumo lasciati esposti online con le impostazioni di fabbrica. È una lezione che vale ben oltre il contesto bellico ucraino, e che riguarda direttamente chiunque gestisca infrastrutture di videosorveglianza connesse in rete.

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)}

informapirata ⁂

2026-07-15 12:36:18

@anfibolo il tuo ospedale si fida di Microsoft, la tua scuola si fida di Microsoft e probabilmente anche il tuo comune e la tua azienda si fidano di Microsoft. Mi spieghi per quale motivo dovrebbe essere colpa di un cittadino se si fida di microsoft?

Non bisogna colpevolizzare mai le vittime se queste vivono in un mondo condizionato dal pregiudizio per cui le Big Tech sono sempre affidabilissime