AgreeToSteal è il tipo di incidente che manda in crisi la narrativa “store uguale fiducia”. Non è un’estensione browser scaricata da un sito sospetto, non è un pacchetto installato in fretta da una repository improvvisata: è un add-in di Outlook passato attraverso un canale ufficiale e, proprio per questo, in grado di trasformare la normalità in un vettore d’attacco. Il dato che rende la storia immediatamente misurabile è l’impatto: oltre 4.000 credenziali rubate, con un flusso di esfiltrazione che arriva a un Telegram Bot e con un comportamento costruito per non far scattare allarmi, perché dopo il furto l’utente viene reindirizzato alla pagina reale di login. Nel frattempo, nello stesso perimetro Microsoft, un’altra falla mostra quanto possa essere sottile il confine tra “feature moderna” e “superficie d’attacco”: Notepad su Windows 11, con supporto Markdown, finisce esposto a una esecuzione di file tramite link e viene corretto con CVE-2026-20841 nel Patch Tuesday di febbraio 2026. Il punto non è sommare due eventi. Il punto è leggerli come un unico segnale: l’ecosistema fidato si sta espandendo, e ogni componente “piccolo”, dall’add-in al blocco note, può diventare una scorciatoia operativa per l’attaccante quando i controlli non sono progettati per il post-approvazione, per il contenuto dinamico e per gli URI non web. È una lezione che assomiglia in modo inquietante ai problemi già visti con estensioni browser e pacchetti npm, ma questa volta entra in un contesto dove molti utenti e aziende abbassano la guardia per definizione.
AgreeToSteal e il salto di qualità: quando un add-in ufficiale diventa un kit phishing
L’add-in nasce come AgreeTo, uno strumento pensato per collegare calendari e condividere disponibilità via email. La traiettoria diventa pericolosa quando il progetto viene abbandonato, attorno al 2023, e un attaccante riesce a rivendicare il dominio associato. È un passaggio che sembra amministrativo, quasi banale, e invece è la chiave dell’intero abuso: se un add-in carica risorse da un dominio che cambia proprietario, quel dominio diventa un telecomando. L’attaccante non deve bucare Microsoft, non deve violare Outlook, non deve “rompere” qualcosa: gli basta servire contenuti nuovi dove prima c’erano contenuti legittimi. Nel caso specifico, il sito outlook-one.vercel.app viene trasformato in un phishing kit che mostra una pagina di login Microsoft fasulla. Il meccanismo è studiato per massimizzare conversione e minimizzare sospetto: l’utente inserisce le credenziali, lo script le raccoglie ed esfiltra, poi arriva il reindirizzamento alla pagina autentica. Psicologicamente, l’utente interpreta l’eventuale secondo login come un piccolo glitch, non come un attacco. Operativamente, per l’attaccante, quel passaggio è il modo di ridurre segnalazioni e mantenere la campagna attiva più a lungo.
Qui entra la prima frattura di fiducia: Microsoft approva l’add-in nel dicembre 2022, ma, secondo il quadro che emerge, non monitora i contenuti post-approvazione quando l’architettura dell’add-in consente di caricare interfacce e codice da URL esterni che possono cambiare. È il problema classico della supply chain in canali fidati, ma trasportato su una piattaforma dove l’utente medio non è abituato a sospettare.
Manifest, URL dinamici e iframe: la superficie d’attacco dentro la piattaforma
Il cuore tecnico dell’abuso è nel modo in cui gli add-in di Outlook possono funzionare: un file manifest può puntare a una risorsa web, e quella risorsa può cambiare nel tempo. Nel caso AgreeToSteal, la dinamica viene sfruttata con URL che caricano contenuti in tempo reale dentro un iframe. Questa scelta non è un dettaglio estetico. È un modo di separare l’add-in dal controllo statico: l’add-in resta “lo stesso”, ma ciò che mostra e ciò che esegue può evolvere senza passare da un nuovo ciclo di revisione.
🔴 OSSERVATORIO INTELLIGENCE: LIVE
Qui nasce la domanda più scomoda per un marketplace: cosa stai approvando davvero? Stai approvando un pacchetto, o stai approvando un “puntatore” che può cambiare volto? Quando la risposta è la seconda, l’attaccante non ha bisogno di convincere Microsoft a pubblicare un malware. Gli basta aspettare, rivendicare un dominio orfano, e sostituire la parte web con un kit di phishing. La scelta di esfiltrare via Telegram Bot API aggiunge un ulteriore elemento di praticità criminale. Telegram è facile da automatizzare, rapido da gestire, e spesso finisce in un’area grigia di visibilità per alcune reti aziendali, soprattutto se l’uso della piattaforma è consentito o non è monitorato con attenzione. Koi Security, nel tuo input, riesce perfino ad accedere al canale di esfiltrazione e a osservare l’operatore mentre testa credenziali rubate. Questo dettaglio conta perché riduce l’ambiguità: non è un furto “accidentale”, è un furto operativo, con validazione attiva delle credenziali raccolte.
Permessi ReadWriteItem: perché il furto password è solo la prima conseguenza
Un altro punto che sposta l’incidente da “phishing classico” a “rischio sistemico” è il set di permessi. L’add-in dispone di ReadWriteItem, un livello che abilita lettura e modifica degli elementi della mailbox. Anche se l’impatto principale osservato resta il furto credenziali, la presenza di quel permesso rende plausibili scenari peggiori: accesso a email sensibili, manipolazione di messaggi, raccolta di thread, ricerca di fatture, reset password, codici OTP, link di invito, workflow interni. In un contesto aziendale, questo tipo di permesso può trasformare un singolo account in un punto di pivot, perché la mailbox è spesso la “memoria centrale” dell’organizzazione. È qui che AgreeToSteal diventa un caso scuola. Non è solo un add-in malevolo: è la dimostrazione che un canale fidato può essere usato per installare un componente che, di fatto, lavora dentro uno dei sistemi più sensibili per utenti e aziende, cioè la posta. Se un attaccante ottiene credenziali Microsoft e può muoversi nel perimetro di Outlook, la linea tra furto account e compromissione di processi si assottiglia. E quando si parla di credenziali Microsoft, la posta non è mai isolata: dietro ci sono spesso accessi a documenti, chat, strumenti di collaborazione e identità federate.
Koi Security e il “post-approvazione” che manca: la domanda sulla governance degli add-in
Il valore dell’analisi attribuita a Koi Security sta nella fotografia della lacuna: l’approvazione iniziale non basta se il contenuto è dinamico e se l’asset più importante, cioè il dominio che ospita la UI, può cambiare proprietà. La raccomandazione che emerge nel tuo testo è concreta: rivedere gli add-in quando lo stesso URL è in grado di servire contenuti diversi, verificare l’ownership del dominio, e delistare add-in non aggiornati o abbandonati. Un’altra proposta, che diventa cruciale per la valutazione dell’impatto, riguarda la visibilità: conoscere il conteggio installazioni aiuta a capire quanto velocemente un incidente può propagarsi, e a chi rivolgere comunicazioni e remediation. È un passaggio che ricorda in modo diretto la gestione di estensioni browser. Se un’estensione può caricare script remoti, la piattaforma deve ragionare sul comportamento nel tempo, non solo sul pacchetto al momento della pubblicazione. Nel mondo Outlook, questa logica sembra arrivare adesso con forza, perché AgreeToSteal dimostra che il rischio non è teorico: è già operativo, con credenziali rubate e un operatore che testa accessi in tempo reale.
Notepad su Windows 11 e CVE-2026-20841: quando un link Markdown diventa esecuzione
Mentre AgreeToSteal espone la supply chain degli add-in, CVE-2026-20841 mostra un’altra dinamica: l’innovazione funzionale può aprire superfici d’attacco non intuitive. Microsoft modernizza Notepad con supporto Markdown e, in questo contesto, emerge una vulnerabilità che consente esecuzione silenziosa di file tramite link incorporati in un file .md. Il gesto è banale: apri il file in Notepad, fai Ctrl+click sul link. Il risultato, prima della correzione, è che un link può puntare a eseguibili locali o remoti e portare all’esecuzione senza avvisi adeguati, perché la neutralizzazione di elementi speciali nel comando risulta impropria e può consentire iniezione.
Nel tuo input compaiono URI che spiegano bene la gravità: file:// per richiamare risorse locali o percorsi che possono diventare trampolini, e ms-appinstaller:// come esempio di schema che non è “web” ma può innescare comportamenti ad alto impatto. L’esecuzione avviene nel contesto utente, quindi l’attaccante non ottiene automaticamente privilegi di sistema, ma ottiene esattamente ciò che serve per molte catene moderne: eseguire un payload con i permessi della vittima, soprattutto se la vittima lavora in contesti dove le credenziali e i token di sessione sono più preziosi dell’admin locale. C’è poi un dettaglio che rende l’attacco realistico: l’uso di link remoti SMB può espandere lo scenario in reti dove certe condivisioni sono raggiungibili e dove il social engineering può convincere qualcuno ad aprire un file Markdown “innocuo”. Non è una tecnica nuova, è l’applicazione di un modello classico a un contesto nuovo: un blocco note che, improvvisamente, non è più un editor passivo.
Versioni affette, Patch Tuesday e aggiornamenti via Store: perché la finestra di rischio si misura in giorni
La vulnerabilità colpisce Notepad 11.2510 e precedenti, viene classificata ad alta severità, e viene corretta come CVE-2026-20841 nel Patch Tuesday di febbraio 2026. Un elemento operativo che cambia la gestione, rispetto al passato, è il canale di aggiornamento: Notepad si aggiorna via Microsoft Store, quindi la patch può arrivare più velocemente per chi ha aggiornamenti automatici attivi. Questo, nel quadro, “minimizza l’impatto ongoing”, perché riduce la durata della finestra in cui un file Markdown malevolo può funzionare come detonatore. Microsoft introduce anche avvisi per URI non http/https, e questo è un punto decisivo: la difesa non è “bloccare i link”, ma rendere visibile all’utente quando sta per attivare uno schema potenzialmente pericoloso. Nel tuo testo compaiono esempi come file:, ms-settings:, ms-appinstaller, mailto:, ms-search:. Il senso di questi avvisi non è tecnico, è comportamentale: spezzare l’automatismo del click. Il parallelismo con AgreeToSteal è immediato. In un caso l’utente viene portato a inserire credenziali in un frame “interno” a Outlook. Nell’altro l’utente viene spinto a cliccare un link in un file Markdown. In entrambi i casi la catena si muove su un punto debole universale: l’azione dell’utente in un contesto che appare normale.
Due incidenti, una sola lezione: il perimetro fidato è la nuova superficie d’attacco
AgreeToSteal e CVE-2026-20841 raccontano un’evoluzione che è già in atto da anni, ma qui diventa evidente perché tocca strumenti quotidiani. L’attaccante non cerca per forza l’exploit “glamour”. Cerca la scorciatoia che gli dà conversione, scalabilità e invisibilità. Un add-in ufficiale con URL dinamici è una scorciatoia perché sfrutta la fiducia del canale. Un link Markdown che attiva URI non web è una scorciatoia perché sfrutta la curiosità e l’abitudine. Per chi gestisce ambienti Microsoft, l’elemento più importante non è il panico, è la disciplina operativa. Quando emerge un add-in compromesso, la risposta non può fermarsi a “Microsoft lo ha rimosso”. Serve ragionare su chi lo ha installato, su quali account hanno inserito credenziali, su quali mailbox hanno privilegi, e su quali segnali di accesso anomalo devono essere cercati. Quando emerge una falla in Notepad, la risposta non può essere “non aprite file .md”. Serve aggiornare, e serve ridurre il rischio di esecuzione involontaria, soprattutto su endpoint dove file di testo e snippet circolano continuamente.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
