Mentre la maggior parte delle organizzazioni gestisce già una distinta base del software (SBOM), la distinta base crittografica (CBOM) rimane in gran parte trascurata. Eppure le normative UE 🇪🇺 stanno convergendo rapidamente per rendere l’inventario crittografico un requisito obbligatorio.

Il Cyber Resilience Act (CRA) e la direttiva europea NIS2 insieme alla roadmap PQC dell’UE, stanno creando un chiaro mandato per la trasparenza crittografica: entro la fine del 2026, comprendere e gestire le proprie risorse crittografiche non sarà più facoltativo, passando da una questione di nicchia a un pilastro fondamentale per la conformità 🇪🇺.

💡PERCHÉ DOVREBBE INTERESSARTI
↳ Evita sanzioni significative per non conformità e restrizioni per l’accesso al mercato europeo ai sensi delle nuove normative UE 🇪🇺.

↳ Mitigare le vulnerabilità critiche derivanti da implementazioni crittografiche non gestite o obsolete, soprattutto con l’avvento della crittografia post-quantum (PQC).

↳ Prepararsi a revisioni operative nello sviluppo dei propri prodotti, nella gestione delle catene di fornitura (supply chain security) e nella risposta agli incidenti, che richiederanno nuovi strumenti e competenze.

💡AZIONI CONCRETE
—> occorre condurre periodicamente audit completi di tutti i componenti crittografici presenti nei dispositivi, software e sistemi digitali
—> sviluppare una solida strategia di generazione e gestione del CBOM (Critical Bill of Materials), integrandola nei framework di conformità esistenti.
—> investire in formazione e strumenti per garantire che i team possano identificare, tracciare e aggiornare efficacemente le risorse crittografiche.

💡STANDARD e REGOLAMENTI di RIFERIMENTO 🇪🇺
Questo cambiamento è promosso direttamente dal Cyber Resilience Act (CRA), dalla direttiva NIS2 e dalla roadmap PQC dell’UE, rendendo l’inventario crittografico un aspetto fondamentale per la conformità alla sicurezza informatica.

Se sviluppate, certificate o vendete prodotti digitali in Europa 🇪🇺, l’inventario crittografico è il vostro nuovo standard di riferimento per la sicurezza e la conformità.

Sistemi IoT (apparentemente) complessi, la curiosità dei gatti e la Cybersecurity

Da decenni i gatti sono un simbolo della sottocultura nerd per diversi motivi:

I meme con i gatti dominano Internet fin dai primi anni 2000. Meme come Lolcats, Nyan Cat, Grumpy Cat ecc. sono stati in parte diffusi proprio dalle prime community tech e hacker, veri primi utenti virali ma liberi di Internet.
Il trolling e l’ironia: gli hacker (specialmente quelli legati ad Anonymous e a community come 4chan) amano l’ironia e seguire la loro curiosità. Chi usa immagini di gattini simpatici in contesti seri o intimidatori lo fa per creare deliberatamente un contrasto satirico — una sorta di trolling culturale.
Nascondere qualcosa di inaspettato o incasinante (come un gatto ad esempio) dentro qualcosa di serio, nella sottocultura hacker rappresenta un classico scherzo. È il principio del bait and switch.
Anonymous e i gatti: il gruppo di hacktivisti Anonymous storicamente ha usato immagini contenenti gatti nei loro messaggi, spesso per deridere l’incompetenza tecnica delle vittime, o come firma ironica.
Simbolo di indipendenza: a differenza dei cani (Ivan Pavlov docet), i gatti sono animali imprevedibili, che non seguono regole — qualità con cui molti hacker si identificano spiritualmente.

In sostanza, dietro il rapporto tra i gatti e gli hacker non c’è una reale motivazione tecnica, ciononostante i gatti sono diventati la mascotte non ufficiale di Internet e della creatività fuori dagli schemi, e gli hacker li hanno virtualmente adottati con entusiasmo e ironia. Il poliedrico matematico nonché creatore di puzzle logici Raymond Smullyan, ad esempio, era un appassionato di gatti in modo quasi ossessivo, e i felini compaiono in molte delle sue opere in vari enigmi come elementi narrativi dei paradossi. Dai libri di Smullyan si intuisce che per lui i gatti rappresentavano creature che esistono al di fuori delle regole (e/o delle certezze) imposte — esattamente come l’ideale di molti hacker.

Un hacker che metta un gatto in un sistema compromesso sta dicendo, inconsciamente o meno, la stessa cosa che prova a trasmetterci Smullyan nei suoi testi e con le sue dimostrazioni di logica formale: “le regole sono costruzioni umane arbitrarie, ma io — come un gatto — posso provare a sovvertirle se trovo la chave giusta per aggirarle con un approccio creativo differente”.

Windows Server e la crittografia Post-Quantum

Microsoft ha appena rilasciato il primo vero aggiornamento che include crittografia PQC (Post-Quantum Cryptography) per Active Directory CS (Certificate Services).

Windows Server 2025 d’ora in avanti supporta gli algoritmi ML-DSA in Active Directory CS (KB5087539), inclusi i modelli di certificati digitali PQC e il supporto per la loro registrazione.

Un passo importante verso l’integrazione della crittografia PQC nell’ecosistema PKI di Microsoft.

Link vari di approfondimento:
– Link1
– Link2
– Link3

Realizzare PKI con sw open-source

Acronimo di Enterprise JavaBeans Certificate Authority, EJBCA è un interessante software open-source per mettere in piedi un’infrastruttura a chiave pubblica (PKI) in grado di avvalersi di crittografia PQC (Post Quantum Cryptography) per emettere e proteggere i certificati digitali dei propri utenti e dispositivi.
Gestito e sponsorizzato dalla società svedese PrimeKey Solutions AB, il pacchetto software EJBCA può essere utilizzato per installare un’autorità di certificazione (una CA), un’autorità di convalida e un’autorità di registrazione gestibili privatamente.
Ormai giunto alla versione 9.4.2 nel momento in cui sto scrivendo, il software EJBCA è utilizzato per gestire autorità di certificazione (CA) in diversi contesti, tra cui e-Government, endpoint management, sistemi IoT, energia, telecomunicazioni, eIDAS, networking e perfino nell’ambito delle PMI.

Una Certification authority **EJBCA** sotto forma di appliance

Ma perché adottare una CA privata quando sono già disponibili quelle pubbliche? Il caso della compromissione della CA DigiNotar, nel 2011, rappresenta probabilmente uno degli esempi più emblematici dei rischi associati all’adozione di autorità di certificazione (CA) pubbliche. In un’infrastruttura PKI (Public Key Infrastructure), una Certification Authority (CA) è responsabile dell’emissione e della firma digitale dei certificati che attestano l’associazione tra una chiave pubblica e l’identità di un dominio o di un’entità. Nel modello delle CA pubbliche, tali certificati sono implicitamente considerati affidabili dai browser e dai sistemi operativi poiché inclusi nei trust store globali. Nel caso di DigiNotar, un attacker riuscì a compromettere l’infrastruttura della CA e a generare certificati fraudolenti per domini di alto profilo, tra cui servizi di Google. Poiché i certificati risultavano firmati da una CA pubblica riconosciuta, i browser li accettavano automaticamente come validi. Questo rese possibile l’esecuzione di attacchi MiTM (man-in-the-middle) su larga scala, intercettando comunicazioni HTTPS apparentemente sicure. L’incidente dimostrò come la compromissione di una singola CA pubblica possa avere conseguenze sistemiche sull’intero ecosistema di fiducia del web.

Una CA privata, al contrario, opera in un contesto di fiducia limitato (private trust domain). I certificati emessi non sono riconosciuti universalmente, ma solo dai sistemi configurati esplicitamente per fidarsi di quella specifica root CA. Questo riduce significativamente la superficie di attacco e l’impatto di un’eventuale compromissione: un certificato fraudolento sarebbe accettato solo all’interno dell’infrastruttura organizzativa e non dall’intera Internet.

Dal punto di vista della sicurezza operativa, inoltre, una CA privata consente un controllo più rigoroso delle policy di emissione, dei processi di autenticazione delle entità richiedenti nonché della protezione delle chiavi critiche (ad esempio tramite HSM e segmentazione della rete). In sintesi, mentre le CA pubbliche offrono scalabilità e interoperabilità globale, le CA private riducono il rischio sistemico limitando l’ambito di fiducia e migliorando il controllo amministrativo dell’infrastruttura crittografica 🔐

Link di approfondimento:
– Link1
– Link2
– Link3

Analisti S.O.C. oppure insider?

Due analisti di sicurezza informatica (S.O.C.) di recente si sono dichiarati colpevoli di attacchi ransomware.

Ryan Goldberg era un manager che si occupava di DFIR (Digital Forensics Incident Response) per la società Sygnia. Viceversa, Kevin Martin ricopriva il ruolo di negoziatore di ransomware presso DigitalMint.

Il loro lavoro era proteggere le aziende da cyber gang e attacchi informatici.
E invece, sono diventati degli hacker…della peggior specie: degli insider.

Tra maggio e novembre 2023 hanno attaccato cinque aziende statunitensi usando il ransomware BlackCat, tra cui:
– un’azienda di dispositivi medici in Florida
– un’azienda farmaceutica nel Maryland
– un produttore di droni in Virginia

Ad una sola vittima hanno estorto ben 1,3 milioni di dollari in bitcoin.

I pubblici ministeri hanno affermato che hanno “abusato di una posizione di fiducia pubblica o privata” e hanno utilizzato “speciali competenze” per commettere i loro crimini.

Sapevano esattamente come le aziende reagiscono agli attacchi ransomware. Conoscevano i loro punti deboli.
E soprattutto, sapevano cosa induce le vittime a pagare per poter avere indietro i loro dati e ottenere il ripristino tempestivo dei loro sistemi.

E hanno usato questa conoscenza per diventare dei moderni predoni. Ma gli è andata male: entrambi ora rischiano fino a 20 anni di carcere federale.

Ogni team di sicurezza informatica dovrebbe basarsi sulla fiducia: la fiducia che le persone che hai ingaggiato o con cui collabori per difendere l’organizzazione in cui lavori o le aziende clienti non siano mai e poi mai quelle da temere ma quelle su cui poter contare, che siano persone non dico sante, ma verosimilmente persone oneste e affidabili.
Prima di poter iniziare la loro professione, gli aspiranti medici si impegnano a prestare fedeltà al “giuramento di Ippocrate” per il resto della loro vita professionale, perché gli analisti S.O.C. non hanno qualcosa di equivalente?

Fonti e letture di approfondimento:
– Link1
– Link2
– Link3

Usi una password o una passphrase? Il caso del furto al Louvre

In questo periodo è ancora su tutti i giornali e su centinaia di blog il caso del furto al Louvre, “il Museo” per definizione.

Non solo per il prestigio del museo e della città (“Paris, je t’aime!”) scalfiti (seppur solo temporaneamente) da questo incidente informatico contestuale al furto dei gioielli, quanto per le inettitudini a livello di gestione della Cybersecurity – questa materia complessa e variegata, piena di sigle strumenti e protocolli, di svariate figure professionali, che pur tuttavia si regge solo rispettando i suoi pilastri (“best practice“) e le sue fondamenta strutturali – che hanno favorito il furto.

E una delle regole fondamentali della Cybersecurity (vera, non a chiacchiere) è: devi avere un sistema di autenticazione (caro utente dietro la connessione in arrivo, ma CHI diavolo sei?) dietro cui ci sia un sistema autorizzativo (dimmi appunto prima CHI sei, e ti dirò COSA sei AUTORIZZATO o meno a fare nel SISTEMA).

Gli enti pubblici spendono milioni di euro (o dollari) in consulenze, infrasrutture, server, certificazioni, appliance e quant’altro il (ricco) mercato della Cybersecurity mette a disposizione, ma spesso mancano le basi, si trascurano i dettagli delle fondamenta strutturali e si dà per scontato questo o quello. Accade in Italia così come all’estero.
Ed è stato questo, ad esempio, proprio ciò che è successo al sistema di videosorveglianza del Louvre, evidentemente gestito con negligenza a livello di sicurezza (chi ha configurato i dispositivi ha impostato “Louvre” 🙃 come password: una lezione di (in)sicurezza informatica da 100 milioni di dollari che – almeno i parigini – ricorderanno a lungo).

Le interfacce di management di una webcam, di un sistema di videosorveglianza e/o di un qualunque altro dispositivo IoT che ha un piede su Internet devono essere configurate con password lunghe e complesse, o ancor meglio con una passphrase facile da ricordare ma non banale né corta (es: “EvvivaLEuropaUnitaOraESempre”)

Non rispetti queste semplici regole? Dai tuoi tecnici fai gestire con superficialità gli aspetti di sicurezza informatica dei tuoi sistemi ICT/OT? Non effettui un monitoraggio proattivo e meticoloso di ciò che accade nel tuo datacenter attraverso SIEM né EDR?
Spiacente, ma la prossima vittima di un databreach o di un’intrusione informatica (con conseguente furto fisico o digitale) potresti essere tu.

P.S.: accertarsi se l’interfaccia di management di un dispositivo (webcam, router, access point ecc..) e/o API e/o webapp sia stata o meno configurata con una password banale non è un processo lungo e complicato, basta un ICT audit o un vulnerability assessment fatto a dovere da un professionista del settore (…come, guarda caso, il sottoscritto).

Link di approfondimento:
– Link1
– Link2
– Link3

PhaaS/AiTM toolkit

Interessante Adversary-in-the-Middle (AiTM) phishing kit… valida alternativa commerciale a Evilginx Pro

Link di approfondimento:
– Link1
– Link2
– Link3

nmap, una galassia di possibilità

Ancora oggi, molti addetti ai lavori utilizzano questo magnifico tool di Fyodor con superficialità… ad esempio in molti credono che da nmap non sia possibile farsi restituire solo gli indirizzi IP (quindi senza gli ulteriori dettagli che il tool normalmente ci restituirebbe) che hanno effettivamente la porta che ci interessa in stato open, ma come si evince da questa schermata, è possibile farlo concatenando in pipe qualche comando bash.

Di seguito il comando testuale se desideri (ri)utilizzarlo:
nmap -n -Pn target/subnet -p3389 -oG – | grep ‘/open/’ | awk ‘/Host:/{print $2}’
(attenzione agli apici e al simbolo – quando incollerai questo codice nella tua shell: riconfrontali con la videata, poiché WordPress cambia volutamente gli apici)

target/subnet va ovviamente sostituito con la sottorete che desideri scansionare (ma puoi inserire banalmente anche un unico target /32), come nella scansione che vedi in videata (da cui è possibile desumere che un sysadmin imprudente abbia lasciato raggiungibili da Internet ben 11 servizi RDP!), mentre immediatamente a destra del flag -p va inserito il numero di porta che ti interessa verificare (da remoto o in locale).

P.S.: è possibile personalizzare ulteriormente il comando per farsi restituire anche l’hostname del target di cui nmap rileva la porta aperta.

Letture di approfondimento:
– “Nmap Network Exploration” (Calderon, 2021)
– “Nmap Network Scanning: A Complete Guide to Exploring And Scanning Networks With NMAP” (S. Gellis, 2024)

NTLM reflection vulnerability, di nuovo!

CVE-2025-33073 è una vulnerabilità sfruttabile da remoto (RCE) se sul target (sistemi Windows) è attivo il servizio SMB sprovvisto di firma digitale nei domini AD (Active Directory) on-premises in cui il sysadmin ha lasciato le impostazioni di default (diciamo il 99% dei casi?🤑😱😈).

Perché dovresti preoccupartene se non hai ancora aggiornato Windows? Poiché sfruttando questa vulnerabilità, un attacker riuscirebbe a fare privilege escalation (permette di ottenere i permessi da SYSTEM partendo da un account con pochi privilegi) in poco tempo sulla maggior parte di host Windows sprovvisti di firme SMB.

Per agevolare il rilevamento dell’exploit è possibile utilizzare la seguente query KQL progettata per identificare richieste DNS sospette, ossia con informazioni di destinazione potenzialmente indicative dello sfruttamento di CVE-2025-33073

Link di approfondimento:
– Link1
– Link2 (PoC originale, pubblicata il 14-giugno-2025)
– Link3 (PoC di approfondimento)