Threat Landscape Q2 2026: l'attacco non forza più la porta. Usa le tue chiavi.

Nel secondo trimestre 2026 il nostro team CTI ha analizzato quattro campagne che sembrano non avere nulla in comune: l'esposizione massiva di credenziali FortiGate (FortiBleed), la compromissione di 32 pacchetti npm nel namespace @redhat-cloud-services (malware Miasma), la disclosure non coordinata di nove zero-day Windows (Nightmare-Eclipse) e una vulnerabilità nel kernel Linux (Bad Epoll, CVE-2026-46242).

Lette come schede separate, chiedono risposte separate. Lette insieme, raccontano una cosa sola.

Il punto: la vulnerabilità non serve più

Per anni la difesa ha inseguito il software vulnerabile. E il patching resta un presidio fondamentale: sistemi aggiornati riducono la superficie d’attacco, rendono molte tecniche più complesse da eseguire e costringono l’attaccante a generare più rumore.

Ma il Q2 2026 mostra anche il limite di una difesa concentrata solo sulle vulnerabilità. Sempre più spesso, per entrare e muoversi nella rete, all’attaccante non serve sfruttare una falla: gli basta utilizzare ciò che è già autorizzato e considerato affidabile.

Credenziali valide, funzioni diagnostiche native, codice firmato, perfino lo stack di sicurezza stesso.

È un cambio di gioco che ha un nome per ogni mossa. LOTL (Living Off the Land): muoversi nella rete utilizzando strumenti di sistema già presenti. LOLBins (Living Off the Land Binaries): binari legittimi come PowerShell, WMI e PsExec piegati a scopi offensivi. BYOVD (Bring Your Own Vulnerable Driver): caricare un driver firmato ma vulnerabile per eseguire codice a livello kernel, il cosiddetto ring 0, e disattivare l’EDR dall’interno.

Il problema?

Molti controlli difensivi presuppongono che l’attività malevola sia distinguibile da quella legittima: una firma antivirus, un exploit da rilevare, un artefatto anomalo.

Quando l’attacco passa invece attraverso account autorizzati, funzioni native e componenti firmati, questo assunto viene meno. Il sistema può essere aggiornato e comunque non generare alcun segnale, perché ciò che sta osservando appare tecnicamente legittimo.

Quattro casi, la stessa tecnica di fondo

FortiBleed: le chiavi, non la serratura.

Nessuna CVE di FortiOS. Gli operatori aggregano, validano e riutilizzano credenziali valide, poi usano il tool FortiGateSniffer, che abusa della funzione nativa diagnose sniffer packet - quella che gli amministratori usano per il troubleshooting - per intercettare il traffico SSL VPN direttamente sul firewall.

Il firewall di sicurezza diventa il sensore dell'attaccante, gli hash raccolti finiscono su un'infrastruttura di cracking Hashtopolis da 45 GPU: parliamo di centinaia di migliaia di euro di risorse dedicate, pianificazione da livello militare. E nel dataset rientrano anche dispositivi aggiornati all'ultima versione.

Miasma: la fiducia della supply chain.

L'attore non deve forzare nulla. Compromette l'account GitHub di uno sviluppatore RedHatInsights via estensione VS Code infostealer, altera i workflow GitHub Actions e pubblica 32 pacchetti npm firmati ma malevoli. Il codice parte da solo, durante un banale npm install, tramite script preinstall. Ogni anello - identità, namespace, pipeline, firma - è legittimo. È l'insieme, la fiducia, a essere sfruttato.

Nightmare-Eclipse: la fiducia come bersaglio.

Nove zero-day (7 già CVE) contro i pilastri di Windows: Microsoft Defender, BitLocker, Secure Boot. E qui il dettaglio cruciale per ogni IT manager: alcuni PoC sono stati rilasciati a ridosso del Patch Tuesday.

Tradotto: la finestra di esposizione si dilata di settimane, fino al ciclo di patch successivo, proprio mentre il proof-of-concept è già pubblico e pronto all'uso. La procedura di disclosure, pensata per proteggere, viene usata contro chi difende.

Bad Epoll: quando anche la conoscenza diventa un'arma.

Un singolo commit del 2023 introdusse due race condition gemelle nel sottosistema epoll del kernel. La prima (CVE-2026-43074) l'ha trovata il modello AI Mythos di Anthropic. La seconda (Bad Epoll) è sfuggita agli analisti umani per anni.

Un caso da manuale di cosa vede una macchina e cosa manca un revisore umano. Tasso di successo dell'exploit: ~99%, cifra eccezionale per una race condition. Sfruttamenti in the wild al momento zero - ma write-up e PoC funzionante sono già su GitHub.

E la classifica ransomware conferma la rotta. I gruppi in ascesa: 888, FulcrumSec, Coinbasecartel, praticano data-theft-led extortion: niente cifratura, niente sistemi bloccati. Furto di credenziali via infostealer, credential stuffing, social engineering. Se hai già un accesso valido, non ti serve cifrare: ti basta uscire con i dati. "Ransomware" è ormai una parola fuorviante.

Il problema non è la mancanza di dati

Ecco la parte scomoda: preso evento per evento, ogni attacco appare legittimo.

Un login riuscito con credenziali valide è legittimo. Una sessione di packet capture su un firewall è legittima. Un npm install che esegue uno script preinstall è legittimo. Un processo con privilegi SYSTEM, in quel singolo istante, è indistinguibile da uno autorizzato.

La compromissione diventa visibile solo mettendo in relazione domini che di solito si monitorano separati: identità, endpoint, rete, supply chain. Non manca la traccia, ogni campagna ne lascia.

Manca la correlazione.: chi non ce l'ha ha tutti i log necessari e resta comunque cieco, perché nessun log, da solo, contiene l'anomalia.

Cosa guardare (i segnali sono comportamentali, non statici)

Accessi riusciti da ASN o posizioni incoerenti col profilo utente, soprattutto su account admin e VPN.

Funzioni native fuori contesto: diagnose sniffer packet senza troubleshooting, montaggio di ISO/VHD da utenti standard, script preinstall che leggono .env, chiavi SSH o token.

Sequenze ravvicinate: accesso VPN → attività su Active Directory; npm install → connessioni in uscita verso infrastrutture sconosciute.

Binari o pacchetti "fidati" solo in apparenza: eseguibili FortiGateSniffer, versioni @redhat-cloud-services pubblicate dopo il 1° giugno 2026.

Credenziali aziendali già presenti in esposizioni note. Nessuno di questi eventi, da solo, è un allarme. La loro combinazione sì.

Azioni prioritarie

Ridurre la fiducia implicita

1. Patching come baseline: necessario, ma non più sufficiente come metodo standalone
2. MFA phishing-resistant su tutte le interfacce VPN e di gestione: interrompe il riutilizzo delle credenziali valide, il fulcro dell'intera catena, e funziona anche sui dispositivi già aggiornati.
3. Least privilege sulle identità di sviluppatori e amministratori: nel caso Miasma sono state la porta d'ingresso.
4. Pinning delle dipendenze: via i modificatori di versione flessibile (^, ~) da package.json, per bloccare gli aggiornamenti automatici a release non verificate.
5. Limitare gli strumenti nativi ad alto potenziale: interfaccia di gestione ristretta a IP fidati, blocco via policy del montaggio immagini disco per utenti non admin, PIN di avvio BitLocker oltre al TPM.

Correlare i segnali

1. Correlazione cross-domain tra autenticazione, attività sugli apparati, movimenti interni e comportamento delle pipeline, non silos separati.
2. Rilevamento comportamentale (UEBA) orientato all'abuso di strumenti legittimi, non solo alla presenza di malware.
3. Investigare gli accessi sospetti anche se riusciti, ed esaminare i log retrospettivamente.
4. Estendere l'Incident Response oltre il perimetro compromesso - Active Directory, host di sviluppo, secret cloud - quando l'accesso iniziale è passato da credenziali o supply chain.

Nota bene

Non tutti i casi pesano allo stesso modo. FortiBleed e Miasma incarnano la tesi in modo diretto: nessuna vulnerabilità software sotto. Bad Epoll e Nightmare-Eclipse partono invece da bug reali; a spostare il baricentro sono l'abuso dei meccanismi fidati e la disponibilità pubblica degli strumenti di sfruttamento — non l'assenza della falla.