Spcnet.it

2026-07-22 10:21:47

Identità ibrida come debito tecnico: la strada pratica verso Entra ID cloud-only

Se la vostra organizzazione ha già spostato la maggior parte dei carichi rivolti agli utenti su Microsoft 365, Intune e Microsoft Entra ID, è lecito chiedersi perché esista ancora un Domain Controller che gira in produzione. La risposta più comune è “così abbiamo sempre fatto”, ed è esattamente la definizione di debito tecnico: un’infrastruttura che continua a costare in manutenzione, superficie di attacco e complessità operativa senza generare più un valore proporzionato. L’identità ibrida, con Entra Connect che sincronizza un Active Directory locale verso il cloud, è diventata per molte aziende proprio questo tipo di debito.

Non si tratta di demonizzare l’ibrido: per organizzazioni con applicazioni legacy pesantemente dipendenti da NTLM, LDAP o Kerberos, mantenere un ponte con l’on-premise è spesso l’unica scelta razionale. Il punto è che la decisione va presa consapevolmente, dopo un inventario reale delle dipendenze, e non per inerzia.

Perché il cloud-only conviene, quando è applicabile

Per un’organizzazione che gira già prevalentemente su Entra ID, Microsoft 365 e client Windows moderni, il modello cloud-only centralizza la gestione IT e accelera l’accesso a nuove funzionalità di sicurezza che spesso arrivano prima, o esclusivamente, sui tenant che non dipendono più da sincronizzazione ibrida. I vantaggi concreti che spingono in questa direzione sono quattro:

• Riduzione del carico operativo: patching, alta disponibilità e scalabilità dei Domain Controller passano al provider cloud.
• Postura di sicurezza migliore: funzionalità come Conditional Access granulare, Identity Protection e governance degli accessi privilegiati sono nativamente più semplici da applicare senza il vincolo di compatibilità con AD locale.
• Costi più prevedibili: si eliminano hardware ridondante, licenze Windows Server per i DC e il tempo ingegneristico dedicato a mantenerli in salute.
• Velocità di adozione: nuove capacità (passkey, agenti AI con identità propria, automazioni Conditional Access) arrivano più rapidamente su tenant che non devono conciliarsi con un’infrastruttura ibrida.

L’errore più comune: migrare l’infrastruttura prima di validare le dipendenze

Il fallimento tipico di un progetto cloud-only non è tecnico, è di sequenza: i team iniziano a spegnere server e migrare workload prima di aver mappato davvero cosa dipende ancora da Active Directory. Un approccio più solido segue queste fasi.

1. Mappare i carichi di lavoro che bloccano il cloud-only

Partite da un audit completo di infrastruttura, applicazioni, dati e dipendenze. Non fermatevi alla lista delle VM: cercate esplicitamente le dipendenze che raramente compaiono nei piani di migrazione di alto livello, perché sono quelle che tengono in vita Entra Connect molto più a lungo del necessario:

• Applicazioni che richiedono ancora query LDAP dirette
• Service account legacy non documentati
• Applicazioni con autenticazione NTLM hard-coded
• Impostazioni di Group Policy che nessuno ha mai rivisto
• Servizi certificati (ADCS) che presuppongono un Domain Controller sempre raggiungibile

2. Definire l’architettura cloud che volete davvero gestire

Stabilite obiettivi chiari su performance, disponibilità, sicurezza e compliance prima di scegliere gli strumenti. Decidete se una strategia single-cloud o multi-cloud è coerente con la vostra tolleranza al rischio e con le competenze del team, non solo con il marketing del vendor.

3. Modernizzare l’identità prima di spegnere Active Directory

Qui sta il cuore del progetto. Rivedere la strategia IAM significa garantire autenticazione robusta, accesso a privilegio minimo e protezione dell’identità sfruttando gli strumenti nativi di Entra ID per unificare la gestione utenti su tutti i servizi, invece di replicare in cloud le stesse logiche pensate per un dominio locale.

4. Ridisegnare la connettività attorno all’accesso cloud, non al data center

Molte architetture di rete sono ancora progettate assumendo che il traffico debba passare da un data center centrale. Un modello cloud-only ribalta la logica: la connettività va progettata per l’accesso diretto ai servizi cloud, sfruttando le backbone dei provider e i servizi di sicurezza integrati, sia per utenti in ufficio sia da remoto.

5. Trattare le applicazioni legacy come il vero collo di bottiglia

File share, servizi di stampa, applicazioni gestionali interne e integrazioni con piattaforme di terze parti datate sono i blocchi reali dei progetti cloud-only, molto più della migrazione di VM o storage. Un’applicazione finance che si aspetta autenticazione Windows integrata, un sistema di magazzino che dipende da query LDAP o una file share con permessi ereditati da anni possono rallentare il progetto più di qualunque altro fattore. Per ciascuna, valutate lift-and-shift, refactoring o riscrittura in base a complessità e valore strategico.

6. Ricostruire la governance per un modello operativo cloud-first

Aggiornate le policy per riflettere una postura cloud-first, automatizzate il reporting di compliance e sfruttate strumenti di sicurezza nativi cloud per cifratura, rilevamento minacce e incident response, invece di adattare policy pensate per l’on-premise.

7. Preparare il team IT al cambio operativo

Investite nella formazione sulle competenze cloud-specifiche, comunicate i cambiamenti con chiarezza e create canali di supporto e feedback per intercettare problemi prima che diventino bloccanti.

Cosa si rompe per primo in una migrazione cloud-only

Anche con una pianificazione accurata, alcuni punti critici emergono quasi sempre:

• Dipendenze nascoste da Active Directory: connessioni LDAP hard-coded, service account non gestiti, applicazioni dipendenti da NTLM o flussi di autenticazione mai documentati. Vanno inventariati prima di ritirare i Domain Controller o disattivare la sincronizzazione.
• Blocchi operativi da Conditional Access e MFA: l’enforcement di Conditional Access e multi-factor authentication migliora la sicurezza, ma una sequenza sbagliata può bloccare fuori gli amministratori o interrompere l’accesso a servizi critici. Testate sempre account di emergenza, opzioni di rollback e flussi di accesso privilegiato prima di un enforcement ampio.
• Resistenza culturale: il cambiamento comporta rischio percepito; serve chiarezza sui benefici e sui nuovi ruoli per ridurre lo scetticismo dei team.
• Interruzioni di servizio: pianificate la migrazione a fasi, con pilot e backup, per minimizzare l’impatto sul business.

Il test pratico per capire quanto siete lontani dal cloud-only

Se la vostra organizzazione ha già adottato Microsoft 365, Intune ed Entra ID per la maggior parte dei carichi rivolti agli utenti, l’identità ibrida va trattata come debito tecnico, a meno che non abbiate una ragione precisa e documentata per mantenerla. Prima di pianificare una migrazione cloud-only, identificate ogni dipendenza residua da Active Directory: se la maggior parte supporta già l’autenticazione moderna, probabilmente siete più vicini al cloud-only di quanto pensiate.

Per i sistemisti che gestiscono ambienti Microsoft, il consiglio pratico è iniziare da un inventario mirato: interrogate Entra Connect per capire quali oggetti sincronizzati sono ancora effettivamente in uso, verificate quali applicazioni autenticano ancora tramite Kerberos/NTLM controllando i log di sicurezza dei Domain Controller, e mappate le Group Policy applicate per capire quali impostazioni di sicurezza andranno ricreate tramite Intune prima di spegnere l’ultimo controller di dominio.

Conclusione

La migrazione a cloud-only non è un progetto infrastrutturale, è un progetto di identità. Le organizzazioni che falliscono di solito partono dal lato sbagliato del problema, migrando VM e storage prima di aver capito cosa dipende ancora da un dominio Active Directory che nessuno ha mai documentato del tutto. Chi parte invece dall’inventario delle dipendenze di identità, tratta l’ibrido come uno stato temporaneo e non come un’architettura permanente, arriva a un ambiente più semplice da gestire, più sicuro per costruzione e meno costoso da mantenere nel tempo.

Fonte: Why Hybrid Identity Becomes Technical Debt and How to Move to Cloud-Only, Petri IT Knowledgebase (Dean Ellerby).

Why Hybrid Identity Becomes Technical Debt

Cloud-only simplifies IT only after you uncover the identity and legacy app dependencies keeping hybrid alive.

^{Dean Ellerby (Petri IT Knowledgebase)}

(in)sicurezza digitale

2026-07-22 10:22:48

Operation Olympus Blade: BKA e FBI smantellano Kratos, il phishing-as-a-service da 1.800 clienti in 35 paesi

Duecento server sequestrati, un arresto in Indonesia e oltre 1.800 clienti criminali lasciati improvvisamente senza il loro strumento di lavoro preferito. Con l’Operazione “Olympus Blade”, le autorità tedesche e statunitensi hanno inferto uno dei colpi più duri mai assestati contro l’industria del phishing-as-a-service, smantellando l’infrastruttura di Kratos, la piattaforma che negli ultimi due anni ha permesso a criminali con competenze tecniche minime di colpire centinaia di migliaia di vittime in 35 paesi.

Un kit “chiavi in mano” per rubare account Microsoft

Kratos non era un semplice kit di phishing statico, ma una piattaforma completa di Phishing-as-a-Service (PhaaS) venduta in abbonamento e pagabile in criptovaluta. Chi acquistava una licenza riceveva l’accesso a un pannello web e a uno shop su Telegram da cui gestire le proprie campagne, registrare nuovi domini civetta e monitorare le credenziali raccolte in tempo reale. Il prodotto di punta erano pagine di login false, quasi indistinguibili dagli originali, che imitavano i portali di autenticazione Microsoft 365.

La caratteristica che ha reso Kratos particolarmente pericoloso agli occhi degli investigatori tedeschi non era però la semplice raccolta di username e password, ormai capacità minima per qualunque kit di phishing del 2026, ma l’implementazione di tecniche Adversary-in-the-Middle (AiTM). Il kit si interponeva tra la vittima e il vero portale Microsoft, inoltrando le richieste di autenticazione in tempo reale e catturando, oltre alle credenziali, anche i cookie di sessione validi dopo il completamento della MFA. Questo permetteva agli operatori di dirottare sessioni già autenticate, aggirando di fatto l’autenticazione a due fattori senza doverla “rompere” tecnicamente: la si scavalcava semplicemente rubando il token già emesso dal legittimo processo di login.

La scala del danno: 15.000 campagne al mese

Secondo la Procura Generale di Francoforte (ZIT) e il Bundeskriminalamt (BKA), che hanno guidato le indagini in collaborazione con l’FBI, Kratos veniva utilizzato da oltre 1.800 clienti criminali per condurre in media 15.000 campagne di phishing al mese, con vittime confermate in almeno 35 paesi, concentrate soprattutto in Europa e Stati Uniti. Gli inquirenti stimano che l’operatore del servizio abbia incassato almeno 300.000 euro dal 2024 a oggi, esclusivamente tramite canoni di abbonamento: una cifra che dà la misura di quanto sia diventato profittevole il modello “as-a-service” applicato al crimine informatico, dove il gestore della piattaforma monetizza l’accesso allo strumento senza dover mai toccare personalmente i dati rubati dai propri clienti.

Il modello di business di Kratos rispecchia da vicino quello di altri kit AiTM emersi negli ultimi anni, come Tycoon2FA ed EvilProxy, confermando una tendenza consolidata: il phishing contro gli account Microsoft 365 aziendali resta uno dei vettori di accesso iniziale più redditizi per i broker di accessi, che poi rivendono le credenziali rubate a gruppi ransomware o le usano per frodi sul Business Email Compromise.

L’operazione: da Francoforte a Giacarta

L’azione di contrasto, ribattezzata Operation Olympus Blade, ha coinvolto il sequestro di oltre 200 server usati per ospitare l’infrastruttura di distribuzione e le pagine di phishing generate dai clienti della piattaforma. Sul sito ufficiale di Kratos è comparso un banner di sequestro che informa gli utenti del trasferimento della proprietà del dominio all’FBI, prassi ormai standard nelle operazioni congiunte USA-Europa contro le infrastrutture criminali online.

La parte più significativa dell’operazione, dal punto di vista dell’attribuzione, è però l’arresto in Indonesia dello sviluppatore e amministratore tecnico della piattaforma. Si tratta di un elemento tutt’altro che scontato: la maggior parte dei kit PhaaS che vengono smantellati porta al sequestro dell’infrastruttura, ma raramente all’identificazione fisica e alla cattura di chi ne cura lo sviluppo, spesso protetto da più livelli di anonimizzazione e da rivenditori intermedi che fanno da schermo. La collaborazione tra BKA, FBI e le autorità indonesiane suggerisce un lavoro di attribuzione durato mesi, probabilmente basato sull’analisi dei flussi di pagamento in criptovaluta e sulla correlazione tra gli account amministrativi della piattaforma e l’identità reale del suo operatore.

Due righe per i difensori

Il takedown di Kratos rimuove un attore significativo dall’ecosistema PhaaS, ma non elimina la tecnica sottostante. Le organizzazioni che si affidano a Microsoft 365 dovrebbero considerare questo caso un promemoria per rivedere le proprie difese contro il phishing AiTM, che per definizione bypassa l’MFA basata su codici OTP o push notification semplici:

• Adottare chiavi di sicurezza hardware FIDO2/WebAuthn o passkey, le uniche forme di MFA resistenti al furto di sessione tramite AiTM, poiché legano l’autenticazione all’origine del dominio.
• Abilitare policy di Conditional Access che valutino segnali di rischio come token replay da IP o dispositivi anomali rispetto alla sessione originale di login.
• Configurare la durata dei token di sessione e i criteri di revoca automatica in caso di cambio di posizione geografica o fingerprint del dispositivo.
• Monitorare i log di Entra ID / Azure AD per pattern di accesso anomali, come login riusciti seguiti da immediata modifica delle regole di inoltro della posta, tipica fase successiva al furto di sessione.
• Diffidare di email che rimandano a portali di login Microsoft con URL leggermente anomali o hosting su domini di terze parti, anche quando la pagina è visivamente identica all’originale.

Resta inoltre da chiedersi quanti cloni o eredi diretti di Kratos emergeranno nei prossimi mesi: la storia recente dei takedown PhaaS, da 16shop a Caffeine, mostra che la domanda di questi kit da parte della criminalità di basso profilo non si esaurisce con la cattura di un singolo operatore, ma semplicemente si sposta verso il prossimo servizio disponibile sui forum underground e sui canali Telegram dedicati.

(in)sicurezza digitale

2026-07-21 19:13:15

HollowGraph: la backdoor che trasforma il calendario di Microsoft 365 in un canale C2 cifrato

Un impianto di spionaggio finora sconosciuto ha trasformato uno degli strumenti più banali della vita d’ufficio, il calendario di Microsoft 365, in un canale di comando e controllo. Si chiama HollowGraph, non sfrutta alcuna vulnerabilità software e per questo è quasi impossibile da rilevare con i controlli di rete tradizionali: il traffico che porta gli ordini dell’attaccante e i file rubati è, a tutti gli effetti, traffico legittimo verso le API di Microsoft Graph.

A scoprirlo è stata Group-IB, che ha pubblicato l’analisi tecnica il 20 luglio 2026 dopo aver individuato l’impianto su almeno 12 macchine compromesse, di cui solo tre attivamente in comunicazione con l’attaccante durante la finestra di osservazione. Il traffico della vittima analizzata copre il periodo dal 3 giugno al 9 luglio 2026, e la casella di posta usata per l’esfiltrazione appartiene a un’organizzazione israeliana. Un’impronta piccola e selettiva, che i ricercatori leggono come spionaggio mirato piuttosto che criminalità opportunistica, anche se la tecnica potrebbe essere riutilizzata su scala molto più ampia.

Il calendario come dead drop

HollowGraph è una DLL .NET che supporta solo due comandi, get e send, e non contatta mai direttamente un server dell’attaccante per ricevere istruzioni. Al loro posto usa il calendario della casella compromessa come dead drop bidirezionale: per ricevere i comandi, interroga un evento specifico piazzato dall’operatore e datato 2050-05-13, una data così lontana nel futuro che nessun utente lo scoprirebbe mai scorrendo la propria agenda, e ne legge le istruzioni da un file allegato.

Per l’esfiltrazione il processo si inverte: il malware cifra il file rubato, crea un proprio evento altrettanto lontano nel tempo e carica i dati come uno o più allegati. L’intero scambio è protetto da uno schema ibrido RSA più AES-256, con coppie di chiavi separate per il canale di comando in entrata e per quello di esfiltrazione in uscita. Chi osservasse solo i log di rete vedrebbe esclusivamente chiamate alle API Microsoft Graph, indistinguibili dal traffico generato da un client Outlook qualsiasi.

Il secondo canale: DNS tunneling per restare vivi

Perché l’accesso a Graph resti valido nel tempo, HollowGraph mantiene un secondo canale, più grezzo ma altrettanto insidioso. Via DNS, il malware aggiorna periodicamente le credenziali dell’applicazione registrata su Entra ID (Azure AD): tenant ID, client ID, client secret e la casella di posta bersaglio. Questi valori vengono decodificati da record AAAA IPv6 restituiti da un dominio controllato dall’attaccante, cloudlanecdn[.]com, e scritti in un file camuffato da log di routine, logAzure.txt. A differenza del traffico sul calendario, qui le credenziali applicative viaggiano in chiaro, il che rende questo canale un punto di osservazione prezioso per i difensori.

Chi c’è dietro: Cavern e l’ombra di Teheran

Group-IB collega HollowGraph al framework backdoor modulare Cavern con alta confidenza, sulla base della sintassi di comando condivisa e di corrispondenze nella logica di tasking interna. Cavern era stato documentato all’inizio di luglio da Check Point, che lo ha attribuito a un cluster legato al Ministero dell’Intelligence e della Sicurezza iraniano (MOIS) soprannominato Cavern Manticore, con sovrapposizioni note verso i gruppi iraniani MuddyWater e Lyceum.

Il legame però riguarda il codice, non necessariamente l’operatore di questa specifica campagna: Group-IB è stata esplicita nel dire di non poter attribuire con sicurezza questa attività a un attore già noto, segnalando solo una sovrapposizione a bassa confidenza con Lyceum, sottogruppo dell’iraniano OilRig. La geografia della vittima, un’organizzazione israeliana, viene trattata dai ricercatori come dato sul bersaglio e non come prova di attribuzione.

Va detto che nascondere il comando e controllo dentro servizi Microsoft fidati non è una novità assoluta: caselle Outlook, cartelle bozze e OneDrive sono già stati abusati in passato con logiche simili. Ciò che rende HollowGraph interessante è aver scelto l’angolo cieco più remoto possibile, un evento di calendario piantato 24 anni nel futuro, in un momento in cui la difesa si concentra sempre di più sul monitoraggio delle identità cloud e delle applicazioni OAuth piuttosto che sui contenuti stessi delle caselle di posta.

Perché conta per i difensori

Non c’è una vulnerabilità Microsoft da patchare: HollowGraph vive su un account compromesso e sulle normali funzionalità dell’API Graph, il che è esattamente ciò che lo rende difficile da individuare. Il lavoro va fatto sul piano dell’identità e dei permessi applicativi, non su quello delle patch. Group-IB raccomanda di restringere e verificare le applicazioni OAuth con credenziali client che possono raggiungere Graph, allertare sulla creazione di nuovi client secret e applicare la consueta igiene su Entra ID: Conditional Access, rotazione delle credenziali e rilevamento di token anomali.

• Cercare eventi di calendario con data remota 2050-05-13
• Verificare oggetti che siano un GUID nudo o seguano schemi tipo Event ID: o Boss{..}ID{..}
• Individuare allegati con nome File{n}.txt
• Auditare le modifiche al calendario generate da un’applicazione anziché da una persona (eventi creati, allegati caricati, oggetti rinominati via app)
• Monitorare query DNS AAAA insolitamente frequenti verso un singolo dominio, con sottodomini lunghi e ad alta entropia
• Cercare il dominio cloudlanecdn[.]com e il file di configurazione logAzure.txt

L’operatore dietro questa campagna resta senza nome, e il traffico della vittima risultava ancora attivo il 9 luglio. Vale la pena controllare fin da ora quegli eventi datati nel remoto futuro: è esattamente lì che nessun analista avrebbe mai pensato di guardare.

Indicatori di compromissione

Dominio C2 (DNS tunneling): cloudlanecdn[.]com
File di configurazione: logAzure.txt
Evento calendario esca: data 2050-05-13
Pattern oggetto evento: GUID nudo / "Event ID:" / "Boss{..}ID{..}"
Allegati di comando: File{n}.txt
Framework correlato: Cavern (Cavern Manticore / MOIS-linked, overlap MuddyWater e Lyceum)
Finestra di attività osservata: 3 giugno - 9 luglio 2026
Set completo di IoC e hash: report tecnico Group-IB, "HOLLOWGRAPH: Turning Microsoft 365 Calendars into Covert Command-and-Control Channels"

(in)sicurezza digitale

2026-07-21 19:12:26

World Leaks nel cuore del nucleare indiano: 19.000 file della centrale di Kudankulam in vendita sul dark web

Diciannovemila file, 14,3 gigabyte di planimetrie, elenchi fornitori, verbali di ispezione e persino polizze assicurative contro il terrorismo. È quanto la gang di data extortion World Leaks ha pubblicato sul proprio leak site relativamente alla Kudankulam Nuclear Power Plant, la più grande centrale nucleare indiana, dopo che l’appaltatore Reliance Infrastructure ha rifiutato di pagare il riscatto. Non si tratta dei sistemi di controllo del reattore — quelli restano di competenza russa, forniti da Rosatom — ma la mole di documentazione tecnica esposta è comunque sufficiente per preoccupare gli esperti di sicurezza nucleare.

Un incidente nato a maggio, esploso a luglio

La vicenda comincia il 29 maggio 2026, quando Yotta, il data center indiano che ospita i server di Reliance Infrastructure, rileva un’attività sospetta su un’istanza riconducibile al gruppo Reliance. Yotta dichiara di aver bloccato l’esecuzione di un probabile ransomware in tempo reale. A fine giugno, però, Reliance Infrastructure comunica a Yotta di aver ricevuto rivendicazioni di data breach da parte di “attori esterni”: il tempo tra il contenimento tecnico e la scoperta dell’esfiltrazione reale è il primo campanello d’allarme di questa storia, e non è un caso isolato nel panorama delle intrusioni contro appaltatori di infrastrutture critiche.

Il 15 luglio i file compaiono sul portale World Leaks, accessibile solo tramite browser specializzati per l’accesso al dark web. Secondo il ricercatore indipendente Rakesh Krishnan, che per primo ha segnalato la fuga di dati a Reuters, i documenti riferiti alla sigla “KKNP” (Kudankulam Nuclear Power) risultavano online già dall’11 giugno — quasi un mese prima che la notizia diventasse pubblica. Reliance ha confermato una “violazione parziale” dei propri dati, senza specificarne l’estensione.

Chi è World Leaks

World Leaks non è un nome nuovo per chi segue il cybercrime organizzato. Il gruppo è la reincarnazione operativa di Hunters International, storica gang ransomware che nel 2025 ha scelto di abbandonare quasi del tutto la cifratura dei file per concentrarsi sulla pura estorsione dei dati: niente più payload di encryption da sviluppare e far evolvere contro gli antivirus, solo intrusione silenziosa, permanenza prolungata nella rete della vittima, esfiltrazione massiva e pressione pubblica sul leak site. Un modello di business più snello, più difficile da rilevare con gli strumenti EDR tradizionali (che sono tarati soprattutto sul comportamento anomalo della cifratura) e altrettanto redditizio.

Dal gennaio 2025 il gruppo rivendica oltre 150 vittime, tra cui Nike (1,4 TB di dati, 188.347 file, gennaio 2026), Dell, UBS e — soprattutto — un trio di società del conglomerato indiano Tata: Tata Technologies (1,4 TB, ereditata direttamente da Hunters International nel marzo 2025), Tata Electronics (630,4 GB, 204.341 file, giugno 2026, con dati sensibili di Apple e Tesla legati alla produzione di iPhone) e ora, con Reliance, un secondo grande gruppo industriale indiano colpito nello spazio di poche settimane. Nel caso Tata, World Leaks aveva dichiarato a Reuters di aver chiesto un riscatto di 1,5 milioni di dollari, pubblicando i dati dopo che l’azienda aveva “ignorato” la richiesta. Lo stesso copione — silenzio della vittima, contatore che scade, pubblicazione integrale — si è ripetuto con Reliance.

Cosa contengono davvero i file

Reuters, che ha potuto visionare parte del materiale senza tuttavia certificarne l’autenticità al 100%, descrive documenti datati tra il 2016 e la metà del 2025: planimetrie dei sistemi di ventilazione e raffreddamento delle Unità 3 e 4 (ancora in costruzione, operative entro il 2027, per una capacità combinata di 2.000 MW), la mappa completa di una control room comune, proposte di fornitori, un elenco di supplier approvati e i verbali di un’ispezione congiunta del 2024 tra Nuclear Power Corporation of India (NPCIL) e Reliance, corredati di fotografie degli impianti. Tra i documenti più delicati compare anche una polizza assicurativa che garantirebbe 112 milioni di dollari a Reliance Infrastructure e NPCIL in caso di atto terroristico contro le Unità 3 o 4 — un dettaglio che, se autentico, offre a un aggressore una stima concreta di quanto l’operatore stesso consideri “critico” quel bersaglio.

Nickolas Roth, senior director della Nuclear Threat Initiative, ha sottolineato a Reuters il vero rischio operativo di questo genere di fughe: non serve accedere ai sistemi del reattore per costruire un profilo utile a un attacco fisico o informatico successivo. Planimetrie, elenchi fornitori e mappe di controllo “mostrano a un avversario non solo chi ha accesso al progetto, ma quali sistemi quell’accesso può raggiungere” — in altre parole, permettono di ricostruire la catena di sicurezza dell’impianto e di individuarne i punti deboli, dai fornitori meno protetti ai varchi fisici meno sorvegliati.

Non è la prima volta per Kudankulam

Kudankulam ha già una storia di incidenti cyber: nel 2019 la rete amministrativa della centrale era stata infettata da un malware attribuito a un gruppo nordcoreano — un episodio che, secondo NPCIL, non aveva toccato i sistemi operativi dell’impianto. Il fatto che la stessa struttura torni due volte in sette anni al centro di un incidente informatico, per quanto di natura diversa, la dice lunga sulla difficoltà di isolare completamente reti industriali critiche dalla catena di fornitura IT che le circonda: la violazione non è avvenuta contro NPCIL direttamente, ma contro un fornitore terzo (Reliance) ospitato su infrastruttura di un altro fornitore terzo (Yotta) — un classico esempio di rischio di supply chain in ambito OT/critical infrastructure.

Contesto: l’India nel mirino

Il caso Reliance si inserisce in un trend più ampio. Secondo dati Surfshark, l’India è il terzo Paese al mondo per numero di account compromessi nel 2025 (28,9 milioni), dietro solo a Stati Uniti e Francia. Un report del Data Security Council of India realizzato con Seqrite ha rilevato che il 73% delle 204 organizzazioni intervistate “non sa se sia mai stata attaccata” e il 57% non applica pratiche basilari di igiene informatica. In un Paese che sta rapidamente espandendo il proprio parco nucleare — Kudankulam è centrale nel piano del governo Modi — il divario tra ambizione infrastrutturale e maturità della sicurezza informatica degli appaltatori resta il vero punto debole.

Due righe per i difensori

Per i team di sicurezza che gestiscono ambienti industriali o infrastrutture critiche, il caso Reliance/World Leaks offre alcune lezioni pratiche:

• Il rilevamento di un tentativo di cifratura bloccato non implica che l’esfiltrazione dei dati sia stata impedita: va sempre assunta l’ipotesi di data theft anche quando il ransomware “classico” viene neutralizzato in tempo.
• La sicurezza dei fornitori terzi (in questo caso un data center che ospita un appaltatore di un operatore nucleare) va trattata come estensione diretta del perimetro critico, con audit periodici e segmentazione delle reti che ospitano documentazione sensibile.
• Documentazione apparentemente “amministrativa” — planimetrie, elenchi fornitori, verbali di ispezione, polizze assicurative — va classificata e protetta con lo stesso rigore dei dati operativi, perché costituisce ricognizione pronta all’uso per un aggressore.
• Il ritardo tra compromissione (29 maggio), notifica interna (fine giugno) e pubblicazione pubblica (15 luglio, con dati online già dall’11 giugno) mostra quanto sia critico ridurre il tempo di rilevamento delle fughe di dati, anche tramite monitoraggio proattivo dei leak site e dei marketplace del dark web.

Dati chiave dell’incidente

Vittima: Reliance Infrastructure (contractor NPCIL/Kudankulam NPP)
Hosting compromesso: Yotta Data Services (data center terze parti)
Gruppo responsabile: World Leaks (rebrand di Hunters International)
Modello operativo: data extortion senza cifratura (double extortion "leak-only")
Volume totale dati Reliance: ~858.000 file
File più sensibili pubblicati: ~19.000 file / 14,3 GB
Data compromissione rilevata: 29 maggio 2026
Data comparsa dati su leak site: online dall'11 giugno, pubblicazione ufficiale 15 luglio 2026
Precedenti vittime note del gruppo: Nike, Dell, UBS, Tata Technologies, Tata Electronics, Mediaworks
Riscatto richiesto (caso Tata, riferimento): 1,5 milioni di USD
Accesso al leak site: solo tramite browser dark web dedicato

NPCIL, CERT-In e l’ufficio stampa del governo indiano non hanno risposto alle richieste di commento di Reuters. L’indagine è in corso, e resta da chiarire l’estensione reale della compromissione oltre i file già pubblicati.

Androidiani.net

2026-07-21 14:12:25

Redmi Watch 6 Active e Lite in arrivo: prezzi e specifiche trapelate

Redmi, il marchio del gruppo Xiaomi, starebbe lavorando a due nuovi smartwatch entry-level: Redmi Watch 6 Active e Redmi Watch 6 Lite. Dalle indiscrezioni emergono immagini di prodotto, specifiche principali e persino i prezzi previsti per il mercato europeo, che andranno ad affiancare l’attuale Redmi Watch 6.

Nome ingannevole: Active costa meno di Lite

Curiosamente, nonostante il nome suggerisca il contrario, sarà Redmi Watch 6 Active il modello più economico della coppia, mentre Lite si posizionerà leggermente più in alto.

• Redmi Watch 6 Active: circa 50 euro (8.100 yen)
• Redmi Watch 6 Lite: circa 60 euro (9.700 yen)

Redmi Watch 6 Active: display AMOLED e batteria da 470 mAh

Il modello Active dovrebbe montare un display AMOLED da 1,85 pollici con risoluzione 390×450 pixel, connettività Bluetooth 5.3 e una batteria da 470 mAh. Non mancano le funzioni base per il monitoraggio della salute: rilevazione della frequenza cardiaca, misurazione della saturazione di ossigeno nel sangue (SpO2), tracciamento del sonno e oltre 140 modalità sportive.

Redmi Watch 6 Lite aggiunge GPS e altoparlante

Il modello Lite si distingue per un display leggermente più grande, da 1,96 pollici con risoluzione 410×502 pixel, e per la presenza di un sensore di movimento a 9 assi oltre al GPS multi-costellazione (GNSS). A differenza di Active, Lite integra anche un altoparlante, pur mantenendo la stessa batteria da 470 mAh. Anche su questo modello sono confermate le funzioni di monitoraggio cardiaco, SpO2, sonno e le oltre 140 modalità sportive.

Lancio ancora senza data ufficiale

Al momento Xiaomi e Redmi non hanno confermato ufficialmente né la data di lancio né la disponibilità nei vari mercati. La presenza di prezzi in euro lascia intendere che l’Europa sarà tra le prime regioni coinvolte, ma resta da vedere se i due smartwatch arriveranno anche in altri mercati. In sintesi, Redmi Watch 6 Active si candida a modello d’ingresso puntando sul prezzo, mentre Watch 6 Lite punta su GPS e altoparlante per un pubblico che cerca qualcosa in più senza spendere cifre elevate.

Xiaomi Archivi - Androidiani.net

^{Androidiani.net}

Spcnet.it

2026-07-21 14:13:41

Sandbox escape negli agenti di coding AI: come Cursor, Codex, Gemini CLI e Antigravity sono stati bypassati

Il sandbox non basta più: come Cursor, Codex, Gemini CLI e Antigravity sono stati bypassati

Per mesi il messaggio rassicurante degli editor e delle CLI potenziate da AI è stato semplice: l’agente lavora dentro un sandbox, quindi anche se un prompt injection lo convince a fare qualcosa di malevolo, il danno resta confinato al workspace. Il team di ricerca di Pillar Security ha appena dimostrato, in una serie di sette advisory pubblicate come “The Week of Sandbox Escapes”, che questa assunzione è sbagliata per almeno quattro strumenti molto usati da sviluppatori e sistemisti: Cursor, OpenAI Codex CLI, Google Gemini CLI e Antigravity.

La cosa interessante, e preoccupante, è che in nessuno dei casi l’agente ha attaccato direttamente il confine del sandbox. Ha semplicemente scritto un file che uno strumento fidato, esterno al sandbox, ha poi eseguito, caricato o scansionato per conto proprio.

Il vero confine non è il processo dell’agente

Il modello mentale comune è: “dentro il workspace l’agente può fare quello che vuole, fuori è protetto”. Pillar mostra che questo confine ha in realtà tre livelli distinti:

• Esecuzione diretta: cosa può lanciare il processo dell’agente
• Scrittura nel workspace: quali file l’agente può creare o modificare
• Fiducia dell’host: cosa fanno i componenti non sandboxati con quei file

È il terzo livello a rompersi sistematicamente. Editor e CLI moderni sono pieni di automazioni che girano fuori dal sandbox: estensioni Python che scoprono interpreti, integrazioni Git che scansionano repository, VS Code che carica task file, hook engine che eseguono comandi al lifecycle, Docker Desktop che espone un socket locale privilegiato. Un agente sandboxato può rispettare ogni singola regola che gli è stata imposta e comunque condizionare l’input che questi componenti consumeranno.

Le quattro classi di vulnerabilità

I ricercatori raggruppano i sette bug in quattro pattern ricorrenti:

1. Sandbox a denylist che non tengono il passo del sistema operativo

Il caso più chiaro è la sandbox Seatbelt di Antigravity su macOS: un profilo “allow by default” deve ricordarsi di bloccare ogni singola funzionalità pericolosa del sistema operativo. Come scrive Pillar, “non è un sandbox, è una lista di cose che qualcuno si è ricordato di bloccare, sempre corta di una voce”.

2. Configurazioni di progetto che sono a tutti gli effetti codice eseguibile

Diversi bug non sono breakout classici: l’agente ha scritto file che era autorizzato a scrivere. Il problema è nato dopo, quando l’host ha trattato quei file come configurazione fidata. È il caso dell’hook .claude in Cursor, diventato esecuzione di comandi non sandboxata (ora CVE-2026-48124, corretto nella 3.0.0), o del task config .vscode che Antigravity ha usato per aggirare la sua Secure Mode.

3. Allowlist di comandi “sicuri” per nome, non per invocazione

In Codex CLI, un comando come git show era considerato sicuro perché il nome suggerisce sola lettura. Ma Git ha decine di flag che cambiano completamente il comportamento: possono scrivere file, caricare configurazioni, invocare hook. La domanda giusta, scrivono i ricercatori, non è “git show è sicuro?” ma “quale invocazione esatta viene eseguita, con quali argomenti, in quale directory, contro quale configurazione?”. OpenAI ha corretto il bug nella v0.95.0 e pagato una bounty per severità alta.

4. Demoni locali privilegiati fuori dal sandbox

Il bug più trasversale riguarda il socket Docker: un demone locale privilegiato raggiungibile da Codex, Cursor e Gemini CLI contemporaneamente, che diventava un ambiente di esecuzione non sandboxato. Sandboxare il processo dell’agente non serve a nulla se lascia aperto un demone con accesso pieno all’host: il confine si sposta semplicemente sull’API del demone.

Come si arriva all’exploit: il ruolo del prompt injection

In tutti i casi il vettore d’ingresso è un’istruzione malevola nascosta in un README, in una issue, in una dipendenza o in un diff, che l’agente legge come input “normale” durante il suo lavoro. Da lì, l’istruzione si trasforma in un’azione locale sulla macchina dello sviluppatore, senza che l’utente abbia mai approvato esplicitamente nulla di sospetto: dal punto di vista dell’agente, ha semplicemente scritto un file di configurazione plausibile in un progetto.

Google ha classificato le due vulnerabilità di Antigravity come “Other valid security vulnerabilities”, applicando un downgrade perché richiedono ingegneria sociale o che l’utente si fidi di un repository con prompt injection indiretto — pur riconoscendo, nelle parole dei ricercatori, che uno dei report era “di qualità eccezionale”.

Cosa chiedere ai vendor (e cosa verificare in azienda)

Per chi gestisce endpoint di sviluppo con strumenti agentici, Pillar suggerisce di andare oltre la domanda “ha un sandbox?” e porsi domande più operative:

• Cosa può scrivere l’agente, esattamente?
• Quali componenti dell’host si fidano di quei file?
• Quali demoni locali privilegiati sono raggiungibili dall’agente?
• Quali comandi saltano l’approvazione, e perché?
• La policy valuta il nome del comando o l’invocazione e i suoi effetti reali?
• Il prodotto distingue file creati dall’utente da file creati dall’agente?
• Che telemetria esiste quando un componente fidato esegue qualcosa scritto dall’agente?

Sul piano pratico, per chi amministra postazioni di sviluppo con Cursor, Codex CLI, Gemini CLI o Antigravity: aggiornate immediatamente alle versioni patchate (Cursor 3.0.0+, Codex CLI 0.95.0+), verificate che l’accesso al socket Docker dagli strumenti AI sia effettivamente ristretto quando non necessario, e trattate le configurazioni di progetto generate o modificabili da un agente (hook, task VS Code, config Git non standard) come superficie di attacco da rivedere in code review, non come dettagli innocui.

Conclusione

Il punto centrale della ricerca di Pillar non è la lista dei singoli bug, quasi tutti già corretti, ma il pattern che li accomuna: gli agenti di coding sono diventati attori endpoint a tutti gli effetti, con accesso a codice sorgente, chiavi SSH, token cloud e sessioni browser, e processano di routine input non fidato (README, issue, dipendenze, diff). Un sandbox che protegge solo il processo dell’agente, ignorando cosa scrive e chi si fida di quello che scrive, non è un confine di sicurezza reale. Per chi introduce questi strumenti in azienda, la domanda da porsi non è più “abbiamo attivato il sandbox”, ma “sappiamo tracciare ogni volta che un componente fidato dell’host esegue qualcosa che l’agente ha scritto”.

Fonte: Pillar Security, “The Week of Sandbox Escapes” e BleepingComputer.

Cursor Desktop sandbox escape via Claude hook configuration

### Summary Cursor Desktop could execute workspace-defined Claude hook commands from `.claude/settings.local.json` without dedicated user approval. ### Impact A malicious workspace or agent-cr...

^GitHub