Nella cybersecurity esiste una contraddizione che viene sistematicamente sottovalutata: quanto più un’organizzazione comunica, si promuove e si digitalizza, tanto più amplia involontariamente la propria superficie di attacco. Non attraverso falle nel codice o configurazioni errate, ma attraverso qualcosa di molto più ordinario: le informazioni pubblicamente disponibili su se stessa.

OSINT offensivo: la ricognizione invisibile che precede ogni attacco

L’Open Source Intelligence offensiva, nota come offensive OSINT, è la pratica con cui attori malevoli raccolgono, correlano e trasformano in arma questi dati pubblici, tutto senza mai toccare un sistema target, senza inviare un pacchetto sospetto, senza lasciare traccia nei log. Come documenta ShadowDragon nel suo riferimento 2026 sull’argomento, la ricognizione passiva non interagisce con la presenza online del bersaglio e rimane non rilevabile, non lasciando alcuna traccia dell’attività di raccolta informazioni. È invisibile per definizione.

Questa invisibilità è la prima ragione per cui l’offensive OSINT è tanto pericolosa quanto sottostimata.

La guerra inizia prima dell’attacco: la fase di ricognizione

La ricognizione precede ogni intrusione. Nel framework MITRE ATT&CK, la tattica TA0043 cataloga formalmente le tecniche con cui gli avversari raccolgono informazioni utili a pianificare operazioni future, distinguendo tra raccolta attiva e passiva. La distinzione non è accademica: determina il profilo di rischio dell’attaccante e la tracciabilità dell’operazione.

La ricognizione passiva si alimenta di tutto ciò che è già pubblico: record DNS, certificati digitali, metadati nei documenti, profili LinkedIn, offerte di lavoro, repository GitHub, comunicati stampa. Nulla di illegale, nulla di tecnico nel senso tradizionale del termine. Eppure questi dati, correlati con metodo, costruiscono un profilo operativo estremamente preciso di qualsiasi organizzazione.

La ricognizione attiva, invece, prevede un’interazione diretta con i sistemi del bersaglio, come la scansione delle porte o l’enumerazione dei servizi, e per questa ragione genera tracce rilevabili. Gli attaccanti sofisticati tendono a restare nella fase passiva il più a lungo possibile, spostandosi all’attivo solo quando hanno già un quadro sufficientemente dettagliato per operare in modo chirurgico.

Come osserva Vectra AI nel suo approfondimento del marzo 2026 sulla ricognizione, la profilazione OSINT include la mappatura dei ruoli dei dipendenti, dei fornitori e delle tecnologie a partire da fonti pubbliche come LinkedIn, le offerte di lavoro e i repository di codice. Queste attività non generano telemetria difensiva: compaiono nel log solo dopo, come precisione inaspettata nelle fasi successive dell’attacco.

Che cosa cercano davvero gli attaccanti: non vulnerabilità ma contesto

L’errore più comune nel ragionare sull’offensive OSINT è pensare che gli attaccanti cerchino vulnerabilità tecniche. In realtà, nella fase di ricognizione cercano soprattutto contesto: chi prende le decisioni, quali fornitori si utilizzano, quale stack tecnologico è in produzione, quale ufficio gestisce i bonifici, chi ha appena cambiato ruolo, chi è in trasferta.

Questi dati, individualmente irrilevanti, diventano letali una volta aggregati. SecurityScorecard evidenzia nel suo aggiornamento del 2026 che la raccolta passiva permette ai threat actor di costruire profili completi delle organizzazioni target prima ancora di passare a metodi di raccolta attiva come la scansione delle porte o le verifiche sulle applicazioni web. Questa ricognizione rivela spesso vettori d’attacco che i team di sicurezza trascurano.

Le fonti preferite degli attaccanti includono: offerte di lavoro (che rivelano stack tecnologici e strumenti di sicurezza adottati); profili sui social network professionali (che espongono organigrammi, riporti diretti e responsabilità operative); repository pubblici di codice (dove credenziali hardcoded e configurazioni sensibili compaiono con frequenza sorprendente); certificate transparency log (che rivelano sottodomini e infrastruttura interna); e breach database pubblicamente accessibili (che contengono credenziali riutilizzate o pattern di password aziendali).

Il ruolo abilitante dell’intelligenza artificiale

Se la reconnaissance manuale richiedeva tempo e competenze, l’integrazione dell’intelligenza artificiale nei flussi di lavoro offensivi ha abbattuto entrambe le barriere. Il Google Threat Intelligence Group documenta nel suo report del febbraio 2026 che gli APT actor hanno usato strumenti di AI a supporto di diverse fasi del ciclo di vita dell’attacco, con un focus specifico sulla ricognizione e sullo sviluppo dei target per facilitare il compromesso iniziale.

I casi documentati dal GTIG sono precisi e verificati. APT42, il gruppo iraniano noto anche come Charming Kitten o Mint Sandstorm, ha impiegato modelli AI per cercare indirizzi email ufficiali di specifiche entità, condurre ricognizioni su potenziali partner commerciali e costruire persona credibili a partire dalla biografia dei target. UNC2970, il gruppo nordcoreano collegato a Lazarus Group, ha sintetizzato intelligence open source per profilare figure di alto valore nel settore della difesa e della cybersecurity, mappando ruoli tecnici specifici e informazioni salariali per affinare le campagne di spear phishing.

La portata di questa accelerazione diventa concreta guardando i dati operativi. Il Palo Alto Networks Unit 42 Global Incident Response Report 2026, basato su oltre 750 indagini in più di 50 paesi, certifica che nel 2025 gli attacchi più veloci hanno raggiunto l’esfiltrazione dei dati in soli 72 minuti dall’accesso iniziale, rispetto ai 285 minuti dell’anno precedente: una riduzione quadrupla del tempo che i difensori hanno a disposizione per rilevare e contenere una minaccia.

Questo è il paradosso che l’AI introduce nell’equazione: mentre velocizza e personalizza la ricognizione sul lato offensivo, comprime drammaticamente la finestra di risposta disponibile sul lato difensivo.

La supply chain come bersaglio strategico: l’anello debole è il tuo fornitore

L’offensive OSINT non si limita al perimetro diretto dell’organizzazione target. Uno dei suoi utilizzi più efficaci è la mappatura della catena di fornitura: identificare i fornitori critici, le loro integrazioni tecniche, i contratti pubblici, le partnership dichiarate. Una volta individuato l’anello più debole dell’ecosistema, l’attaccante non ha bisogno di affrontare le difese del bersaglio principale.

I dati del Unit 42 Report 2026 certificano che nel 2025 le applicazioni SaaS di terze parti sono state rilevanti nel 23% dei casi analizzati. In un’indagine documentata nel report, gli attaccanti hanno sfruttato token OAuth validi di una piattaforma commerciale compromessa per accedere agli ambienti Salesforce dell’organizzazione target. La revisione post-incidente ha rivelato quasi 100 integrazioni di terze parti collegate all’istanza, molte delle quali inattive, non monitorate o associate a ex dipendenti.

Per un threat actor che ha condotto una ricognizione OSINT accurata, l’identificazione di questa rete di trust è tutt’altro che casuale: è il risultato di settimane di analisi pubblica delle relazioni tra fornitori, dei contratti pubblicati, degli annunci di partnership. Informazioni che esistono nel dominio pubblico e che nessuno, nel frattempo, stava aggregando e interpretando con intento offensivo.

Il tema è strettamente collegato alle pratiche di threat intelligence e gestione del rischio di terze parti, su cui ICT Security Magazine ha già pubblicato approfondimenti specifici nel contesto della conformità NIS2.

La velocità come elemento sistemico

Un dato del Unit 42 Report 2026 richiede una riflessione separata: gli attaccanti cominciano a scansionare nuove vulnerabilità entro 15 minuti dall’annuncio pubblico di un CVE. In molti casi, i tentativi di exploit iniziano prima che i team di sicurezza abbiano terminato di leggere l’advisory.

Questo dato ridefinisce il problema. L’OSINT offensiva non è soltanto uno strumento per la fase preparatoria degli attacchi mirati: è anche un meccanismo di monitoraggio continuo che consente agli attaccanti di identificare opportunità in tempo reale. La stessa logica con cui un analista difensivo monitora le fonti pubbliche per anticipare le mosse degli avversari viene applicata specularmente da chi vuole sfruttarle.

Le strutture di identità digitale delle organizzazioni sono l’altra faccia del problema. Sempre secondo il Unit 42 Report 2026, le debolezze nell’identità hanno giocato un ruolo materiale in circa il 90% delle indagini condotte. Non perché le credenziali siano state rubate attraverso attacchi tecnici sofisticati, ma perché informazioni pubblicamente disponibili, abbinate a tecniche di social engineering alimentate da ricognizione OSINT, hanno reso i tentativi di compromissione dell’identità estremamente efficaci.

Questo legame diretto tra offensive OSINT e attacchi di social engineering è uno degli aspetti più critici e meno presidiati del panorama attuale.

https://www.ictsecuritymagazine.com/articoli/osint-offensivo/

C’è un paradosso silenzioso al cuore dell’economia digitale contemporanea. Le API (Application Programming Interface) sono l’infrastruttura nervosa che tiene in vita ogni transazione bancaria, ogni ordine di e-commerce, ogni scambio di dati sanitari, ogni richiesta di un’applicazione mobile. Sono invisibili all’utente finale, onnipresenti nel codice, fondamentali per qualunque modello di business digitale. Eppure, proprio questa ubiquità le rende il bersaglio preferito degli attaccanti moderni e, troppo spesso, il punto più trascurato dell’intera catena della sicurezza informatica.

I numeri aiutano a comprendere la dimensione del problema. Secondo il Cloudflare Radar 2025 Year in Review, l’analisi più autorevole e aggiornata disponibile, basata sull’osservazione diretta di una rete globale presente in oltre 330 città, le API rappresentano oggi più della metà di tutto il traffico web dinamico, con un’incidenza in costante crescita.

Akamai, su un campione diverso di traffico internet, stima la quota fino all’83%. Nel solo 2025, le API hanno generato oltre 11.000 bollettini di sicurezza, pari al 17% di tutte le vulnerabilità software pubblicamente divulgate in un anno. Il traffico malevolo diretto verso le API è cresciuto del 681% nell’arco degli ultimi anni, secondo il Wallarm 2026 API ThreatStats Report. Quasi il 99% delle organizzazioni ha dichiarato di aver subito almeno un incidente legato alla sicurezza delle API negli ultimi dodici mesi. Non si tratta di statistiche marginali: è la fotografia di un’infrastruttura critica sotto assedio sistematico, e di un settore che stenta ancora a rispondere con adeguata consapevolezza.

Un bersaglio su misura per gli attaccanti

Cosa rende le API un vettore così attraente? La risposta sta nella loro natura strutturale. A differenza delle applicazioni web tradizionali, un’API non ha una “porta d’ingresso” visibile: non ha un login, non ha un CAPTCHA, non ha l’interfaccia grafica che un essere umano deve attraversare. È progettata per essere consumata da macchine, e le macchine non faticano a sparare decine di migliaia di richieste al secondo. Un’organizzazione che espone API pubbliche riceve in media 10.000 attacchi al giorno. Le API GraphQL, sempre più diffuse per la loro flessibilità, hanno visto un incremento del 140% nei tentativi di abuso nel corso del 2025.

La semplicità di attacco è altrettanto allarmante. Secondo il Wallarm 2026 API ThreatStats Report, il 97% delle vulnerabilità API è sfruttabile con una singola richiesta HTTP. Il 98% è classificato come facile o banale da sfruttare. Il 59% non richiede nemmeno autenticazione. Il 30% ha già exploit pubblici disponibili nel momento stesso in cui la vulnerabilità viene divulgata. Questa combinazione di alta diffusione, alta sfruttabilità e bassa complessità trasforma le API in un terreno di caccia privilegiato per attori di ogni livello, dai criminali opportunistici alle APT sofisticate.

A questo si aggiunge la questione del rilevamento. Solo il 21% delle organizzazioni dichiara di avere capacità solide nell’identificare attacchi a livello API. Appena il 13% riesce a prevenire più del 50% degli attacchi. Gli strumenti tradizionali come i Web Application Firewall (WAF) si rivelano inadeguati: il 53% delle organizzazioni ne riconosce apertamente i limiti nella rilevazione di frodi a livello API. Siamo di fronte a un disallineamento strutturale tra la superficie esposta e le difese disponibili.

L’OWASP API Security Top 10: una mappa delle fragilità

Dal 2019, l’Open Worldwide Application Security Project pubblica la propria lista delle vulnerabilità API più critiche. La versione aggiornata al 2023, oggi il riferimento di settore, riflette un’evoluzione significativa del panorama delle minacce. L’88% degli attacchi reali sfrutta almeno una delle vulnerabilità elencate, il che rende questa tassonomia uno strumento di prioritizzazione imprescindibile per qualunque team di sicurezza.

API1:2023 – Broken Object Level Authorization (BOLA) rimane, a distanza di anni, la vulnerabilità più sfruttata nelle API. Si manifesta quando un endpoint espone dati di un oggetto senza verificare che l’utente autenticato abbia effettivamente il diritto di accedervi. Un attaccante che conosce o indovina l’identificatore di un record (un numero d’ordine, un ID paziente, un codice cliente) può semplicemente cambiarlo nella richiesta e accedere ai dati altrui. La logica è elementare; l’impatto, devastante.

API2:2023 – Broken Authentication aggrega tutte le debolezze legate alla gestione dell’identità: password deboli, token JWT mal configurati, assenza di blocco su tentativi multipli, meccanismi di reset insicuri. In questa categoria rientrano anche i frequenti errori nella gestione dei segreti: chiavi API hard-coded nel codice sorgente, token esposti in repository pubblici, credenziali condivise tra ambienti di produzione e sviluppo. Un caso emblematico, divulgato nel dicembre 2024 dal team TRIAD di CloudSEK: la scoperta di oltre 30.000 workspace Postman accessibili pubblicamente, contenenti token di accesso attivi, chiavi API reali e payload con dati sanitari e credenziali aziendali di organizzazioni in settori che vanno dalla finanza all’abbigliamento sportivo.

API3:2023 – Broken Object Property Level Authorization (BOPLA) è una novità della lista 2023, nata dalla fusione di due categorie precedenti (Excessive Data Exposure e Mass Assignment). Riconosce che il problema non è solo chi può accedere a un oggetto, ma anche quali proprietà di quell’oggetto possono essere lette o modificate. Un utente che riesce a modificare un campo come role: admin in una richiesta PUT sta sfruttando esattamente questa vulnerabilità.

API4:2023 – Unrestricted Resource Consumption riguarda la mancanza di limiti efficaci sull’uso delle risorse: assenza di rate limiting, nessun controllo sulla dimensione dei payload, nessun tetto alle query su database o ai servizi di terze parti a pagamento. Gli attacchi DDoS diretti alle API sono cresciuti del 200% nel 2025. In assenza di throttling, un attaccante può paralizzare un servizio o generare costi operativi insostenibili attraverso richieste massive e automatizzate.

API5:2023 – Broken Function Level Authorization (BFLA) colpisce quando la distinzione tra funzioni amministrative e funzioni utente non è enforcement a livello backend. Se un’API non verifica il livello di privilegio richiesto per ciascun endpoint, un utente ordinario potrebbe invocare endpoint di amministrazione semplicemente conoscendone il path.

API6:2023 – Unrestricted Access to Sensitive Business Flows è la vulnerabilità più sottile e difficile da rilevare automaticamente. Non riguarda un bug tecnico, ma l’assenza di protezione contro l’uso massiccio e automatizzato di flussi di business legittimi: acquisto di biglietti, creazione di account, pubblicazione di contenuti. Un bot che acquista in millisecondi tutti i posti di un concerto sta sfruttando questa categoria, e nessuno scanner tradizionale lo individuerà.

API7:2023 – Server-Side Request Forgery (SSRF) è una novità del 2023. Si verifica quando un’API recupera risorse remote senza validare l’URI fornito dall’utente, consentendo a un attaccante di instradare richieste verso sistemi interni, servizi di metadata cloud o endpoint protetti da firewall.

API8:2023 – Security Misconfiguration è il contenitore di una casistica vastissima: CORS permissivi, header di sicurezza assenti, messaggi di errore verbosi che rivelano la struttura interna, TLS non configurato, porte di debug esposte in produzione. I cloud provider registrano misconfigurazioni API in oltre il 30% dei casi di breach.

API9:2023 – Improper Inventory Management riguarda le cosiddette shadow API, un tema che merita un approfondimento dedicato per la rilevanza che ha assunto negli ultimi anni, come illustrato nel paragrafo seguente.

API10:2023 – Unsafe Consumption of APIs è l’unica voce della lista che capovolge la prospettiva: non riguarda i rischi di essere un provider di API, ma quelli di essere un consumer. Un’applicazione che consuma API di terze parti senza validarne l’output, senza limitare i dati elaborati e senza considerare la possibilità di un provider compromesso, eredita automaticamente le vulnerabilità di quell’ecosistema.

Il problema delle shadow API: quello che non sai che esiste

Tra tutte le sfide della sicurezza API, la gestione delle API non documentate, denominate shadow API o zombie API, è probabilmente la più sistemica e la più sottovalutata. Le shadow API sono endpoint reali, attivi, raggiungibili dalla rete, che non compaiono in nessun inventario ufficiale, non sono soggetti a test di sicurezza, non sono monitorati da nessun team. Possono essere API di vecchie versioni dimenticate durante una migrazione, endpoint di sviluppo mai rimossi in produzione, integrazioni create da team interni senza passare per il processo formale di release.

I numeri dicono che le shadow API rappresentano oltre il 20% dell’inventario API totale nelle organizzazioni enterprise. Le istituzioni finanziarie gestiscono in media 601 API e una parte rilevante di queste sfugge a qualsiasi governance attiva. Un caso paradigmatico del 2025 è quello di Stripe: attaccanti hanno individuato un endpoint legacy (/v1/sources) ancora collegato ai sistemi di validazione pagamenti, privo dei controlli di sicurezza delle API moderne, e lo hanno sfruttato per condurre una campagna massiva di card skimming su almeno 49 e-commerce compromessi. L’endpoint era un residuo dell’architettura precedente, scarsamente documentato e ignorato nei security audit. Non una vulnerabilità zero-day: un oggetto dimenticato.

Quello di Stripe non è un caso isolato. Il breach di Optus del settembre 2022 ha esposto i dati personali di quasi 10 milioni di clienti australiani, quasi un terzo della popolazione del paese, attraverso un’API priva di autenticazione rimasta accessibile da internet per circa tre mesi. Secondo l’analisi dell’Australian Communications and Media Authority (ACMA), un errore di codifica introdotto nel 2018 aveva reso inefficaci i controlli di accesso su un sottodominio, e il problema era rimasto non rilevato nonostante una correzione parziale applicata nel 2021 sul dominio principale. L’attaccante non aveva bisogno di strumenti sofisticati: l’API non richiedeva alcuna autenticazione, e i customer ID erano numerici e incrementali, rendendoli banalmente enumerabili.

Il breach che nel 2022 ha colpito Twitter è spesso descritto in modo impreciso. Non si trattava di un’API legacy dimenticata, ma di un bug introdotto nell’aggiornamento del codice di giugno 2021: la vulnerabilità consentiva a chiunque di sottomettere un numero di telefono o un indirizzo e-mail all’API della piattaforma e ricevere in risposta l’ID dell’account Twitter associato, anche quando l’utente aveva esplicitamente configurato le impostazioni di privacy per impedire questa correlazione.

Il bug fu segnalato tramite bug bounty in gennaio 2022 e corretto subito dopo; era però già stato sfruttato da almeno dicembre 2021. Un threat actor aveva creato un database di 5,4 milioni di profili, incluse informazioni private come numeri di telefono e indirizzi e-mail, poi venduto online e infine diffuso gratuitamente. Ulteriori analisi rivelarono che la stessa vulnerabilità era stata sfruttata su scala molto più ampia, portando a un dataset finale di oltre 200 milioni di account.

In entrambi i casi, come nel caso Stripe, la catena causale è identica: controlli insufficienti, endpoint dimenticati o alterati, nessun monitoraggio, nessun alert.

Breach recenti: leggere gli incidenti come segnali

L’analisi dei 60 breach API divulgati nel 2025, condotta da Wallarm nel 2026 API ThreatStats Report, restituisce un quadro per settori e categorie: software (15%), piattaforme AI (15%), vendor di cybersecurity (13%), SaaS (8%), automotive (7%), cloud services (7%). Mappati sulla tassonomia OWASP, la broken authentication è responsabile del 52% degli incidenti, mentre l’unsafe consumption di API di terze parti spiega il 27%.

Tra gli episodi più rilevanti del 2025: API di terze parti hanno esposto milioni di record presso il fornitore di servizi creditizi 700Credit; debolezze nell’autenticazione delle API Qantas hanno permesso accessi di massa non autorizzati; credenziali rubate e permessi API eccessivi hanno abilitato transazioni fraudolente su SwissBorg; server MCP esposti hanno fatto trapelare infrastrutture di agent AI su larga scala. A maggio 2025 un hacker con lo pseudonimo “ByteBreaker” ha pubblicato su forum underground la presunta raccolta di dati relativi a 1,2 miliardi di account Facebook tramite abuso di API.

Meta ha negato si tratti di un breach nuovo, sostenendo che il dataset reimpacchetti dati già divulgati nel 2021; i ricercatori di Cybernews e Hackread hanno rilevato incongruenze strutturali nella dimensione dichiarata e sovrapposizioni significative con il leak precedente. Il claim resta pertanto non verificato indipendentemente, ma l’episodio conferma il modello di sfruttamento delle API come vettore di data harvesting massivo.

Il filo conduttore è sempre lo stesso: non exploit sofisticati, non attori nation-state con capacità eccezionali, ma debolezze fondamentali (autenticazione assente o debole, autorizzazione non granulare, endpoint dimenticati, terze parti non verificate) sfruttate con strumenti automatizzati alla portata di qualunque attore.

DevSecOps e la sicurezza by design: integrare prima che sia tardi

La risposta sistemica al problema della sicurezza API non può essere post-hoc. Applicare controlli di sicurezza su API già in produzione è costoso, inefficace e spesso destinato a fallire. La strada maestra è l’integrazione della sicurezza nel ciclo di vita dello sviluppo, in quello che il settore definisce approccio DevSecOps oppure, più recentemente, shift-left security.

In pratica, questo significa che il processo di sviluppo deve includere: modellazione delle minacce nella fase di design (identificare le attack surface prima di scrivere codice); revisione del codice orientata alla sicurezza (con particolare attenzione alla gestione dei segreti, alla sanitizzazione degli input, alla corretta implementazione dell’autenticazione); test automatizzati di sicurezza nelle pipeline CI/CD (SAST per il codice sorgente, DAST per le API deployate, test specifici contro le vulnerabilità OWASP); e monitoraggio continuo in produzione, con alerting su anomalie comportamentali che potrebbero segnalare tentativi di exploitation.

Questo approccio richiede che la sicurezza non sia responsabilità esclusiva di un team separato, ma venga distribuita attraverso l’intera organizzazione di sviluppo. I developer devono conoscere le vulnerabilità OWASP API Top 10. I team di prodotto devono includere requisiti di sicurezza nelle specifiche. I team di infrastruttura devono garantire che le pipeline espongano segnali di sicurezza rilevabili. Tuttavia, secondo il 2025 State of API Security Report di Traceable AI, basato su oltre 1.500 professionisti IT e cybersecurity, solo il 14% delle organizzazioni ha attualmente una strategia formale di API posture governance. Il gap tra l’ambizione del DevSecOps e la sua attuazione pratica rimane ampio.

Un nodo critico è rappresentato dall’adozione dell’AI generativa nello sviluppo software. La pratica del cosiddetto vibe coding, generare codice API con assistenti AI senza un’adeguata revisione critica, è diventata pervasiva. Secondo Akamai, l’AI-assisted coding è associato a un aumento di misconfigurazioni, impostazioni predefinite insicure e vulnerabilità trascurate nelle API generate. Il 65% delle organizzazioni considera la GenAI un rischio da serio a estremo per la sicurezza delle proprie API. La velocità di sviluppo che l’AI permette amplifica proporzionalmente la superficie esposta se non è accompagnata da un’eguale accelerazione dei controlli di sicurezza.

PSD2, Open Banking e DORA: la sicurezza delle API come obbligo regolatorio

Nel settore finanziario, la sicurezza delle API non è solo una questione tecnica: è un obbligo normativo con conseguenze legali misurabili. La Direttiva PSD2 ha imposto alle banche europee di esporre API dedicate ai Third-Party Provider (TPP), ovvero fintech autorizzate a offrire servizi di pagamento e aggregazione di conti, con requisiti stringenti di Strong Customer Authentication (SCA), dynamic linking e identificazione tramite certificati eIDAS. In questa architettura aperta, ogni vulnerabilità su un’API bancaria è potenzialmente una violazione dei dati del cliente, una frode abilitata dalla piattaforma e una sanzione per la banca emittente.

Le penali per non conformità possono raggiungere il 4% del fatturato annuo o 5 milioni di euro, applicando il criterio più alto. Ma il quadro si è ulteriormente complicato. Con l’accordo politico su PSD3/PSR raggiunto a novembre 2025 e l’adozione formale attesa nel primo semestre 2026, cui seguirà un periodo di transizione di 21 mesi verso l’implementazione completa prevista intorno al 2027, le banche europee si trovano ora a navigare obblighi paralleli e crescenti: responsabilità ampliata per le frodi da impersonificazione, verifica obbligatoria del beneficiario (Verification of Payee), autenticazione a doppia inerenza e benchmark di performance API più severi.

Parallelamente, DORA (il Digital Operational Resilience Act, entrato pienamente in vigore il 17 gennaio 2025) ha unificato il regime di incident reporting per il settore finanziario. L’EBA ha formalmente abrogato le proprie linee guida PSD2 sulla notifica degli incidenti, sostituendole con il framework DORA. Questo cambiamento non è meramente amministrativo: significa che un breach su un’API Open Banking deve ora essere gestito attraverso il prisma della resilienza operativa digitale, con obblighi di notifica armonizzati e un orizzonte di governance che abbraccia l’intera catena tecnologica, incluse le terze parti. Va notato che questa convergenza risolve parzialmente, ma non elimina, la tensione strutturale tra PSD2 (che spinge verso l’apertura dei dati) e il GDPR (che impone la protezione dei dati personali).

Come documentato in uno studio peer-reviewed pubblicato su MDPI nel gennaio 2026, i requisiti sovrapposti di consenso e protezione dei dati creano ancora incertezza nella governance e nell’allocazione delle responsabilità tra banche e TPP, anche alla luce del quadro normativo europeo DORA e NIS2.

Sul piano tecnico, il framework FAPI 2.0 (Financial-grade API Security Profile) ha raggiunto la propria specifica finale nel febbraio 2025, diventando il riferimento per l’implementazione sicura di API ad alto valore. FAPI 2.0 richiede l’uso di Pushed Authorization Requests (PAR), PKCE per tutti i client e token sender-constrained tramite mTLS o DPoP. Il 75% delle banche europee ha già adottato lo standard NextGenPSD2 del Berlin Group.

PCI DSS 4.0.1, diventata l’unica versione attiva dall’aprile 2025, è il primo standard PCI a citare esplicitamente le API come oggetto di controlli di sicurezza: il Requisito 6.4.2 impone soluzioni automatizzate davanti alle API pubbliche per rilevare e prevenire attacchi; il Requisito 6.3.2 richiede un inventario completo di tutto il software custom incluse le API. La non conformità comporta sanzioni tra 5.000 e 100.000 dollari al mese.

La frammentazione persistente nella qualità delle implementazioni rimane una fonte di rischio documentata dalla stessa Commissione Europea, che ha rilevato significative discrepanze negli standard API tra istituti diversi: un problema che PSD3 punta a risolvere attraverso benchmark di performance più stringenti e l’eliminazione definitiva del fallback allo screen scraping.

Verso una maturità sistemica: cosa manca ancora

Osservando il panorama nel suo insieme, la distanza tra il livello di esposizione e il livello di maturità difensiva delle organizzazioni appare strutturalmente preoccupante. Il 57% delle organizzazioni ha subito un breach API negli ultimi due anni, con il 73% di queste che ne ha subiti tre o più. Il 41% dichiara cinque o più episodi. Si tratta di fallimenti sistemici, non di incidenti episodici.

La risposta richiede un cambio di paradigma su più livelli. Primo, il problema della visibilità: non è possibile proteggere ciò che non si conosce. La discovery continua delle API, incluse le shadow API, deve diventare una funzione operativa permanente, non un esercizio periodico. Secondo, il problema della governance: le organizzazioni devono trattare ogni API come un asset critico, con un ciclo di vita documentato, un responsabile identificato, test di sicurezza automatizzati e metriche di esposizione misurabili. Terzo, il problema della cultura: finché la sicurezza API è percepita come un vincolo tecnico imposto a posteriori, anziché come una proprietà architettonica costruita ab initio, il divario tra attaccanti e difensori continuerà ad ampliarsi.

Le previsioni per il 2026 non lasciano spazio all’ottimismo passivo. Akamai stima che le API diventeranno il vettore dominante per i breach a livello applicativo, potenzialmente responsabili di più della metà di tutti gli attacchi alle applicazioni. Il Model Context Protocol, l’infrastruttura che collega gli agenti AI alle API esterne, ha già accumulato 315 vulnerabilità documentate nel 2025, pari al 14,4% di tutte le vulnerabilità AI, con una crescita del 270% tra il secondo e il terzo trimestre. L’interconnessione crescente tra sistemi AI agentici e API di business apre una superficie d’attacco che oggi non è ancora pienamente compresa né adeguatamente presidiata.

Conclusione

Le API sono, nel senso più letterale, i punti di connessione dell’economia digitale. Sono ciò che permette a una banca di condividere i dati di un cliente con un’app fintech, a un ospedale di integrare i referti con un sistema di telemedicina, a una supply chain di coordinare ordini e spedizioni in tempo reale. La loro sicurezza non è un problema tecnico tra gli altri: è una condizione necessaria per la fiducia digitale su cui si regge l’intero ecosistema.

Il paradosso è che questa centralità non si traduce ancora in un’attenzione proporzionale. Le organizzazioni investono in perimetri, in endpoint protection, in SIEM sofisticati e lasciano le API senza inventario, senza test, senza monitoraggio. Solo il 14% ha una strategia formale di governance. Meno di una su cinque riesce a rilevare con sufficiente efficacia gli attacchi che la colpiscono. Gli attaccanti hanno capito dove si trova il valore. La domanda è se le organizzazioni abbiano la stessa chiarezza sul proprio tallone d’Achille e, soprattutto, se abbiano la volontà di trasformare quella consapevolezza in azione prima che sia il prossimo breach a farlo decidere per loro.

https://www.ictsecuritymagazine.com/articoli/sicurezza-delle-api/

Mag 11, 2026 Redazione Attacchi, In evidenza, News, RSS 0

---

La corsa all’AI sta creando nuove superfici di attacco e i cybercriminali stanno iniziando a sfruttarle con tecniche sempre più sofisticate. L’ultimo caso arriva dal mondo dei modelli open source e delle piattaforme collaborative dedicate all’intelligenza artificiale: un repository malevolo pubblicato su Hugging Face è riuscito a spacciarsi per un progetto ufficiale di OpenAI, raggiungendo rapidamente la vetta dei contenuti più popolari prima di essere rimosso.

Secondo quanto riportato da The Hacker News, il repository fraudolento imitava il progetto “privacy-filter” di OpenAI, copiandone descrizione e struttura per convincere sviluppatori e ricercatori a scaricare codice malevolo. L’obiettivo finale, come avviene sempre più spesso negli attacchi alla catena del software, era il furto di credenziali, cookie di sessione e dati sensibili dai browser Windows delle vittime.

L’attacco alla fiducia dell’ecosistema AI open source

La vicenda mostra come l’ecosistema AI stia vivendo una dinamica molto simile a quella già osservata negli anni nel mondo dei package npm, PyPI e GitHub. I criminali non devono necessariamente violare infrastrutture complesse: spesso basta sfruttare la fiducia implicita che sviluppatori e ricercatori ripongono nei repository pubblici.

Nel caso specifico, gli attaccanti hanno creato un progetto chiamato “Open-OSS/privacy-filter”, estremamente simile a quello reale pubblicato da OpenAI. Il repository riprendeva testi, descrizioni e struttura del progetto originale, rendendo difficile per molti utenti distinguere il repository legittimo da quello malevolo.

Secondo le analisi, il repository sarebbe riuscito a ottenere centinaia di migliaia di download prima della rimozione, sfruttando anche account fake e meccanismi di trending della piattaforma.

Come funzionava il malware nascosto nel repository

Il cuore dell’attacco era un file Python apparentemente innocuo chiamato “loader.py”. Dietro codice, che simulava normali funzioni AI, il file nascondeva una catena di infezione progettata per scaricare ed eseguire un infostealer sviluppato in Rust.

L’analisi tecnica evidenzia diversi elementi tipici delle moderne campagne malware. Uno dei primi passaggi consisteva nella disattivazione della verifica SSL, scelta che permetteva al codice di contattare server remoti senza controlli rigorosi sui certificati.

Successivamente il malware decodificava dinamicamente URL in Base64 e recuperava payload esterni contenenti comandi PowerShell eseguiti in background. Da lì veniva scaricato il componente finale dell’attacco: un infostealer compilato in Rust, linguaggio sempre più utilizzato nel cybercrime moderno perché più difficile da analizzare e facilmente utilizzabile su più piattaforme.

Una volta attivo, il malware cercava informazioni nei browser Chromium e Gecko-based, inclusi Chrome, Edge e Firefox. Nel mirino finivano password salvate, cookie, token di autenticazione e sessioni attive, informazioni particolarmente preziose per compromettere account cloud, piattaforme AI e servizi enterprise.

Il nuovo problema: modelli AI come vettore di supply chain attack

Il caso conferma una tendenza che molti ricercatori stanno osservando da mesi: le piattaforme AI stanno diventando un nuovo terreno di supply chain attack.

Hugging Face, come GitHub nel mondo software tradizionale, si basa su un modello estremamente aperto. Chiunque può pubblicare modelli, dataset e codice. Questa apertura accelera l’innovazione, ma crea anche un ambiente ideale per campagne di impersonificazione, typosquatting e distribuzione malware.

Il problema è amplificato dalla velocità con cui le aziende stanno adottando strumenti AI. Molti sviluppatori scaricano modelli e repository senza effettuare verifiche approfondite sull’autore, sulle dipendenze o sul codice eseguito localmente. Il risultato è che la fiducia nell’ecosistema open source AI rischia di diventare un nuovo punto debole della sicurezza enterprise. Non a caso, negli ultimi mesi si sono moltiplicati gli incidenti legati a modelli malevoli, package compromessi e strumenti AI distribuiti con payload nascosti.

Perché gli infostealer sono così pericolosi nel mondo AI

Gli infostealer rappresentano oggi una delle categorie malware più redditizie per i cybercriminali. Nel contesto AI, il loro valore cresce ulteriormente perché gli sviluppatori tendono ad avere accesso privilegiato a infrastrutture cloud, repository di codice e piattaforme di training. Un singolo account compromesso può consentire attacchi a catena contro pipeline CI/CD, modelli proprietari, dataset sensibili e infrastrutture cloud aziendali. Cookie di sessione e token API possono inoltre permettere agli attaccanti di bypassare MFA e altri controlli tradizionali.

In pratica, il furto di credenziali da un laptop di sviluppo può diventare il punto di partenza per compromissioni molto più ampie, incluse intrusioni nella supply chain software o manipolazioni di modelli AI distribuiti pubblicamente.

---

• AI security, browser cookie, credential theft, cybercrime, cybersecurity, hugging face, infostealer Rust, loader.py, malware AI, malware Windows, openai, repository malevoli, supply chain attack

---

---

https://www.securityinfo.it/2026/05/11/falso-repository-openai-su-hugging-face-distribuisce-malware/?utm_source=rss&utm_medium=rss&utm_campaign=falso-repository-openai-su-hugging-face-distribuisce-malware

L’Unione Europea ha un problema con le VPN, le reti private virtuali. E lo sa bene. Il Servizio di Ricerca del Parlamento Europeo, il braccio dell’Europarlamento dedicato alle ricerche, ha pubblicato un briefing questa settimana descrivendo le VPN come “un buco nero nella legislazione che va colmato”.  

Il motivo scatenante: milioni di persone stanno utilizzando strumenti per la privacy per aggirare i nuovi sistemi di verifica dell’età progettati per impedire ai minori di accedere ai siti web per adulti.

La tempistica è precisa. La vicepresidente esecutiva dell’UE, Henna Virkkunen, aveva appena dichiarato in una conferenza stampa che aggirare la nuova app di verifica dell’età lanciata dal blocco tramite una VPN non dovrebbe essere possibile, definendolo uno dei “prossimi passi” che i responsabili politici dovranno esaminare. Non ha usato la parola “divieto”, ma ci è andata molto vicino.

Ma la limitazione dell’uso delle VPN per agevolare i sistemi di age verification (verifica dell’età) è un’arma a doppio taglio che, se da un lato cerca di proteggere i minori, dall’altro introduce significativi risvolti negativi sulla sicurezza online e la privacy degli adulti.

Che cos’è una VPN?

Ue ultima in ordine di tempo a muoversi sulle VPN

L’UE è l’ultima autorità a segnalare che le VPN saranno le prossime a essere prese di mira, dopo aver lanciato la sua app per la verifica dell’età: ecco come le VPN sono passate da strumento di sicurezza indispensabile a software di elusione che deve essere limitato.

Con l’accesso a Internet sempre più limitato in base all’età, gli utenti si rivolgono alle app VPN nel tentativo di aggirare i controlli obbligatori. L’UE è ora l’ultima a rivolgere la sua attenzione a questa tecnologia e gli esperti di sicurezza informatica sono preoccupati.

La vicepresidente esecutiva dell’UE, Henna Virkkunen, non ha dovuto menzionare esplicitamente l’espressione “divieto delle VPN” o “restrizioni alle VPN” per allarmare gli esperti di sicurezza informatica e i cittadini attenti alla privacy. Dopotutto, quella che un tempo era una misura drastica riservata ai regimi autoritari si è semplicemente trasformata nel naturale passo successivo per le autorità di regolamentazione democratiche, poiché l’obbligo di verificare la propria età è diventato semplicemente un aspetto normale dell’essere online.

“Naturalmente, un aspetto importante dei prossimi passi è anche quello di evitare che il sistema venga aggirato”, ha detto Virkkunen durante una conferenza stampa tenutasi il 29 aprile, rispondendo a una domanda sulle misure per impedire ai minori di eludere la nuova app di verifica dell’età semplicemente utilizzando un servizio VPN.

Negli ultimi sette giorni, una valanga di critiche ha invaso i social media per contestare la risposta di Virkkunen, con il crittografo belga Bart Preenel che l’ha definita “la china scivolosa di cui gli esperti avevano messo in guardia”.

Restrizioni sulle VPN in Utah

Ma questo non è affatto un caso isolato. La scorsa settimana, lo Utah è diventato il primo Stato americano a imporre restrizioni sull’uso delle VPN nell’ambito della sua ultima normativa sulla verifica dell’età. Tuttavia, una forte reazione negativa era riuscita a far naufragare un’idea simile nel Wisconsin lo scorso febbraio.

Solo pochi giorni prima, il Regno Unito aveva approvato il Children’s Wellbeing and Schools Bill, che include l’obbligo per i fornitori di servizi per adulti di adottare “ragionevoli misure anti-elusione”.

E la consultazione del Regno Unito sui danni online è tuttora in corso. Il governo ha già confermato che le VPN potrebbero essere soggette a restrizioni di età se riterrà che questi strumenti compromettano la sicurezza online.

In altri paesi europei, anche i politici francesi hanno confermato pubblicamente che “le VPN sono le prossime sulla lista” dopo che il Parlamento ha approvato il primo divieto europeo sull’uso dei social media da parte degli adolescenti.

Da strumento cruciale per la sicurezza informatica, un tempo molto apprezzato e raccomandato, le VPN e servizi simili sembrano essere stati etichettati come pericolosi software di elusione che i governi vogliono controllare e limitare. Ma come siamo arrivati ​​a questo punto? E, soprattutto, quali sono i rischi di questa crociata contro le VPN?

L’effetto della verifica dell’età sulla minaccia rappresentata dalle VPN

La verifica obbligatoria dell’età arriva come risposta a un mondo online che molti governi ritengono sia diventato troppo pericoloso per i minori.

Il Regno Unito è stato il primo paese a implementare la verifica obbligatoria per accedere ai cosiddetti contenuti “legali ma dannosi” nel luglio dello scorso anno. Altri paesi in tutto il mondo hanno rapidamente replicato una legislazione simile.

Poi è arrivato il momento per l’Australia di dare un altro esempio da seguire, quando a dicembre il governo ha imposto il divieto, il primo al mondo, di utilizzare i social media per i minori di 16 anni. Diversi governi, tra cui Francia, Regno Unito, Unione Europea, Grecia e Spagna, stanno ora spingendo per l’adozione di norme simili.

Con la diffusione dei controlli obbligatori sull’età, è emerso uno schema ricorrente: l’introduzione di tali controlli coincide sempre con un picco nell’utilizzo delle VPN da parte dei cittadini.

Le VPN, infatti, non solo crittografano tutte le connessioni internet, ma mascherano anche il vero indirizzo IP, facendo apparire la navigazione come se ci si trovasse in un altro Paese. Questa capacità permette di eludere qualsiasi restrizione geografica, compresi i controlli sull’età.

Non è facile stabilire con certezza se questi utenti siano per lo più adulti non disposti a scansionare il proprio volto o il passaporto per utilizzare internet, o minori che cercano di accedere a contenuti non adatti alla loro età; in realtà, alcuni studi condotti da gruppi come Childnet e Internet Matters sostengono che la proporzione penda dalla prima ipotesi.

Ma a quanto pare questo è sufficiente a spingere i governi a considerare l’uso delle VPN principalmente come uno strumento di elusione.

I pericoli del divieto delle VPN

Che ci piaccia o no, i controlli obbligatori sull’età sono una realtà, quindi sembra comprensibile che i legislatori vogliano chiudere tutte le scappatoie che consentono ai cittadini di aggirare la legge. Ma la realtà sarà più complessa.

Una rete privata virtuale (VPN) è un software di sicurezza che milioni di adulti e aziende utilizzano quotidianamente per migliorare la propria privacy online, la sicurezza e l’esperienza complessiva su Internet. Una VPN crittografa tutti i dati in uscita dal dispositivo, rendendo difficile tracciare le attività dell’utente.

Ecco perché gli esperti di sicurezza informatica temono che limitare l’uso delle VPN possa avere un impatto significativo sulla sicurezza online delle persone, il che, ironicamente, è esattamente ciò che queste leggi cercano di impedire.

Un gruppo del settore VPN, la VPN Trust Initiative (VTI), ha illustrato perfettamente questo rischio in una recente dichiarazione indirizzata al governo del Regno Unito.

“Le politiche che indeboliscono o limitano le VPN rischiano di ridurre la sicurezza online”.

Più paesi impongono controlli sull’età, più persone scaricano VPN

Lo schema è quasi comico. Dopo l’entrata in vigore dell’Online Safety Act nel Regno Unito, uno sviluppatore di app ha segnalato un aumento del 1.800% dei download in un solo mese, secondo Tom’s Hardware. Proton VPN ha visto un aumento del 1.400% delle iscrizioni. In Florida si è registrato un picco del 1.150% di VPN nelle ore successive al blocco dell’accesso a Pornhub. Il documento dell’EPRS lo riconosce apertamente, ma non offre una spiegazione chiara.

Ad aumentare l’imbarazzo dell’UE: è stato scoperto che la sua app di verifica dell’età memorizzava i dati della scansione facciale in file non crittografati, e che il controllo biometrico poteva essere aggirato in meno di due minuti da un ricercatore di sicurezza modificando una singola impostazione. CyberInsider ha riportato per primo il briefing dell’EPRS che ne è seguito.

Le associazioni per la privacy sostengono che questa strada porta a conseguenze pericolose.

Mozilla, Mullvad e Proton hanno replicato con una lettera congiunta indirizzata alle autorità britanniche la scorsa settimana, mettendo in guardia contro mosse che “minerebbero la libertà di Internet”. La VPN Trust Initiative lo ha ribadito senza mezzi termini: considerare le VPN come una scappatoia è “una completa incomprensione del loro ruolo”.

Dall’altra parte dell’Atlantico, lo Utah è diventato il primo stato americano a definire legalmente la posizione di un utente in base alla presenza fisica, e non all’indirizzo IP, rendendo di fatto irrilevante l’uso delle VPN. Le organizzazioni per i diritti digitali l’hanno definita inapplicabile. Gli esperti citano come monito il tentativo, durato anni, costoso e in gran parte fallimentare, della Russia di bloccare le VPN.

Non esiste ancora una legislazione concreta a livello europeo. Ma la direzione intrapresa sta diventando sempre più difficile da fraintendere.

Novità su Google, per aggiungere Key4Biz tra le tue fonti preferite, clicca qui

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/la-ue-vuole-introdurre-nuove-regole-per-limitare-le-vpn-quali-rischi-per-la-sicurezza-online/572330/

L’Open Source Intelligence non è mai stata soltanto una questione di strumenti. È sempre stata, prima di tutto, una questione di metodo: la capacità di trasformare frammenti di informazione pubblica in conoscenza operativa, passando attraverso raccolta, correlazione, verifica e interpretazione. Per decenni, questo processo ha richiesto pazienza, rigore analitico e una buona dose di creatività umana. Oggi, l’intelligenza artificiale sta comprimendo in minuti ciò che richiedeva giorni, e sta aprendo possibilità analitiche che fino a poco tempo fa appartenevano alla fantascienza. Ma sta anche consegnando le stesse capacità a chi ha interesse a fare danno.

Questo è il doppio binario su cui si muove l’AI-OSINT nel 2026: uno strumento di straordinaria utilità difensiva e, al tempo stesso, un moltiplicatore di forza per gli avversari. Capire entrambe le facce non è un esercizio teorico, è una necessità pratica per chiunque lavori nel campo della sicurezza.

Il problema del volume: quando i dati superano la capacità umana

Al cuore dell’OSINT è sempre stata la capacità di usare dati pubblici per risolvere un’indagine, ma oggi il volume ha superato di gran lunga ciò che qualsiasi analista umano può realisticamente gestire. Il web indicizzato, il dark web, i social media, i registri pubblici, le immagini satellitari commerciali, le blockchain, i repository di codice aperti: la superficie informativa disponibile cresce in modo esponenziale, e con essa il rischio che segnali rilevanti si perdano nel rumore.

Secondo un’analisi peer-reviewed condotta da Riccardo Ghioni, Mariarosaria Taddeo e Luciano Floridi dell’Oxford Internet Institute, pubblicata sulla rivista AI & Society nel 2023, l’OSINT costituisce oggi tra l’80 e il 90 per cento di tutte le attività di intelligence condotte dalle forze dell’ordine e dai servizi di sicurezza in Occidente. Questo dato, già significativo, diventa ancora più rilevante se si considera che la mole di dati pubblicamente accessibili continua ad aumentare. L’analista umano, per quanto esperto, incontra un limite fisico invalicabile.

Il mercato globale dell’OSINT riflette questa centralità crescente: secondo Global Market Insights, il settore era valutato 12,7 miliardi di dollari nel 2025 e si prevede raggiunga i 133,6 miliardi entro il 2035, con un tasso di crescita annuo composto del 26,7%. Una traiettoria che segnala un’adozione sistematica, non più sperimentale, in governi, aziende e organizzazioni di sicurezza di tutto il mondo.

Con il calo del costo della potenza di calcolo e la sofisticazione crescente degli algoritmi, quantità sempre maggiori di dati possono essere acquisiti ed elaborati in tempo quasi reale. L’AI non sostituisce il ragionamento dell’analista: abbatte il collo di bottiglia che precede quel ragionamento, liberando risorse cognitive per le fasi a più alto valore aggiunto.

Cosa cambia con i modelli linguistici di grandi dimensioni

L’introduzione dei Large Language Model (LLM) nella toolchain OSINT ha segnato un salto qualitativo rispetto alle generazioni precedenti di automazione. Non si tratta più soltanto di parser e crawler: i modelli linguistici possono leggere, riassumere, tradurre, correlare e suggerire percorsi di indagine su testi non strutturati provenienti da fonti eterogenee.

Lo Stimson Center, nel webinar del 26 marzo 2026 organizzato congiuntamente dallo Strategic Foresight Hub e dall’Energy, Water, and Sustainability Program, ha esaminato come i sistemi guidati dall’AI stiano trasformando la pratica OSINT allargandone le applicazioni attraverso sicurezza, governance e sviluppo sostenibile, analizzando in particolare le pipeline che alimentano modelli di analisi con dati da social media e immagini satellitari, e i sistemi di machine learning che classificano e mappano eventi globali in tempo reale.

Il contributo dei modelli linguistici si articola su più livelli. In fase di raccolta, automatizzano la strutturazione di dati grezzi eterogenei rendendoli immediatamente utilizzabili per analisi successive. In fase di verifica, permettono di confrontare più fonti simultaneamente, incrociare affermazioni e segnalare contraddizioni: un analista che indaga su un profilo sospetto può usare strumenti AI per confrontare nomi utente, biografie e attività in tempo reale, identificando istantaneamente le discrepanze. In fase di esplorazione, suggeriscono nuovi percorsi investigativi quando le piste sembrano esaurite.

La capacità multilingue merita un cenno a parte. L’OSINT operata su scala globale si scontra sistematicamente con la barriera linguistica: la maggior parte dei segnali di interesse non è in inglese. I modelli linguistici attuali trattano questa barriera come una variabile secondaria, non come un ostacolo strutturale. Per approfondire il ruolo dell’AI nella cybersecurity difensiva si rimanda agli approfondimenti della redazione.

Il lato oscuro: i threat actor e l’OSINT potenziata dall’AI

Ogni capacità difensiva ha la sua controparte offensiva. L’AI applicata all’OSINT non fa eccezione, e i dati disponibili nel 2026 disegnano un quadro preoccupante ma anche, almeno per ora, parzialmente rassicurante nelle sue proporzioni effettive.

Per gli attori sostenuti da governi, i modelli linguistici di grandi dimensioni sono diventati strumenti essenziali per la ricerca tecnica, la definizione dei target e la rapida generazione di contenuti di phishing sofisticati. Il report trimestrale di Google GTIG del 12 febbraio 2026 documenta come gruppi legati a Corea del Nord, Iran, Cina e Russia abbiano operazionalizzato l’AI nella seconda metà del 2025, coprendo attività di oltre 57 gruppi APT distinti provenienti da almeno sedici paesi.

Il meccanismo è preciso: i threat actor usano l’AI per accelerare la reconnaissance e trasformare informazioni pubblicamente disponibili in piani di attacco pronti all’uso. Invece di passare manualmente in rassegna siti web, profili social, dati di breach e tracce tecniche, possono usare strumenti AI per sintetizzare grandi volumi di OSINT in note di targeting operative.

Gli LLM possono servire come moltiplicatori strategici durante la fase di reconnaissance, consentendo agli attori malevoli di profilare rapidamente target ad alto valore, identificare i decisori chiave nei settori della difesa e mappare le gerarchie organizzative, passando dalla reconnaissance iniziale al targeting attivo con velocità e scala prima impossibili.

Una precisazione fondamentale è però indispensabile per leggere correttamente questo scenario: GTIG specifica chiaramente che i threat actor stanno sperimentando con l’AI ottenendo guadagni di produttività, ma non stanno ancora sviluppando capacità genuinamente nuove che alterino in modo fondamentale il panorama delle minacce. L’AI agisce come acceleratore della tradecraft esistente, non come generatore di capacità radicalmente diverse.

Il blog Microsoft Security del 6 marzo 2026 ha documentato una dinamica ulteriore: sebbene non ancora osservata su larga scala, la sperimentazione con sistemi di AI agentici segnala un potenziale cambiamento nella tradecraft, dove flussi di lavoro supportati dall’AI assistono sempre più il processo decisionale iterativo e l’esecuzione di compiti, indicando un adattamento più rapido e una maggiore resilienza nelle intrusioni future. In particolare, il gruppo nordcoreano Coral Sleet ha già sviluppato un flusso di lavoro completamente AI-assistito per la creazione di lure, il provisioning di infrastrutture e il testing di payload.

Il termine agentico merita una definizione precisa. A differenza dei modelli linguistici reattivi, i sistemi di AI agentici si basano sugli stessi modelli sottostanti ma sono integrati in flussi di lavoro che perseguono obiettivi nel tempo, pianificando passi, invocando strumenti, valutando risultati e adattando il comportamento senza continui interventi umani.

Ancora più recentemente, al RSAC 2026 di aprile, Microsoft ha presentato dati che mostrano come l’AI stia riducendo le frizioni lungo l’intero ciclo di vita dell’attacco, aiutando i threat actor a fare ricerche più velocemente, scrivere lure migliori, generare o effettuare il debug di malware e triagare i dati rubati. Rimane tuttavia ancora un operatore umano nel ciclo che controlla le campagne, senza AI pienamente autonoma o agentiva che gestisca gli attacchi in modo indipendente.

Il paradosso della disinformazione: l’AI come problema e come soluzione

Esiste una tensione profonda al cuore dell’AI-OSINT che merita di essere nominata esplicitamente. L’AI genera contenuti sintetici in quantità e qualità crescenti, rendendo la verifica dell’informazione sempre più difficile. Al tempo stesso, l’AI è lo strumento principale che abbiamo per operare quella verifica su scala.

Secondo Blackdot Solutions, la disinformazione generata dall’AI e i deepfake rendono più difficile che mai fidarsi di ciò che si vede online. Nel 2026, i professionisti OSINT si trovano ad affrontare un bisogno ancora maggiore di verificare l’autenticità delle informazioni, poiché gli attori malevoli usano strumenti avanzati per manipolare i media e creare identità false convincenti. Sarà cruciale per le organizzazioni assicurarsi che i propri analisti siano addestrati a riconoscere i contenuti generati dall’AI; in caso contrario, rischiano di facilitare involontariamente attività criminali.

La conseguenza pratica è che la catena di verifica dell’OSINT non può più appoggiarsi soltanto sull’analisi semantica del contenuto: deve includere l’analisi della provenienza, della coerenza interna, della contestualizzazione storica e del confronto con fonti primarie di natura diversa. La verifica delle informazioni sulla proprietà effettiva di aziende, per esempio, richiede di confrontare quanto emerge da fonti online con registri societari di fonte ufficiale.

Questo introduce un rischio di concentrazione: chi ha accesso alle fonti migliori e agli strumenti più affidabili costruisce un vantaggio informativo strutturale rispetto a chi ne è privo. La democratizzazione dell’OSINT resa possibile dall’AI porta con sé, paradossalmente, una nuova forma di asimmetria. Il tema si intreccia strettamente con quello della threat intelligence e disinformazione già affrontato sulle pagine di questa rivista.

L’elemento umano: insostituibile, non residuale

Di fronte all’accelerazione tecnologica, si genera spesso una retorica della sostituzione che merita di essere corretta con precisione. Nonostante i progressi tecnologici, il giudizio e l’esperienza umana continueranno a definire i processi OSINT di maggior successo. La migliore difesa contro l’attività criminale guidata dall’AI sarà la combinazione di automazione intelligente e investigatori qualificati, in grado di validare i risultati e garantire gli standard etici.

Il punto non è che gli analisti umani siano superiori ai sistemi AI nei task di elaborazione massiva: non lo sono, e fingere il contrario sarebbe controproducente. Il punto è che l’AI tende a ottimizzare per pattern già noti, mentre l’analista umano è capace di riconoscere l’anomalia che non ha precedenti, di costruire contestualizzazioni che richiedono comprensione culturale profonda, di prendere decisioni in condizioni di ambiguità radicale.

Affidarsi esclusivamente all’AI per la totalità di un’indagine è rischioso a causa delle tendenze alla distorsione e alle allucinazioni. L’esperienza umana rimane cruciale per l’analisi contestualizzata, la verifica e il processo decisionale etico. Bilanciare correttamente l’efficienza dell’AI con l’intuizione umana sarà la chiave del successo nel 2026 e negli anni a venire.

La metafora più utile non è quella della sostituzione ma quella dell’amplificazione: l’AI amplifica le capacità degli analisti preparati e amplifica i limiti di quelli non preparati. Investire nella formazione degli operatori diventa, in questo contesto, una priorità tanto strategica quanto l’investimento negli strumenti.

Verso l’OSINT agentiva: cosa ci aspetta

Il 2026 segna un punto di transizione, non un punto di arrivo. La traiettoria tecnologica indica chiaramente la direzione: sistemi OSINT sempre più autonomi, capaci di monitorare superfici informative in continuo, aggiornare modelli di rischio in tempo reale e produrre intelligence azionabile senza intervento umano nelle fasi di raccolta e prima elaborazione.

Strumenti come Taranis AI navigano attraverso diverse fonti di dati per raccogliere articoli non strutturati, utilizzano il Natural Language Processing e l’AI per migliorare la qualità del contenuto e supportano la condivisione collaborativa di threat intelligence tramite integrazione con MISP. Non si tratta di prototipi di laboratorio, ma di sistemi operativi open source che ridisegnano già oggi il flusso di lavoro degli analisti.

La dimensione etica e di governance non è accessoria a questa trasformazione, ne è parte costitutiva. La convergenza tra AI e OSINT solleva importanti preoccupazioni in termini di governo, implicazioni etiche, legali e sociali, con la necessità di supervisione crescente a fronte di strumenti di analisi sempre più avanzati che richiedono poca o nessuna supervisione continua. Domande come: chi è responsabile delle conclusioni prodotte da un sistema AI-OSINT? Come si gestisce il falso positivo che innesca un’azione operativa? Come si bilancia la capacità di raccolta con il rispetto della privacy degli individui non coinvolti in attività illecite? Queste domande non hanno ancora risposte consolidate, ma richiedono risposte urgenti.

Conclusione: lucidità senza ingenuità

L’AI-OSINT non è una moda tecnologica né una promessa lontana. È una realtà operativa che sta già ridisegnando le pratiche di intelligence, sicurezza e investigazione in tutto il mondo. La sfida per i professionisti della sicurezza non è decidere se adottarla, ma come farlo con lucidità.

Lucidità significa riconoscere le capacità reali senza sovrastimarle: l’AI non elimina l’errore, lo sposta e lo trasforma. Significa comprendere che ogni strumento che rafforza il difensore sta, potenzialmente, rafforzando anche l’offensore: la simmetria dell’accesso è una caratteristica strutturale delle tecnologie generative. Significa anche tenere a mente che, come confermano sia Google GTIG che Microsoft, l’AI agisce oggi come acceleratore della tradecraft esistente e non come generatore di capacità radicalmente nuove: un dato che non va sottovalutato, ma nemmeno usato per abbassare la guardia.

Chi si occupa di sicurezza sa già che il vantaggio non si costruisce su un singolo strumento, ma sulla capacità di integrare strumenti, metodi e giudizio critico in un sistema coerente. L’AI è uno strumento potente. Usarlo bene è, ancora, una questione umana.

https://www.ictsecuritymagazine.com/articoli/ai-osint/

La 14ª Cyber Crime Conference, svoltasi il 6 e 7 maggio 2026 nella prestigiosa cornice dell’Auditorium della Tecnica a Roma, si conferma come appuntamento di riferimento per istituzioni, aziende, professionisti ed esperti impegnati nel contrasto alla criminalità informatica.

L’evento B2B ha offerto due giornate di analisi e approfondimento sullo stato attuale del cybercrime globale, con la presentazione di soluzioni e strategie per contrastarlo efficacemente sul piano di governance, tecnico e normativo.

Alternandosi sul palco, rappresentanti delle istituzioni nazionali ed internazionali, del mondo accademico e dell’industria hanno animato i lavori con riflessioni stimolanti e mai scontate sui temi più attuali del settore.

La prima giornata si è aperta sulla dimensione globale del fenomeno: dalla firma e implementazione della Convenzione delle Nazioni Unite contro il cybercrime illustrata dall’UNODC, alle sfide della cooperazione internazionale per l’acquisizione delle prove elettroniche affrontate dal Consiglio d’Europa, passando per le operazioni Power-Off e Lightning condotte da Europol-EC3 contro gli asset criminali, fino al punto di vista delle forze di polizia italiane – con la Polizia Postale per la Sicurezza Cibernetica – e tedesche, rappresentate dal Bundeskriminalamt.

Il pomeriggio è stato dedicato al cambio di paradigma rappresentato dall’AI agentica, con interventi su Agentic AI e nuove frontiere del cybercrime, anti-forensics e prova digitale, fino agli scenari di Cyber Warfare autonoma. A chiusura, la Tavola Rotonda “Geopolitica e Cybercrime: quando il codice diventa strumento di potere tra Stati“, che ha visto confrontarsi DIS, Bundeskriminalamt, accademia e consulenti internazionali sotto la moderazione di Cyber 4.0.

Nel corso della giornata si sono susseguiti contributi tecnici di alto profilo: software supply chain compromessa da attori nation-state, Volt Typhoon e ambienti OT, abuso di file MSC da parte degli APT, OSINT potenziato dall’AI, campagne phishing contro lo Stato, minacce hardware e vulnerabilità nei sistemi di sicurezza aerea (TCAS). A chiusura, due interventi dedicati ai limiti tecnico-giuridici dell’indagine digitale: il caso Graphite tra tecnica, diritto ed etica, e la fine della copia integrale e del sequestro “a strascico” tra barriere crittografiche, garanzie costituzionali e giurisprudenza.

La seconda giornata ha aperto sulla cornice strategica europea e nazionale, con i contributi dello European Security and Defence College (ESDC), del CASD-IASD e del Servizio per la Sicurezza Cibernetica del Ministero dell’Interno sugli attacchi alle infrastrutture critiche italiane.

Centrale la Tavola Rotonda “L‘attribuzione impossibile: identificare il nemico nell’era dell’AI e dei Proxy“, che ha riunito ROS dei Carabinieri, accademia italiana ed europea e ricercatori indipendenti di cyber in telligence, in un confronto rigorosamente transnazionale.

Come di consueto, foto, registrazioni e contenuti delle presentazioni saranno presto disponibili per tutti gli iscritti. Quest’anno, inoltre, è stata sviluppata per la prima volta una web app dalla quale è possibile -senza necessità di installazione – scaricare i materiali dell’evento e il proprio attestato di partecipazione, lasciare un feedback sull’esperienza complessiva e assegnare un punteggio ai singoli interventi.

Un sentito ringraziamento a Cyber 4.0 e SOCINT per la collaborazione, ai relatori e alle relatrici, alle aziende sponsor e a tutti gli ospiti che hanno animato queste due intense giornate di lavori. Vi diamo appuntamento il 18 e 19 novembre 2026 per la 24ª Edizione del Forum ICT Security.

https://www.ictsecuritymagazine.com/notizie/cyber-crime-conference-2026-il-resoconto-della-14a-edizione/

Con l’evoluzione delle minacce informatiche, dal ransomware agli attacchi sponsorizzati da Stati, la gestione degli incidenti è entrata stabilmente nell’agenda dei consigli di amministrazione. Le organizzazioni hanno rafforzato processi, strumenti e competenze, costruendo nel tempo strutture sempre più solide di incident response.

Eppure, quando si verifica un attacco reale, emerge una criticità ricorrente. Le aziende sanno cosa fare. Ma spesso non riescono a farlo abbastanza velocemente.

Il problema non è tecnico, né legato alla mancanza di preparazione formale. È un problema di esecuzione: coordinare persone, decisioni e azioni in tempo reale, mentre la situazione evolve rapidamente.

Spesso molte strategie di risposta falliscono per una carenza di chiarezza decisionale. Ma c’è un ulteriore elemento che, crisi dopo crisi, si dimostra altrettanto determinante: la capacità di orchestrare la risposta. Quando questa manca, anche i piani migliori restano sulla carta.

Gestire una crisi cyber: coordinamento, velocità e orchestrazione della risposta agli incidenti

In uno scenario ideale, la risposta a un incidente segue un flusso chiaro. Nella realtà, accade l’opposto.

Durante una crisi, team IT, sicurezza, legale, comunicazione, management e partner esterni devono agire simultaneamente, spesso senza avere un quadro completo e con priorità che cambiano di continuo.

In assenza di un modello di coordinamento strutturato, le organizzazioni si affidano agli strumenti più immediati: email, chat, fogli di calcolo, call improvvisate, appunti condivisi. Presi singolarmente, funzionano. Insieme, generano disordine.

Le informazioni si disperdono, le responsabilità si sovrappongono, le decisioni vengono prese su basi parziali. I vertici aziendali, chiamati a decidere rapidamente, spesso non dispongono di una visione aggiornata e coerente della situazione.

In queste condizioni, la risposta perde efficacia. Non è possibile prendere decisioni solide senza una visione d’insieme. Non è possibile eseguire un piano se non è chiaro chi debba fare cosa. E non è possibile ricostruire quanto accaduto se le informazioni sono frammentate.

La crisi, quindi, smette di essere solo un problema tecnico e diventa un problema organizzativo.

La risposta agli incidenti non è più solo tecnica

Oggi un incidente cyber coinvolge l’intera organizzazione. Non riguarda soltanto l’IT, ma impatta operatività, compliance, finanza, reputazione e relazioni con gli stakeholder. Richiede decisioni che vanno ben oltre la dimensione tecnica.

Gestire questa complessità non significa avere più documenti, ma essere in grado di coordinare azioni e persone in modo efficace.

Una gestione matura delle crisi dovrebbe garantire:

• chiarezza nei ruoli e nelle responsabilità
• visibilità in tempo reale su attività e criticità
• flussi operativi adattabili al tipo di incidente
• tracciabilità delle decisioni e delle escalation
• comunicazione coordinata tra tutte le funzioni coinvolte
• una documentazione centralizzata

In assenza di questi elementi, anche il miglior piano rischia di fallire nel momento dell’esecuzione.

Un modello superato: la “war room” fisica

Per anni, la gestione delle crisi si è basata su un presupposto implicito: riunire tutte le persone chiave nello stesso luogo.

Oggi questo approccio non è più realistico. Le organizzazioni operano in contesti distribuiti, con team globali, lavoro ibrido e un forte coinvolgimento di partner esterni. Le persone necessarie alla gestione di una crisi possono trovarsi in città, Paesi o fusi orari diversi.

In uno scenario di attacco, aspettare che tutti si coordinino fisicamente non è un’opzione. Ogni ritardo si traduce in conseguenze concrete: downtime prolungati, aumento dei costi, esposizione dei dati, rischi normativi e perdita di fiducia.

Il modello tradizionale, quindi, non è più adeguato.

La risposta: una “war room” virtuale

Per rispondere a questa evoluzione, sempre più organizzazioni adottano un approccio basato su un centro di comando virtuale.

Una war room digitale consente di riunire immediatamente tutte le figure coinvolte, indipendentemente dalla loro posizione geografica, e di creare un unico punto di coordinamento.

I vantaggi sono evidenti:

• accesso immediato per tutti i team coinvolti
• visibilità in tempo reale per il management
• assegnazione chiara delle attività
• comunicazione centralizzata
• tracciamento continuo delle decisioni
• coinvolgimento rapido di partner esterni

In questo modo, non sono più le persone a doversi spostare verso il luogo di coordinamento: è il coordinamento che si adatta alle persone. Non si tratta solo di efficienza operativa, ma di velocità di risposta. In una crisi, iniziare subito fa la differenza.

Senza un punto di orchestrazione condiviso, la gestione si frammenta rapidamente in flussi paralleli e non sincronizzati. Con una regia centralizzata, invece, anche team distribuiti possono operare come un’unica unità.

Più visibilità, decisioni migliori

La capacità decisionale, già centrale nella gestione delle crisi, dipende direttamente dalla qualità delle informazioni disponibili.

I decisori devono poter comprendere in ogni momento cosa è stato fatto, cosa è in corso, cosa è bloccato, quali sistemi sono coinvolti e quali rischi stanno emergendo.

Senza questa visione, le decisioni diventano ipotesi. E quando le decisioni non sono supportate da dati chiari, aumenta il rischio di paralisi.

Un approccio orchestrato consente invece di monitorare costantemente l’evoluzione della crisi, stabilire priorità sulla base di evidenze e correggere rapidamente la direzione.

È questo che permette di passare da una gestione reattiva a una realmente governata.

Dopo la crisi: il tema della responsabilità

Un aspetto spesso sottovalutato riguarda ciò che accade dopo l’incidente. Ogni crisi significativa genera inevitabilmente una serie di domande: cosa è successo, quando è stato rilevato, chi ha deciso, perché sono state intraprese determinate azioni. Le risposte non sono richieste solo internamente, ma anche da regolatori, clienti, assicuratori e stakeholder.

Se la gestione è avvenuta attraverso strumenti frammentati, ricostruire la sequenza degli eventi diventa estremamente complesso. Un modello coordinato, invece, produce una traccia chiara e completa: azioni intraprese, decisioni, responsabilità, evidenze di conformità.

Non è solo una questione di audit. È una forma di tutela per l’organizzazione e per chi prende decisioni.

L’orchestrazione come leva di maturità

Spesso si pensa che l’orchestrazione sia un obiettivo per organizzazioni già avanzate. In realtà, è uno strumento che porta benefici a ogni livello di maturità.

Le realtà meno strutturate ottengono ordine e chiarezza, quelle intermedie migliorano coerenza ed efficacia, le più mature rafforzano controllo e resilienza.

L’orchestrazione non sostituisce la pianificazione. La rende applicabile quando serve davvero: sotto pressione.

Dalla reazione alla gestione

Gli incidenti informatici sono inevitabili. Ciò che distingue le organizzazioni non è la capacità di evitarli completamente, ma il modo in cui li affrontano.

Le realtà più resilienti sono quelle che riescono a mantenere il focus sulle priorità, prendere decisioni senza esitazioni, coordinare l’intera organizzazione, operare con lucidità anche in condizioni critiche e ricostruire e giustificare quanto fatto. È questo che trasforma una risposta in una vera gestione della crisi.

La differenza non sta quindi nei piani disponibili, ma nella capacità di metterli in pratica. E quando questo accade, le organizzazioni non si limitano a reagire a un attacco: dimostrano di saperlo governare.

Articolo a cura di Courtney Guss, Director of Crisis Management, Semperis

https://www.ictsecuritymagazine.com/notizie/crisi-cyber/

Mag 08, 2026 Redazione In evidenza, News, RSS, Tecnologia 0

---

L’intelligenza artificiale sta, ovviamente e progressivamente, cambiando anche il modo in cui vengono condotte attività di reconnaissance, threat intelligence e analisi offensiva. Accanto ai tradizionali strumenti OSINT, stanno emergendo nuovi progetti che vanno oltre la pura automazione e puntano sulla capacità di guidare i Large Language Model attraverso metodologie operative strutturate. Uno degli esempi più interessanti è Claude-OSINT, progetto pubblicato su GitHub dallo sviluppatore “ElementalSoul” e pensato per trasformare Claude Code in una piattaforma di supporto avanzata per analisti di sicurezza, red teamer e bug bounty hunter.

Il progetto non introduce un nuovo scanner o un motore di intelligence autonomo. La sua forza risiede invece nella capacità di modificare il comportamento operativo del modello AI, fornendogli workflow, metodologie investigative, tecniche di enumerazione e processi di analisi tipici di un professionista della sicurezza offensiva.

Un nuovo approccio all’OSINT basato sugli LLM

A differenza dei framework OSINT tradizionali, Claude-OSINT non si presenta come un insieme di utility standalone. Il progetto sfrutta infatti il sistema di “skill” di Claude Code per estendere il contesto cognitivo del modello.

In pratica, il sistema inserisce all’interno dell’ambiente operativo di Claude una serie di istruzioni strutturate che insegnano al modello come affrontare attività di reconnaissance. Questo significa che Claude non si limita più a rispondere genericamente alle richieste dell’utente, ma inizia a seguire processi logici, sequenze investigative e metodologie di analisi coerenti con le pratiche del mondo offensive security.

Il repository contiene principalmente due aree operative: osint-methodology e offensive-osint. La prima definisce il modo in cui il modello deve ragionare durante la raccolta delle informazioni, mentre la seconda include template operativi, query, pattern regex, strategie di enumerazione e workflow tattici.

Uno strumento per risparmiare tempo in maniera sensata

Per chi lavora nella cybersecurity offensiva, la fase di reconnaissance rappresenta spesso una delle attività più lunghe e dispersive. Identificare asset, correlare informazioni, individuare superfici di attacco e classificare le priorità richiede tempo e competenze avanzate.

Claude-OSINT prova a intervenire proprio su questo punto, aiutando il modello AI a organizzare metodicamente le attività di raccolta delle informazioni. Secondo la documentazione del progetto, il framework include decine di moduli dedicati all’asset discovery, numerosi pattern regex per l’identificazione di secret leakage e una vasta raccolta di query e dork utilizzabili durante le indagini OSINT.

L’obiettivo è trasformare Claude in una sorta di “copilota cognitivo” capace di assistere il professionista nella costruzione di mappe relazionali, nella ricerca di endpoint interessanti e nell’identificazione di possibili punti di esposizione.

Come funziona il sistema di skill

Dal punto di vista tecnico, Claude-OSINT si basa sul sistema di skill supportato da Claude Code. Le skill sono file markdown strutturati, generalmente denominati SKILL.md, che vengono caricati all’interno dell’ambiente del modello per modificarne il comportamento operativo.

Questo significa che il framework non altera direttamente il modello AI, ma agisce tramite prompt engineering avanzato e knowledge injection contestuale. Una volta installate le skill, Claude acquisisce nuove capacità procedurali e metodologiche, imparando a seguire workflow specifici durante le attività di analisi.

Il progetto include procedure per la gestione del tempo investigativo, classificazione degli asset, prioritizzazione delle attività, correlazione delle informazioni e costruzione di report operativi. Sono presenti, inoltre, workflow dedicati all’enumerazione di domini, sottodomini, endpoint e possibili esposizioni di credenziali.

Dal punto di vista architetturale, questo approccio rappresenta un esempio molto interessante di “augmentation layer”: invece di creare un nuovo motore AI, il progetto costruisce uno strato specialistico sopra un modello generalista già esistente.

Installazione e avvio dell’ambiente

Per utilizzare Claude-OSINT è necessario avere accesso a Claude Code, l’ambiente CLI sviluppato da Anthropic per interagire con i modelli Claude.

L’installazione può essere eseguita tramite script ufficiali disponibili per Linux, macOS e Windows. Una volta configurato l’ambiente, il repository GitHub va clonato localmente e le directory contenenti le skill devono essere copiate nella cartella dedicata di Claude.

Dopo il caricamento delle skill, il modello può iniziare a utilizzare i workflow OSINT definiti dal framework. In pratica, l’utente interagisce normalmente con Claude, ma il comportamento del modello viene guidato dalle metodologie e dai processi introdotti dal progetto.

I limiti e i rischi di uno strumento del genere

Gli stessi autori del progetto sottolineano come Claude-OSINT debba essere utilizzato esclusivamente in contesti autorizzati di red teaming, penetration testing e bug bounty.

Ed è un punto cruciale, perché sistemi di questo tipo possono ridurre significativamente la barriera di accesso ad attività OSINT avanzate. Automatizzare parte del processo investigativo significa infatti aumentare velocità, capacità di correlazione e profondità dell’analisi anche per operatori meno esperti.

Questo apre inevitabilmente interrogativi più ampi sull’evoluzione dell’AI applicata alla cybersecurity offensiva. L’impressione è che il settore stia entrando in una nuova fase, in cui i modelli linguistici non saranno più semplici assistenti conversazionali, ma veri e propri “analisti aumentati” capaci di supportare operazioni complesse di intelligence e reconnaissance.

---

---

---

https://www.securityinfo.it/2026/05/08/ecco-il-github-per-fare-di-claude-un-operatore-osint-avanzato/?utm_source=rss&utm_medium=rss&utm_campaign=ecco-il-github-per-fare-di-claude-un-operatore-osint-avanzato

Mag 07, 2026 Redazione Approfondimenti, In evidenza, News, RSS, Scenario, Scenario 0

---

Il problema del dipendente “infedele” è vecchio quanto le aziende stesse, ma sembra che il panorama stia evolvendo più velocemente del previsto nella direzione sbagliata e che una parte dei lavoratori sembra aver normalizzato comportamenti che fino a pochi anni fa sarebbero stati considerati gravissimi. Un nuovo studio pubblicato dal servizio britannico per la prevenzione delle frodi (Cifas) mostra infatti un quadro estremamente preoccupante: il 13% dei lavoratori afferma di aver venduto credenziali aziendali o di conoscere qualcuno che lo ha fatto negli ultimi dodici mesi.

Il dato assume un peso ancora maggiore se si considera che un altro 13% degli intervistati ritiene “giustificabile” vendere accessi ai sistemi aziendali, soprattutto a ex colleghi o soggetti ritenuti “fidati”. Secondo gli analisti, questo fenomeno indica un cambiamento culturale profondo nel modo in cui parte dei dipendenti percepisce il valore delle credenziali digitali e la responsabilità legata alla gestione degli accessi.

Il problema è culturale, non solo tecnologico

L’aspetto più inquietante emerso dalla ricerca è che la tolleranza verso questi comportamenti aumenta con il livello gerarchico. Lo studio evidenzia infatti che il 32% dei manager, il 36% dei direttori e addirittura il 43% degli executive di livello C-suite ritengono accettabile la vendita delle proprie credenziali aziendali in determinate circostanze. Ancora più sorprendente il dato relativo agli imprenditori: l’81% degli imprenditori coinvolti nel sondaggio ha dichiarato che il comportamento può essere giustificato

Questi numeri suggeriscono che il problema non riguarda soltanto la consapevolezza degli utenti finali, ma coinvolge direttamente la governance e la cultura organizzativa. In molte aziende, infatti, le credenziali continuano a essere percepite come strumenti operativi personali, anziché come componenti critiche della superficie di attacco aziendale.

Secondo Cifas, dietro questi comportamenti si nascondono spesso motivazioni economiche, insoddisfazione lavorativa, convinzione di non essere scoperti oppure la percezione che il gesto sia “innocuo” o che non abbia vere conseguenze.

Credenziali legittime: la porta perfetta per gli attaccanti

Dal punto di vista della cybersecurity, la vendita di account aziendali rappresenta uno scenario estremamente pericoloso. Gli attaccanti cercano sempre più spesso di ottenere accessi legittimi invece di forzare direttamente le difese perimetrali e delle credenziali autentiche permettono di aggirare numerosi controlli di sicurezza, ridurre la probabilità di rilevamento e muoversi lateralmente nei sistemi con maggiore facilità.

L’uso di identità valide è ormai centrale nelle operazioni ransomware, negli attacchi supply chain e nelle campagne di cyber spionaggio. In molti casi, gli access broker acquistano o rivendono credenziali sottratte o cedute volontariamente per poi monetizzarle nei marketplace underground.

Secondo la ricerca, i settori più esposti a una maggiore tolleranza verso comportamenti fraudolenti includono IT e telecomunicazioni, dove gli utenti possiedono spesso privilegi elevati e accessi sensibili.

La sicurezza non può dipendere soltanto dai controlli tecnici

I risultati del report mostrano chiaramente come la sicurezza aziendale non possa più basarsi esclusivamente su firewall, MFA o sistemi di monitoraggio. Le organizzazioni devono affrontare il problema anche dal punto di vista culturale e organizzativo, lavorando su formazione, consapevolezza e governance degli accessi.

Secondo Cifas, la prevenzione passa attraverso la costruzione di una vera “fraud-aware culture”, nella quale ogni dipendente comprenda le conseguenze operative, economiche e legali legate alla condivisione o vendita delle credenziali.

In questo scenario, onestamente desolante, assumono un ruolo centrale i modelli Zero Trust, la segmentazione degli accessi, il principio del privilegio minimo e il monitoraggio continuo delle anomalie comportamentali. Tuttavia, ricordiamoci che anche le architetture più avanzate rischiano di diventare inefficaci se una parte significativa del personale considera normale monetizzare l’accesso ai sistemi aziendali.

---

• access broker, access governance, account compromise, Cifas, credenziali aziendali, cybercrime, cybersecurity, frodi interne, identity security, insider threat, sicurezza informatica, Zero Trust

---

---

https://www.securityinfo.it/2026/05/07/un-dipendente-su-otto-considera-accettabile-vendere-le-credenziali/?utm_source=rss&utm_medium=rss&utm_campaign=un-dipendente-su-otto-considera-accettabile-vendere-le-credenziali

Il modello Managed Detection and Response supera i limiti strutturali del SOC tradizionale. Con NovaMDR™, Sangfor Technologies e Forenova portano in Italia una soluzione che trasforma il dato grezzo in risposta operativa concreta, con copertura 24/7 e presidio umano qualificato.

Il problema non è più stabilire se un’azienda verrà attaccata, ma capire con quanta rapidità sarà in grado di accorgersene e reagire. Eppure, nella stragrande maggioranza delle organizzazioni italiane, soprattutto tra PMI e medie imprese, la distanza tra il momento in cui una minaccia si infiltra nella rete e quello in cui qualcuno se ne accorge è ancora drammaticamente ampia: ore, a volte giorni interi. Un lasso di tempo sufficiente affinché un ransomware cifri interi archivi oppure un attore malevolo esfiltri dati sensibili nel silenzio più totale.

Secondo il report IBM Cost of a Data Breach 2024, il tempo medio globale per identificare e contenere una violazione è di 258 giorni, in calo rispetto ai 277 dell’anno precedente, ma ancora un dato che descrive organizzazioni esposte per oltre otto mesi consecutivi prima di riuscire a contenere un incidente. Il costo medio per violazione ha raggiunto i 4,88 milioni di dollari, con un incremento del 10% rispetto al 2023 e il valore più alto mai registrato dal rapporto.

In Europa il quadro non è più rassicurante: secondo l’ENISA Threat Landscape 2024, il ransomware si conferma la seconda minaccia più diffusa nel panorama europeo, stabilizzata su livelli elevati nonostante le crescenti operazioni di contrasto delle autorità. Gli attacchi alla supply chain rappresentano un vettore trasversale in forte espansione, con le PMI sempre più nel mirino proprio perché percepite come anello debole delle catene di fornitura.

La risposta strutturale a questa fragilità si chiama MDR (Managed Detection and Response) e negli ultimi anni è diventata uno degli ambiti a maggiore crescita nell’intero panorama della cybersecurity globale. Non si tratta di un semplice aggiornamento tecnologico: è un cambio di paradigma nella gestione del rischio informatico aziendale.

SOC troppo costoso, SIEM insufficiente: il gap operativo che l’MDR colma

Per comprendere perché il Managed Detection and Response stia guadagnando terreno con tanta rapidità, è utile partire da ciò che non funziona nei modelli tradizionali di sicurezza informatica.

Un Security Operations Center (SOC) interno garantisce controllo e personalizzazione, ma richiede infrastrutture, personale altamente qualificato e processi strutturati che solo una minoranza di aziende può permettersi. Un sistema di monitoraggio classico basato su SIEM e raccolta di log produce volumi enormi di alert, la maggior parte dei quali sono falsi positivi che consumano tempo prezioso senza generare valore reale.

Il risultato è prevedibile: team IT esausti, minacce reali sepolte sotto tonnellate di rumore digitale e un senso diffuso di impotenza di fronte a un panorama delle minacce che evolve più velocemente delle capacità difensive interne.

Un servizio MDR interviene esattamente in questo spazio critico: non si limita a raccogliere segnali, ma li analizza, li valida e li trasforma in azioni concrete. È la differenza tra ricevere un allarme e avere qualcuno che risponde alla porta sapendo già se si tratta di un’emergenza reale o di un falso allarme.

NovaMDR™: tecnologia XDR e analisti umani per la cybersecurity aziendale italiana

In questo contesto si inserisce il lancio di NovaMDR™ sul mercato italiano, frutto della collaborazione tra Sangfor Technologies, leader globale nella cybersecurity e nel cloud computing abilitato all’intelligenza artificiale, e Forenova, provider europeo specializzato nei servizi di sicurezza gestita.

La soluzione combina una piattaforma XDR (Extended Detection and Response) con il SOC d’élite di Forenova, operativo 24 ore su 24 per 7 giorni su 7. Il vero punto di differenziazione non è però esclusivamente tecnologico: ogni alert viene convalidato da analisti esperti prima di tradursi in un’azione operativa. Questo presidio umano riduce drasticamente i falsi positivi e garantisce che le organizzazioni vengano allertate e supportate nella risposta solo quando esiste un rischio reale e verificato.

«Oggi la vera differenza non è solo intercettare una minaccia, ma sapere cosa fare nei primi minuti, quando l’impatto può ancora essere contenuto. Con NovaMDR™ trasformiamo un flusso continuo di dati e alert in decisioni operative concrete, validate da analisti esperti e attuate in tempo reale. La sicurezza non può più essere solo reattiva: deve essere gestita, proattiva e misurabile», afferma Jeffrey Zhang, Regional Manager Europa di Sangfor Technologies.

Il mercato dei servizi MDR in Italia sta crescendo in modo significativo, trainato dalla crescente consapevolezza delle imprese sui limiti degli strumenti di monitoraggio tradizionali e dalla pressione normativa derivante dalla Direttiva NIS2.

Rilevamento delle minacce in meno di 30 minuti: i KPI che fanno la differenza

Tra i parametri più significativi per valutare un servizio di Managed Detection and Response c’è il MTTD (Mean Time to Detect), ovvero il tempo medio necessario per identificare una minaccia attiva. NovaMDR™ punta a portare questo valore sotto i 30 minuti, con intervento immediato sugli incidenti reali già validati dagli analisti.

In un contesto in cui il ransomware può cifrare migliaia di file nell’arco di pochi minuti dall’attivazione del payload, questa metrica non è un dettaglio tecnico secondario: è la differenza concreta tra un incidente contenuto e una crisi aziendale a pieno regime.

Tra i benefici misurabili della soluzione figurano la riduzione significativa del carico operativo sui team IT interni grazie al filtraggio dei falsi positivi e alla contestualizzazione degli alert, la copertura completa di monitoraggio e threat hunting da parte di specialisti dedicati, l’ottimizzazione dei costi rispetto alla costruzione di un SOC interno con risparmi sostanziali su personale, licenze e infrastrutture, e il supporto strutturato alla compliance attraverso reportistica dettagliata e processi standardizzati.

Managed Detection and Response per PMI e grandi imprese: tre scenari reali

Una azienda manifatturiera con 150 dipendenti, nessun CISO interno e un responsabile IT che gestisce tutto da solo, dalla postazione del CEO alla rete di produzione: un SOC esterno dedicato costerebbe quanto assumere due specialisti senior, mentre un SIEM interno richiederebbe mesi di configurazione e competenze specialistiche non disponibili internamente. NovaMDR™ è progettato esattamente per questa realtà.

Oppure: uno studio professionale nel settore legale o sanitario, obbligato dalla normativa a garantire la riservatezza dei dati dei propri clienti, ma privo delle risorse per strutturare una funzione di sicurezza dedicata. O ancora una media impresa che fa parte della supply chain di un gruppo industriale più grande e deve dimostrare ai propri committenti un livello minimo di presidio cyber per mantenere i contratti.

In tutti questi scenari, NovaMDR™ offre una via concreta: protezione di livello enterprise, deployment completabile in pochi giorni, pacchetti di servizio modulari e un Customer Success Manager dedicato che adatta la soluzione alle esigenze specifiche dell’organizzazione, senza lunghi progetti di implementazione e senza costruire infrastrutture complesse da zero.

NIS2 e cybersecurity aziendale: l’MDR come risposta operativa alla compliance

C’è un ulteriore livello di urgenza che le imprese italiane devono considerare: quello normativo. La Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 entrato in vigore il 16 ottobre 2024, estende significativamente il perimetro dei soggetti obbligati a implementare misure di sicurezza adeguate, includendo ora anche fornitori e operatori di medie dimensioni in settori considerati critici o importanti.

Tra le misure richieste dalla norma figurano esplicitamente il monitoraggio continuo degli incidenti, la capacità di risposta rapida, la gestione della business continuity e la reportistica strutturata verso le autorità competenti. Un servizio come NovaMDR™ non è quindi soltanto uno strumento di difesa tecnica: è una vera e propria infrastruttura di compliance operativa. Fornisce la documentazione degli incidenti, i log di attività, le analisi post-incident e i processi standardizzati che le autorità e i clienti possono richiedere in caso di verifica o notifica obbligatoria.

Per le aziende che devono dimostrare la propria postura di sicurezza a committenti, partner o al regolatore, disporre di un servizio MDR attivo e documentato è sempre più un requisito contrattuale prima ancora che normativo.

Il fattore umano nella cybersecurity: perché l’AI da sola non basta

NovaMDR™ propone un approccio che va controcorrente rispetto a una narrativa dominante nel settore: quella secondo cui automazione e intelligenza artificiale possano sostituire integralmente il giudizio umano nella gestione della sicurezza informatica.

NovaMDR™ non nega il valore dell’AI: l’integrazione nativa con la piattaforma XDR garantisce visibilità profonda e correlata su rete e endpoint, con rilevamento automatizzato di pattern anomali. Sceglie però consapevolmente di collocare l’analista umano al centro del processo. Le decisioni di sicurezza e la responsabilità verso il cliente rimangono ancorate al team europeo, mentre la scalabilità tecnologica è garantita dall’ingegneria globale.

Un equilibrio che riflette una maturità nella comprensione del rischio: l’intelligenza artificiale individua, l’essere umano decide. In un dominio in cui le conseguenze di un falso negativo non gestito possono avere impatti economici e reputazionali di grande rilievo, questa filosofia non è conservatorismo tecnologico. È rigore metodologico applicato alla cybersecurity aziendale.

Sicurezza informatica proattiva: la domanda che ogni CISO dovrebbe porsi oggi

Il mercato MDR è in rapida espansione anche in Italia, spinto da una convergenza di fattori che non accenna a rallentare: pressione normativa crescente, shortage strutturale di talenti in cybersecurity, aumento della superficie di attacco legato alla digitalizzazione accelerata delle imprese.

Con oltre 4.500 clienti attivi in Italia tra pubblica amministrazione, sanità, università e imprese private, Sangfor Technologies porta su NovaMDR™ un patrimonio di esperienza concreta nel mercato locale, unito a una capacità di ingegneria globale che garantisce scalabilità e aggiornamento continuo delle capacità di rilevamento.

La vera domanda che ogni responsabile IT o CISO dovrebbe porsi non riguarda la probabilità di essere attaccati. Riguarda se, nel momento in cui accadrà, la propria organizzazione avrà gli occhi aperti oppure starà ancora analizzando i log del giorno precedente.

Per saperne di più su NovaMDR™ e sulle soluzioni di cybersecurity per le imprese italiane, visita www.sangfor.it.

https://www.ictsecuritymagazine.com/notizie/mdr-aziende-italiane/