ShinyHunters rivendica l'accesso al portale di reclutamento del Bureau con uno zero-day su Oracle PeopleSoft. Il campione diffuso dal gruppo contiene dati del personale in chiaro.

Il 22 settembre il gruppo ShinyHunters ha rivendicato un'intrusione nei sistemi dell'FBI. Stando a quanto il gruppo ha raccontato a BleepingComputer, l'accesso sarebbe partito da uno zero-day in Oracle PeopleSoft sul portale di reclutamento fbijobs.gov, per poi spostarsi sull'infrastruttura AWS GovCloud del Bureau e portare via fra 2 e 3 terabyte di dati su dipendenti e candidati. Alla CNN l'FBI ha dichiarato di essere a conoscenza delle rivendicazioni e di stare indagando; due fonti sentite dall'emittente parlano di un'apparente violazione delle reti. Reuters ha trovato corrispondenze tra alcuni record del campione diffuso dagli attaccanti e gli archivi dei credit bureau, mentre Oracle non ha commentato.

Uso il condizionale finché mancano conferme ufficiali. Il caso, però, si inserisce in una serie che la CNN ricorda nello stesso articolo: a marzo un sospetto incidente su una rete dell'FBI usata per intercettazioni e mandati di sorveglianza, ad agosto la diffusione di file che sembrano sottratti all'ATF. E il meccanismo descritto è quello che oggi apre più violazioni: secondo il Verizon DBIR 2026 lo sfruttamento di vulnerabilità è diventato il primo vettore di accesso iniziale, nel 31% dei casi.

Valerio Pastore, Founder di CyberGrant Inc

Cosa trova chi entra

Uno zero-day arriva prima della patch, quindi anche un amministratore con gli aggiornamenti in regola può ritrovarsi un estraneo dentro l'applicazione. Da quel momento la variabile decisiva diventa lo stato in cui l'attaccante trova i dati. Di solito i file di un gestionale HR sono cifrati a riposo, sul disco o nel bucket cloud, e questa cifratura protegge bene dal furto fisico del supporto. Per chi controlla l'applicazione o un account cloud con i privilegi giusti è invece trasparente: i documenti gli arrivano già decifrati, esattamente come al responsabile del personale.

La cifratura che resta sul file

La cifratura nativa sposta il controllo sul documento. Il file viene cifrato quando nasce o quando entra nel sistema e porta con sé le proprie regole di accesso. Resta cifrato su ogni copia, nel bucket come sul disco di chi l'ha esfiltrato. La chiave vive separata dal contenuto e dal server applicativo, sotto il controllo dell'organizzazione, che la rilascia solo a utenti e dispositivi autorizzati. Chi copia l'archivio dal server compromesso si porta a casa blocchi cifrati. Se l'accesso viene revocato, quella copia resta chiusa anche fuori dal perimetro, mentre le aperture autorizzate restano registrate.

Poi c'è la durata del dato. Cynthia Kaiser, ex dirigente della divisione cyber dell'FBI, ha ricordato a Reuters che un leak del 2016 viene ancora usato per molestare agenti del Bureau. Un indirizzo di casa o il numero di Social Security di un coniuge (tra i dati che il gruppo dichiara di avere) restano sfruttabili per decenni, e un avversario statale ha tutto l'interesse a conservare anche un archivio cifrato in attesa di poterlo aprire. Per un dato con un valore così lungo la protezione va costruita su scambi di chiave post-quantum, come ML-KEM (CRYSTALS-Kyber), standardizzato dal NIST con FIPS 203 nel 2024.

Per chi opera in Europa la differenza ha anche un peso giuridico. L'art. 34, par. 3, lett. a) del GDPR esonera il titolare dal comunicare la violazione agli interessati quando i dati erano resi incomprensibili a chi non è autorizzato, e cita espressamente la cifratura; la NIS2 (art. 21, par. 2, lett. h) chiede politiche documentate sull'uso della crittografia. Il test che proporrei a un CISO o a un DPO parte dall'archivio del personale e dei candidati: se domani un attaccante lo copiasse con i privilegi dell'applicazione, quanti di quei file riuscirebbe a leggere? La risposta decide dove andrà la prossima voce di budget.