La Direttiva UE 2015/2366 PSD2 (Payment Services Directive 2) è una normativa dell’Unione Europea che ha come obiettivo il rafforzamento della sicurezza nei pagamenti online e la promozione dell’innovazione nel settore dei servizi di pagamento. In Italia è ufficialmente operativa dal 14 settembre 2019 e ha condotto a nuovi standard di autenticazione e sicurezza per autorizzare le operazioni bancarie. Introducendo nuovi requisiti di sicurezza e regolamentando l’accesso ai conti di pagamento da parte di terzi, la PSD2 ha rappresentato una vera e propria rivoluzione nel panorama dei pagamenti elettronici.

In questo articolo, esploreremo i principali aspetti della PSD2, concentrandoci sulla sicurezza dei pagamenti online e su come le aziende, le banche e i consumatori devono adattarsi alle nuove regole per garantire un ambiente sicuro e trasparente.

Autenticazione forte del cliente (SCA): requisiti e modalità di implementazione

Uno degli aspetti fondamentali della Direttiva PSD2 è l’introduzione dell’autenticazione forte del cliente (SCA). Si tratta di una misura di sicurezza pensata per proteggere i consumatori dai rischi legati alle frodi durante le operazioni online, come gli accessi non autorizzati ai conti bancari o le transazioni fraudolente. In base alla PSD2, le operazioni di pagamento devono essere soggette a un processo di autenticazione che coinvolga due fattori distinti, appartenenti a categorie diverse.

Requisiti dell’autenticazione forte del cliente

L’SCA si basa su tre principali fattori di autenticazione:

1. Conoscenza: qualcosa che solo l’utente conosce (ad esempio, una password, un PIN, una risposta a una domanda di sicurezza).
2. Possesso: qualcosa che solo l’utente possiede (ad esempio, un dispositivo mobile, una carta di pagamento, un token di sicurezza).
3. Inerenza: qualcosa che identifica unicamente l’utente, come le caratteristiche biometriche (impronta digitale, riconoscimento facciale, ecc.).

Secondo la PSD2, almeno due di questi fattori devono essere utilizzati per autenticare una transazione online. Questo significa che una semplice password non è più sufficiente; anche un codice inviato tramite SMS o una verifica tramite impronta digitale devono essere integrati nel processo.

Inoltre, il nuovo sistema migliora la sicurezza creando un codice univoco per ogni transazione, a differenza dei codici OTP delle chiavette bancarie, che si basano su una logica temporale. I codici OTP, infatti, permettevano, seppur in modo limitato, di eseguire più operazioni durante il periodo in cui erano validi. Con le nuove regole, invece, il codice “restituito” al cliente è legato solo e soltanto a quella determinata transazione, aumentando quindi ancora di più la sicurezza.

Le modalità di implementazione dell’autenticazione forte del cliente variano in base al tipo di pagamento e alla tipologia di dispositivo utilizzato. Ad esempio, nelle transazioni effettuate tramite dispositivi mobili, l’autenticazione tramite biometria (come il riconoscimento facciale o l’impronta digitale) sta diventando sempre più comune. Inoltre, le carte di pagamento possono essere dotate di sistemi di verifica in due passaggi, dove il primo passaggio è una verifica della carta stessa, e il secondo passaggio un codice inviato via SMS.

Tuttavia, la PSD2 prevede delle esenzioni dall’obbligo di SCA in casi specifici, come ad esempio per i pagamenti a basso rischio (quando l’importo della transazione è inferiore a una determinata soglia) o per i pagamenti ricorrenti a favore dello stesso beneficiario.

Accesso ai conti di pagamento da parte di terzi (Third Party Providers)

La PSD2 introduce anche una regolamentazione sull’accesso ai conti bancari da parte di terzi fornitori di servizi di pagamento (Third Party Providers, TPP). Questo significa che le banche non possono più limitarsi a gestire i pagamenti in modo esclusivo, ma devono permettere a terzi di accedere ai dati dei conti bancari (con il consenso del cliente) per offrire nuovi servizi, come la gestione delle finanze personali o i pagamenti tramite piattaforme di terze parti.

Tipologie di Third Party Providers

Secondo la PSD2, esistono tre principali categorie di fornitori di servizi di pagamento terzi:

1. Servizi di informazione sui conti (Account Information Service Providers, AISPs): Questi fornitori possono accedere ai dati del conto di pagamento del cliente, al fine di fornire servizi di consulenza finanziaria, gestione delle spese o aggregazione di conti.
2. Servizi di iniziazione dei pagamenti (Payment Initiation Service Providers, PISPs): Questi fornitori consentono ai consumatori di effettuare pagamenti direttamente dal proprio conto bancario, senza dover utilizzare una carta di credito o debito.
3. Servizi di custodia dei fondi (Fund Confirmation Service Providers, FCPs): Questi fornitori si occupano di verificare la disponibilità di fondi sui conti bancari per garantire che le transazioni siano adeguatamente coperte.

PSD2 e Open API

I principali cambiamenti apportati dalla normativa europea sui servizi di pagamento sono strettamente legati al fenomeno dell’Open Banking e delle Open API.

In particolare, a partire dal 14 settembre 2020, le banche sono state obbligate a condividere tramite API (Application Programming Interface) alcune informazioni relative ai conti e alle operazioni di pagamento dei propri clienti con terze parti, ma solo se autorizzate dal cliente stesso, in conformità con il regolamento GDPR.

Questo processo dà vita all’Open Banking, un nuovo modello che consente ai clienti di accedere liberamente alle proprie informazioni e di effettuare transazioni finanziarie senza i limiti imposti dalle tradizionali modalità bancarie. I servizi introdotti dal regolatore sono principalmente tre:

1. Account Information Service: consente ai clienti di consultare il saldo dei propri conti correnti attraverso applicazioni di terze parti, diverse dalle app bancarie tradizionali.
2. Payment Initiation Service: permette ai clienti di autorizzare trasferimenti di denaro senza l’uso di carte di credito, utilizzando applicazioni e servizi che si collegano direttamente al loro conto corrente.
3. Card Issuing Service: consente ai clienti di utilizzare una carta di pagamento emessa da un soggetto diverso dalla propria banca, simile a un classico Bancomat, ma che si collega direttamente al loro conto corrente.

Con l’introduzione della PSD2, si è quindi ampliato lo scenario competitivo, creando nuove opportunità di collaborazione tra le banche e i nuovi attori resi possibili dall’Open API, come startup, aziende Fintech e nuove realtà imprenditoriali.

Vantaggi e sfide per i consumatori

L’introduzione dei TPP ha portato numerosi vantaggi per i consumatori, come l’accesso a servizi bancari più flessibili, innovativi e personalizzati. Tuttavia, l’accesso ai dati bancari da parte di terzi solleva preoccupazioni in merito alla privacy e alla tutela dei dati personali. Per questo motivo, la PSD2 stabilisce che i clienti devono fornire il consenso esplicito per autorizzare l’accesso ai propri dati, e devono essere informati sui diritti di revoca e sulla durata del consenso.

La PSD2 obbliga le banche e i prestatori di servizi di pagamento ad adottare misure rigorose per la protezione dei dati personali. Questi soggetti sono tenuti a garantire che tutte le informazioni sensibili siano trattate in conformità con il Regolamento Generale sulla Protezione dei Dati (GDPR), e a implementare misure di sicurezza adeguate a prevenire violazioni dei dati.

Le banche e i fornitori di servizi di pagamento devono quindi garantire che i TPP siano autorizzati e regolamentati dalle autorità competenti, e che utilizzino protocollo sicuro per proteggere le informazioni sensibili.

Se da un lato la SCA ha fatto sentire gli utenti più protetti durante le transazioni, dall’altro ha avuto un impatto negativo sulla percentuale di successo dei pagamenti online, che è diminuita di circa l’11%, secondo uno studio condotto da Visa.

Altri dati interessanti emergono da una ricerca dell’Osservatorio Innovative Payments in collaborazione con Unguess (piattaforma di crowdsourcing che offre servizi di testing e fornisce insight reali per ottimizzare la qualità, l’esperienza e la sicurezza delle soluzioni digitali). I test, condotti su un campione di 80 persone, hanno rivelato che il principale problema riscontrato nei pagamenti tramite smartphone è la necessità di passare a un’altra app durante il processo di checkout, per poi tornare all’app originaria. Questo evidenzia che c’è ancora molto da fare per ottimizzare l’esperienza utente legata alla SCA, al fine di migliorare il tasso di conversione e rendere i pagamenti più semplici e sicuri.

Misure per prevenire le frodi nei pagamenti online

La lotta contro le frodi è uno degli obiettivi principali della PSD2. L’introduzione dell’autenticazione forte del cliente è solo uno degli strumenti per ridurre i rischi legati alle truffe. Oltre a questo, la PSD2 obbliga le banche e i prestatori di servizi di pagamento a implementare una serie di misure preventive per proteggere i consumatori dalle truffe online.

Monitoraggio delle transazioni

Un altro elemento cruciale della normativa è l’obbligo per le banche di monitorare in tempo reale le transazioni sospette. Utilizzando sistemi di intelligenza artificiale e machine learning, le istituzioni finanziarie sono in grado di rilevare comportamenti anomali o fraudolenti nelle operazioni e bloccare tempestivamente i pagamenti sospetti.

Regole per le transazioni a distanza

La PSD2 stabilisce anche delle regole più severe per le transazioni a distanza, come quelle effettuate online. In particolare, è previsto che ogni transazione online di importo elevato debba essere sottoposta a una verifica aggiuntiva, per ridurre il rischio di frodi. Queste misure includono l’invio di codici di conferma tramite SMS, l’uso di dispositivi di sicurezza fisici e l’adozione di altre tecnologie avanzate per garantire l’identità dell’utente.

Responsabilità delle banche e dei prestatori di servizi di pagamento

La Direttiva PSD2 stabilisce anche delle responsabilità precise per le banche e i prestatori di servizi di pagamento, in caso di transazioni non autorizzate o truffe. In particolare, se un pagamento viene effettuato senza l’autorizzazione del cliente, il prestatore di servizi di pagamento è tenuto a rimborsare l’importo della transazione entro un termine prestabilito.

Obblighi di comunicazione e risoluzione delle dispute nella PSD2

Uno degli aspetti più rilevanti introdotti dalla Direttiva PSD2 riguarda gli obblighi di comunicazione delle operazioni sospette o non autorizzate da parte delle banche, nonché la gestione delle dispute relative a tali transazioni. La PSD2 mira a garantire che i consumatori siano protetti da operazioni fraudolente e non autorizzate e che possano risolvere rapidamente qualsiasi controversia relativa ai pagamenti, con un processo chiaro e trasparente. Analizziamo più in dettaglio gli obblighi e le modalità di risoluzione delle dispute stabiliti dalla normativa.

1. Comunicazione tempestiva di transazioni sospette o non autorizzate

Una delle misure chiave della PSD2 è l’obbligo per le banche e gli istituti di pagamento di informare immediatamente i propri clienti nel caso in cui vengano rilevate transazioni sospette o non autorizzate. Questo obbligo ha lo scopo di ridurre i danni derivanti da operazioni fraudolente, consentendo ai consumatori di reagire tempestivamente e di bloccare o contestare l’operazione prima che essa venga completata.

Le banche devono fornire una notifica chiara e tempestiva riguardo a qualsiasi operazione che risulti dubbia o che non sia stata autorizzata dal titolare del conto. Questa notifica deve essere inviata entro un termine molto breve dopo che la transazione è stata identificata come sospetta, preferibilmente entro 24 ore.

Inoltre, le banche sono tenute a garantire che il processo di segnalazione di una transazione sospetta sia semplice e accessibile, per facilitare la comunicazione da parte dei clienti. I consumatori devono essere in grado di contattare facilmente la propria banca, anche tramite canali digitali, per segnalare rapidamente qualsiasi problema.

2. Procedura chiara e trasparente per la risoluzione delle dispute

Un altro elemento cruciale della PSD2 è la creazione di una procedura di risoluzione delle dispute chiara e trasparente. Questo significa che le banche devono predisporre un sistema efficace per gestire le contestazioni da parte dei consumatori, soprattutto in caso di transazioni non autorizzate o errate.

La risoluzione delle dispute dovrebbe avvenire in tempi rapidi e con la massima trasparenza, al fine di ridurre al minimo il disagio per i consumatori. Secondo la PSD2, le banche hanno l’obbligo di avviare un’indagine sulla disputa entro un termine massimo di 15 giorni dalla segnalazione da parte del cliente e devono risolvere la disputa entro 35 giorni, salvo complicazioni particolari che giustifichino un termine più lungo.

Durante questo processo, le banche devono garantire che i consumatori abbiano piena accessibilità alle informazioni relative alla disputa e che possano seguire lo stato della procedura. Inoltre, le banche sono obbligate a fornire una risposta dettagliata, spiegando le ragioni per cui una transazione è stata accettata o rifiutata, e devono informare il cliente del risultato dell’indagine.

3. Rimborso in caso di transazione non autorizzata

In caso di transazioni non autorizzate o errate, le banche sono tenute a rimborsare immediatamente l’importo della transazione al consumatore, senza applicare penalità o commissioni, purché il cliente non abbia agito in modo fraudolento o negligente. Questo obbligo di rimborso è parte integrante della protezione offerta dalla PSD2 ai consumatori, che garantisce loro il diritto di essere rimborsati per le operazioni non autorizzate, anche se la disputa è ancora in corso.

La PSD2 prevede che le banche debbano rimborsare il cliente senza indugi e, comunque, entro un termine massimo di 24 ore dalla segnalazione della transazione non autorizzata, in modo da limitare il danno economico subito dal consumatore.

4. Involvement di Autorità di Vigilanza e Organismi di Risoluzione delle Dispute

Nel caso in cui una disputa non venga risolta in modo soddisfacente tra il consumatore e la banca, la PSD2 consente ai clienti di rivolgersi a organismi esterni di risoluzione delle dispute. Questi organismi sono progettati per risolvere le controversie senza dover ricorrere a procedure legali complesse e costose.

Inoltre, la PSD2 stabilisce che le autorità di vigilanza nazionale (come la Banca d’Italia o altre autorità finanziarie locali) abbiano un ruolo attivo nel monitorare l’applicazione delle normative e l’efficienza del processo di risoluzione delle dispute. Qualora un consumatore non fosse soddisfatto del risultato del reclamo, può presentare una denuncia all’autorità competente, che avrà il compito di valutare la situazione e, se necessario, adottare misure correttive.

5. Protezione dei consumatori e trasparenza

La PSD2 sottolinea anche l’importanza di una protezione adeguata dei consumatori in tutte le fasi del processo di pagamento e risoluzione delle dispute. Le banche devono garantire che tutte le informazioni relative ai diritti dei consumatori, alle modalità di reclamo e alla risoluzione delle controversie siano chiare, facilmente comprensibili e accessibili. Ciò include la corretta informazione riguardo ai diritti di rimborso, alle modalità di contestazione e ai tempi di risposta previsti.

Questa trasparenza non solo tutela i consumatori, ma garantisce anche una maggiore fiducia nei sistemi di pagamento digitali, che possono essere percepiti come più sicuri quando le banche rispettano gli obblighi di comunicazione e di risoluzione delle dispute previsti dalla PSD2.

Conclusioni

La Direttiva PSD2 ha significativamente trasformato il panorama dei pagamenti online, introducendo misure di sicurezza più rigorose e promuovendo l’innovazione nel settore dei servizi di pagamento. È importante sottolineare che la PSD2 non rappresenta l’ultimo passo per i regolatori e gli operatori del settore dei pagamenti. Infatti, la Commissione Europea ha già avviato le consultazioni per la terza versione della Payment Services Directive, offrendo agli operatori l’opportunità di inviare i propri feedback sulla bozza precedente.

La necessità di aggiornare la PSD2 nasce da vari fattori, tra cui: garantire la trasparenza dei costi dei pagamenti tra l’UE e i paesi esteri, rivedere l’accesso ai conti e ai servizi di pagamento, considerare l’ingresso di nuovi attori nel mercato e intensificare la lotta contro le frodi a danno dei consumatori (come nel caso del “social engineering”). Inoltre, si sottolinea la necessità di aggiornare periodicamente la normativa per tenere conto dei cambiamenti tecnologici e dei nuovi rischi emergenti, ad esempio legati all’uso delle criptovalute e dei pagamenti mobili.

L’autenticazione forte del cliente, l’accesso ai conti da parte di terzi e le misure di tutela contro le truffe sono solo alcuni degli aspetti chiave di questa normativa che ha come obiettivo principale la sicurezza dei pagamenti online. La sfida per le banche, i prestatori di servizi di pagamento e i consumatori è quella di adattarsi rapidamente a queste nuove regole, garantendo al contempo la protezione delle informazioni sensibili e il miglioramento dell’esperienza di pagamento.

https://www.ictsecuritymagazine.com/articoli/direttiva-psd2-payment-services-directive-2-sicurezza-dei-pagamenti-online/

Trustwave’s Spider Labs, meanwhile, said the sample of LDAP credentials provided by rose87168 “reveals a substantial amount of sensitive IAM data associated with a user within an Oracle Cloud multi-tenant environment. The data includes personally identifiable information (PII) and administrative role assignments, indicating potential high-value access within the enterprise system.”

Oracle initially denied any such breach had occurred against its cloud infrastructure, telling publications: “There has been no breach of Oracle Cloud. The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data.”

On Friday, when I asked Oracle for comment, a spokesperson asked if they could provide a statement that couldn’t be attributed to Oracle in any way. After I declined, the spokesperson said Oracle would have no comment.

For the moment, there’s a stand-off between Oracle on the one hand, and researchers and journalists on the other, over whether two serious breaches have exposed sensitive information belonging to its customers. Reporting that Oracle is notifying customers of data compromises in unofficial letterhead sent by outside attorneys is also concerning. This post will be updated if new information becomes available.

https://arstechnica.com/security/2025/03/oracle-is-mum-on-reports-it-has-experienced-2-separate-data-breaches/

Mar 28, 2025 Marina Londei Hacking, In evidenza, News, RSS 0

---

Un vecchio dominio di Microsoft Stream è stato compromesso e utilizzato per mostrare un falso sito Amazon e, come conseguenza, tutte le pagine SharePoint che integravano video del sito includevano contenuti spam. 

Come si legge su Bleeping Computer, il dominio microsoftstream[.]com rimandava a una pagina web simil-Amazon che pubblicizzava un casinò thailandese. Secondo le informazioni di WHOIS, la modifica sarebbe stata effettuata ieri, il 27 marzo.

Per anni Microsoft Stream è stato un servizio di condivisione video per consentire alle organizzazioni di distribuirli sulle applicazioni Microsoft 365. I contenuti, caricati sul dominio compromesso, potevano essere integrati su altri siti web, come quelli creati con SharePoint.

“Oggi pomeriggio un utente ha segnalato un sito web sospetto nella nostra intranet che utilizza microsoftstream[.com]“ ha scritto un utente su Reddit. “Dopo l’analisi, è venuto fuori che il dominio rimanda a un sito web sospetto firmato da ‘Ibiza99’“. Il dominio appartiene ancora a Microsoft, ma qualcuno è riuscito a modificarne il contenuto.

Un altro utente su Reddit ha confermato la problematica, spiegando che, analizzando il sito SharePoint aziendale incriminato, ha scoperto che integrava video dal dominio Stream compromesso. Il vecchio dominio è stato dismesso dopo la notizia, impedendo ai siti SharePoint di caricare contenuti spam.

Microsoft aveva invitato i propri clienti a migrare i propri video su Stream sulla nuova piattaforma entro aprile 2024, quando il servizio è stato ufficialmente interrotto.

Non appena la notizia si è diffusa, molti amministratori SharePoint hanno provveduto a eliminare i link dei video legati al dominio sabotato dai cyberattaccanti. Al momento non si hanno dettagli sull’identità del gruppo o dell’attaccante.

Contattata da Bleeping Computer, Microsoft ha spiegato di essere al corrente della situazione e di aver bloccato l’accesso al vecchio dominio per impedire la diffusione di spam. La compagnia non ha però chiarito in che modo il sito sia stato compromesso.

---

---

---

https://www.securityinfo.it/2025/03/28/sharepoint-inondato-dallo-spam-la-colpa-e-di-un-dominio-stream-compromesso/?utm_source=rss&utm_medium=rss&utm_campaign=sharepoint-inondato-dallo-spam-la-colpa-e-di-un-dominio-stream-compromesso

Research from Jeremiah Fowler has revealed an exposed database containing 27,000 records. The database is associated with Vroom by YouX (formerly Drive IQ), an Australian fintech organization facilitating automotive financing. This was a publicly exposed Amazon S3 database without password protection or encryption. 

Additionally, Fowler discovered an internal screenshot containing information of a MongoDB storage instance containing 3.2 million documents. The researcher did not review the MongoDB, so it is currently unknown if those records were accessible. Nevertheless, the research emphasizes the potential risks of exposing database names, file storage locations, and systems designed for internal use, as it could possibly offer malicious actors a backdoor or new attack vector. 

The types of data exposed include: 

• Driver’s license 
• Bank statements (including account numbers and partial credit card numbers) 
• Employment statements 
• Medicaid cards

At this time, it is unknown if the Vroom by YouX database was accessed by anyone else before Fowler discovered it. Fowler informed the organization of the exposure and received the following response: “We’ve identified and resolved the issue causing this vulnerability so thank you for bringing it to our attention. A post incident review will be conducted shortly so we can determine the communication plan and process improvements required.”

https://www.securitymagazine.com/articles/101503-27-000-records-in-australian-fintech-database-were-exposed

The resulting dataset, which reflected a distribution of attack categories similar to the complete dataset, showed an attack success rate of 65 percent and 82 percent against Gemini 1.5 Flash and Gemini 1.0 Pro, respectively. By comparison, attack baseline success rates were 28 percent and 43 percent. Success rates for ablation, where only effects of the fine-tuning procedure are removed, were 44 percent (1.5 Flash) and 61 percent (1.0 Pro).

While Google is in the process of deprecating Gemini 1.0 Pro, the researchers found that attacks against one Gemini model easily transfer to others—in this case, Gemini 1.5 Flash.

“If you compute the attack for one Gemini model and simply try it directly on another Gemini model, it will work with high probability, Fernandes said. “This is an interesting and useful effect for an attacker.”

Another interesting insight from the paper: The Fun-tuning attack against Gemini 1.5 Flash “resulted in a steep incline shortly after iterations 0, 15, and 30 and evidently benefits from restarts. The ablation method’s improvements per iteration are less pronounced.” In other words, with each iteration, Fun-Tuning steadily provided improvements.

The ablation, on the other hand, “stumbles in the dark and only makes random, unguided guesses, which sometimes partially succeed but do not provide the same iterative improvement,” Labunets said. This behavior also means that most gains from Fun-Tuning come in the first five to 10 iterations. “We take advantage of that by ‘restarting’ the algorithm, letting it find a new path which could drive the attack success slightly better than the previous ‘path.'” he added.

Not all Fun-Tuning-generated prompt injections performed equally well. Two prompt injections—one attempting to steal passwords through a phishing site and another attempting to mislead the model about the input of Python code—both had success rates of below 50 percent. The researchers hypothesize that the added training Gemini has received in resisting phishing attacks may be at play in the first example. In the second example, only Gemini 1.5 Flash had a success rate below 50 percent, suggesting that this newer model is “significantly better at code analysis,” the researchers said.

https://arstechnica.com/security/2025/03/gemini-hackers-can-deliver-more-potent-attacks-with-a-helping-hand-from-gemini/

Mar 28, 2025 Stefano Silvestri Hacking, In evidenza, Malware, Minacce, News, Phishing, Tecnologia, Vulnerabilità 0

---

RedCurl, gruppo hacker russo attivo almeno dal 2018 e noto per le sue operazioni di spionaggio industriale, ha compiuto una svolta significativa nel proprio modus operandi.

Per la prima volta, infatti, è stato collegato a una campagna ransomware, segnando un cambio di passo che potrebbe indicare una nuova strategia del collettivo.

A lanciare l’allarme è Bitdefender, che ha rilevato l’uso di un nuovo ransomware mai osservato prima, denominato QWCrypt.

L’infezione scoperta è il risultato di una catena di attacco complessa, fondata su tecniche consolidate di ingegneria sociale e sul caricamento occulto di codice malevolo tramite strumenti legittimi.

Una catena d’infezione a più stadi

Il vettore iniziale dell’attacco è rappresentato da file immagine ISO mascherati da curriculum vitae, diffusi attraverso campagne di phishing.

All’interno del file ISO si nasconde un eseguibile Adobe legittimo, “ADNotificationManager.exe”, accompagnato da una DLL malevola (“netutils.dll”), che viene caricata attraverso la tecnica del DLL side-loading.

Dopo l’esecuzione, viene aperta una pagina di login reale di Indeed, una piattaforma online per la ricerca di lavoro. Questa tecnica è usata come diversivo per distrarre la vittima e lasciare agire il malware in background.

La DLL malevola netutils.dll in pratica funge da loader: il suo compito è scaricare una backdoor che consente all’attaccante di controllare da remoto il sistema compromesso.

Per mantenere la persistenza nel sistema, e quindi per ‘sopravvivere’ a un riavvio del computer o alla chiusura forzata dei processi, la DLL crea una scheduled task, ossia un’attività pianificata che forza l’esecuzione automatica del malware a intervalli regolari o all’avvio del sistema operativo.

Infine, per eseguire il payload finale e continuare a evitare il rilevamento da parte dei software di sicurezza, RedCurl sfrutta il Program Compatibility Assistant di Windows (pcalua.exe).

Questo componente, del tutto legittimo, viene utilizzato per lanciare il malware mascherandolo da processo di sistema, in una tecnica nota come LOLBins (Living Off the Land Binaries), che sfrutta strumenti nativi del sistema operativo per scopi malevoli.

L’impianto appena descritto consente movimenti laterali all’interno della rete, raccolta di informazioni e progressiva escalation dei privilegi.

Obiettivo: le infrastrutture virtualizzate

La novità più rilevante, dicevamo, è che una delle operazioni condotte da RedCurl ha portato per la prima volta al rilascio di ransomware.

L’obiettivo però non sono i classici endpoint ma le macchine virtuali ospitate sugli hypervisor, ossia i software che permettono di crearle e gestirle sugli hardware fisici. RedCurl le rende inaccessibili tramite cifratura, compromettendo così tutti i servizi erogati.

“Questo tipo di attacco mirato può essere interpretato come un tentativo di causare il massimo danno con il minimo sforzo”, ha dichiarato Martin Zugec, direttore delle soluzioni tecniche di Bitdefender. “Criptando le macchine virtuali e rendendole non avviabili, RedCurl disabilita di fatto l’intera infrastruttura virtualizzata”.

Il ransomware esegue una ricognizione del sistema prima di attivare la cifratura e utilizza la tecnica nota come bring your own vulnerable driver (BYOVD) per disattivare i software di protezione degli endpoint.

La nota di riscatto lasciata dopo l’attacco sembra ispirata a quelle già viste nei ransomware LockBit, HardBit e Mimic, ma resta incerta la reale finalità dell’estorsione.

Un’evoluzione che apre interrogativi

L’emergere di QWCrypt e la sua attribuzione a RedCurl rappresentano un possibile segnale di ridefinizione degli obiettivi da parte del gruppo.

Storicamente impegnato in campagne di spionaggio mirate a raccogliere informazioni sensibili per conto terzi, RedCurl sembra ora esplorare anche la via del danno diretto e dell’estorsione.

Secondo MarinZugec, il riutilizzo di frammenti testuali da altre campagne ransomware “solleva interrogativi sull’origine e sulle reali motivazioni del gruppo RedCurl”.

Inoltre, l’assenza di un sito di leak o di elementi riconducibili a estorsioni pubbliche suggerisce che la componente ransomware possa essere, almeno in parte, una distrazione tattica.

Resta da capire se si tratti di un’eccezione o dell’inizio di una nuova fase operativa, in cui gruppi tradizionalmente legati all’information gathering si spostano verso modelli di attacco più distruttivi e redditizi.

---

---

---

https://www.securityinfo.it/2025/03/28/redcurl-passa-al-ransomware-scoperto-il-primo-attacco-con-qwcrypt/?utm_source=rss&utm_medium=rss&utm_campaign=redcurl-passa-al-ransomware-scoperto-il-primo-attacco-con-qwcrypt

In un’epoca in cui la complessità e la velocità delle minacce informatiche superano la capacità di risposta umana, il RAG Agentico introduce un cambio di paradigma: sistemi capaci non solo di informare, ma di agire. Questo articolo accompagna il lettore in un viaggio tra architetture emergenti, applicazioni reali e scenari futuri in cui l’intelligenza artificiale agentica diventa protagonista di una cybersecurity più proattiva, autonoma e adattiva.

Introduzione

Nel panorama in rapida evoluzione della sicurezza informatica, l’implementazione di sistemi di intelligenza artificiale avanzati rappresenta una delle frontiere più promettenti per contrastare minacce sempre più sofisticate. In particolare, l’integrazione di modelli di Retrieval-Augmented Generation (RAG) con capacità agentiche sta emergendo come un paradigma rivoluzionario che supera i limiti delle tradizionali architetture di sicurezza.

Secondo recenti studi, il mercato globale dell’intelligenza artificiale nella cybersecurity ha raggiunto un valore di 24,8 miliardi di dollari nel 2024 e si prevede che crescerà fino a 29,6 miliardi di dollari nel 2025, superando i 146,5 miliardi di dollari entro il 2034, con l’IA agentica destinata a occupare una quota crescente di questo mercato. Questo articolo esplora l’evoluzione del RAG Agentico (Agentic RAG) nel contesto della cybersecurity, analizzando le sue applicazioni pratiche, i benefici rispetto ai sistemi convenzionali e le prospettive future per la protezione proattiva delle infrastrutture digitali.

Fondamenti del RAG Agentico

Il RAG Agentico rappresenta una significativa evoluzione rispetto ai tradizionali sistemi di Retrieval-Augmented Generation. Il RAG convenzionale combina le capacità generative dei Large Language Models (LLM) con meccanismi di recupero esterni per migliorare la rilevanza e la tempestività delle risposte. Tuttavia, questi sistemi sono limitati da flussi di lavoro lineari e statici che ne riducono l’efficacia in scenari complessi di sicurezza informatica.

L’introduzione di agenti autonomi nel processo RAG trasforma radicalmente questo paradigma. Il RAG Agentico incorpora pattern di design agentici fondamentali – riflessione (reflection), pianificazione (planning), utilizzo di strumenti (tool use) e collaborazione multi-agente (multi-agent collaboration) – per gestire dinamicamente le strategie di recupero, raffinare iterativamente la comprensione contestuale e adattare i flussi di lavoro attraverso strutture operative chiaramente definite.

A differenza dei sistemi RAG tradizionali, dove il recupero delle informazioni e la generazione seguono percorsi predeterminati, il RAG Agentico introduce capacità di presa di decisioni autonome. Gli agenti possono valutare indipendentemente la complessità delle query, ottimizzare le strategie di recupero e orchestrare dinamicamente i flussi di lavoro per affrontare scenari di sicurezza in tempo reale. Questi agenti non sono limitati ai semplici sistemi di domanda e risposta, ma possono interagire proattivamente con molteplici fonti di dati, come database di vulnerabilità, knowledge graph, sistemi di logging e intelligence sulle minacce in tempo reale.

Architetture di RAG Agentico per la Sicurezza Informatica

Nel contesto della sicurezza informatica, le architetture di RAG Agentico possono essere classificate in diverse categorie, ciascuna con caratteristiche e applicazioni specifiche:

Sistema a Singolo Agente

Il sistema RAG Agentico a singolo agente (Single-Agent Agentic RAG) funge da strumento centralizzato di supporto decisionale in cui un unico agente gestisce il recupero, l’instradamento e l’integrazione delle informazioni. Questa architettura semplifica il sistema consolidando questi compiti in un agente unificato, risultando particolarmente efficace per configurazioni con un numero limitato di strumenti o fonti di dati.

In un contesto di sicurezza, questo tipo di sistema può analizzare i log di accesso di un’applicazione, identificare modelli di attacco, recuperare informazioni pertinenti da una knowledge base di best practice di sicurezza e generare raccomandazioni per affrontare le vulnerabilità rilevate. Un vantaggio significativo è la capacità dell’agente di comprendere il contesto organizzativo, adattando le sue raccomandazioni alle specifiche politiche di sicurezza dell’organizzazione.

Il flusso di lavoro tipico comprende:

1. Ricezione e valutazione della query;
2. Selezione delle fonti di conoscenza appropriate (database strutturati, ricerca semantica, ricerca web);
3. Integrazione dei dati e sintesi tramite LLM;
4. Generazione di una risposta completa e contestualmente rilevante.

Sistema Multi-Agente

L’architettura RAG Agentica multi-agente (Multi-Agent Agentic RAG) rappresenta un’evoluzione modulare e scalabile dei sistemi a singolo agente, progettata per gestire flussi di lavoro complessi e diversi tipi di query sfruttando più agenti specializzati. Invece di fare affidamento su un singolo agente per gestire tutte le attività, questo sistema distribuisce le responsabilità su più agenti, ciascuno ottimizzato per un ruolo specifico o una fonte di dati.

Nel contesto della sicurezza informatica, un sistema multi-agente potrebbe comprendere:

• Un agente di intelligence sulle minacce che raccoglie informazioni da varie fonti come NVD (National Vulnerability Database) ed ExploitDB;
• Un agente di triage che funge da router, indirizzando le informazioni all’agente appropriato;
• Un agente di gestione delle vulnerabilità che valuta l’impatto e la probabilità di una vulnerabilità;
• Un agente offensivo che verifica se una vulnerabilità può essere sfruttata;
• Un agente di remediation che implementa le contromisure necessarie.

Questa architettura è particolarmente efficace per le organizzazioni con infrastrutture complesse e requisiti di sicurezza diversificati, permettendo operazioni parallele che migliorano significativamente l’efficienza e la velocità di risposta.

RAG Agentico Correttivo

Il RAG Agentico Correttivo (Corrective RAG) introduce meccanismi per autocorreggere i risultati del recupero, migliorando l’utilizzo dei documenti e la qualità della generazione delle risposte. Incorporando agenti intelligenti nel flusso di lavoro, il RAG Correttivo garantisce il raffinamento iterativo dei documenti contestuali e delle risposte, minimizzando gli errori e massimizzando la rilevanza.

Per un team di sicurezza, questa architettura può essere invaluabile per analizzare grandi volumi di log di sicurezza, identificare falsi positivi e concentrarsi sulle minacce reali. Il sistema valuta dinamicamente la rilevanza dei documenti recuperati, esegue azioni correttive quando i documenti sono al di sotto della soglia di rilevanza e affina le query per migliorare la precisione della risposta generata.

Il sistema è costruito su cinque agenti chiave:

1. Agente di recupero del contesto: recupera documenti iniziali dal database vettoriale;
2. Agente di valutazione della rilevanza: valuta i documenti recuperati e segnala quelli irrilevanti;
3. Agente di raffinamento delle query: riscrive le query per migliorare i risultati;
4. Agente di recupero di conoscenza esterna: esegue ricerche web o accede a fonti alternative quando necessario;
5. Agente di sintesi della risposta: sintetizza tutte le informazioni validate in una risposta coerente.

RAG Agentico Adattivo

Il RAG Agentico Adattivo (Adaptive RAG) migliora la flessibilità e l’efficienza dei modelli linguistici di grandi dimensioni regolando dinamicamente le strategie di gestione delle query in base alla loro complessità. A differenza dei flussi di lavoro di recupero statici, il RAG Adattivo impiega un classificatore per valutare la complessità della query e determinare l’approccio più appropriato, dal recupero in un unico passaggio al ragionamento in più passaggi, o persino bypassando il recupero per query semplici.

Questa architettura è particolarmente utile nei sistemi di rilevamento e risposta alle minacce, dove le query possono variare da semplici verifiche di stati a complesse analisi forensi. Il sistema può allocare in modo efficiente le risorse, dedicando più potenza di elaborazione alle indagini complesse mentre gestisce rapidamente le richieste di routine.

Il principio fondamentale del RAG Adattivo sta nella sua capacità di adattare dinamicamente le strategie di recupero:

• Query semplici: utilizza la conoscenza preesistente dell’LLM senza recupero aggiuntivo;
• Query moderate: esegue un recupero in un singolo passaggio per ottenere il contesto minimo necessario;
• Query complesse: attiva un processo di recupero in più passaggi con raffinamento iterativo.

RAG Agentico Basato su Grafi

Il RAG Agentico Basato su Grafi (Graph-Based Agentic RAG) integra database di conoscenza basati su grafi con il recupero di documenti non strutturati. Combinando fonti di dati strutturati e non strutturati, questo framework migliora i sistemi RAG con un migliore ragionamento e una maggiore precisione di recupero. Impiega banche di recuperatori modulari, interazione dinamica degli agenti e cicli di feedback per garantire output di alta qualità.

Nel contesto della cybersecurity, questa architettura eccelle nella mappatura di complesse relazioni tra vulnerabilità, asset e controlli di sicurezza. Ad esempio, può tracciare le connessioni tra una specifica vulnerabilità (CVE), le debolezze software associate (CWE), i modelli di attacco potenziali (CAPEC) e le tecniche di attacco specifiche (ATT&CK), fornendo una visione olistica del panorama delle minacce.

Due implementazioni significative di questo approccio sono:

1. Agent-G: un framework agentico che integra conoscenze basate su grafi con recupero di documenti non strutturati. Agent-G utilizza un’architettura modulare con una banca di recuperatori, un modulo critico per la valutazione dei dati recuperati, e interazioni dinamiche tra agenti per garantire un recupero e una sintesi coesivi.
2. GeAR (Graph-Enhanced Agent for RAG): un’architettura che incorpora tecniche di espansione del grafo e un framework basato su agenti per migliorare i tradizionali recuperatori. GeAR permette una traversata più profonda delle relazioni tra entità cyber, facilitando l’analisi di query multi-hop che richiedono ragionamento su più informazioni interconnesse.

Caso di studio: Agente di sicurezza difensivo con RAG

Un esempio concreto dell’applicazione del RAG Agentico nella sicurezza informatica è lo sviluppo di un agente di sicurezza difensivo. Questo agente è progettato per analizzare i log di un server applicativo, identificare modelli di attacco e consultare una knowledge base interna di best practice di sicurezza contro particolari classi di vulnerabilità. Infine, fornisce raccomandazioni su come affrontare le vulnerabilità rilevate.

Il flusso di lavoro dell’agente segue questi passaggi specifici:

• Analisi dei Log: L’agente esamina i file di log del server applicativo per identificare potenziali indicatori di compromissione o modelli di attacco. È in grado di riconoscere tentativi falliti di accesso, richieste sospette e altre anomalie che potrebbero indicare un’attività malevola.
• Consultazione della knowledge base: Per ogni modello di attacco identificato, l’agente consulta una knowledge base interna di best practice di sicurezza. Questa knowledge base è implementata come un database vettoriale che memorizza le misure di sicurezza rilevanti per varie classi di vulnerabilità.
• Generazione di raccomandazioni: Basandosi sulle informazioni recuperate dalla knowledge base, l’agente genera raccomandazioni specifiche su come affrontare le vulnerabilità identificate. Queste raccomandazioni possono includere modifiche alla configurazione del server, aggiornamenti del codice o altre misure di mitigazione.

Un aspetto significativo di questo agente è la sua consapevolezza organizzativa; è consapevole delle best practice di sicurezza dell’organizzazione e può formulare raccomandazioni di conseguenza. Questa contestualizzazione è fondamentale per garantire che le soluzioni proposte siano allineate con le politiche e i vincoli specifici dell’organizzazione.

Vantaggi del RAG Agentico nella Sicurezza Informatica

L’implementazione del RAG Agentico nei sistemi di sicurezza informatica offre numerosi vantaggi rispetto ai tradizionali approcci RAG:

Flessibilità migliorata

I sistemi RAG Agentici possono estrarre dati da più knowledge base esterne e consentire l’uso di strumenti esterni. Le pipeline RAG standard collegano un LLM a un singolo dataset esterno, come indicato dal Pacific Northwest National Laboratory (PNNL), limitando la loro capacità di integrare diverse fonti di informazioni sulla sicurezza. I sistemi agentici possono accedere e correlare dati da diverse fonti, come database di vulnerabilità, log di sistema e intelligence sulle minacce, fornendo una visione più completa del panorama delle minacce.

Adattabilità

Mentre i sistemi RAG tradizionali sono strumenti reattivi di recupero dati che trovano informazioni rilevanti in risposta a query specifiche, i sistemi RAG Agentici possono adattarsi a contesti mutevoli e accedere dinamicamente a fonti di dati pertinenti. Questa capacità è cruciale nel panorama della sicurezza in rapida evoluzione, dove le minacce emergenti richiedono un adattamento rapido e una risposta contestuale. Secondo studi condotti dalla Gartner, l’IA agentica migliorerà l’efficienza dei Security Operations Center (SOC) del 40% entro il 2026 rispetto al 2024, con un conseguente spostamento dei ruoli SOC verso lo sviluppo, la manutenzione e la sicurezza dell’IA.

Precisione

I sistemi RAG tradizionali non validano né ottimizzano i propri risultati, richiedendo l’intervento umano per discernere se il sistema sta trovando i dati giusti. Al contrario, gli agenti AI possono iterare su processi precedenti per ottimizzare i risultati nel tempo, migliorando continuamente la precisione della rilevazione delle minacce e delle raccomandazioni di risposta. Ad esempio, CrowdStrike ha riportato che il suo sistema Charlotte AI Detection Triage, lanciato nel febbraio 2025, offre un’accuratezza superiore al 98% nel triage delle rilevazioni di sicurezza, eliminando più di 40 ore di lavoro manuale a settimana.

Scalabilità

Con reti di agenti RAG che lavorano insieme, attingendo a più fonti di dati esterne e utilizzando capacità di chiamata di strumenti e pianificazione, il RAG Agentico offre una maggiore scalabilità. Gli sviluppatori possono costruire sistemi RAG flessibili e scalabili in grado di gestire una vasta gamma di query di sicurezza, dall’analisi dei log di routine all’indagine di incidenti complessi. Secondo quanto riportato da ReliaQuest, il loro agente AI autonomo per le operazioni di sicurezza automatizza il 98% degli alert di sicurezza e riduce il tempo di contenimento delle minacce a meno di cinque minuti.

Multimodalità

I sistemi RAG Agentici beneficiano dei recenti progressi nei LLM multimodali per lavorare con una gamma più ampia di tipi di dati, come immagini e file audio. Questa capacità è particolarmente preziosa nell’analisi della sicurezza, dove le minacce possono manifestarsi in diverse forme di dati, dalle immagini che contengono codice malevolo nascosto ai file audio che potrebbero essere utilizzati in attacchi di deepfake.

Efficienza operativa

Secondo i dati forniti da Darktrace, il loro sistema RAG agentico riduce i tempi di triage del 90%, consentendo ai team di sicurezza di concentrarsi su attività più strategiche. Questo miglioramento dell’efficienza operativa è particolarmente importante alla luce della carenza globale di quasi 4 milioni di professionisti della cybersecurity, come riportato dal World Economic Forum.

Soluzioni di RAG Agentico per la Cybersecurity: casi concreti

Diverse aziende di cybersecurity stanno già offrendo soluzioni di RAG agentico per migliorare l’efficienza e rafforzare la sicurezza. Ecco alcuni esempi significativi:

CyRAG e GraphCyRAG

Il Pacific Northwest National Laboratory (PNNL) ha sviluppato due sistemi RAG distinti per la cybersecurity: CyRAG e GraphCyRAG. CyRAG è progettato per gestire dati strutturati da database di cybersecurity come CVE e CWE, consentendo agli utenti di accedere a informazioni dettagliate su vulnerabilità e debolezze specifiche. GraphCyRAG, invece, sfrutta dati basati su grafo da Neo4j, esplorando le complesse relazioni tra vulnerabilità, debolezze, modelli di attacco e attacchi conosciuti. Attraverso il recupero di dati in tempo reale e la generazione contestuale, questi sistemi offrono insight più profondi e intelligenza azionabile, migliorando significativamente il modo in cui i dati di cybersecurity vengono accessiti e utilizzati per la mitigazione efficace delle minacce.

Piattaforma GreyMatter di ReliaQuest

ReliaQuest ha lanciato nel settembre 2024 un agente di sicurezza AI autonomo che elabora gli alert di sicurezza 20 volte più velocemente dei metodi tradizionali, migliorando al contempo la precisione del rilevamento delle minacce del 30%. L’agente, addestrato su oltre un decennio di dati di risposta agli incidenti, gestisce autonomamente i compiti di sicurezza di livello 1 e 2, analizzando gli alert ed eseguendo le azioni necessarie, utilizzando dati in tempo reale specifici per il cliente in un ambiente sicuro e privato per eliminare le allucinazioni dell’IA.

CrowdStrike Falcon Agent

L’agente Falcon di CrowdStrike è progettato per integrare varie funzionalità avanzate di protezione degli endpoint, operando con un’architettura snella e leggera inferiore a 20 MB. La piattaforma, guidata dall’IA e dal CrowdStrike Security Cloud, monitora indicatori di attacco, intelligence sulle minacce e dati di telemetria per fornire un’identificazione accurata delle minacce, protezione e remediation automatizzate, caccia avanzata alle minacce e prioritizzazione delle vulnerabilità.

“Digital Employee” Alex di Twine

Twine, una startup di cybersecurity con sede a Tel Aviv, mira ad affrontare la carenza di talenti sviluppando agenti IA come Alex, il suo primo “dipendente digitale”, specializzato in gestione delle identità e degli accessi (IAM). In questo ruolo, Alex svolge il compito di identificare vulnerabilità e adottare misure proattive per bloccare accessi non autorizzati, riducendo il carico di lavoro per i team IT e di cybersecurity.

Darktrace / ENDPOINT

Utilizzando l’IA agentica, Darktrace monitora, rileva e mitiga autonomamente i potenziali rischi informatici mentre si verificano, garantendo un apprendimento e una protezione continui. Darktrace / ENDPOINT utilizza agenti leggeri per analizzare i dati provenienti da ogni pacchetto e connessione di rete per scoprire attività insolite in tempo reale. L’IA auto-apprendente viene distribuita localmente, addestrata esclusivamente sui dati aziendali senza richiedere una connessione cloud, fornendo risultati di sicurezza su misura mantenendo la privacy.

Limiti e considerazioni

Nonostante i suoi numerosi vantaggi, il RAG Agentico nella sicurezza informatica presenta anche alcune limitazioni e considerazioni:

Complessità di coordinamento

Gestire la comunicazione e la delega dei compiti tra gli agenti nei sistemi multi-agente richiede meccanismi di orchestrazione sofisticati. Questa complessità può portare a sfide di implementazione e potenziali fallimenti di coordinamento che potrebbero compromettere l’efficacia del sistema di sicurezza. Secondo un rapporto di Gartner, le aziende devono gestire centinaia o migliaia di agenti in ambienti in rapido cambiamento, il che aumenta significativamente la complessità operativa.

Overhead computazionale

L’elaborazione parallela di più agenti può aumentare significativamente l’utilizzo delle risorse. Questa intensità computazionale può rappresentare una sfida per le organizzazioni con risorse limitate o in scenari dove è richiesta una risposta in tempo reale alle minacce. Come evidenziato da Darktrace, gli agenti possono consumare CPU, memoria e risorse di rete, potenzialmente impattando le prestazioni, in particolare in ambienti con carichi di lavoro elevati o risorse limitate.

Integrazione dei dati

Sintetizzare gli output da diverse fonti in una risposta coerente non è un compito banale e richiede capacità LLM avanzate. Nel contesto della sicurezza, dove l’accuratezza è fondamentale, le incoerenze nell’integrazione dei dati potrebbero portare a falsi positivi o, peggio, a falsi negativi nella rilevazione delle minacce. Il fenomeno delle “allucinazioni AI” rimane una preoccupazione critica, anche se i sistemi RAG agentici sono progettati per mitigare questo rischio attingendo a fonti di dati verificate.

Vulnerabilità di sicurezza nel RAG

La complessità dei sistemi RAG introduce nuove vulnerabilità specifiche. Ad esempio, il RAG si affida a componenti multipli, tra cui piattaforme di hosting per LLM, librerie open-source e database vettoriali, ciascuno con potenziali vulnerabilità. Ricerche hanno individuato numerose CVE non patchate in piattaforme come Ollama e server mal configurati che eseguono llama.cpp e ChromaDB, esponendo migliaia di LLM a potenziali exploit. Poiché l’IA agentica condivide molti componenti con il RAG, affronta rischi simili, inclusi furto di dati, manipolazione del servizio e sabotaggio.

Minacce emergenti: avvelenamento dei dati e prompt injection

Le tecniche avanzate di attacco come l’avvelenamento dei dati (data poisoning) e l’iniezione di prompt (prompt injection) rappresentano minacce significative per i sistemi RAG agentici. I ricercatori hanno dimostrato che anche un attaccante con budget limitato potrebbe realisticamente avvelenare lo 0,01% dei dataset LAION-400M o COYO-700M nel 2023 per soli 60 dollari. In modo simile, gli attaccanti potrebbero utilizzare tecniche di iniezione di prompt per manipolare gli agenti IA e indurli a comportamenti non intenzionali, come l’approvazione di transazioni fraudolente nel contesto dell’e-commerce.

Framework di gestione del rischio nell’IA Agentica

La gestione efficace del rischio nei sistemi RAG agentici richiede un approccio strutturato. Un Framework di Gestione del Rischio (Risk Management Framework) sottolinea l’idea che la cybersecurity riguardi la gestione efficace dei rischi piuttosto che l’eliminazione completa delle minacce. Gli elementi chiave di questo framework nel contesto dell’IA agentica includono:

Minaccia (Threat)

Qualsiasi potenziale rischio che potrebbe compromettere la sicurezza dei sistemi, dei dati o della rete di un’organizzazione quando è coinvolta l’IA agentica. Le minacce possono essere analizzate esaminando la superficie di attacco, che si espande significativamente con l’IA agentica. A differenza dei modelli AI standard, dove le minacce sono limitate agli input, all’elaborazione, agli output e alle vulnerabilità del software, gli agenti AI espandono la superficie di attacco per includere l’intera catena di interazioni che iniziano, molte delle quali rimangono invisibili agli operatori umani o di sistema.

Vulnerabilità (Vulnerability)

Il grado in cui un’organizzazione è suscettibile ai danni derivanti da attacchi informatici. La vulnerabilità ha due dimensioni: oggettiva e soggettiva. La vulnerabilità oggettiva si riferisce a fattori politici, sociali, economici e demografici che determinano la suscettibilità agli attacchi informatici, mentre la vulnerabilità soggettiva riguarda la percezione del rischio da parte di un’entità. L’uso negligente dei sistemi di IA, come riportato dalle aziende di cybersecurity, può portare a una percezione errata del rischio.

Impatto Potenziale (Potential Impact)

Il possibile impatto o danno che può verificarsi quando una vulnerabilità viene sfruttata da una minaccia. L’impatto degli attacchi informatici può includere furto di identità, danni alla reputazione, perdite finanziarie e potenziali danni fisici. Ad esempio, assistenti AI compromessi potrebbero esporre dati organizzativi privati, che potrebbero poi essere sfruttati per sofisticati attacchi di social engineering e phishing. L’impatto di questi rischi è amplificato dal fatto che gli agenti AI elaborano grandi volumi di dati personali e possono avere accesso a sistemi critici.

Verso un’architettura di Sicurezza Proattiva

Il futuro del RAG Agentico nella sicurezza informatica si sta muovendo verso un’architettura di sicurezza più proattiva e integrata. Consideriamo uno scenario in cui un’organizzazione ha dispiegato nel suo ambiente molteplici agenti di sicurezza AI:

• Non appena viene rilasciata una nuova vulnerabilità zero-day o una CVE, un agente di intelligence sulle minacce raccoglie tutte le informazioni rilevanti da varie fonti e fornisce una visione aggregata all’agente di triage.
• L’agente di triage, che funge da router, passa le informazioni sulla vulnerabilità a un agente di gestione delle vulnerabilità per comprendere l’impatto e la probabilità di questa vulnerabilità sull’organizzazione.
• L’agente di gestione delle vulnerabilità potrebbe interagire con molteplici strumenti e sistemi all’interno dell’organizzazione per essere consapevole degli obiettivi di business e della propensione al rischio. Potrebbe anche invocare un agente offensivo per verificare se la vulnerabilità può essere sfruttata.
• In base all’analisi, l’agente di triage prende una decisione se mitigare/rimediare alla vulnerabilità o accettare il rischio. Questa decisione potrebbe essere delegata a un essere umano o a un agente specializzato di valutazione del rischio.
• Se la decisione è di risolvere la vulnerabilità, l’agente di triage passa tutte le informazioni a un agente di remediation che ha accesso alla knowledge base interna di best practice di sicurezza e agli strumenti necessari per implementare le soluzioni.

Questo approccio integrato consente una risposta più rapida e coordinata alle minacce emergenti, riducendo il carico cognitivo sui professionisti della sicurezza umani e migliorando l’efficacia complessiva della postura di sicurezza dell’organizzazione.

Mitigazione dei rischi e rafforzamento della governance

Per mitigare i rischi associati all’integrazione dell’IA agentica, è essenziale implementare strategie di governance robuste. Alcuni approcci chiave includono:

Governance e limiti dell’autonomia

I leader aziendali e IT proattivi dovrebbero adottare l’IA agentica stabilendo al contempo chiari guardrail, applicando rigorose politiche di accesso ai dati e promuovendo le migliori pratiche organizzative. Un approccio chiave per proteggere l’automazione è limitare il livello di autonomia di un agente in base al rischio. Se un agente non può essere completamente valutato per vulnerabilità o affidabilità, le sue capacità dovrebbero essere limitate fino a quando non vengono implementate misure di sicurezza più forti.

Formazione e consapevolezza

È essenziale migliorare la consapevolezza della sicurezza attraverso strumenti di formazione dinamici adattati ai livelli di rischio. Le organizzazioni dovrebbero anche educare i dipendenti sui rischi del social engineering e promuovere una cultura della cybersecurity. Per mitigare le potenziali minacce degli agenti AI, i leader IT dovrebbero educare le loro organizzazioni sui rischi degli agenti AI, rilevare e segnalare attività anomale e mappare tutte le interazioni degli agenti AI per garantire la conformità con le politiche aziendali.

Sicurezza a più livelli

Un approccio di sicurezza a più livelli, costituito da sistemi predittivi di IA agentica generativa, è essenziale per proteggersi contro le potenziali minacce informatiche. I fornitori di IA generativa come OpenAI, Anthropic e Google implementano salvaguardie dei contenuti, mentre le aziende aggiungono i propri gateway e protezioni AI. Il software agentico richiede guardrail interni, filtraggio dei prompt e monitoraggio delle risposte. Man mano che emergono sistemi multi-agente, saranno necessarie ulteriori salvaguardie per gestire le interazioni tra agenti.

Riflessione finale

Il RAG Agentico rappresenta un significativo avanzamento nell’arsenale di strumenti disponibili per i professionisti della sicurezza informatica. Integrando capacità autonome di presa di decisioni, ragionamento iterativo e flussi di lavoro collaborativi nel tradizionale framework RAG, questi sistemi possono affrontare minacce di sicurezza complesse con una precisione e un’adattabilità senza precedenti.

I casi di studio presentati, dalle piattaforme GreyMatter di ReliaQuest al Falcon Agent di CrowdStrike, dimostrano come l’IA agentica stia già trasformando le operazioni di sicurezza nelle organizzazioni reali. Come evidenziato dai dati del Pacific Northwest National Laboratory e da altre fonti, l’integrazione di RAG con knowledge graph di cybersecurity rappresenta un significativo passo avanti nell’intelligence delle minacce, consentendo decisioni più informate e strategie di difesa più forti.

Mentre la tecnologia continua a maturare, possiamo anticipare lo sviluppo di ecosistemi sempre più sofisticati di agenti di sicurezza AI che lavorano in concerto per difendere proattivamente le infrastrutture digitali. I professionisti della sicurezza dovrebbero iniziare a esplorare le potenzialità di questi sistemi, comprendendo sia i loro punti di forza che le loro limitazioni, e considerare come possano essere integrati nelle loro strategie di sicurezza esistenti.

Fondamentale sarà l’adozione di un approccio equilibrato che riconosca sia il potenziale trasformativo del RAG agentico sia i rischi inerenti alla sua implementazione. Secondo gli studi del PNNL, l’integrazione dei knowledge graph con il RAG ha già dimostrato di migliorare significativamente sia l’accuratezza che la profondità dell’analisi delle minacce. Tuttavia, come evidenziato nell’articolo di Kshetri, questa tecnologia introduce anche nuove vulnerabilità, espandendo la superficie di attacco e creando potenziali vettori per il data poisoning e l’iniezione di prompt.

Per massimizzare i benefici minimizzando i rischi, le organizzazioni dovrebbero implementare solidi framework di governance che definiscano chiaramente i limiti dell’autonomia degli agenti, stabiliscano protocolli di monitoraggio continuo e garantiscano la supervisione umana nei processi decisionali critici. Un approccio di sicurezza a più livelli, che combini guardrail tecnici, filtri di contenuto e monitoraggio delle interazioni, sarà essenziale per proteggere i sistemi RAG agentici da manipolazioni e abusi.

La formazione dei team di sicurezza è un altro aspetto cruciale. I professionisti devono essere preparati a lavorare in sinergia con questi sistemi, comprendendo come interpretare i loro output, quando fidarsi delle loro raccomandazioni e quando intervenire. Questo richiederà lo sviluppo di nuove competenze che integrino la conoscenza tradizionale della cybersecurity con una comprensione approfondita dei modelli AI e dei loro metodi di ragionamento.

In ultima analisi, il successo del RAG agentico nella sicurezza informatica dipenderà non solo dagli avanzamenti tecnologici ma anche dalla collaborazione uomo-macchina. Combinando l’intuizione e l’esperienza umana con la potenza di elaborazione e l’adattabilità degli agenti AI, le organizzazioni possono costruire difese più resilienti contro l’evoluzione continua del panorama delle minacce.

Con l’emergere di nuove minacce e tecniche di attacco, i sistemi di sicurezza basati su RAG agentico dovranno evolversi continuamente, apprendendo da ogni interazione e migliorando le loro capacità di rilevamento e risposta. Le organizzazioni che adotteranno un approccio proattivo a questa tecnologia, investendo nelle infrastrutture necessarie e nelle competenze del personale, saranno meglio posizionate per affrontare le sfide di sicurezza del futuro digitale.

Come dimostrato dalle implementazioni di aziende come ReliaQuest, CrowdStrike e Darktrace, l’integrazione dell’IA agentica nei sistemi di sicurezza sta già producendo risultati tangibili in termini di riduzione dei tempi di risposta, maggiore precisione nel rilevamento delle minacce e miglioramento dell’efficienza operativa. Questi casi di successo offrono una roadmap per l’adozione più ampia di queste tecnologie, evidenziando le best practice e gli approcci che hanno dimostrato la loro efficacia nel mondo reale.

Il futuro della sicurezza informatica sarà plasmato dalla nostra capacità di sfruttare il potenziale del RAG agentico mantenendo al contempo un controllo adeguato sui rischi associati. Con un’implementazione attenta e una gestione responsabile, queste tecnologie promettono di trasformare radicalmente il modo in cui proteggiamo le nostre infrastrutture digitali, rendendo possibile una difesa più proattiva, adattiva e resiliente contro un panorama di minacce in continua evoluzione.

https://www.ictsecuritymagazine.com/articoli/rag-agentico-sicurezza/

AI is transforming both Security Operations Centers (SOCs) and security as a whole. Yet with new opportunities come new risks. One of the biggest challenges in security today is how to manage AI’s inherent unpredictability, especially for complex tasks. In this article, we’ll take a closer look at the specific hurdles of using AI in security (specifically in your SOC), and how a modular, focused approach can mitigate these risks.  

The challenge of AI hallucinations in security  

It’s no secret that AI models do not always get things right. Sometimes, they generate false or misleading information known as hallucinations. In everyday settings, this might result in an AI chatbot giving a wrong historical fact or a navigation app suggesting a nonexistent road. While inconvenient, these mistakes are usually harmless. 

In security operations, the consequences of AI hallucinations are far more serious. A security analyst might ask an AI model to summarize an incident, only to receive an inaccurate or completely fabricated report. If teams rely on this faulty information, they could waste time chasing non-existent threats or, worse, fail to respond to actual ones.  

Studies show that AI hallucination rates can be significant, and the risk increases as tasks become more complex. A model might correctly classify simple security logs but struggle when analyzing more nuanced threats. This makes AI unreliable for advanced detection, investigation, and response workflows. What’s more, AI hallucinations can be difficult to spot. Unlike a human analyst who might show hesitation when unsure, AI confidently presents false outputs as fact. Less experienced analysts may not have the experience to recognize these errors, which can lead to poor decision-making.  

AI errors can also create broader trust issues, slowing the rollout of potentially game-changing AI-powered security tools. If security teams frequently encounter misleading or incorrect AI-driven insights, they will start to question whether the technology is helping or hurting. When trust in AI declines, teams may revert to slower, manual processes, negating the efficiency benefits AI was meant to provide.  

AI has clear benefits, but in security, even small mistakes can have major consequences. Instead of treating AI as a fully autonomous tool, organizations need a controlled, structured approach to ensure accuracy and reliability.  

The unique challenges of using AI in your SOC  

Integrating AI into an SOC presents challenges beyond general cybersecurity concerns. These environments operate in high-stakes conditions where real-time accuracy is critical. Unlike other areas of security where AI can assist with broad threat intelligence or user behavior analytics, SOC workflows require precise, context-aware decision-making. AI struggles when applied to complex investigations, where subtle threat indicators must be correlated across multiple data sources. If it misinterprets these signals, it can generate false positives or, worse, overlook genuine threats.  

Another challenge is that SOC teams rely on rapid response. Analysts often work under pressure, and AI-driven insights must be both accurate and actionable. If AI injects uncertainty or produces misleading outputs, it slows response times and creates operational friction. In a time of crisis, analysts could waste valuable minutes verifying questionable AI findings instead of addressing urgent threats.  

AI also needs to interact with an SOC’s existing security stack, which introduces significant integration challenges. Many teams use a mix of rule-based detection, machine learning models, and human-driven analysis. Ensuring that AI enhances these systems rather than disrupting them requires careful tuning, validation, and oversight. Without this balance, AI can add noise rather than clarity, making security teams less efficient rather than more effective.  

A controlled approach: Using AI as an enabler  

AI can be incredibly useful in security operations, but only when applied carefully. Through research and real-world testing, we’ve found that AI is most effective when used in a controlled, modular way. Instead of handing full tasks over to AI, it’s safer to break them into smaller, well-defined steps. This minimizes errors while preserving efficiency.  

For example, AI can assist in log normalization by identifying log types, but final categorization should rely on rule-based methods. This prevents AI from making unpredictable decisions that could compromise accuracy. Similarly, cross-model comparisons and focused prompting help reduce hallucinations by ensuring AI outputs align with established security logic. 

AI works best when it enhances, rather than replaces, existing security processes. Tasks that require absolute accuracy, such as incident correlation, should not be left to AI alone. Instead, AI should handle repetitive, low-risk elements while human analysts oversee critical decisions.  

This controlled approach allows teams to benefit from AI’s speed without falling victim to its flaws. By using AI selectively and verifying its outputs, organizations can ensure that automation remains an asset rather than a source of new risks.  

The bottom line  

AI is reshaping security operations, offering the ability to process vast amounts of data at unprecedented speeds. However, its inherent unpredictability can pose serious risks. Hallucinations, inaccurate outputs and over-reliance can undermine security efforts rather than enhance them. 

A smarter way forward is to use AI as a targeted enabler rather than a replacement for human expertise. By applying AI to specific, well-defined tasks (such as log normalization, anomaly detection or data correlation) organizations can leverage AI’s strengths without exposing themselves to undue risk. Even so, AI’s outputs should always be validated through structured workflows, ensuring that automation serves as a safeguard rather than a liability. 

Ultimately, the success of any tool (AI-powered tools included) depends on the success of implementation. A modular, controlled approach that blends efficiency with human judgment ensures that teams can work smarter and faster — without sacrificing accuracy. By maintaining oversight, refining AI applications, and continuously validating results, organizations can harness AI’s full potential while keeping risks firmly in check.  

https://www.securitymagazine.com/articles/101504-mitigating-the-hidden-risks-of-ai-in-security-and-socs

An investigation by CloudSEK’s XVigil platform has uncovered a breach against Oracle Cloud. Via a suspected, undisclosed vulnerability, this breach exfiltrated 6 million records. Around 140,000 tenants have been impacted by this breach due to exposed sensitive SSO and LDAP data. 

At this time, Oracle Cloud denies a breach occurred. 

Below, security leaders discuss the investigation and its implications. 

Security leaders weigh in 

Patrick Tiquet, Vice President, Security & Architecture at Keeper Security: 

The ongoing investigation into an alleged cyberattack on Oracle Cloud underscores key security risks that organizations must address, and highlights the critical need for timely patching and proactive security measures. 

Timely patching is essential — delayed updates can leave systems exposed to known vulnerabilities. This serves as a reminder for businesses to prioritize security updates, particularly for critical systems, to reduce the risk of exploitation. Organizations must stay up to date with resources like CISA’s Known Exposed Vulnerabilities catalog and NIST’s Cybersecurity Framework to ensure they are addressing the most current and serious risks. 

Organizations using cloud services must ensure strong password management policies, enforce least-privilege access and protect credentials with robust encryption. A zero-trust approach, where access is continuously verified, helps mitigate the risk of unauthorized access, even if credentials are compromised. A layered security model that includes Privileged Access Management (PAM), Multi-Factor-Authentication (MFA) and strong encryption is vital for minimizing the impact of a breach. Automated credential rotation using a PAM solution reduces exposure and strong access controls for privileged resources limit the potential damage if a cyberattack occurs.

Chad Cragle, CISO at Deepwatch:

Jake Williams raises a critical point. If there was no breach, how did a threat actor allegedly upload a file to the Oracle Cloud subdomain? This indicates unauthorized access, even if it wasn’t a full-scale compromise. Dismissing the incident without addressing this key detail raises more questions than answers. If Oracle wants to maintain credibility, they must clarify how the file ended up there, whether any security gaps were exploited, and why the subdomain was taken down.

Rom Carmel, Co-Founder and CEO at Apono:

By compromising what appears to be a significant number of keys and credentials, the attackers can potentially gain unauthorized access to many more systems and data.

This incident raises important questions about whether access to the server containing such sensitive resources was properly restricted — not just who had access, but also when that access was permitted. It also calls into question whether the affected resources had adequate access controls in place to enforce least privilege and limit access to defined, secure time windows.

As more resources move into the cloud, we need to shift our mindset for how we protect them without hindering productivity. This means embracing intelligent access control methodologies and the agility that automation can provide us to not only make our organizations more secure and resilient, but also enable the business to run faster.

Heath Renfrow, CISO and Co-Founder at Fenix24:

The situation involving Oracle Cloud and the claims made by the threat actor ‘rose87168’ underscores a persistent and growing challenge in cloud security: the exploitation of legacy systems and unpatched vulnerabilities. While Oracle has issued a denial of a breach affecting Oracle Cloud customers, the technical indicators shared — such as the apparent presence of outdated Oracle Fusion Middleware and the CVE-2021-35587 exploit vector — are consistent with how threat actors gain initial access and move laterally within cloud environments.

Regardless of Oracle’s position, the presence of a threat actor-uploaded file in the webroot of what appears to be an Oracle Cloud Infrastructure (OCI) login subdomain is deeply concerning. This detail, coupled with the public availability of sensitive data on forums, raises valid questions about the scope of compromise and whether customers with federated login configurations could be at risk.

This incident also highlights the importance of continuously monitoring third-party platforms, ensuring regular patching of middleware components, and validating federated identity infrastructure configurations. Supply chain and cloud identity are increasingly attractive attack surfaces, and it is vital that all organizations using shared cloud platforms apply a zero trust posture to identity and access management.

Those who were potentially impacted Oracle Cloud should immediately assess their federated SSO configurations, rotate any potentially exposed credentials or keys, and monitor for indicators of compromise associated with the published artifacts.

https://www.securitymagazine.com/articles/101500-6-million-records-allegedly-stolen-from-oracle-cloud

Mar 27, 2025 Redazione news Approfondimenti, In evidenza, News, RSS, Tecnologia, Tecnologia 0

---

Ogni nuova tecnologia porta con sé nuovi rischi. Nel caso dell’intelligenza artificiale, il settore della cyber security ha spesso concentrato l’attenzione sugli aspetti legati all’affinamento delle tecniche di phishing e sulla possibilità di realizzare più facilmente malware sempre più sofisticati. C’è però un aspetto che viene (troppo) poco considerato: il rischio di esposizione o esfiltrazione di informazioni sensibili legati a errori o attacchi malevoli ai danni di sistemi di AI.

Se l’AI diventa l’anello debole

L’implementazione di sistemi di AI generativa all’interno dei sistemi IT aziendali ha generato grandi aspettative in termini di aumento della produttività, ma l’efficacia in ambito business nell’uso dei Large Language Model (LLM) è indissolubilmente legato alla messa a valore di dati aziendali.

La tecnica di Retrieval Augmented Generation (RAG) consente, infatti, di individuare e utilizzare le informazioni utili all’interno di database e documenti per generare contenuti o automatizzare operazioni attraverso gli AI agent. Quanto più queste informazioni sono puntuali, tanto più l’AI potrà essere efficace. In altre parole, le potenzialità dell’AI dipendono dalla disponibilità di informazioni qualitativamente rilevanti, cioè quelle conservate in azienda.

Quello che gli esperti si aspettano nei prossimi mesi è uno scenario in cui le aziende daranno accesso a un numero sempre maggiore di informazioni ai sistemi di AI generativa. In pratica, chatbot e AI agent avranno un’ampia libertà di azione e il rischio che tutto questo si traduca in una esposizione di informazioni riservate crescerà in maniera esponenziale.

Tutte le vulnerabilità dell’AI

All’interno dei sistemi IT di un’azienda, normalmente, le informazioni sono compartimentate attraverso policy che assicurano che gli utenti possano avere accesso soltanto ai dati di loro competenza. Anche se questo tipo di approccio può essere replicato anche con gli strumenti di AI generativa, la sua introduzione aumenta sensibilmente sia il rischio di condivisioni involontarie provocate da errori umani, sia la superficie di attacco a disposizione di eventuali cyber criminali.

Tra le minacce più rilevanti ci sono tecniche come il jailbreak e la prompt injection. Il jailbreak viene solitamente definito come una tecnica che consente di aggirare o superare i limiti e i controlli di sicurezza implementati in un modello di AI, al fine di fargli eseguire azioni o produrre contenuti che vanno oltre i suoi normali parametri di funzionamento. Nella pratica, l’uso di tecniche di jailbreak potrebbero consentire a un utente legittimo di accedere a informazioni che travalicano i suoi privilegi.

Gli attacchi basati su prompt injection, invece, prevedono la “iniezione” di comandi nascosti che possono portare l’AI a compiere azioni indesiderate, come l’inserimento di informazioni riservate in comunicazioni dirette a soggetti esterni. Uno degli stratagemmi potenzialmente utili per raggiungere questo scopo è quello di inserire le istruzioni in un documento rendendole invisibili agli esseri umani (per esempio inserendo del testo bianco su sfondo bianco) ma rilevanti per i sistemi di AI.

Il ruolo della Data Loss Prevention

In uno scenario estremamente “acerbo” e in continua evoluzione, affidarsi esclusivamente ai controlli di sicurezza interni ai sistemi di AI non è sufficiente. Per implementare una protezione efficace è necessario intervenire su tutti gli strumenti di comunicazione e collaborazione, a partire dall’email. La posta elettronica è ancora il principale strumento attraverso cui possono essere diffuse le informazioni sensibili e le tecnologie di Mimecast possono rappresentare un valido aiuto perché impiegano algoritmi di pattern matching e analisi semantica per identificare dati sensibili all’interno di e-mail e allegati.

Il sistema può anche essere configurato per crittografare automaticamente determinati contenuti o impedire il loro invio in caso di violazione delle policy aziendali.

Allo stesso modo, è necessario controllare le piattaforme ddi collaborazione, come Microsoft Teams, Slack e Zoom. In questo caso, il compito è affidato a filtri avanzati in grado di identificare parole chiave, espressioni regolari e comportamenti atipici per prevenire la fuga accidentale di dati riservati.

L’efficacia di Mimecast è garantita dall’uso di sistemi di intelligenza artificiale, che permettono di analizzare con estrema accuratezza i contenuti. In questo caso, potremmo dire che si combatte il fuoco con il fuoco.

La velocità con cui le aziende italiane stanno abbracciando l’uso dell’IA rende indispensabile poter proporre ai mercati gli strumenti giusti per proteggersi dai rischi connessi a una tecnologia potente, ma ancora poco esplorata dal punto di vista della sicurezza. Ingecom, il distributore ufficiale per l’Italia di Mimecast, permette a tutte le aziende del nostro Paese di poter sfruttare la potenza dell’IA riducendone i rischi con il minimo sforzo.

---

---

---

https://www.securityinfo.it/2025/03/27/mimecast-con-lai-una-nuova-era-per-la-data-loss-prevention/?utm_source=rss&utm_medium=rss&utm_campaign=mimecast-con-lai-una-nuova-era-per-la-data-loss-prevention