TTP-chain validation: dimostrare l'exploit senza exploit

Il 23 giugno 2026, un Security Research Engineer di Picus Security ha pubblicato su BleepingComputer una metodologia che ribalta il paradigma della vulnerability management: dimostrare che una vulnerabilità è sfruttabile in un ambiente specifico senza disporre di un exploit funzionante. La proposta arriva mentre il tempo medio tra disclosure ed exploit disponibile — la metrica Zero Day Clock — è sceso a circa 8 ore nel 2026, da 53 giorni nel 2024.

Parallelamente, il tempo mediano di fix per vulnerabilità con exploit noto è salito a 43 giorni da 32 giorni precedenti. Le metriche Verizon DBIR 2026 citate dall'autore indicano che la percentuale di organizzazioni che patcha completamente è scesa dal 38% al 26%.

Il gap che inghiotte il day-one

L'autore articola un mismatch temporale crescente. L'offensiva accelera, la difesa rallenta. Quando il disclosure-to-exploit si misura in ore e il fix in settimane, la finestra di esposizione effettiva si allarga in modo strutturale.

Secondo la fonte, il 30-40% delle organizzazioni migliori riesce a chiudere la vulnerabilità nella prima settimana, ma la maggioranza non raggiunge questa soglia. Il dato quantitativo più severo: 48.185 CVE nel 2025, con meno dello 0,6% patchate sul totale.

Questa percentuale estrema non implica che il 99,4% restante sia sfruttabile in pratica, ma evidenzia l'impossibilità di gestire per esposizione diretta un volume così dilatato. Il CISO si trova a dover prioritizzare senza strumenti adeguati nella maggior parte dei casi.

Come funziona la TTP-chain validation

La metodologia si fonda su una decomposizione ingegneristica. Invece di cercare l'exploit completo, si analizza la catena di tattiche, tecniche e procedure (TTP) che un attaccante dovrebbe eseguire per sfruttare la vulnerabilità.

Ogni anello viene testato isolatamente contro i controlli di sicurezza già presenti nell'ambiente: EDR, GPO, LSASS protection, application allow-listing, NGFW.

L'esempio concreto è CVE-2025-29824, una use-after-free nel Common Log File System (CLFS) di Windows. La catena TTP identificata comprende: ingresso ed esecuzione iniziale via certutil o MSBuild (T1105, T1127); escalation a kernel tramite la vulnerabilità CLFS stessa (T1068); modifica di token per privilege escalation (T1134); iniezione in dllhost.exe per persistenza (T1055).

Se uno qualsiasi di questi passaggi è bloccato dai controlli deployati, la catena si interrompe e la CVE risulta non sfruttabile su quell'asset specifico.

Come ha dichiarato l'autore: "An exploit isn't magic. It's a chain of specific techniques, the TTPs an attacker has to execute in sequence". E più nel dettaglio: "If your allow-listing stops the MSBuild exec, or your LSASS protection blocks the credential dump, the chain breaks, the CVE isn't exploitable on that asset, and you can show exactly why. No certified exploit needed".

"The launch is the proof you reach for when you can; the ground test is the proof you rely on when you can't" — Security Research Engineer, Picus Security

Il contesto dell'AI-offensive

L'articolo colloca la TTP-chain validation in un arco più ampio: la corsa all'armamento AI-offensive che comprime i tempi di weaponization. Viene citato il modello Mythos-class di Anthropic, che ha individuato una vulnerabilità in OpenBSD latente da 27 anni.

La fonte non standardizza questo termine al di fuori del proprio contesto: "Mythos" non è una designazione riconosciuta dall'industria come metrica o prodotto. Il dato è rilevante come indicatore di direzione.

La capacità di modelli di linguaggio estesi e ragionamento di individuare bug in codebase mature e sottoposte a decenni di audit suggerisce che il volume di vulnerabilità scoperte continuerà a crescere, accentuando la necessità di metodologie di prioritizzazione alternative all'exploit live.

Cosa fare adesso

Per i team di sicurezza che operano con il 85-90% di esposizioni non testabili con exploit live, la TTP-chain validation offre un percorso operativo concreto. La prima azione è mappare le CVE prioritarie contro il framework MITRE ATT&CK, identificando per ciascuna la sequenza di tecniche necessarie all'exploit.

Il passaggio successivo è verificare quali controlli dell'ambiente target — EDR, application allow-listing, protezioni LSASS, GPO — intercettano ciascuna tecnica. Se un controllo blocca un anello della catena, la priorità di patching può essere ridotta per quell'asset specifico.

Per CVE-2025-29824, questo significa testare: se MSBuild è allow-listato (T1127), se certutil può scaricare payload (T1105), se le protezioni kernel intercettano l'escalation CLFS (T1068), se il monitoraggio token rileva modifiche sospette (T1134), se l'EDR blocca l'iniezione in dllhost.exe (T1055).

La documentazione del risultato per anello — non per CVE intera — genera evidenza gestionale della postura di rischio senza esecuzione di codice exploitativo.

Limiti della proposta e punti da verificare

La metodologia presenta vincoli intrinseci. La precisione della validazione dipende dalla completezza della mappatura MITRE ATT&CK per ciascuna CVE: se un percorso alternativo non è documentato, il test potrebbe classificare come sicuro un ambiente che in realtà permette altre catene TTP.

La fonte non affronta esplicitamente questo scenario. Non emerge inoltre sovrapposizione con framework di vulnerability management riconosciuti come standard industriale.

Il dossier non documenta diffusione in produzione della metodologia presso terze parti indipendenti, né sottoposizione a peer review o valutazione accademica. Non sono elencate implementazioni open source o vendor-neutral, né confronti quantitativi con il penetration testing tradizionale su campioni controllati.

La verificabilità indipendente delle metriche Verizon DBIR 2026 e Zero Day Clock resta non confermata al di fuori della citazione dell'autore.

Chiusura

La TTP-chain validation non sostituisce l'exploit live dove questo è disponibile e applicabile. Ma per la maggior parte delle esposizioni — quelle che non rientrano nel 10-15% testabile — offre una via per produrre evidenza di rischio senza codice weaponizzato.

Come ha sintetizzato l'autore: "When offense runs in hours and remediation runs in weeks, the breach lands in between". In quella finestra, la capacità di dimostrare l'esploitabilità senza lanciare l'exploit può essere il margine che separa la prioritizzazione informata dalla cecità operativa.