(in)sicurezza digitale

2026-05-20 14:41:42

Intelligenza artificiale, responsabilità e cybersicurezza: il punto sul convegno di Cagliari

Si parla di:
Toggle

Nel grande auditorium dell’ARNAS G. Brotzu di Cagliari, si parla di intelligenza artificiale, responsabilità e cybersicurezza nel sistema sanitario nazionale. Sul palco si alternano dirigenti pubblici, giuristi, esperti di compliance, rappresentanti istituzionali e figure di primo piano della sicurezza informatica italiana.

Un convegno importante per far diventare la cybersicurezza un tema per tutti

I temi sono quelli inevitabili del momento: AI generativa, governance del dato, regolamentazione europea, rischio cyber, continuità operativa, resilienza.

Il tono è solenne, spesso tecnico, quasi rassicurante. Si parla di protezione delle infrastrutture critiche, di necessità di regolamentare l’uso dell’intelligenza artificiale, di responsabilità giuridica e organizzativa. Ma mentre scorrono le slide e si susseguono gli interventi, emerge una sensazione difficile da ignorare: manca il protagonista principale di tutta questa discussione. Il dato sanitario reale. Quello che ogni giorno viene esposto, rubato, venduto, pubblicato o utilizzato senza controllo.

Il convegno è stato un momento di grande opportunità per innescare discussioni sul tema a me molto a cuore: la cybersicurezza nazionale. E gli interventi sono stati un momento importante per sentire punti di vista e situazione attuale nel campo della sanità. Ciò che mi piacerebbe introdurre con questo articolo, vista la qualità della discussione introdotta dal convegno, è la necessità come paese Italia di fare un passo indietro rispetto a ciò che attualmente occupa il maggior spazio nelle scrivanie decisionali, di vedere cosa davvero sta succedendo ai dati dei cittadini italiani.

Il mio intento con questo intervento è quello di farci porre delle domande affinché si possano innescare processi per migliorare eventuali situazioni quotidiane.

Il dato sanitario purtroppo è già ovunque

C’è un paradosso evidente. Tutti concordano sul fatto che il dato sanitario sia “speciale”, “sensibile”, “delicato”, “meritevole di protezione rafforzata”. Eppure quasi nessuno affronta davvero cosa accade quando questi dati finiscono fuori controllo. Nessuno racconta il destino concreto delle cartelle cliniche sottratte durante gli attacchi ransomware. Gli unici interventi che si sono avvicinati a centrare questo punto sono stati il brillante discorso introduttivo del Gen CdA Luciano Carta e quello del Gen CdA Leandro Cuzzocrea entrambi con una visione estramente strategica del mondo criminale dei dati. Che poi è esattamente ciò che occorre su questo tema al Paese Italia.

Nessuno spiega dove finiscono referti, analisi, documenti oncologici, dati psicologici, informazioni genetiche o amministrative una volta pubblicati sui leak site dei gruppi criminali. Nessuno sembra voler affrontare il fatto che, in Italia, gli attacchi contro strutture sanitarie non siano scenari ipotetici o eventualità remote, ma eventi ormai sistematici.

Basta osservare quanto monitorato negli ultimi anni da piattaforme indipendenti come quella sviluppata e mantenuta da me Ransomfeed, che da tempo traccia le rivendicazioni ransomware pubblicate dai gruppi criminali a livello globale. Nel database compaiono ASL, aziende ospedaliere universitarie, strutture territoriali, centri diagnostici e realtà sanitarie italiane finite nel mirino di operatori ransomware ovunque nel tempo: c’è Lazio Crea del 2020 ma dopo quello ce ne sono nel 2021, 2022, 2023, 2024, 2025. Non episodi isolati, ma una sequenza costante di compromissioni che racconta un fenomeno strutturale. Alcuni casi sono rimasti confinati ai disservizi temporanei; altri hanno comportato la sottrazione e pubblicazione di grandi quantità di documentazione sanitaria e amministrativa.

È assolutamente prioritario e strategico sapere e far sapere a tutti i cittadini che questi Terabyte di dati persi nell’Internet e nelle mani criminali, sono gli stessi dati alla base di altri attacchi personali ai cittadini. Sono spesso la risposta alla domanda che spesso ci poniamo su Come ha fatto questo numero sconosciuto dall’Africa a inviarmi un SMS/messaggio Whatsapp, con una truffa a tema bancario?

Eppure, durante il convegno, il tema dominante sembra essere soprattutto la resilienza operativa. Il backup. Il ripristino rapido. La continuità del servizio. Elementi certamente fondamentali, ma che spesso finiscono per ridurre il problema cyber a una semplice questione di disponibilità dei sistemi. Come se il vero obiettivo fosse soltanto “riaccendere tutto il prima possibile”. Come se la perdita definitiva del controllo sui dati fosse un danno secondario.

Ma nel settore sanitario il problema non è soltanto il downtime. È la persistenza del danno. Un referto medico pubblicato online non può essere “ripristinato” da un backup. Una diagnosi oncologica esfiltrata non può essere annullata. Una banca dati sanitaria sottratta e venduta può continuare a circolare per anni in forum criminali, marketplace underground, archivi privati o circuiti di estorsione. E questo aspetto sembra quasi assente dal dibattito istituzionale.

Dico quasi perché effettivamente mi sono ritrovato molto nel discorso conclusivo del Prof. UNICAL Mario Caligiuri, che in qualche modo ha tracciato una “strada del pericolo” di quello che realmente sta già accadendo da anni.

Anche l’AI non è nemica, il problema è caricarci dentro dati sensibili

Lo stesso discorso vale per l’intelligenza artificiale. Sul palco si discute di AI Act, governance, responsabilità dell’algoritmo, supervisione umana. Ma raramente emerge una domanda molto più concreta: cosa accade quando personale sanitario, amministrativo o tecnico inizia a utilizzare chatbot di AI generativa caricando documenti clinici, referti o informazioni dei pazienti? Dove finiscono quei dati? Come vengono trattati? Vengono conservati? Utilizzati per training? Processati da terze parti? Quali controlli esistono realmente nelle strutture pubbliche?

È una questione enorme, eppure ancora affrontata in modo marginale. In molte realtà sanitarie italiane manca completamente una cultura operativa capace di gestire questi strumenti. Il rischio non è teorico. È quotidiano.

Basta osservare cosa accade negli ospedali: porte USB liberamente utilizzabili, workstation condivise, installazione incontrollata di software terzi, accessi a servizi cloud esterni, credenziali riutilizzate, navigazione senza restrizioni, segmentazione di rete insufficiente. In alcuni casi persino software obsoleti e dispositivi medicali non aggiornabili continuano a convivere con infrastrutture moderne.

Tutto questo è sicuramente governance, ma non che sia ancora da normare. È tutto perfettamente normato, ma l’attuale infrastruttura non ne permette la precisa attuazione, purtroppo, all’interno della pubblica amministrazione, come invece avviene da decenni nelle grandi aziende private (come giustamente indicato dal responsabile della sicurezza informatica di Poste Italiane, Rocco Mammoliti).

Il contrasto tra il linguaggio istituzionale del convegno e la realtà operativa percepibile sul campo è netto. Da una parte la narrazione strategica, fatta di regolamenti, framework e governance. Dall’altra la quotidianità di strutture spesso prive di risorse adeguate, personale insufficiente, processi fragili e superfici di attacco enormi. E soprattutto una mancanza cronica di trasparenza pubblica su ciò che avviene dopo un incidente.

Anche il post incidente è una questione di sicurezza

Perché il vero nodo è anche questo: in Italia si parla pochissimo delle conseguenze concrete degli attacchi cyber sulla sanità. Quando una struttura viene colpita, il dibattito si concentra sul blocco dei servizi, sulle prenotazioni sospese, sui disagi temporanei. Molto meno sulla sorte dei dati sottratti. Raramente i cittadini vengono informati in modo chiaro su cosa sia stato realmente esfiltrato, dove quei dati possano finire o quali rischi futuri possano derivarne.

Ed è forse proprio qui che emerge il limite più evidente di molti eventi istituzionali sul tema cybersecurity: la distanza tra il racconto teorico della sicurezza e la realtà pratica delle compromissioni. La cybersicurezza sanitaria non può essere ridotta a compliance normativa o disaster recovery. Richiede una presa di coscienza molto più dura: i dati sanitari italiani sono già oggi un bersaglio costante del cybercrime internazionale, e in molti casi sono già stati sottratti.

Continuare a trattare questi temi come eccezioni anziché come parte di una crisi strutturale rischia di produrre soltanto altra burocrazia, altra documentazione e altri tavoli tecnici. Mentre nel mondo reale, i leak site ransomware continuano ad aggiornarsi. Ogni settimana. Anche con nomi italiani.

Ransomfeed

^Ransomfeed

Spcnet.it

2026-05-19 14:33:40

Passkey in Microsoft Entra ID: perché l’enforcement con Conditional Access è fondamentale

Introduzione: le passkey non bastano da sole

Le passkey rappresentano uno dei passi più significativi nell’evoluzione dell’autenticazione moderna. Basate sullo standard FIDO2, eliminano le password tradizionali sostituendole con coppie di chiavi crittografiche legate al dispositivo e all’identità biometrica dell’utente. Su Microsoft Entra ID, abilitare le passkey è diventato relativamente semplice — il vero problema emerge subito dopo: abilitarle non significa renderle obbligatorie.

Molte organizzazioni configurano le passkey come metodo di autenticazione disponibile e si fermano lì, convinte di aver rafforzato significativamente la loro postura di sicurezza. In realtà, senza un enforcement esplicito tramite Conditional Access, l’utente può ancora scegliere di autenticarsi con password e SMS — esattamente come prima. Questo scenario introduce un rischio spesso sottovalutato: il downgrade attack.

Cos’è un downgrade attack nel contesto dell’autenticazione

Un downgrade attack, nell’ambito dell’autenticazione, non è un attacco sofisticato nel senso tradizionale del termine. È semplicemente la possibilità di utilizzare un metodo di autenticazione meno sicuro rispetto a quello ideale. Dal punto di vista dell’utente, si manifesta come il familiare link “Accedi in un altro modo” nella schermata di login di Microsoft.

Gli attaccanti dispongono di toolkit avanzati — come Evilginx2 o strumenti analoghi — capaci di rilevare automaticamente quali metodi di autenticazione sono disponibili per un determinato account. Se il sistema accetta password + SMS come alternativa alla passkey, l’attaccante sfrutterà il percorso più debole. La passkey registrata diventa di fatto irrilevante dal punto di vista della sicurezza pratica.

Il problema non è tecnico, è organizzativo: manca il tassello dell’enforcement. Ed è qui che entra in gioco Conditional Access insieme alle Authentication Strengths.

Authentication Strengths: il fondamento dell’enforcement

Microsoft Entra ID offre il concetto di Authentication Strength come meccanismo per specificare non solo che si richiede la MFA, ma quali specifici metodi sono accettati. Esistono tre Authentication Strengths predefinite:

• Multifactor authentication — la più permissiva, accetta password + qualsiasi secondo fattore (incluso SMS)
• Passwordless MFA — richiede metodi senza password, come Windows Hello o Microsoft Authenticator
• Phishing-resistant MFA — la più restrittiva, accetta solo certificati, Windows Hello for Business, passkey FIDO2

Il problema è che la maggior parte delle organizzazioni usa ancora la prima categoria — quella meno restrittiva. Alcune sono migrate dalla vecchia grant control “Require MFA”, ma si sono fermate al livello base. Usare Phishing-resistant MFA come Authentication Strength è già un passo corretto, ma la vera potenza arriva con le Custom Authentication Strengths.

Custom Authentication Strengths: controllo granulare

Le Authentication Strengths personalizzate permettono di specificare esattamente quali metodi sono ammessi, incluso il vincolo a specifici tipi di passkey tramite gli AAGUID (Authenticator Attestation GUID). Ogni tipo di passkey certificata — YubiKey 5C NFC, Google Titan, Microsoft Authenticator su iOS — ha il proprio AAGUID. Limitare l’accesso a specifici AAGUID garantisce che solo i dispositivi approvati dall’organizzazione possano autenticarsi.

Questo livello di granularità è particolarmente importante per gli account amministrativi, dove il rischio di compromissione è massimo.

Configurare la policy Conditional Access di baseline

Il punto di partenza consigliato è una policy di Conditional Access che prenda di mira un gruppo pilota di utenti che hanno già registrato una passkey. La policy deve:

1. Essere creata inizialmente in modalità report-only per monitorare l’impatto senza bloccare gli accessi
2. Targetizzare un security group contenente gli utenti del pilota
3. Usare la grant control “Require authentication strength” con l’Authentication Strength appropriata
4. Essere attivata in produzione solo dopo aver verificato i log di accesso e confermato che tutti gli utenti del gruppo hanno una passkey funzionante

Man mano che più utenti registrano le passkey, il gruppo viene espanso. Questo approccio graduale riduce il rischio di lockout e costruisce fiducia nelle varie business unit.

Account amministrativi: requisiti più stringenti

Gli account privilegiati richiedono una policy separata e più restrittiva. Le considerazioni principali sono:

• Creare una Custom Authentication Strength dedicata agli amministratori che accetti solo passkey specifiche (con AAGUID approvati)
• La policy Conditional Access per gli admin deve targetizzare esclusivamente le identità amministrative
• Aggiungere condizioni supplementari: accesso solo da reti trusted, dispositivi compliant o hybrid-joined
• Mantenere policy separate per accessi admin e utenti standard: facilita il troubleshooting e riduce la complessità

Un pattern comune negli ambienti Entra è la mancanza di protezioni specifiche per gli account amministrativi. Spesso questi account non hanno policy Conditional Access dedicate, o le policy esistenti si basano su MFA generica anziché su metodi phishing-resistant. Gli account amministrativi sono il bersaglio primario degli attaccanti: una compromissione a questo livello equivale a una compromissione del tenant.

Come usare i Sign-in Logs per verificare l’efficacia

Una volta attivate le policy in report-only, i log di accesso di Entra ID mostrano il risultato teorico della policy per ogni accesso. Per ogni evento di login è possibile vedere quale Authentication Strength è stata valutata, se l’accesso avrebbe soddisfatto i requisiti e quale metodo è stato effettivamente utilizzato.

Filtrando per gli utenti del gruppo pilota è possibile identificare chi ancora non ha registrato una passkey o chi tenta di usare metodi alternativi. Questo permette un’azione proattiva prima di attivare la policy in enforcement completo.

Conclusione: l’enforcement è dove il valore si manifesta

Le passkey sono una tecnologia potente e in rapida evoluzione, soprattutto nell’ecosistema Microsoft. Ma la loro efficacia dipende interamente dall’enforcement. Distribuire passkey senza Conditional Access che ne imponga l’uso equivale a blindare la porta principale lasciando le finestre aperte.

La sequenza corretta è: abilitare le passkey → creare le Custom Authentication Strengths appropriate → configurare le Conditional Access policy in report-only → espandere gradualmente il gruppo → attivare l’enforcement. Gli account amministrativi richiedono attenzione immediata e policy separate con requisiti più stringenti, incluso il binding a AAGUID specifici.

In un contesto di minacce sempre più sofisticate — con phishing kit come Tycoon 2FA che aggirano la MFA tradizionale — i metodi phishing-resistant non sono più un’opzione premium: sono il requisito minimo per chi gestisce identità critiche nel cloud Microsoft.

---

Fonte: Passkeys Aren’t Enough: Why Enforcement Matters in Entra ID — Petri IT Knowledgebase, Brandon Colley (TrustedSec)

Passkeys Aren’t Enough: Why Enforcement Matters in Entra ID - Petri IT Knowledgebase

Implementing passkeys in Microsoft Entra is far more than simply enabling a new authentication method. A successful passkey rollout requires careful planning

^{Brandon Colley (Petri IT Knowledgebase)}

(in)sicurezza digitale

2026-05-19 13:01:17

QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software

Si parla di:
Toggle

Un nuovo implant Linux mai documentato prima — denominato Quasar Linux RAT (QLNX) — sta prendendo di mira sviluppatori e ambienti DevOps con l’obiettivo di appropriarsi silenziosamente delle credenziali più preziose del ciclo di sviluppo software: token npm, PyPI, AWS, Kubernetes, GitHub e molto altro. La scoperta, opera dei ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim di Trend Micro, descrive uno strumento che non si limita ad essere un semplice trojan di accesso remoto, ma una piattaforma di spionaggio industriale progettata per persistere, nascondersi e colpire l’intera supply chain del software.

Cosa rende QLNX diverso dagli altri RAT Linux

A differenza di molti implant Linux che puntano sulla semplicità, QLNX è costruito come una piattaforma d’attacco coerente e modulare. Il suo punto di forza non sta in una singola tecnica innovativa, ma nell’integrazione armoniosa di più capacità offensive che si concatenano in un flusso d’attacco preciso: arriva, cancella le tracce dal disco, si radica con sei meccanismi ridondanti, si nasconde sia a livello userspace che kernel, e infine raccoglie sistematicamente le credenziali che contano davvero.

Il malware esegue filelessly dalla memoria, mascherandosi da thread del kernel attraverso nomi come kworker o ksoftirqd — nomi che ogni amministratore di sistema Linux incontra quotidianamente nei propri processi. Questo lo rende praticamente invisibile a una normale ispezione manuale. È inoltre in grado di profilare l’host per rilevare ambienti containerizzati, cancellare i log di sistema e stabilire persistenza attraverso non meno di sette metodi diversi, tra cui systemd, crontab e shell injection nel file .bashrc.

Un harvester di credenziali pensato per la supply chain

Il componente di furto credenziali di QLNX è ciò che lo rende particolarmente pericoloso per l’ecosistema open source. Il malware estrae sistematicamente segreti da un elenco preciso di file ad alto valore per uno sviluppatore:

File target di QLNX per il furto credenziali:

.npmrc              → Token di pubblicazione npm
.pypirc             → Credenziali PyPI
.git-credentials    → Credenziali Git
.aws/credentials    → Chiavi di accesso AWS
.kube/config        → Credenziali Kubernetes
.docker/config.json → Autenticazione Docker Registry
.vault-token        → Token HashiCorp Vault
.env                → Variabili d'ambiente con segreti
**/terraform.tfvars → Credenziali Terraform
GitHub CLI tokens   → Token di accesso GitHub

Il rischio non è solo per lo sviluppatore compromesso: un attore che ottiene accesso a uno di questi token può pubblicare pacchetti malevoli su npm o PyPI, accedere all’infrastruttura cloud o muoversi lateralmente attraverso pipeline CI/CD. È esattamente il meccanismo che ha consentito attacchi supply chain devastanti in passato, come l’operazione TeamPCP che ha colpito oltre 160 pacchetti npm e PyPI nelle scorse settimane.

Architettura rootkit a doppio livello: LD_PRELOAD + eBPF

L’aspetto più sofisticato di QLNX è la sua architettura rootkit a due livelli, che combina tecniche di occultamento a livello userspace e kernel.

Il primo strato è un rootkit userland deployato attraverso il meccanismo LD_PRELOAD del dynamic linker di Linux. Questo garantisce che tutti gli artefatti e i processi dell’implant rimangano nascosti agli strumenti di ispezione standard. Il secondo strato è un componente kernel-level basato su eBPF (Extended Berkeley Packet Filter) — il potente sottosistema Linux originariamente pensato per il networking e l’osservabilità dei sistemi. QLNX sfrutta eBPF per nascondere processi, file e porte di rete agli strumenti userland come ps, ls e netstat, su istruzione del server di comando e controllo (C2).

L’uso offensivo di eBPF per il rootkitting è una tendenza già documentata da altri ricercatori, ma la sua integrazione in un RAT con builder pipeline modulare indica una maturazione significativa di queste tecniche al di fuori di ambienti di ricerca accademica.

Backdoor PAM: furto di credenziali SSH in tempo reale

QLNX include anche un backdoor basato su PAM (Pluggable Authentication Module) che intercetta le credenziali in chiaro durante gli eventi di autenticazione SSH. Il componente PAM inline-hook registra i dati delle sessioni SSH in uscita e li trasmette al C2. È inoltre presente un secondo logger PAM che viene caricato automaticamente in ogni processo collegato dinamicamente, per estrarre nome del servizio, username e token di autenticazione.

Questa tecnica è particolarmente insidiosa perché i moduli PAM girano tipicamente con privilegi root e operano a un livello così basso nello stack di autenticazione che la maggior parte dei sistemi di monitoring tradizionali non riesce a intercettarli. Non a caso, negli ultimi mesi sono emersi altri strumenti simili — come PamDOORa, venduto su forum russi di cybercrime per 900 dollari — che sfruttano lo stesso vettore.

58 comandi C2 e un’infrastruttura operativa completa

QLNX supporta ben 58 comandi distinti che conferiscono agli operatori il controllo completo dell’host compromesso. Le capacità operative includono esecuzione di shell commands, gestione file, code injection nei processi, cattura di screenshot, keylogging, SOCKS proxy, TCP tunneling, esecuzione di Beacon Object Files (BOFs) — la stessa tecnica usata da Cobalt Strike — e gestione di una rete P2P mesh tra host compromessi.

La comunicazione con il C2 avviene su tre protocolli — TCP grezzo, HTTPS e HTTP — con un loop persistente che tenta continuamente di mantenere attiva la connessione. La vettore di infezione iniziale rimane ancora sconosciuto, ma una volta stabilito il foothold, QLNX cancella i propri artefatti dal disco e avvia la fase operativa principale.

Indicatori di compromissione e contromisure

QLNX evidenzia una tendenza preoccupante: la supply chain del software sta diventando il bersaglio privilegiato di attori sofisticati, perché compromettere un singolo sviluppatore con accesso ai registri npm o PyPI può avere effetti moltiplicatori su migliaia di utenti downstream. Per i team di sicurezza, alcune contromisure prioritarie:

• Ruotare regolarmente tutti i token di pubblicazione per npm, PyPI, GitHub e altri registri, soprattutto dopo accessi da sistemi non familiari.
• Monitorare processi Linux con nomi simili a thread del kernel — kworker, ksoftirqd ecc. — che non corrispondono agli effettivi thread del kernel: strumenti come pstree con verifica del PPID possono rivelare anomalie.
• Verificare l’integrità dei moduli PAM: controllare regolarmente che i file .so nei percorsi PAM non siano stati modificati rispetto alla versione del package manager.
• Abilitare audit logging di eBPF per rilevare il caricamento di programmi eBPF non autorizzati: auditctl -a always,exit -F arch=b64 -S bpf.
• Isolare i segreti CI/CD dall’ambiente di sviluppo locale, usando secret manager dedicati piuttosto che file in chiaro su disco.

Trend Micro ha pubblicato i dettagli tecnici completi nel proprio blog di ricerca. La natura fileless di QLNX e il suo doppio rootkit rendono il rilevamento basato su signature sostanzialmente inefficace: la difesa deve puntare su behavioral analytics e monitoraggio delle anomalie a livello di syscall, combinati con soluzioni EDR capaci di ispezionare la memoria dei processi.

Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM Backdoor, Credential Harvesting Capabilities

TrendAI™ Research breaks down Quasar Linux (QLNX), a previously undocumented sophisticated Linux RAT with low detection rates.

^{Trend Micro}