ShinyHunters colpisce ReliaQuest, ma device trust blocca il furto dei dati

🛡️ Executive Summary

• Un dipendente ReliaQuest inserisce la password in una falsa pagina SSO e approva una notifica MFA dopo una chiamata di social engineering.
• L’attaccante ottiene accesso temporaneo e read-only alla dashboard di identità, ma device trust impedisce l’ingresso nelle applicazioni e nei sistemi aziendali.
• ReliaQuest revoca sessione, password e fattori di autenticazione: l’indagine non rileva furto di dati, altre identità compromesse o persistenza.

ShinyHunters ha rivendicato un attacco contro ReliaQuest, ma quello che inizialmente poteva apparire come un nuovo data breach ai danni di una società di cybersecurity si è fermato alla compromissione temporanea di una singola identità. Il 22 agosto 2026 un dipendente ha inserito le proprie credenziali in una falsa pagina Single Sign-On dopo una telefonata nella quale l’attaccante impersonava un membro reale del team di sicurezza, approvando successivamente anche una richiesta MFA push. La sessione ottenuta ha consentito di visualizzare la dashboard dell’identity provider, ma i controlli di device trust hanno impedito l’accesso alle applicazioni aziendali. ReliaQuest afferma che nessun dato aziendale o dei clienti sia stato raggiunto.

La telefonata usa il nome di un vero dipendente per rendere credibile il phishing

Secondo la ricostruzione ufficiale pubblicata da ReliaQuest, l’operazione è iniziata con la registrazione di un dominio visivamente simile a quello dell’azienda e con la creazione di una falsa pagina SSO collocata dietro una content delivery network. Gli aggressori hanno quindi telefonato a più dipendenti presentandosi come un membro del team di sicurezza, utilizzandone il nome reale per aumentare la credibilità del pretesto. Uno degli utenti ha seguito le istruzioni, inserito la password sulla pagina controllata dagli attaccanti e approvato la notifica MFA ricevuta sul telefono. La tecnica è perfettamente coerente con le campagne nelle quali ShinyHunters ha sfruttato vishing e applicazioni OAuth per colpire gli ambienti Salesforce: l’obiettivo non è trovare una vulnerabilità nel software, ma convincere una persona autorizzata a trasformare volontariamente una sessione malevola in una sessione apparentemente legittima. Nel caso ReliaQuest la componente psicologica era ulteriormente rafforzata dalla conoscenza dell’identità di un dipendente della security, un’informazione sufficiente per far apparire plausibile una telefonata interna.

MFA superata, ma la sessione non equivale automaticamente all’accesso aziendale

L’approvazione della notifica MFA ha effettivamente consegnato all’attaccante una sessione valida sull’identity dashboard, dimostrando ancora una volta perché autenticazione corretta e autorizzazione alle risorse non debbano coincidere. Secondo ReliaQuest l’accesso era però esclusivamente view-only. Gli aggressori hanno tentato ripetutamente di raggiungere le applicazioni disponibili attraverso la dashboard, ma ogni richiesta è stata respinta dai controlli che consentono l’accesso soltanto da dispositivi considerati attendibili dall’organizzazione. È precisamente il limite che ha impedito alla compromissione dell’identità di trasformarsi in data theft. Il caso offre un contrasto interessante con le campagne di device code phishing capaci di superare l’MFA e conquistare account Microsoft 365, dove il possesso di un token valido può aprire direttamente l’accesso alle risorse cloud concesse all’utente. ReliaQuest applica invece una seconda condizione: anche una sessione autenticata deve provenire da un endpoint aziendale riconosciuto. L’identità compromessa rimane quindi necessaria, ma non sufficiente.

Device trust contiene l’incidente dopo l’errore umano

ReliaQuest presenta l’episodio come dimostrazione di un principio di defense in depth costruito partendo dall’ipotesi che prima o poi un dipendente possa cadere nel phishing. È un’impostazione importante perché sposta il problema dalla ricerca irrealistica dell’utente infallibile alla capacità dell’infrastruttura di contenere un’identità già compromessa. Il dipendente ha commesso entrambe le azioni richieste dall’attaccante: ha consegnato la password e ha approvato l’MFA. Eppure il compromesso non ha automaticamente sbloccato CRM, documenti, piattaforme interne o dati dei clienti. Gli incidenti analizzati nelle campagne AiTM contro Microsoft 365 mostrano quanto rapidamente una sessione valida possa trasformarsi in frode e accesso persistente quando non esistono controlli ulteriori sull’endpoint e sul contesto della sessione. Nel caso ReliaQuest, il dispositivo utilizzato dall’attaccante non possedeva invece i requisiti di trust necessari. La società ha quindi terminato la sessione, invalidato la password esposta e reimpostato tutti i fattori di autenticazione associati all’utente prima che l’operatore riuscisse a estendere l’accesso.

L’indagine non trova applicazioni raggiunte, altri account o persistenza

Dopo il contenimento ReliaQuest ha verificato device trust, accessi dalla rete aziendale e attività sospette nelle 48 ore precedenti, arrivando alla conclusione che l’attaccante abbia ottenuto soltanto quella singola sessione di identità. Nessun altro account risulterebbe compromesso, nessuna applicazione aziendale sarebbe stata raggiunta e nessun dato appartenente a ReliaQuest o ai clienti sarebbe stato consultato. Non sono inoltre emersi meccanismi di persistenza. Questo punto è particolarmente importante perché ShinyHunters ha pubblicato screenshot della dashboard compromessa sul proprio leak site, materiale sufficiente a dimostrare l’accesso iniziale ma non il furto di informazioni. Lo stesso attore, contattato successivamente, avrebbe riconosciuto che l’accesso era rimasto read-only e che non erano stati raggiunti sistemi o dati. La rivendicazione non deve quindi essere confusa con la prova di un data breach completo. Il gruppo ha già utilizzato il proprio nome come strumento di pressione in campagne contro sanità e grandi organizzazioni, mentre false estorsioni hanno sfruttato la reputazione ShinyHunters per aumentare la credibilità delle minacce. Nel caso ReliaQuest esiste una compromissione verificata, ma l’entità tecnica dell’incidente è molto più limitata di quanto l’apparizione su un leak site possa suggerire.

ShinyHunters usa sempre più identità e SaaS invece del malware

L’attacco corrisponde quasi esattamente al playbook che la stessa ReliaQuest aveva attribuito pochi mesi prima a ShinyHunters. Nel Threat Spotlight dedicato all’evoluzione delle campagne del gruppo i ricercatori descrivevano telefonate con pretesto help desk, domini costruiti per imitare SSO e Okta, pagine AiTM, MFA completata dalla vittima e successivo utilizzo della sessione autenticata contro applicazioni SaaS. Il gruppo preferisce sempre più spesso questo percorso all’installazione di malware: un’identità valida produce meno segnali di un eseguibile sconosciuto e permette di utilizzare direttamente API e servizi autorizzati. Le informazioni rubate in precedenti CRM ed ERP vengono inoltre riutilizzate per rendere le nuove telefonate più credibili, creando una sorta di ciclo nel quale un breach alimenta il social engineering successivo. La stessa convergenza tra assistenza fasulla, account esterni e infrastrutture cloud è visibile nelle campagne che utilizzano Teams per arrivare a RAT e compromissioni aziendali. Il perimetro da difendere non è quindi più soltanto endpoint e rete, ma l’intero rapporto tra identità, sessione e SaaS.

La lezione ReliaQuest è che il phishing non deve equivalere automaticamente a un breach

L’episodio ha una rilevanza particolare proprio perché coinvolge un’azienda di cybersecurity. Il fatto che un suo dipendente sia caduto nel social engineering non dimostra che la formazione sia inutile; dimostra piuttosto che nessuna strategia seria può assumere che ogni persona riconosca sempre un attacco costruito correttamente. Un operatore che conosce il nome di un collega, utilizza una pagina SSO convincente e accompagna telefonicamente la vittima durante l’autenticazione può superare anche utenti consapevoli. La differenza viene fatta da ciò che accade dopo. Device trust, session revocation, autenticazione resistente al phishing, controllo dell’enrollment MFA e telemetria sulle identità devono impedire che una singola credenziale diventi automaticamente una chiave universale. ReliaQuest ha effettivamente subito una compromissione di identità e ShinyHunters può quindi dimostrare di avere raggiunto la dashboard. Ma il tentativo di trasformare quell’accesso in furto di dati, movimento verso applicazioni aziendali e persistenza è fallito. È una distinzione essenziale in un mercato nel quale il semplice nome di un’organizzazione pubblicato su un leak site viene troppo spesso interpretato come prova automatica di un breach completo.