ShinyHunters ha provato a colpire ReliaQuest: i device-trust…

ReliaQuest conferma un attacco di ingegneria sociale contenuto il 22 agosto 2026. Device-trust controls hanno impedito movimenti laterali nonostante credenziali

Il 22 agosto 2026 un dipendente ReliaQuest ha approvato una notifica MFA su una pagina SSO contraffatta, cedendo a una campagna di ingegneria sociale orchestrata da ShinyHunters. Il giorno dopo il gruppo ha pubblicato la vittima sul proprio leak site. ReliaQuest ha confermato l'accesso limitato a un dashboard identità in sola visualizzazione, ribadendo che nessun dato cliente è stato toccato e che i controlli device-trust hanno bloccato ogni tentativo di accesso alle applicazioni o movimento laterale.

Punti chiave

ShinyHunters ha elencato ReliaQuest sul leak site il 23 agosto 2026, ma la stessa fonte ha poi confermato alla stampa che nessun dato è stato sottratto.
L'attacco del 22 agosto ha combinato vishing, dominio fasullo reliaquest.claims con CDN, e approvazione MFA push da parte di un singolo dipendente.
ReliaQuest ha ottenuto accesso view-only al dashboard identità del dipendente: nessuna applicazione o sistema aziendale è stato raggiunto.
I controlli device-trust, che richiedono dispositivi gestiti per l'accesso alle applicazioni, hanno reso impraticabile ogni espansione della compromissione.

Come è fallita l'escalation nonostante credenziali valide

La catena offensiva si è innescata con chiamate telefoniche a più dipendenti: uno ha ceduto, inserendo credenziali su una pagina SSO clonata ospitata sul dominio reliaquest.claims, protetta da CDN per mascherare l'origine. L'approvazione della notifica MFA push ha completato il bypass del primo perimetro.

Da qui la difesa si è attivata su un secondo livello. ReliaQuest impone controlli device-trust che legano l'accesso alle applicazioni alla presenza di dispositivi aziendali gestiti e registrati. Gli attaccanti, pur in possesso di una sessione identitaria valida, non disponevano di endpoint conformi. Secondo Help Net Security, i tentativi di accesso sono stati consistently denied.

L'azienda ha terminato la sessione, revocato la password, resettato i token di autenticazione e analizzato una finestra di 48 ore di attività sospette precedenti all'incidente. Non è stata riscontrata persistenza. Il contrasto tra questa ricostruzione e la narrazione del leak site — dove ShinyHunters ha pubblicato screenshot Okta con il messaggio "This time the post is about you, not us. Let Mandiant report and advise on us accurately, go away" — misura la distanza tra accesso tecnico e compromissione effettiva.

"The extent of the access was view-only. No ReliaQuest applications or systems were accessed, and no customer data was ever touched."

La tattica MFA push: efficace contro il perimetro, inerte contro i device-trust controls

L'incidente riproduce un pattern documentato. A febbraio 2026 Help Net Security aveva già tracciato ShinyHunters — associati ai cluster UNC6661 e UNC6040 secondo Mandiant — nell'uso di ingegneria sociale per aggirare MFA basata su notifica push. La differenza qui sta nell'outbound: non nel vettore iniziale, ma nella capacità o meno di sfruttarlo.

ReliaQuest opera nel campo della sicurezza gestita e della protezione endpoint. I device-trust controls implementati dall'azienda hanno isolato la compromissione identitaria dal perimetro applicativo. Il caso offre un esempio di verifica sul campo: un vendor di sicurezza messo alla prova con le proprie armi.

Il brief non specifica se la stessa infrastruttura reliaquest.claims sia stata impiegata in campagne simultanee contro altri target. Non emergono sovrapposizioni infrastrutturali che colleghino questo specifico operatore a precedenti attività ShinyHunters al di là delle dichiarazioni del gruppo.

Il teatro del leak site e il danno reputazionale

ShinyHunters ha alimentato la narrazione su più fronti. Prima del leak site, un account X associato al gruppo — @odysseusgroup — ha pubblicato screenshot con la provocazione "Who's hunting who?". La tempistica è precisa: taunt pubblico il 22 agosto, elenco sul leak site il 23 agosto, conferma alla stampa che nessun dato era stato rubato nelle ore successive.

ReliaQuest ha reagito con una dichiarazione esplicita: "Claims that ReliaQuest was compromised or targeted by ransomware are false". La scelta semantica è rilevante. Il gruppo non ha affermato di avere ransomware in campo — ShinyHunters è associato principalmente a estorsione di dati, non a ransomware basato su cifratura — ma l'azienda ha ugualmente smentito, anticipando la possibile fusione narrativa tra leak site e ransomware.

Il caso evidenzia un problema strutturale della threat intelligence commerciale. SOCRadar, piattaforma di intelligence sulle minacce, ha tracciato l'incidente con il formato Q&A tipico del suo modello commerciale: utile per strutturare la timeline, ma potenzialmente esposto all'amplificazione delle rivendicazioni per ricaduta marketing. Dark Reading, nel podcast "What We Missed", ha invece concentrato l'analisi su questo gap semantico tra "breach" e "contained access", notando come il linguaggio del leak site colonizzi il dibattito pubblico indipendentemente dai fatti tecnici.

Cosa cambia

L'incidente ReliaQuest-ShinyHunters delinea tre tensioni che attraversano il settore della sicurezza gestita.

Prima tensione: la validità delle credenziali non equivale alla validità dell'accesso. L'approvazione MFA push ha aperto una sessione, ma i device-trust controls l'hanno confinata a un dashboard view-only. La lezione è architetturale, non procedurale: la sicurezza risiede nel vincolo tra identità e dispositivo, non nella sola autenticazione.

Seconda tensione: i leak site operano come teatri di narrazione indipendenti dai fatti tecnici. ShinyHunters ha pubblicato screenshot, taunt e rivendicazioni senza mai estrarre dati. La distanza tra performance pubblica e impatto reale è diventata un campo di battaglia reputazionale, non solo tecnico.

Terza tensione: i vendor di sicurezza sono bersagli preferenziali non per i dati che detengono, ma per la dimostrazione di vulnerabilità che rappresentano. Colpire ReliaQuest equivale a colpire il suo mercato: la provocazione "Who's hunting who?" è indirizzata agli acquirenti, non solo ai tecnici.

Limiti della ricostruzione

Questo articolo si basa su fonti convergenti ma nessuna advisory primaria vendor. Non risulta che un regolatore o una società indipendente di incident response abbia revisionato la ricostruzione di ReliaQuest. ShinyHunters potrebbe pubblicare materiale aggiuntivo per sostenere rivendicazioni di accesso più ampio. L'identità completa dell'operatore dell'account X @odysseusgroup non è verificata. La fonte non specifica se i controlli device-trust siano stati progettati esplicitamente per questo scenario o rappresentino una configurazione standard dell'azienda.

Fonti: Dark Reading | SOCRadar | BleepingComputer | Help Net Security | CyberInsider

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter