mein-0/mercilessamdProof-of-concept che sfrutta le IOCTL di lettura/scrittura MSR di AMD AmdTools64.sys per sovrascrivere IA32_LSTAR, aggirare SMEP ed escalare da amministratore a SYSTEM su Windows 10 x64.
ciao hacker.
AmdTools64.sys è il driver firmato Special Tools che viene distribuito con AMD uProf. Nessun bypass UAC, nessun superamento del confine utente standard. Una volta ottenuto l'handle non c'è alcuna whitelist sull'indice MSR, quindi puoi leggere e scrivere qualsiasi MSR tu voglia.
Il lato lettura di per sé rompe già il KASLR. Leggi IA32_LSTAR (0xC0000082) e il driver ti consegna gratuitamente ntoskrnl!KiSystemCall64. Il lato scrittura è il vero problema. IA32_LSTAR è l'indirizzo a cui la CPU salta a ogni syscall, e il driver permette a un utente normale di sovrascriverlo. Puntalo a codice che controlli e la successiva syscall eseguirà il tuo codice a CPL0. SMEP è l'unica cosa che ostacola, quindi l'exploit legge prima IA32_LSTAR per trovare ntoskrnl, analizza la directory degli import dal disco, trova un paio di gadget per disabilitare SMEP con mov cr4, rax, esegue un piccolo shellcode che copia il token SYSTEM nel processo corrente e ripristina IA32_LSTAR in uscita così la macchina continua a funzionare.
Ci sono due IOCTL e questa è tutta la storia. 0xFFF02804 legge un MSR e 0xFFF02808 ne scrive uno, entrambi con un buffer da 20 byte e nessuna validazione dell'indice. Il dispatcher controlla solo le lunghezze dei buffer. C'è anche una lettura/scrittura di memoria fisica e una mappa fisica in modalità utente (0xFFF0281C, 0xFFF02820, 0xFFF028A4), ma il percorso della mappa può causare PFN_LIST_CORRUPT su RAM arbitraria, quindi il percorso MSR è quello usato qui.
L'ho testato su Windows 10 x64 22H2 (build 19045.6456) con AMD uProf 5.3.521.0. Il driver è versione 1.7.16.218. Nessuna race e nessun heap grooming, ha funzionato ogni volta che l'ho eseguito. Il driver viene distribuito con uProf ed è installato su molte macchine AMD, quindi è già caricato per te. Lo screenshot è la macchina Win10: whoami è subhan\windows10 prima, nt authority\system dopo.
Su Windows 11 26300 sono riuscito a installare il driver e a leggere IA32_LSTAR, ma la wrmsr su LSTAR fallisce quando Memory Integrity è attivo, VBS/HVCI la intercetta. Il layout noto di EPROCESS su Win11 è UniqueProcessId 0x1D0, ActiveProcessLinks 0x1D8, Token 0x248, ImageFileName 0x338, verificato rispetto a PsGetProcessId, PsReferenceProcessToken e PsGetProcessImageFileName in quella build.
Il valore è il driver firmato e la primitiva kernel: un amministratore può caricare il driver AMD e ottenere l'esecuzione di codice a ring-0. La catena LSTAR-to-SYSTEM qui è la parte exploit, non una nuova scoperta di driver.
L'ho segnalato ad AMD PSIRT il 2026-08-17. Tuttavia, hanno fatto tutto il possibile per evitare di riconoscere questa lacuna, mi hanno persino bloccato su Gmail così che non potessi più inviare loro email dal mio indirizzo. Questo è solo l'inizio; d'ora in poi, non condividerò le mie scoperte riguardanti i prodotti AMD con loro direttamente o tramite i loro altri canali. Continuerò a condividere tutto proprio qui. Restate sintonizzati e continuate a fare hacking!
