Cybersecurity Dossier: Vulnerabilità Microsoft e Smishing BRT
- Campagna di smishing a tema BRT punta al furto di dati finanziari tramite false tariffe di riconsegna.
- Microsoft risolve 973 vulnerabilità, tra cui due 0-day di Elevation of Privilege (CVE-2026-81963 e CVE-2026-85880).
- SAP rilascia patch critiche per CVE-2026-2332, con Proof of Concept pubblico disponibile online.
- Allerta su infrastrutture critiche: vulnerabilità rilevate in prodotti Schneider Electric, Dell e Qualcomm.
Il perimetro di sicurezza di un'impresa non è più una linea definita, ma una superficie porosa che si estende dallo smartphone del dipendente ai core system dell'ERP aziendale. I recenti bollettini dell'Agenzia per la Cybersicurezza Nazionale (ACN) delineano un panorama dove l'ingegneria sociale più semplice convive con falle di sistema estremamente sofisticate.
Un SMS di BRT che sblocca un conto corrente
Tutto inizia con una notifica sul display di uno smartphone. Il testo mima perfettamente le comunicazioni di un corriere espresso: una consegna non è andata a buon fine e l'utente è invitato a prenotare un nuovo tentativo. È l'innesco di una campagna di smishing a tema BRT, rilevata dal CSIRT Italia, che non punta a installare malware, ma a manipolare la psicologia della vittima attraverso un percorso a tappe.
Il primo clic conduce a una pagina di aggiornamento dell'indirizzo di consegna. Una volta inseriti i dati anagrafici, l'utente viene spinto verso l'ultima fase: il pagamento di una tariffa di gestione per la riconsegna. L'importo è volutamente modico, una strategia per ridurre la percezione del rischio e persuadere la vittima a inserire nome del titolare, numero della carta, scadenza e codice CVV/CVC. Per rendere l'inganno credibile, il sito mostra animazioni di verifica del pagamento identiche a quelle delle transazioni online legittime. L'allerta ACN evidenzia come la semplicità del vettore SMS rimanga uno degli strumenti più efficaci per l'esfiltrazione di credenziali finanziarie.
973: l'entità del rischio Microsoft
Mentre il singolo utente combatte contro lo smishing, l'infrastruttura aziendale affronta numeri di altra portata. Gli ultimi aggiornamenti mensili di Microsoft hanno dovuto sanare un totale di 973 nuove vulnerabilità. Tra queste, spiccano due falle di tipo 0-day, ovvero vulnerabilità già sfruttate dagli attaccanti prima che venisse rilasciata la patch.
Entrambe le 0-day sono classificate come Elevation of Privilege (EoP) con uno score CVSS v3.1 di 7.8. La prima, CVE-2026-81963, colpisce lo stack di gestione degli aggiornamenti di Windows. La seconda, CVE-2026-85880, interessa il meccanismo di comunicazione interprocesso Advanced Local Procedure Call (ALPC). In entrambi i casi, l'obiettivo dell'attaccante è lo stesso: partendo da un accesso locale autenticato, scalare i privilegi fino a raggiungere il livello SYSTEM, ottenendo il controllo totale della macchina target.
Analisi strategica: Il volume di 973 vulnerabilità in un singolo ciclo di aggiornamento suggerisce che la complessità del codice di Microsoft sia diventata un rischio sistemico. Per un imprenditore, questo significa che il concetto di sistema operativo sicuro non esiste; esiste solo un sistema operativo aggiornato in tempo reale.
Il trucco del link following per scalare i privilegi
Per comprendere come un attaccante passi da un utente limitato al controllo totale del sistema, occorre analizzare la CVE-2026-81963. Il problema risiede in un meccanismo denominato link following. In termini semplici, il sistema operativo non risolve correttamente i collegamenti prima di accedere ai file.
Un attaccante locale può sfruttare questa incongruenza per manipolare i percorsi del file system. Creando collegamenti simbolici o hard link che puntano a file di sistema protetti, l'attaccante può indurre il processo di aggiornamento di Windows — che gira con privilegi elevati — a modificare o sovrascrivere file che l'utente normale non potrebbe toccare. È un gioco di specchi dove il sistema viene ingannato sulla reale destinazione di un'operazione di scrittura, permettendo l'elevazione dei privilegi a livello SYSTEM.
Perché i Proof of Concept pubblici rendono SAP più fragile?
Nel mondo degli ERP, SAP è il cuore pulsante delle operazioni business. L'ultimo Security Patch Day di settembre ha rivelato diverse vulnerabilità, tra cui quattro critiche e quattro alte. La CVE-2026-2332, con uno score di 7.4, è particolarmente preoccupante perché è disponibile in rete un Proof of Concept (PoC) pubblico.
Un PoC è essenzialmente un manuale d'istruzioni che spiega come sfruttare la falla. In questo caso, la vulnerabilità di tipo HTTP Request/Response Smuggling è dovuta all'uso di componenti Jetty vulnerabili alla CRLF Injection. Inserendo caratteri di Carriage Return (CR) e Line Feed (LF) in parametri URL o header HTTP, un attaccante può modificare la struttura della risposta generata dal server, bypassando i controlli di sicurezza di SAP Commerce Cloud.
Lettura critica: La pubblicazione di un PoC accorcia drasticamente il tempo tra la scoperta della falla e l'attacco massivo. Se prima l'exploit era appannaggio di gruppi APT (Advanced Persistent Threats), ora diventa accessibile a script-kiddies. La fragilità di SAP non risiede solo nel bug, ma nella velocità con cui la conoscenza tecnica della vulnerabilità si democratizza nel dark web.
L'anatomia di una transazione malevola
Se guardiamo dietro le quinte di un attacco, sia esso un'iniezione di codice in SAP o un furto di carta di credito via SMS, emerge un pattern comune: l'inganno della fiducia. Nel caso dello smishing BRT, l'anatomia della transazione segue questo flusso:
- Fase di Hooking: SMS con senso di urgenza (consegna fallita).
- Fase di Profiling: Richiesta di aggiornamento indirizzo per raccogliere dati anagrafici.
- Fase di Monetizzazione: Richiesta di una modica tariffa di gestione per abbassare le difese psicologiche.
- Fase di Esfiltrazione: Inserimento dei dati della carta di credito in un form contraffatto.
- Fase di Conferma: Visualizzazione di animazioni di caricamento per simulare una transazione reale e prevenire sospetti immediati.
Chi deve aggiornare cosa in un'infrastruttura ibrida
Immaginiamo un dialogo tra un CTO e un Responsabile IT di un'azienda manifatturiera che utilizza un mix di cloud, server on-premise e macchinari industriali. La complessità degli ultimi alert ACN rende questa discussione critica.
CTO: Abbiamo patch per Microsoft, SAP, Dell e Schneider Electric. Da dove iniziamo?
Responsabile IT: La priorità è l'edge e l'accesso. Dobbiamo aggiornare Dell Secure Connect Gateway, perché le 3 vulnerabilità critiche e le 37 alte permettono l'esecuzione di codice remoto a utenti non autenticati. Se cade il gateway di supporto remoto, siamo ciechi.
CTO: E i PLC in fabbrica?
Responsabile IT: Schneider Electric ha segnalato falle critiche nei Modicon M580. Se non aggiorniamo l'application level a 4.00 o 4.20, rischiamo un bypass dell'autenticazione direttamente sulla linea di produzione. È un rischio fisico, non solo digitale.
CTO: E per i chipset dei dispositivi mobili della flotta?
Responsabile IT: Qualcomm ha 14 vulnerabilità alte. Riguardano la corruzione della memoria e la stabilità. Meno urgenti del gateway Dell, ma necessarie per evitare crash sistemici dei terminali.
La gestione dei patch day tra NIS2 e la resilienza delle PA italiane
L'attuale scenario di vulnerabilità non è solo un problema tecnico, ma un obbligo normativo. Con l'entrata in vigore della direttiva NIS2, la gestione delle vulnerabilità diventa un parametro di conformità legale per le entità essenziali e importanti. Non aggiornare un sistema SAP o un gateway Dell non è più una negligenza tecnica, ma una violazione della resilienza operativa.
In Italia, la Pubblica Amministrazione e le imprese collegate affrontano una sfida di scala. Quando l'ACN segnala vulnerabilità in TYPO3 CMS (che interessano diverse versioni dalla 10.x alla 14.x) o in prodotti Qualcomm, l'impatto sistemico è classificato come medio o alto. La resilienza non si misura più sulla capacità di prevenire l'intrusione, ma sulla velocità di applicazione della patch.
Analisi geopolitica e normativa: L'UE sta spingendo verso una standardizzazione della risposta agli incidenti. La NIS2 impone una catena di responsabilità che risale fino al top management. Se un'azienda italiana subisce un data breach a causa di una vulnerabilità nota e non patchata (come la CVE-2026-2332 di SAP), l'imprenditore potrebbe essere chiamato a rispondere personalmente della mancata adozione di misure di sicurezza adeguate.
Per monitorare l'efficacia di questa transizione, l'indicatore verificabile sarà il tempo medio di patching (Mean Time to Patch) nelle aziende soggette a NIS2 entro il 2026. Una riduzione di questo tempo sarà l'unico vero segno di resilienza.
Per approfondire le procedure di aggiornamento, è possibile consultare i bollettini ufficiali su SAP Security Patch Day o monitorare le aggiornamenti mensili Microsoft.
Impatto per le imprese italiane e l'UE
Per le imprese italiane, l'interconnessione tra vulnerabilità software (Microsoft/SAP) e hardware industriale (Schneider Electric) crea un rischio di "effetto domino". La conformità alla NIS2 e l'allineamento all'AI Act richiederanno investimenti non più solo in software di difesa, ma in processi di governance del rischio. Il mercato locale deve evolvere verso una cultura della manutenzione preventiva del software, equiparandola a quella dei macchinari industriali.
Domande frequenti
Cos'è lo smishing e come riconoscerlo?
Lo smishing è il phishing via SMS. Si riconosce per l'uso di messaggi urgenti, link verso siti non ufficiali e richieste di pagamenti modici per sbloccare servizi o consegne.
Perché la CVE-2026-81963 di Microsoft è pericolosa?
Perché permette a un utente già presente nel sistema di scalare i propri privilegi fino al livello SYSTEM tramite il link following, ottenendo il controllo totale del computer.
Cosa deve fare un'azienda che usa SAP Commerce Cloud?
Deve applicare immediatamente le patch del Security Patch Day di settembre per mitigare la CVE-2026-2332, dato che esiste un Proof of Concept pubblico che facilita l'attacco.
Quali prodotti Schneider Electric sono a rischio?
Sono interessati i Modicon M580 (application level < 4.00), Modicon M580 Safety (< 4.20), EcoStruxure IT Data Center Expert (<= 9.1.2) e PowerLogic T300 (<= 2.9.8-5620).
Fonti: Acn (7) ·
glacom · Intelligenza artificiale per aziende: i modelli girano sui tuoi server, i dati non escono →Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
