Le violazioni sicurezza di settembre 2025 impongono una revisione immediata delle difese su portali critici, finanza al consumo e infrastrutture hardware. Un account fraudolento nel Law Enforcement Request System (LERS) di Google è stato creato e disabilitato rapidamente, senza esfiltrazioni; un ex dipendente FinWise ha acceduto a dati di 689.000 clienti American First Finance, scatenando notifiche e un anno di monitoraggio del credito; il nuovo attacco Phoenix dimostra che è possibile eludere le difese Rowhammer su DDR5, provocando bit flip affidabili fino a ottenere privilegi root e a compromettere RSA-2048 in tempi ridottissimi. La combinazione di social engineering, insider threat e debolezze fisiche della memoria mette sotto pressione identity governance, offboarding e security engineering in cloud e on-prem, rendendo settembre un turning point per policy, processi e investimenti.
Cosa leggere
Account fraudolento nel LERS di Google: cosa è successo davvero
Il caso Google LERS evidenzia la fragilità dei portali ad alto valore istituzionale quando l’attaccante riesce a superare i controlli di primo livello. La creazione di un profilo non autorizzato in un sistema progettato per gestire richieste delle forze dell’ordine mostra come impersonificazione e ingegneria sociale restino vettori praticabili anche contro piattaforme con procedure di verifica consolidate. L’account fasullo è stato disattivato rapidamente e non risultano richieste inviate né dati consultati, ma l’episodio conferma che l’attacco al processo può essere tanto efficace quanto l’attacco al codice. La lezione operativa è concreta: verifiche fuori banda, MFA resistente al phishing e telemetria fine-grained su creazione, uso e revoca delle identità applicative diventano elementi imprescindibili per neutralizzare tentativi di masquerading anche quando le credenziali appaiono legittime.
Perché il rischio di impersonificazione è sistemico
Un portale come LERS custodisce percorsi privilegiati verso dati altamente sensibili. Anche senza esfiltrazione, la semplice abilitazione di un profilo può aprire spazio a falsi ordini o a richieste manipolate se i flussi di lavoro non prevedono doppie approvazioni e richiami telefonici dedicati. La convergenza fra identità, processi e catena di custodia impone di trattare la governance come una funzione operativa a tutti gli effetti: controlli a più fattori su operatori e sponsor, registri immutabili per gli audit e policy di rotazione dei token riducono l’angolo d’attacco e accelerano la rilevazione delle anomalie.
Breach FinWise: 689.000 clienti AFF e la lezione sull’insider threat
L’insider breach che coinvolge FinWise dimostra la pericolosità dei privilegi residui in contesti BaaS e catene a responsabilità condivisa. Un ex dipendente ha acceduto a file sensibili dopo la cessazione del rapporto, esponendo nominativi e altre PII relative a 689.000 clienti di American First Finance. La risposta ha incluso notifiche, supporto e 12 mesi di monitoraggio del credito, a fronte di una indagine esterna e di un rafforzamento dei controlli interni. Gli scostamenti tra stime in documenti regolatori e notifiche successive sono fisiologici in fasi d’indagine, ma il punto sostanziale resta l’offboarding: senza revoche atomiche su directory, SaaS e datalake, il dwell time dell’insider si allunga e i danni aumentano.
Dove si rompe la catena dei controlli interni
L’esperienza di molte realtà finanziarie mostra come il deprovisioning manuale generi lacune temporali sfruttabili. In pratica servono workflow automatizzati che, al momento della cessazione, invalidino l’accesso su IdP, applicazioni critiche, repository e strumenti di pagamento, con recertification periodiche sui ruoli sensibili. L’adozione di least privilege, just-in-time access e token a scadenza breve riduce il rischio di abuso. Lato clienti, monitoraggio dei conti, cambio delle password, 2FA e attenzione ai tentativi di phishing successivi al breach sono accorgimenti che limitano gli impatti.
Phoenix su DDR5: perché Rowhammer non è finito
L’attacco Phoenix riapre il dossier Rowhammer dimostrando che le contromisure on-die come Target Row Refresh (TRR) su DDR5 non sono definitive. I ricercatori hanno ottenuto bit flip su tutti i moduli testati, confermando che è possibile sincronizzare l’hammering con i cicli di refresh fino a colpire PTE e costruire primitive di lettura/scrittura arbitraria. L’orizzonte operativo cambia: su sistemi default, l’attaccante può escalare a root in tempi dell’ordine dei minuti, manipolare binari privilegiati e perfino influenzare RSA-2048 in scenari di co-residenza.
Pattern di hammering e sincronizzazione auto-correttiva
La novità tecnica di Phoenix sta nella sincronizzazione auto-correttiva con i meccanismi TRR. Pattern di 128 e 2608 intervalli di tREFI vengono modulati per tenere il passo con migliaia di refresh, individuando slot in cui le protezioni non si attivano. Questo rende i bit flip ripetibili, requisito fondamentale per passare dal PoC allo sfruttamento. Il controllo sul layout fisico e l’uso di sonde temporali software permettono di mappare regioni vulnerabili e di orchestrare l’hammering senza far scattare le euristiche anti-Rowhammer.
Impatto su RSA e privilegi root
La valutazione d’impatto cita risultati quantitativi: compromissione di RSA-2048 in VM co-locate su una quota significativa dei moduli e escalation tramite alterazione di sudo su una frazione non trascurabile dei DIMM testati. In sintesi, un attaccante con codice in esecuzione sulla macchina può forzare l’integrità della memoria fino a ottenere privilegi amministrativi, con ripercussioni dirette su cloud multi-tenant, hypervisor e server di frontiera.
Perché DDR5 non basta e cosa significa per i data center
DDR5 offre densità e prestazioni superiori, ma TRR ed ECC lavorano in modo probabilistico. Phoenix dimostra che un adversary paziente può trovare finestre di efficacia ridotta. Nei data center, questo si traduce nella necessità di rivedere le assunzioni di sicurezza sulla memoria: schedulatori consapevoli del rischio Rowhammer, pinning mirato, randomizzazione della mappatura fisica, telemetria su errori correggibili ed MCE, insieme a policy che limitino carichi notoriamente propensi a generare pattern di accesso aggressivo.
Implicazioni trasversali: identità, processi, hardware
I tre eventi condividono un principio: identità, processi e hardware sono piani inseparabili. L’account LERS insegna che il processo deve resistere anche a credenziali apparentemente legittime; FinWise mostra che i privilegi residui sono un debito tecnico che si paga con dati esposti; Phoenix ricorda che la memoria non è un dogma di integrità e va monitorata come qualunque altro asset critico. La risposta matura evita soluzioni puntuali e adotta un framework unificato di governance e telemetria.
Mitigazioni operative per aziende e PA
Le organizzazioni possono agire subito senza rivoluzionare gli stack. Nei portali sensibili, applicare MFA resistente al phishing con chiavi hardware, prevedere verifiche fuori banda per flussi autoritatvi e abilitare alert in tempo reale sulla creazione e elevazione degli account riduce il rischio di impersonificazione. Nel fintech, automatizzare l’offboarding, introdurre just-in-time access, fissare scadenze brevi per token e segreti e imporre recertification periodiche sui ruoli che toccano PII limita l’insider threat. Lato DDR5, attivare telemetria su errori ECC, valutare tREFI più conservativi in segmenti ad alto rischio, e inserire test sintetici in pre-produzione per misurare la resilienza della piattaforma ai pattern di hammering permette di scovare instabilità prima che diventino incidenti. La gestione coordinata di questi rischi passa da tre accorgimenti misurabili. Primo, identity hardening sui portali critici: MFA con chiavi FIDO2, verifiche fuori banda, doppia approvazione per richieste sensibili e audit trail immutabili su creazione ed elevazione degli account, con telemetria su device, IP e impronte del browser. Secondo, offboarding atomico nel fintech: integrazione tra HRIS, IdP e ITSM per dismettere accessi in modo sincrono, recertification trimestrali dei ruoli che toccano PII, token a vita breve e data minimization per restringere l’impatto in caso di abuso. Terzo, hardening DDR5: raccolta di ECC correctable, analisi di MCE, profilazione dei carichi che generano accessi ad alta frequenza e, dove possibile, randomizzazione della mappatura e schedulazione consapevole del rischio Rowhammer, accompagnate da test sintetici pre-rilascio per catturare instabilità legate al tREFI. Trattando identità, processi e memoria come un unico sistema operativo della sicurezza, le organizzazioni possono ridurre superficie d’attacco, dwell time e costo degli incidenti, trasformando le criticità di settembre in vantaggio competitivo.
