La piattaforma Greatness Phishing-as-a-Service ha esteso le proprie capacità dal semplice furto di credenziali a tecniche avanzate di adversary-in-the-middle e device-code phishing, compromettendo account Microsoft 365 con persistenza superiore a due settimane. Secondo la ricerca pubblicata da ZeroBEC su BleepingComputer il 4 agosto 2026, gli operatori hanno aggirato i filtri di sicurezza email impersonando RingCentral, sfruttando il fatto che il dominio della piattaforma SaaS era presente nelle whitelist aziendali delle vittime. La combinazione di bypass tecnico e ingegneria sociale rappresenta un'evoluzione significativa nella maturità operativa del servizio, attivo dal mid-2022.
- Greatness ha ottenuto Spam Confidence Level -1 su Microsoft Exchange spoofando RingCentral già in whitelist aziendale, bypassando i normali stadi di filtraggio.
- Le email includevano un banner fraudolento "verified by organization's safe-sender list" per rafforzare la credibilità della comunicazione agli occhi degli utenti.
- Il doppio meccanismo di compromissione MFA combina flussi AiTM per intercettazione token in tempo reale e device-code phishing per scenari alternativi.
- Post-compromissione, gli attaccanti hanno effettuato enumerazione multi-servizio via Microsoft Graph API con accesso persistente superiore a due settimane in alcuni casi.
Il trucco della whitelist: perché il filtro non filtra
Il nucleo dell'attacco risiede nell'abuso della trust architecture email delle organizzazioni bersaglio. Gli operatori di Greatness hanno inviato email dal mittente spoofato service@ringcentral[.]com, ospitate su server IONOS sconosciuti, con SPF e DMARC falliti e assenza di firma DKIM. Secondo il dossier citato, queste email sono state comunque accettate dai sistemi di filtraggio perché RingCentral figurava nelle whitelist aziendali.
Il risultato è stato un valore di Spam Confidence Level pari a -1 su Microsoft Exchange. Lo SCL -1 indica che il messaggio è stato trattato come interno o esplicitamente attendibile, saltando i controlli antispam e antimalware standard. ZeroBEC spiega che "la tattica ha ottenuto uno Spam Confidence Level di -1 su Microsoft Exchange, permettendo di bypassare i normali stadi di filtraggio delle email". Non si tratta di una vulnerabilità del prodotto Microsoft, ma del comportamento atteso di un sistema configurato per considerare attendibile un dominio senza verifiche aggiuntive.
Per completare il bypass, le email includevano un banner fraudolento che dichiarava la comunicazione "verified by organization's safe-sender list". Questo elemento di ingegneria sociale rafforzava la percezione di legittimità, riducendo la probabilità che gli utenti segnalassero l'anomalia anche in presenza di indici di sospetto contestuali.
Dal click alla compromissione MFA: AiTM e device-code phishing
I link presenti nelle email portavano a infrastruttura Greatness con routing dinamico verso due flussi distinti di attacco. Il primo, basato su tecniche adversary-in-the-middle, intercettava i token di autenticazione approvati tramite MFA durante la sessione legittima dell'utente. Il secondo utilizzava il device-code phishing, una tecnica alternativa che non richiede l'inserimento diretto di credenziali sul portale clonato ma sfrutta il flusso di autorizzazione tra dispositivi per ottenere accesso.
Post-acquisizione dei token, gli operatori hanno replicato le sessioni da VPS e VPN commerciali, un pattern indicativo di deliberate misure di anonimizzazione. La scelta di questa architettura di accesso riflette una maturità operativa che distingue Greatness dai servizi di phishing meno strutturati attivi nel panorama criminale.
Enumerazione Graph API e persistenza oltre due settimane
Una volta stabilito l'accesso, gli attaccanti hanno condotto attività di ricognizione e esfiltrazione tramite Microsoft Graph API. L'enumerazione ha riguardato: caselle Outlook, team Teams, siti SharePoint, archivi OneDrive, rubriche contatti, calendari e applicazioni registrate nel tenant. Questo profilo di accesso multi-servizio indica un obiettivo di ricognizione approfondita piuttosto che semplice furto di credenziali isolato.
La persistenza ha superato le due settimane in alcuni casi analizzati. Questa durata, combinata con l'enumerazione sistematica, supporta la lettura che la compromissione dell'account rappresenti una fase iniziale per operazioni successive — Business Email Compromise, furto di dati sensibili, o pivoting verso altri sistemi aziendali — piuttosto che un fine a sé stante. Il dossier non specifica la natura dei dati esposti né eventuali estorsioni post-compromissione.
Il contesto della breach RingCentral: correlazione ipotizzata, non provata
Il 28 luglio 2026 RingCentral ha pubblicato una security bulletin relativa a un data breach attribuito al threat actor ShinyHunters, con dichiarazione che "l'incidente ha interessato i dati di una porzione limitata di clienti RingCentral, e stiamo comunicando direttamente con i clienti interessati". ZeroBEC ha ipotizzato che gli operatori di Greatness potessero aver ottenuto una lista di target validi — utenti della piattaforma RingCentral — da questo incidente.
La connessione tuttavia non è confermabile allo stato attuale. Il dossier esplicita l'incertezza di questa correlazione, e non emergono sovrapposizioni infrastrutturali che colleghino tecnicamente la campagna Greatness al breach ShinyHunters. L'ipotesi rimane plausibile ma non verificata, e l'utilizzo del dominio RingCentral come vettore di spoofing non richiede necessariamente l'accesso a dati di breach: l'impersonificazione di piattaforme SaaS diffuse è una tattica comune nel phishing indipendentemente da fonti di targeting specifiche.
Cosa fare adesso
Le organizzazioni che utilizzano Microsoft 365 devono rivedere le configurazioni di whitelist e safe-sender list per ridurre la superficie di attacco esposta da questo vettore. Tre azioni specifiche emergono dal caso documentato:
Rimuovere RingCentral e altri domini SaaS generici dalle whitelist incondizionate. Lo SCL -1 ottenuto da Greatness deriva direttamente dalla presenza di ringcentral[.]com in safe-sender list aziendali. L'assegnazione di trust implicito a domini di servizi pubblici bypassa SPF, DMARC e DKIM anche quando questi falliscono, come accaduto con server IONOS sconosciuti.
Implementare verifiche aggiuntive per mittenti con SPF/DMARC falliti anche in presenza di whitelist. Il dossier documenta che le email di Greatness presentavano SPF e DMARC falliti e nessuna firma DKIM, ma erano accettate comunque. Le configurazioni di Exchange devono mantenere controlli di autenticazione indipendenti dalla lista dei mittenti attendibili.
Monitorare l'accesso da VPS e VPN commerciali ai tenant Microsoft 365. Post-compromissione, gli operatori di Greatness hanno replicato token da queste infrastrutture. Il rilevamento di sessioni Graph API attive da IP associati a provider di hosting commerciali rappresenta un indicatore comportamentale rilevante, specialmente quando combinato con enumerazione multi-servizio.
Verificare la presenza di banner "verified by organization's safe-sender list" nelle email in ingresso. Questo elemento di ingegneria sociale è stato generato dagli attaccanti, non dai sistemi Microsoft. La sua presenza in email esterne indica manipolazione attiva del contenuto e deve attivare controlli manuali.
"ZeroBEC comments that it's likely that cybercriminals using Greatness got a list of valid targets, users of the RingCentral platform, from that incident, though a connection cannot be confidently made."
L'evoluzione di Greatness dal mid-2022 a oggi illustra una traiettoria comune nel mercato PhaaS: l'aggiunta progressiva di tecniche di bypass MFA, l'integrazione di ingegneria sociale più raffinata, e l'estensione della persistenza post-compromissione. Il caso specifico dello SCL -1 ottenuto tramite whitelist abuse rappresenta tuttavia un salto qualitativo, perché sfrutta non una vulnerabilità tecnica ma un'assunzione di sicurezza gestionale: che un dominio legittimo rimanga legittimo anche quando viene impersonato.
Le organizzazioni che mantengono whitelist estese di domini SaaS sono esposte a questo vettore indipendentemente dalla maturità dei propri controlli di autenticazione email. La lettura che emerge dal dossier è che la sicurezza del canale email non può affidarsi a liste statiche di fiducia in un contesto dove l'impersonificazione di piattaforme note è diventata operativamente banale per servizi criminali strutturati.
Domande frequenti
Lo SCL -1 è una vulnerabilità di Microsoft Exchange?
No. Lo SCL -1 è il risultato atteso della configurazione di whitelist aziendali in Exchange: quando un mittente è nella safe-sender list, il sistema assegna questo valore per bypassare i filtri. Il problema risiede nella configurazione della whitelist, non nel prodotto.
Il device-code phishing richiede l'MFA?
Il flusso di device-code phishing sfrutta meccanismi di autorizzazione tra dispositivi che possono aggirare le procedure di autenticazione tradizionali. Secondo il dossier, questo meccanismo rappresenta uno dei due vettori utilizzati da Greatness, alternativo al flusso AiTM.
Le vittime possono identificare l'attacco dai log?
Il dossier non specifica indicatori di compromissione pubblicati o pattern di log rilevabili. La fonte non documenta segni anomali specifici oltre all'accesso da VPS/VPN commerciali post-compromissione.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://www.bleepingcomputer.com/news/security/phishing-service-spoofs-ringcentral-to-steal-microsoft-365-accounts/
- https://www.bleepingcomputer.com/
- https://www.bleepingcomputer.com/tutorials/
- https://www.bleepingcomputer.com/download/
- https://deals.bleepingcomputer.com/