Due notizie emerse negli ultimi giorni fotografano bene il momento della sicurezza informatica: gli attaccanti non cercano solo falle tecniche, ma anche persone da convincere. Da un lato usano Microsoft Teams per fingersi supporto IT e ottenere accesso remoto; dall’altro stanno già provando a sfruttare nuove vulnerabilità PHP ad alta gravità. Per un’azienda, il messaggio è semplice: oggi il rischio nasce sia da configurazioni esposte sia da un dipendente che, in buona fede, clicca o concede accesso.
Cosa è successo
Il 26 ottobre 2026 Arctic Wolf Labs ha richiamato l’attenzione su un modello di attacco ricorrente osservato in centinaia di casi: criminali che sfruttano la chat esterna di Microsoft Teams per contattare le vittime fingendosi il supporto tecnico interno. L’obiettivo non è solo truffare l’utente, ma arrivare a installare malware, sottrarre dati e, in alcuni casi, distribuire ransomware.
Pochi giorni prima, il 23 ottobre 2026, è emerso un secondo fronte: tentativi su larga scala di sfruttare le vulnerabilità PHP2Shell, identificate come CVE-2026-109618 e CVE-2026-109619, entrambe con punteggio CVSS 9.2. Gli attacchi osservati puntavano a eseguire codice da remoto senza autenticazione e a infettare i sistemi con una variante della botnet Mirai chiamata Potassium.
Sono due vicende diverse, ma insieme mostrano una realtà importante per le imprese: non basta aggiornare i server se poi un utente si fida del messaggio sbagliato; allo stesso tempo, la formazione del personale non basta se siti e applicazioni restano vulnerabili.
Il nuovo abuso di Microsoft Teams: fiducia trasformata in accesso
Secondo i ricercatori, gli attaccanti stanno sfruttando la funzione di creazione delle chat esterne di Teams. Creano o acquistano tenant Microsoft 365, scelgono nomi credibili e avviano conversazioni che sembrano provenire dall’help desk aziendale. I nomi visualizzati imitano il reparto IT, spesso con etichette come “IT Support”, “Help Desk” o formule simili.
Un dettaglio emerso con chiarezza è l’uso di tenant “usa e getta”, spesso associati a domini *.onmicrosoft[.]com, cioè il dominio generato automaticamente quando si crea un tenant Microsoft 365. Arctic Wolf indica che quasi il 30-40% dei casi analizzati coinvolgeva proprio questo tipo di dominio. In altri casi, gli attaccanti hanno usato domini a pagamento per sembrare ancora più credibili: circa il 50% delle identità false osservate negli ultimi mesi usava il TLD .top, circa il 40% un normale .com, e poco più del 5% domini multilivello come .com.pl, .com.vn e .com.br.
La parte più insidiosa è che l’attacco non si basa su una vulnerabilità di Teams, ma sulla fiducia. Il dipendente riceve un messaggio apparentemente plausibile, spesso in un momento di stress creato ad arte.
Come funziona la catena dell’attacco
In molti casi, la conversazione su Teams è preceduta da una tecnica nota come mail bombing: la casella di posta della vittima viene sommersa in poco tempo da centinaia di iscrizioni a newsletter o conferme di sottoscrizione. L’utente si trova improvvisamente in una situazione caotica e, quando poco dopo arriva il messaggio del “supporto IT” che si offre di aiutare, è più incline a fidarsi.
A quel punto entra in gioco una seconda leva: il vishing, cioè l’ingegneria sociale via voce o via chat guidata per portare la vittima a concedere accesso remoto. I criminali fanno usare strumenti legittimi di assistenza e gestione remota, tra cui Quick Assist, AnyDesk, ScreenConnect, TeamViewer, Atera, Zoho Assist, NetSupport e LogMeIn.
Una volta ottenuto l’accesso “hands-on-keyboard”, cioè il controllo operativo della postazione, l’attaccante può:
- esplorare il sistema e la rete aziendale;
- distribuire altri strumenti di accesso o persistenza;
- muoversi lateralmente verso sistemi più importanti, inclusi i domain controller;
- esfiltrare dati sensibili;
- rilasciare il ransomware.
In alcuni incidenti collegati a questa attività è stato osservato il ransomware Chaos. In un caso descritto dai ricercatori, la vittima è stata convinta a eseguire un comando PowerShell che scaricava un file da Azure Blob Storage. L’installer avviava poi uno script che estraeva un impianto Python e successivamente interrogava Active Directory via LDAP per raccogliere informazioni su computer e utenti, inviandole a un server esterno.
Un elemento interessante per chi si occupa di difesa è che gli attaccanti evitano spesso di incollare direttamente un URL dentro Teams, per non attivare i controlli automatici come Safe Links o ZAP. Preferiscono guidare l’utente durante la sessione remota. Tradotto: il solo filtro sui messaggi non basta, servono anche monitoraggio degli endpoint e visibilità sugli account.
PHP2Shell: milioni di tentativi, ma il pericolo resta reale
Sul fronte tecnico, i tentativi di sfruttare PHP2Shell mostrano quanto velocemente gli attaccanti si muovano quando viene divulgata una vulnerabilità critica. Le due falle coinvolte, CVE-2026-109618 e CVE-2026-109619, permetterebbero esecuzione di codice remoto senza autenticazione tramite richieste HTTP appositamente costruite.
Le correzioni sono già disponibili nelle versioni PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Questo è il primo dato che interessa davvero alle aziende: se si usa PHP in applicazioni web, portali, gestionali via browser o siti WordPress con componenti personalizzati, verificare la versione in uso non è un’attività rinviabile.
La buona notizia, almeno per ora, è che i tentativi osservati non risultano aver avuto successo in modo diffuso. Sophos segnala che gli attaccanti sembrano ancora faticare a trasformare le falle in exploit affidabili. Tuttavia, “difficile da sfruttare” non significa “sicuro da ignorare”. Significa solo che il tempo guadagnato va usato per aggiornare i sistemi prima che qualcuno trovi una catena di attacco più stabile.
Gli attacchi rilevati puntavano a installare Potassium, una variante di Mirai. Si tratta di malware pensato per arruolare sistemi compromessi in una botnet capace di lanciare attacchi DDoS. Le analisi citate indicano anche funzionalità di download di payload e di disturbo di rete. In altre parole, il rischio non riguarda solo il singolo server compromesso, ma anche l’uso dell’infrastruttura aziendale come piattaforma per colpire altri.
Un ulteriore elemento emerso dalle ricerche è la presenza di strumenti di exploit su un server controllato dagli attaccanti, con script usati per verificare se i siti pubblici bersaglio avessero i prerequisiti necessari. Alla data del 22 ottobre 2026 non c’erano prove di accesso shell riuscito sui siti esaminati, ma la fase di ricognizione era già in corso.
Perché queste due notizie vanno lette insieme
A prima vista sembrano temi separati: Teams riguarda gli utenti, PHP i server. In realtà condividono un punto chiave: gli attaccanti lavorano su tutta la catena aziendale.
Se trovano una persona convincibile, entrano dalla chat. Se trovano un servizio esposto e non aggiornato, entrano dal web server. Se riescono in uno dei due punti, poi cercano di espandersi, mantenere l’accesso e monetizzare il più possibile.
Per questo la sicurezza moderna non può essere affrontata a compartimenti stagni. Non esiste il confine netto tra “problemi dell’ufficio” e “problemi dell’IT”: una chat esterna lasciata aperta senza regole e un server PHP non aggiornato sono due facce dello stesso rischio operativo.
Cosa significa per la tua azienda
Per una PMI italiana, le priorità pratiche sono cinque.
Primo: rivedere subito le impostazioni di Microsoft Teams. Se la chat esterna è attiva, bisogna chiedersi se serve davvero a tutti. In molte aziende è opportuno limitarla, definire regole chiare o restringere i domini ammessi. Se un dipendente può essere contattato da chiunque con un account esterno, il rischio cresce molto.
Secondo: formalizzare una regola semplice sull’assistenza IT. Nessun tecnico, interno o esterno, dovrebbe chiedere via chat non verificata di installare software, eseguire comandi PowerShell o aprire strumenti di accesso remoto. Se serve un intervento, il dipendente deve poter verificare la richiesta attraverso un canale già noto: numero interno, ticket, referente nominato.
Terzo: controllare tutti i server e applicativi basati su PHP. Siti web, aree riservate, CRM interni, portali clienti e vecchie applicazioni spesso restano online per anni senza una mappa aggiornata. Serve un inventario minimo e un controllo versioni immediato. Se c’è PHP, va verificato se le istanze sono aggiornate alle release corrette.
Quarto: migliorare il monitoraggio di endpoint e identità. Nel caso Teams descritto dai ricercatori, parte dell’attacco sfugge ai controlli sul solo contenuto del messaggio. Per questo è utile avere visibilità su accessi anomali, strumenti remoti eseguiti fuori standard, comandi PowerShell sospetti e download inusuali. Qui entrano in gioco servizi di sicurezza informatica e una gestione coerente delle postazioni con desktop IT management.
Quinto: prepararsi al peggio. Se un attacco porta a cifratura o cancellazione di dati, la differenza la fa un backup realmente separato, verificato e ripristinabile. Non basta “avere un NAS”: serve una strategia di remote backup con test di ripristino e ruoli chiari.
Per le aziende che trattano dati personali, c’è anche un riflesso organizzativo e normativo: una compromissione che comporti esfiltrazione di dati può avere impatti su continuità operativa, obblighi documentali e valutazioni privacy. Non è solo un problema tecnico, ma di processo.
I segnali da non sottovalutare
Ci sono alcuni indicatori che, se compaiono insieme, meritano attenzione immediata:
- improvvisa ondata di email di iscrizione o conferma non richieste;
- messaggio su Teams da un presunto supporto IT esterno o non riconosciuto;
- richiesta urgente di aprire Quick Assist, AnyDesk o strumenti simili;
- invito a eseguire script, installer o comandi da terminale;
- comparsa di processi o software remoti non previsti sulle postazioni;
- server web PHP non censiti o con versioni non allineate.
In una PMI, ignorare questi segnali perché “sembra solo un disguido” è spesso il passaggio che consente all’incidente di crescere.
Domande frequenti
Se usiamo Microsoft Teams dobbiamo disattivarlo?
No, ma va configurato con attenzione. Il punto non è smettere di usare Teams, bensì limitare le chat esterne non necessarie e definire una procedura chiara per le richieste del supporto IT.
Se i tentativi PHP2Shell non stanno riuscendo, possiamo aspettare prima di aggiornare?
No. Il fatto che gli exploit osservati siano ancora poco affidabili è una finestra utile per aggiornare, non un motivo per rinviare. Quando un exploit matura, il tempo di reazione si riduce drasticamente.
Qual è la prima misura concreta da fare domani mattina?
Inviare una comunicazione interna molto semplice: il supporto IT non chiederà mai via chat esterna di installare strumenti o eseguire comandi. In parallelo, far verificare subito le impostazioni di Teams e le versioni PHP esposte su Internet.