Questo articolo analizza la disclosure presentata a Microsoft e consultabile in inglese su digitaldefense, dove sono disponibili immagini, video dimostrativi e un esempio di codice Python.
Negli ultimi anni la sicurezza delle comunicazioni digitali ha amplificato un certo paradigma: l’attacco non punta più soltanto a violare l’infrastruttura, ma a smantellare la fiducia dell’utente sfruttando ogni tipo di aggancio cognitivo.
Se email, calendari e piattaforme di collaborazione rappresentano il centro di gravità della vita aziendale, la superficie di attacco più efficace non è quella puramente tecnica, ma quella capace di incide sul fattore umano.
 Christmas Sale -40% 𝗖𝗵𝗿𝗶𝘀𝘁𝗺𝗮𝘀 𝗦𝗮𝗹𝗲! Sconto del 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮 del Corso "Dark Web & Cyber Threat Intelligence" in modalità E-Learning sulla nostra Academy!🚀
Fino al 𝟯𝟭 𝗱𝗶 𝗗𝗶𝗰𝗲𝗺𝗯𝗿𝗲, prezzi pazzi alla Red Hot Cyber Academy. 𝗧𝘂𝘁𝘁𝗶 𝗶 𝗰𝗼𝗿𝘀𝗶 𝘀𝗰𝗼𝗻𝘁𝗮𝘁𝗶 𝗱𝗲𝗹 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮.
Per beneficiare della promo sconto Christmas Sale, scrivici ad [email protected] o contattaci su Whatsapp al numero di telefono: 379 163 8765.
Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì. |
Il fenomeno analizzato dal presente articolo non riguarda prodotti certamente marginali o scenari teorici. Colpisce Outlook Web e Outlook Desktop nella sua versione moderna, nonché Microsoft Teams sia in versione Web sia Desktop. Parliamo quindi dell’ecosistema su cui si fonda la quotidianità operativa di moltissime aziende. In questo quadro merita un’annotazione significativa: la versione “classica” di Outlook, quella storica e meno recente, non è affetta dal problema. Il comportamento critico emerge soltanto nel nuovo stack applicativo, dove l’interfaccia ha assunto un ruolo più centrale e integrato nell’esperienza utente.
In questo contesto, le evidenze riportate nel prosieguo dell’articolo, relative a un ambiente di comunicazione basato su Microsoft Outlook e Teams, assumono un’importanza critica. Comprenderle significa acquisire consapevolezza di quanto possa accadere nella quotidianità operativa di un’azienda.
Mostreremo come sia possibile, con relativa semplicità, manipolare l’interfaccia, alterare l’identità dei mittenti e indirizzare l’utente verso destinazioni controllate dall’attaccante. Tutto questo sfruttando la fiducia consolidata negli strumenti di produttività che utilizziamo ogni giorno, aumentando drasticamente le probabilità di successo delle campagne malevole.
Si tratta di un caso emblematico di come anche gli strumenti più comuni, se non supportati da un modello di sicurezza adeguato, possono trasformarsi in vettori di rischio tanto subdoli quanto inattesi.
A rendere la questione ancora più rilevante è il contesto della disclosure. Le vulnerabilità sono state segnalate a Microsoft MSRC per la prima volta nel dicembre 2024 (VULN-144184). Nonostante l’evidente impatto sulla fiducia dell’utente e sulla capacità di inganno dell’interfaccia, il comportamento è stato classificato come “atteso” oppure non meritevole di un intervento correttivo.
La segnalazione è stata riaperta nell’ottobre 2025 (VULN-164593), con un set di evidenze tecniche più ampio, prove complete dell’intera catena di attacco e l’introduzione di due ulteriori criticità capaci di alterare il comportamento degli strumenti. Anche queste nuove vulnerabilità sono state definite “moderate“, senza alcuna data stimata di remediation (ETA), mentre le due evidenze di impersonificazione, che consentono di presentare un aggressore come un contatto interno legittimo, sono state considerate come un comportamento previsto.
A complicare ulteriormente il quadro è la scelta di non associare alcuna CVE. La motivazione ufficiale è che non viene richiesto alcun intervento agli utenti e che eventuali mitigazioni possono essere applicate in modo silente lato SaaS. Questo approccio esclude la possibilità di riconoscere le vulnerabilità in modo trasparente e impedisce di attribuire il merito a chi le ha individuate. Di conseguenza si indebolisce la catena di fiducia tra ricercatori e vendor, scoraggiando la divulgazione responsabile e normalizzando il rischio per gli utenti finali.
Questa cornice solleva una domanda scomoda per il settore. Se una vulnerabilità non compromette i sistemi dell’azienda che li sviluppa ma mina la fiducia degli utenti che li utilizzano ogni giorno, può davvero essere trattata come un problema secondario?
Le campagne di phishing classiche cercano di convincere l’utente ad aprire un allegato o cliccare un link sospetto. Oggi il livello si alza: il sospetto potrebbe non bastare. L’attaccante può impersonare identità interne e presentarsi attraverso indicatori visivi credibili: nome, foto profilo, contesto aziendale.
La chiave di volta è la gestione dei file ICS (iCal), che Microsoft utilizza per le convocazioni calendario. Attraverso campi ical normalmente legittimi, come:
l’attaccante non sfrutta un exploit, ma funzionalità standard, manipolandole a proprio favore.
Risultato:
Questa dinamica comporta un salto qualitativo: l’utente non vede più un link sospetto, vede una funzione di piattaforma affidabile.
Il valore di un’interfaccia moderna sta nella capacità di astrarre complessità. Ma dove l’interfaccia semplifica, si creano “zone cieche” per la sicurezza.
Quando un utente vede nel calendario un invito:
il livello di diffidenza arriva quasi a zero.
Non c’è più contesto sospetto, non c’è un dominio esterno nel corpo della mail, non c’è un banner di avvertimento.
L’attacco sfrutta la fiducia sedimentata nell’ecosistema Microsoft 365, non una falla tecnica isolata.
Nei casi osservati emerge un ulteriore elemento che amplifica il rischio: la scomparsa della dicitura “per conto di” (on behalf of) dalla mail ricevuta, ottenuta con un semplice accorgimento tecnico, come l’inserimento di una lunga sequenza di caratteri “_” (underscore) nel nome del mittente. L’utente si trova di fronte a un messaggio email che sembra provenire da un account interno (ma anche esterno), completo di tutti gli elementi grafici associati a quel contatto che l’interfaccia ci farebbe normalmente vedere, come foto profilo e informazioni correlate. Non perché tali elementi siano stati alterati o generati artificialmente, ma perché le applicazioni coinvolte estraggono e mostrano realmente i dati del contatto impersonato. Questo accade anche se l’email è stata inviata tramite SMTP da un servizio terzo, ad esempio Gmail senza l’essenziale necessità di registrate domini fake per indurre in errore l’occhio dell’utente.
Il punto critico si manifesta quando il contenuto dell’invito viene automaticamente proiettato nel calendario: l’email, pur alterata, mantiene ancora tracce della sua origine esterna, mentre l’evento calendarizzato le perde completamente. Nel calendario spariscono i riferimenti a servizi terzi, sparisce qualsiasi indicazione del reale mittente e rimane solo la rappresentazione “pulita” dell’identità impersonata, con il relativo nome e la foto profilo aziendale. L’invito non è più una comunicazione sospetta, ma un appuntamento apparentemente interno, coerente e perfettamente integrato nel contesto lavorativo.
La mail è il punto di ingresso e l’utente quindi si trova di fronte a un messaggio che sembra provenire da un account interno, completo di tutti gli elementi grafici associati a quel contatto, come foto profilo e informazioni correlate. Non perché tali elementi siano stati alterati o forzati, ma perché le applicazioni coinvolte mostrano effettivamente i dati del contatto impersonato. Questo accade anche se l’email è stata inviata tramite SMTP da un servizio terzo, ad esempio Gmail.
È vero che osservando gli header del messaggio o esplorando angoli meno evidenti dell’interfaccia si possono individuare gli indizi dell’origine reale. Ma la domanda è tanto semplice quanto scomoda: quanti utenti lo faranno davvero? Nella percezione visiva e nell’uso quotidiano, l’unica identità che rimane è quella impersonata, mentre il mittente reale scompare.
Non si tratta di una vulnerabilità tecnica in senso tradizionale, ma di un difetto nella presentazione che indebolisce il modello di fiducia. L’identità visibile non corrisponde all’identità reale, creando un contesto in cui l’interfaccia diventa parte dell’inganno.
L’inserimento automatico di inviti in calendario apre un altro vettore: il calendar flooding.
Un attaccante può saturare l’agenda aziendale di eventi fraudolenti:
Perché è critico?
Il rischio scala linearmente col numero di target, non con la complessità dell’attacco.
L’aspetto più insidioso non è quindi soltanto la manipolazione del messaggio email. Arriva una mail, e immediatamente compare un invito nel calendario dell’utente, senza che sia necessaria alcuna azione. Il contenuto della mail può contenere alterazioni, indicatori sospetti o tracce dell’origine reale. L’evento calendarizzato invece no. È la versione “pulita”, priva di ogni riferimento a terze parti.
Nel momento in cui l’invito viene inseritocome evento di calendario in Outlook o Teams, il sistema perde completamente i riferimenti all’indirizzo o al servizio esterno che lo ha generato. Rimane soltanto la rappresentazione visiva dell’account impersonato: nome, foto profilo, entità apparente dell’organizzatore. Tutto ciò che potrebbe suggerire un’origine non legittima viene assorbito dall’interfaccia.
L’email è il vettore di ingresso, l’evento calendario è il cavallo di Troia. L’utente, o peggio ancora un gruppo aziendale che usa il calendario come fonte operativa, non vede più solo un messaggio sospetto o un mittente anomalo. Vede un appuntamento interno, formalmente coerente con il contesto aziendale e accompagnato dalla UI che ha imparato a considerare “sicura”.
Non stiamo parlando di un difetto cosmetico, ma di un cortocircuito nel modello di fiducia. Si passa da una comunicazione che porta ancora con sé tracce dell’origine reale a un oggetto applicativo che non ne conserva più nessuna. L’attaccante smette di sembrare un attaccante. Diventa un collega, un manager, un referente, un contatto di fiducia. E a quel punto, l’utente smette semplicemente di difendersi.
Il punto più delicato non riguarda esclusivamente Microsoft. È un problema di settore.
La sicurezza delle interfacce non viene trattata alla stregua delle vulnerabilità di sistema perché non produce RCE, privilege escalation o memory corruption. Non “buca” i server.
Ma la sicurezza non è solo integrità tecnica.
Una piattaforma che guida milioni di persone a cliccare automaticamente su pulsanti il cui significato può essere alterato è una piattaforma vulnerabile, anche se il backend risulti integro. Sarebbe come dire che una XSS non è una vulnerabilità, solo perché non intacca il backend.
Le aziende che oggi operano in ecosistemi Microsoft 365 non subiscono più attacchi di tipo tecnico, subiscono attacchi che tentano di minare la loro fiducia quindi la sicurezza deve essere parte integrante anche della user interface, che è di fatto quella che la maggioranza di utenti hanno a che fare continuamente tutti i giorni.
Se una vulnerabilità espone al rischio “solo” gli utenti e non la piattaforma, deve essere considerata “moderata”? In un mondo fatto (ancora) da umani, la risposta è semplice: no!
Quando il perimetro privilegiato è il comportamento umano, non basta dire che il problema non intacca l’infrastruttura o i sistemi.
Un attacco che rende indistinguibili interazioni legittime e false è un problema di primo livello, perché mina il principio stesso di autenticità.
In un contesto in cui:
la fiducia nell’interfaccia è un asset primario di sicurezza.
E come tale deve essere trattata.
Seguici su Google News, LinkedIn, Facebook e Instagram per ricevere aggiornamenti quotidiani sulla sicurezza informatica. Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
