CyberWeek 38/2026

Questa settimana il filo conduttore è piuttosto netto:non serve più scegliere tra vulnerabilità tecniche e ingegneria sociale, perché gli attaccanti stanno usando entrambe con una velocità sempre crescente.
Da una parte abbiamo apparati di sicurezza aziendali colpiti da zero-day già sfruttate prima ancora che molti amministratori sapessero della loro esistenza; dall’altra utenti italiani bombardati da rimborsi, multe, finte comunicazioni sanitarie e applicazioni bancarie fasulle (anche se a me continua ad arrivare la vecchia e cara email della truffa nigeriana, questa settimana regalano una decina di milioni di dollari dalla Turchia, se a qualcuno interessano).

In mezzo compare ancora una volta l’intelligenza artificiale. Non soltanto come strumento capace di trovare vulnerabilità (e sarebbe un utilizzo più che auspicabile): questa settimana abbiamo due casi particolarmente interessanti nei quali entra direttamente nella catena di sicurezza del software.
Un assistente AI compromesso è stato sfruttato per propagare malware attraverso repository aziendali, mentre un piccolo gruppo di ricercatori ha utilizzato Claude per arrivare fino agli account interni di OpenAI. Non si tratta dello scenario hollywoodiano dell’“AI hacker”: sono esempi molto più concreti — e forse proprio per questo più interessanti — di quanto rapidamente stiano cambiando sviluppo e sicurezza.

Sul fronte italiano, intanto, CERT-AGID ha contato191 campagne malevole tra il 12 e il 18 settembre, contro le 170 della settimana precedente: 158 erano specificamente rivolte all’Italia.
Rimborsi, multe e banking restano le esche preferite, ma le campagne stanno diventando decisamente più curate e rendersi conto di trovarsi davanti ad un tentativo di truffa è sempre più complicato, per un utente base ma anche per i piùscafatiavanzati.

Cisco: due zero-day in due giorni, e questa volta sono colpiti gli strumenti che dovrebbero proteggere la rete

Quando la vulnerabilità è dentro un normale PC è un problema. Quando si trova nell’apparato che controlla chi può entrare nella rete, è un grosso problema.

Cisco ha correttoCVE-2026-76460, vulnerabilità con punteggioCVSS10.0in Identity Services Engine (ISE) e ISE Passive Identity Connector. ISE viene utilizzato nelle reti aziendali per identificare utenti e dispositivi e applicare le policy di accesso: in altre parole, è uno dei componenti che può decidere chi entra e dove può andare.

La falla nasce da controlli insufficienti sull’autenticazione di un endpoint API. Un attaccante remoto non autenticato può inviare una richiesta appositamente costruita eaggirare l’autenticazione dell’interfaccia di gestione. Non è soltanto una possibilità teorica: Cisco ha confermato che CVE-2026-76460 viene già sfruttata e ha individuato il problema durante la gestione di un caso di assistenza tecnica. Non esistono workaround: occorre aggiornare.

E non è arrivata da sola.

Pochi giorni prima era emersaCVE-2026-76461, vulnerabilità critica in Cisco Secure Email Gateway. In questo caso il vettore è quasi disarmante nella sua semplicità: una email opportunamente costruita può sfruttare una SQL injection nel processo di parsing e portare all’esecuzione di comandi con privilegi root, senza autenticazione. Anche questa vulnerabilità risulta sfruttata attivamente. Cisco ha persino contattato direttamente alcuni clienti sui cui dispositivi Secure Email Cloud era stata osservata attività malevola.

Ovviamente, poi una volta ottenuti privilegi root sul gateway, l’attaccantedeve...ehm...può cercare di cancellare o nascondere le tracce lasciate sull’apparato. Per questo Cisco suggerisce di controllare anche log di rete e firewallesternial dispositivo compromesso.

Due vulnerabilità sfruttate quasi contemporaneamente in prodotti che si occupano rispettivamente di controllo degli accessi e sicurezza della posta ricordano una regola fondamentale:gli strumenti di sicurezza fanno parte della superficie d’attacco esattamente come tutto il resto.

Fonti

Un assistente AI compromesso diventa il cavallo di Troia della supply chain

Ci stiamo abituando a sviluppare software tramite l'IA (me compreso e mi sono ripromesso di fare un articolo al riguardo), è comodo, veloce, potentissimo e tante altre belle cose ma quanto stiamo attenti a cosa il nostro amico virtuale ci consiglia? O a cosa fa?
Anzi no, cambio: quantodovremmostarci attenti?
Spoiler: tanto!

Mandiant, una società di cyber security parte di Google Cloud, ha documentato il caso di un’azienda SaaS nella quale un attaccante è riuscito adirottare una sessione attiva di un assistente AI utilizzato per programmare. Il nome dell’azienda e quello dell’assistente non sono stati resi pubblici (e, privacy a parte, la cosa mi lascia un po' perplesso).

Durante la sessione compromessa, l’assistente ha suggerito al programmatore una dipendenza software che l’attaccante aveva precedentemente avvelenato. Il suggerimento è stato accettato e da lì è iniziata la catena: un pacchetto PyPI malevolo ha installato un infostealer, sono stati sottratti token OAuth di GitHub e successivamente è entrato in scenaShai-Hulud(un worm in grado di replicarsi in giro per la rete. Se avete visto Dune capirete la citazione), propagandosi in circa100 repository interni. Sono stati rubati segreti contenuti nei repository e codice sorgente dei prodotti aziendali.

L’attaccante è arrivato inoltre a contaminare un pacchetto appartenente al namespace ufficiale dell’azienda. Quando un secondo dipendente ha scaricato quella versione, si è verificata una nuova infezione.

È un caso quasi da manuale per capire un problema emergente dell’AI applicata allo sviluppo:tendiamo ad attribuire all’assistente una fiducia che non attribuiremmo a uno sconosciuto che ci propone una libreria su Internet.

L’AI non ha autonomamente deciso di infettare l’azienda. L’attaccante ha compromesso una sessione e manipolato ciò che entrava nel processo di sviluppo. Ma proprio perché gli assistenti AI stanno diventando intermediari tra sviluppatore, repository, dipendenze, documentazione e terminale, la loro compromissione può moltiplicare enormemente il raggio d’azione di un attaccante.

Mandiant suggerisce quindi di verificare le dipendenze proposte dagli assistenti contro allowlist e checksum approvati, evitare che estensioni e agenti possano raggiungere direttamente API key o token OAuth di lunga durata e instradare le dipendenze attraverso repository aziendali controllati.

L’AI può velocizzare enormemente il lavoro, automatizzare task ripetitivi e addirittura fare cose che noi non riusciremmo mai a fare (vi spiegherò...).
Ma“me l’ha consigliato l’assistente” non può diventare il nuovo equivalente di “ho cliccato OK senza leggere”.

Fonti

Claude contro OpenAI: meno di 72 ore per arrivare agli account interni

Restiamo sull’intelligenza artificiale, ma cambiamo completamente prospettiva.

Tre ricercatori della società di sicurezza Hacktron, hanno utilizzatoClaude Opus 5 di Anthropicper compromettere account appartenenti a dipendenti OpenAI e raggiungere un repository interno.

Fermi tutti, però:non è stato un attacco criminale contro OpenAI, ma una ricerca condotta nell’ambito del bug bounty e comunicata responsabilmente all’azienda dai ricercatori che, in questo caso vengono definiti "white-hat hackers".

La catena dell'attacco partiva dal software utilizzato dal forum pubblico di assistenza di OpenAI. Una vulnerabilità permetteva di ottenere esecuzione di codice attraverso l’elaborazione di un’immagine HEIF appositamente costruita; combinandola con una debolezza nell’implementazione SSO di OpenAI, i ricercatori sono riusciti a impossessarsi delle sessioni di alcuni dipendenti e raggiungere servizi interni.

Come prova dell’accesso hanno creato unapull request innocuasu un repository interno e si sono fermati lì.

Secondo Hacktron, dal primo esame dell’obiettivo all’accesso interno sono trascorse meno di72 ore. OpenAI avrebbe corretto il problema circa 14 ore dopo la segnalazione e il 1° settembre ha riconosciuto ai ricercatori un bounty di 6.500 dollari per la parte relativa ai propri sistemi.

Il punto però non è stabilire se “Claude sappia hackerare OpenAI”. Sarebbe una semplificazione e soprattutto sappiamo benissimo che, se correttamente indirizzati, gli agenti AI sono perfettamente in grado di lanciare attacchi.

Il punto è che un piccolo gruppo di ricercatori può utilizzare un modello avanzato per accelerare analisi, sviluppo degli exploit e concatenazione delle vulnerabilità. La capacità tecnica dell’essere umano resta fondamentale, ma il moltiplicatore sta diventando molto potente.

Ed èimpossibiledifficile immaginare che rimanga un’esclusiva dei difensori...

Fonti

Revolut e il data breach con la cartella "Italy"

La storia italiana più delicata della settimana riguarda Revolut, società britannica che offre servizi finanziari, in particolare lavora (anche) sulle criptovalute, fornendo cambio e gestione.

Il caso è diventato molto più interessante — e, per certi versi, più inquietante — con il passare dei giorni. Le prime ricostruzioni facevano pensare a una classica compromissione informatica: qualcuno entra nei sistemi, raggiunge un archivio e porta via i dati.
Oggi sappiamo che la dinamica sembra essere stata completamente diversa.

Gli aggressorinon avrebbero violato direttamente l'infrastruttura di Revolut. Avrebbero invece compromesso un indirizzo email istituzionale italiano legittimo e lo avrebbero utilizzato per presentarsi alla fintech come, appunto, una legittima autorità investigativa. Da quell'indirizzo sarebbero partite richieste formali di informazioni su alcuni clienti e Revolut, ritenendole autentiche, avrebbe risposto consegnando i dati richiesti.

È una differenza enorme.

Qui il criminale non ha dovuto forzare il database della banca. Ha sfruttatola fiducia tra due organizzazioni.

Il meccanismo ricorda per certi versi unaBusiness Email Compromiseportata a un livello decisamente superiore: invece di impersonare un amministratore delegato o un fornitore, gli attaccanti disponevano di una casella appartenente a un dominio governativo reale. La richiesta non proveniva quindi da un facilmente riconoscibilepolizia-italiana123.ru, ma da un canale che, almeno a un primo controllo, aveva tutte le caratteristiche necessarie per essere considerato attendibile.

Secondo le ricostruzioni pubblicate dal Financial Times e riprese dalle agenzie italiane, il sistema sarebbe stato utilizzato ripetutamente nell'arco di diversi mesi. Gli aggressori avrebbero ottenuto informazioni relative a circa680 clienti Revolut(dato stimato dal FT e non confermato da Revolut), scegliendo in particolare soggetti considerati interessanti per la loro attività nel mondo delle criptovalute. Tra i dati comunicati figurerebbero informazioni anagrafiche, indirizzi di residenza, documenti d'identità, numeri di conto e dettagli sulle transazioni, comprese operazioni in Bitcoin e altre criptovalute.

Ed è qui che il problema assume una dimensione che va oltre il "semplice" furto d'identità. Per uncomune mortalenormale cliente, la diffusione di passaporto, indirizzo e informazioni finanziarie è già estremamente grave. Per una persona nota per possedere quantità importanti di criptovalute, rendere pubblico anchedove vivepuò introdurre un rischio fisico concreto: non è difficile capire perché alcune vittime abbiano espresso preoccupazione anche per possibili estorsioni o cosiddetti “wrench attack”, nei quali il bersaglio non è più il wallet digitale ma direttamente il suo proprietario.

Revolut ha precisato chei propri sistemi non risultano compromessi e che i fondi dei clienti non sono stati toccati. Una volta scoperta la frode, l'indirizzo utilizzato dagli attaccanti è stato bloccato e sono state informate l'autorità governativa interessata, le forze dell'ordine, i regolatori finanziari e le autorità per la protezione dei dati.

Questo però apre inevitabilmente una seconda domanda:quanto deve essere considerata affidabile una richiesta semplicemente perché arriva da un indirizzo istituzionale autentico?

Sul proprio sito Revolut indica che le autorità e i rappresentanti legali possono inviare ordinanze e richieste ufficiali attraverso un canale dedicato. Ma proprio l'incidente dimostra che l'autenticità del dominio di provenienza non può essere l'unico elemento utilizzato per autorizzare la consegna di una grande quantità di dati sensibili. Se un account governativo viene compromesso, SPF, DKIM, PEC e dominio corretto possono confermare che il messaggio proviene realmente da quell'infrastruttura; non possono garantire che davanti alla tastiera ci sia ancora la persona autorizzata a utilizzarla.

Diventa quindi essenziale una verificaalternativa: controllare l'identità del richiedente attraverso un secondo canale, verificare numero e validità del procedimento, limitare i dati trasmessi allo stretto necessario e introdurre controlli aggiuntivi quando una stessa autorità comincia a chiedere grandi quantità di informazioni o richieste riguardanti molti clienti.

Quindi ,per quanto sappiamo finora, si tratta di undata breach ottenuto attraverso la compromissione di una terza parte e l'abuso di un rapporto di fiducia istituzionale. Il sistema informatico della fintech può anche non essere mai stato penetrato, ma i dati sono comunque usciti perché l'attaccante è riuscito a presentarsi con credenziali abbastanza convincenti da farsi aprire la porta dall'interno.

Ed è forse questo l'aspetto più interessante dell'intera vicenda: possiamo costruire sistemi tecnicamente sicuri, autenticazioni forti e infrastrutture isolate, ma prima o poi dobbiamo permettere a qualcuno di prendere una decisione basandosi sull'identità di qualcun altro.

Gli attaccanti lo sanno.

E sempre più spesso, invece di cercare una vulnerabilità nel software, cercanouna vulnerabilità nella fiducia.

Fonti

Bonus Vacanze, FSE e rimborsi IRPEF: il phishing italiano continua per la sua strada

I numeri CERT-AGID sono eloquenti:191 campagne in sette giorni, 158 specificamente italiane e1.498 indicatori di compromissionedistribuiti agli enti accreditati.

Il rimborso continua a essere l’esca preferita, con 46 campagne; seguono le false multe con 42 e il banking con 25. Ma questa settimana è soprattutto la qualità di alcune campagne a meritare attenzione.

Una falsa iniziativa dell’Agenzia delle Entratepropone un inesistente “Bonus Vacanze”. Il sito non si limita a copiare un logo e presentare un modulo: simula diverse sezioni e persino la procedura di autenticazione tramiteSPID o CieID.

Il Fascicolo Sanitario Elettronico viene invece utilizzato per convincere la vittima che la relativa app stia per essere bloccata e che sia necessario confermare i propri dati.

Poi ci sono i rimborsi IRPEF: alcune campagne chiedono codice fiscale e carta di credito, mentre una variante arriva a richiederecodice fiscale, IBAN e informazioni bancarie simulando persino una verifica a due fattori tramite SMS.

La vecchia regola “si vede subito che è phishing” sta diventando pericolosamente obsoleta. La grafica è migliore, il percorso è più lungo e realistico e l’attaccante riproduce procedure che l’utente conosce davvero.

Il controllo decisivo resta quindi l’origine della comunicazione: per bonus, rimborsi fiscali, multe o servizi sanitariconviene entrare autonomamente nel portale ufficiale invece di seguire il link ricevutospecialmente se si tratta di qualcosa di insolito e non richiesto.

Fonti

RatHat arriva in Italia: il malware Android passa dagli SMS bancari

La terza storia chiude perfettamente il cerchio tra ingegneria sociale e compromissione tecnica.

CERT-AGID ha individuato durante la settimana una campagna italiana a tema banking che distribuisceRatHatattraverso SMS contenenti link a un APK malevolo. Nello stesso scenario è stata osservata anche una campagna BingoMod. Complessivamente il CERT ha rilevato10 famiglie malwareattive in Italia, tra cui Remcos, AgentTesla, FormBook, Guloader, AsyncRat, Grandoreiro e MassLogger.

RatHat merita attenzione perché rappresenta bene l’evoluzione del malware mobile: non basta più pensare all’APK fasullo come a una semplice app che ruba username e password.

La prima barriera rimane però sorprendentemente tradizionale:convincere l’utente a installare un’app proveniente da fuori dello store ufficiale.

È lo stesso principio visto con ClickFix sui computer. Invece di cercare necessariamente una vulnerabilità costosissima, l’attaccante prova a trasformare la vittima nel proprio installatore.

Su Android questo significa diffidare radicalmente da qualsiasi SMS bancario che richieda di scaricare un APK (in realtà dovrebbe essere "che richieda di scaricare qualsiasi cosa"!), anche quando grafica, nome dell’app e pagina di destinazione sembrano plausibili. Una banca non distribuisce in questo modo un aggiornamento urgente della propria applicazione.

Fonti

In definitiva...

Da una parte abbiamo vulnerabilità tecniche estremamente sofisticate:Cisco ISE che può perdere la propria barriera di autenticazione, un gateway email che può consegnare privilegi root e una catena di vulnerabilità capace di portare ricercatori dentro gli account di OpenAI.

Dall’altra abbiamo qualcosa di molto meno sofisticato: un SMS, una finta multa, un rimborso IRPEF o una pagina che ci chiede di installare un’app.

Nel mezzo sta comparendo l’AI. Sempre più spesso.

Può aiutare un ricercatore a trovare e concatenare vulnerabilità in tempi impressionanti. Può entrare nei workflow degli sviluppatori e accelerarne enormemente il lavoro. Ma proprio per questo diventa anche un nuovo punto della catena di fiducia: se compromettiamo l’assistente, la sessione o ciò che gli viene fornito, rischiamo di trasformare quella velocità in un moltiplicatore dell’attacco.
O, come per il problema di Microsoft della settimana scorsa, grazie alla maggiore potenza ed alla fiducia riposta negli agent, creare casini su scala molto più grande
Per chi vuole sfruttarla in maniera malevola, inoltre, aiuta a creare email di phishing credibili molto più velocemente che ai "bei tempi" della truffa nigeriana che ho citato all'inizio, quando anche la mail della nostra banca sembrava l'avesse scritta Tarzan.
Ora sono scritte in un linguaggio che è difficile se non quasi impossibile da riconoscere come truffa.

E forse è questa la lezione più utile della settimana:la cybersecurity continua a costruire barriere sempre più sofisticate, mentre gli attaccanti continuano a cercare il punto in cui concediamo fiduciao abbassiamo la guardia.

E, anche se la tecnologia avanza e i "cattivi" usano sistemi sempre più perfezionati, molto più spesso di quanto vorremmo ammettere, il problema siamo semplicemente noi, quelli con le mani sulla tastiera.

Alla prossima!
M.