← Torna al blog

Security Briefing, 26 aprile 2026: malware Snow distribuito via Teams, violazione ADT legata a ShinyHunters e finestra di exploit di 13 ore per LMDeploy

Lo schema di oggi è netto: gli attaccanti stanno abusando di chat fidata, identità SaaS fidata e infrastruttura AI fidata più rapidamente di quanto molti team riescano a patchare o verificare.

---

---

1. UNC6692 trasforma la fiducia nel helpdesk di Microsoft Teams in una catena completa del malware Snow

Google Mandiant afferma che UNC6692 usa email bombing e impersonazione su Microsoft Teams per spingere i dipendenti a installare una falsa patch anti-spam. La vittima in realtà avvia il toolkit Snow: l’estensione browser SnowBelt, il tunneler SnowGlaze e la backdoor Python SnowBasin. Da lì gli operatori dumpano LSASS, si muovono lateralmente, raggiungono i domain controller ed esfiltrano materiale di Active Directory. Non è solo un altro phishing: è un percorso d’intrusione nativo del chat mascherato da supporto interno.

• Tratta ogni contatto IT inatteso via Teams come ostile finché non viene verificato fuori banda.
• Correla telemetria di Quick Assist, supporto remoto, task schedulati ed estensioni browser invece di guardarle a silos.
• Se la falsa patch è stata eseguita, presumi furto d’identità e movimento laterale.

---

2. ADT conferma una violazione dopo che ShinyHunters avrebbe ottenuto accesso tramite vishing a un account dipendente supportato da Okta

ADT afferma che gli attaccanti hanno rubato dati di clienti e potenziali clienti, inclusi nomi, numeri di telefono, indirizzi e, in una quota minore, date di nascita e le ultime quattro cifre di SSN o ID fiscali. ShinyHunters ha detto a BleepingComputer che l’intrusione è iniziata con un attacco di vishing contro un account SSO Okta di un dipendente e poi si è estesa a Salesforce. Che ogni affermazione dell’attore sia vera o meno, la lezione operativa è chiara: quando cade un’identità SaaS fidata, l’intera piattaforma business collegata diventa il raggio d’impatto.

• Rafforza verifica vocale e callback in ogni flusso helpdesk e di recupero identità.
• Caccia su Okta, Salesforce e altri log SaaS come un solo incidente, non come ticket separati.
• Ricontrolla subito least privilege e monitoraggio delle esportazioni per CRM e piattaforme di supporto.

---

3. LMDeploy mostra che la finestra di exploit AI si sta comprimendo a poche ore

La falla SSRF di LMDeploy, CVE-2026-33626, sarebbe stata sfruttata entro 12 ore e 31 minuti dalla disclosure. Gli attaccanti hanno usato il vision-language image loader per sondare metadata AWS, Redis, MySQL, superfici amministrative locali e un endpoint di callback esterno. Questo conta perché LMDeploy è esattamente il tipo di componente di serving LLM che i team distribuiscono in fretta e revisionano poco. Quando un advisory consegna causa radice e percorso di codice colpito, gli attaccanti non aspettano il tuo prossimo sprint.

• Patching o disattivazione immediata per i deployment LMDeploy vision-language vulnerabili.
• Blocca per default che i percorsi di model serving raggiungano metadata cloud e servizi amministrativi interni.
• Tratta i server di inferenza AI come infrastruttura esposta a internet, perché gli attaccanti lo fanno già.

---

Cosa dovrebbero fare oggi i team di sicurezza

1. Blocca i workflow di supporto basati su Teams e riverifica gli eventi recenti di assistenza remota.
2. Avvia una revisione d’incidente sull’identità SaaS se il tuo ambiente dipende da Okta, Salesforce o connettori high-trust simili.
3. Inventaria i componenti AI esposti o raggiungibili e patcha LMDeploy prima della prossima ondata di scansioni.
4. Usa questa mattina per chiudere falle di fiducia, non solo ticket.

---

---

In sintesi: Lo schema di oggi è netto: gli attaccanti stanno abusando di chat fidata, identità SaaS fidata e infrastruttura AI fidata più rapidamente di quanto molti team riescano a patchare o verificare.