Cosa ha davvero confermato RingCentral
Il bollettino di sicurezza del Trust Center di RingCentral, datato 28 luglio 2026 e classificato di gravità ALTA, afferma che l'azienda "ha recentemente scoperto di essere bersaglio di una sofisticata campagna di social engineering" e ha "immediatamente adottato misure per fermare l'attività non autorizzata" con l'aiuto di una società forense esterna. Il bollettino aggiunge: "questo incidente ha riguardato i dati di una parte limitata dei clienti RingCentral, e stiamo comunicando direttamente con i clienti coinvolti. Se non siete stati contattati da RingCentral, non siete coinvolti."
Il gruppo di estorsione ShinyHunters ha rivendicato l'attacco un giorno prima, il 27 luglio 2026, dichiarando di aver sottratto 623 GB di dati, e ha poi pubblicato un archivio da 280 GB dopo il mancato pagamento da parte di RingCentral. Have I Been Pwned ha elaborato quell'archivio e lo ha aggiunto al proprio database il 13 agosto 2026: circa 1,6 milioni di indirizzi email univoci, insieme a nomi, numeri di telefono e indirizzi fisici. RingCentral ha precisato che la violazione non ha raggiunto RingEX, RingCentral Contact Center, RingCX né altri servizi principali, che a suo dire "continuano a funzionare senza interruzioni."
Uno schema tra fornitori, non tra vittime
Nel 2026 ShinyHunters ha ripetuto lo stesso copione contro un fornitore SaaS dopo l'altro: istanze clienti di Salesforce, dati clienti ospitati su Snowflake e implementazioni Oracle PeopleSoft, con il gruppo stesso che quantifica il bottino complessivo delle sue campagne in oltre 1,5 miliardi di record. RingCentral è l'ultimo nome di questa lista, e il metodo descritto dall'azienda stessa, una persona convinta a cedere l'accesso, anziché una falla che l'attaccante dovesse cercare, rispecchia una tendenza più ampia del 2026: campagne di vishing e social engineering che hanno successo contro dipendenti con accesso privilegiato presso il fornitore, non presso il cliente.
Questa distinzione, però, conta davvero per chiunque valuti RingCentral come fornitore. Un cliente può correggere il proprio software e ruotare le proprie credenziali, ma non ha modo di verificare, né tantomeno di vedere, quanto bene il personale di supporto e amministrazione di un fornitore resista a una telefonata convincente. Qui il bersaglio era il personale di RingCentral, non il suo codice.
Il vuoto nel registro di rischio dei fornitori
Le entità finanziarie soggette al Regolamento sulla resilienza operativa digitale dell'UE devono mantenere, secondo gli articoli da 28 a 30 del DORA, un registro delle informazioni su ogni fornitore ICT e valutare il rischio che ciascuno rappresenta per la propria resilienza. Le entità essenziali e importanti secondo la direttiva NIS2 hanno un obbligo parallelo, all'articolo 21, di gestire il rischio di cybersicurezza della catena di fornitura, comprese le pratiche di sicurezza dei fornitori diretti. Entrambi i quadri normativi presuppongono che l'entità regolata possa ottenere dal fornitore dettagli sufficienti a valutarne davvero il rischio.
Il bollettino di RingCentral, però, non indica il ruolo del dipendente coinvolto, il sistema interno raggiunto dall'attaccante, né quale controllo, autenticazione a più fattori, verifica tramite richiamata, controllo d'identità all'help desk, abbia fallito nel trasformare una telefonata in una violazione. Una banca tedesca, un gruppo ospedaliero olandese o un assicuratore britannico che elenca RingCentral nel proprio registro dei fornitori ICT non ha nulla di concreto da aggiungere a quella voce oltre al fatto che si è verificato un incidente. Il consueto questionario di sicurezza fornitori, un'attestazione SOC 2, un certificato di cifratura dei dati inattivi, una sintesi del penetration test, verifica esattamente i controlli tecnici che non sono mai entrati in gioco in un incidente iniziato e concluso con una conversazione.
Cosa dovrebbe cambiare davvero un operatore
La soluzione pratica non è un'altra scartoffia sulla cifratura. Gli operatori che dipendono da RingCentral, o da qualsiasi fornitore UCaaS o CCaaS al servizio di clienti regolati, dovrebbero chiedere direttamente al fornitore se conduce propri test simulati di social engineering contro il personale di supporto e amministrazione, e trattare la risposta, o il rifiuto di rispondere, come una voce a pieno titolo nel proprio registro di rischio.
I rinnovi contrattuali successivi a questa divulgazione sono il momento giusto per aggiungere una clausola specifica: il diritto a un'analisi tecnica post-incidente, non a una dichiarazione di marketing, entro un termine fisso da ogni incidente confermato. Senza questa clausola, il prossimo avviso di violazione di un fornitore suonerà esattamente come questo, completo e conforme sulla carta, ma inutile per l'unico documento, il registro di rischio, che la normativa richiede davvero a un operatore di tenere aggiornato.
Da leggere ora: 45.601 falle, solo 171 vengono davvero usate | Un solo messaggio ha raggiunto le chiavi SSH
