Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Arile! Scopri di più
Dirottamento via KernelCallbackTable: Hijack Execution Flow – KernelCallbackTable (T1574.013)
Ogni processo Windows che carica user32.dll riceve, all'interno del proprio Process Environment Block (PEB), una struttura chiamata KernelCallbackTable: un array di puntatori a funzioni grafiche di callback usate dal sottosistema GUI del kernel. Un attaccante che riesce a sovrascrivere anche un solo puntatore in questa tabella può dirottare il flusso di esecuzione del processo, facendogli invocare codice arbitrario quando il sistema invia un normale messaggio Windows.
La tecnica si colloca contemporaneamente in tre tattiche della kill chain. In Persistence (TA0003), perché la modifica della callback table può garantire ri-esecuzione del payload ogni volta che il messaggio Windows corrispondente viene ricevuto. In Privilege Escalation (TA0004), perché il codice malevolo eredita il contesto di sicurezza del processo vittima — e se quel processo gira con privilegi elevati, l'attaccante scala automaticamente. In Defense Evasion (TA0005), perché l'esecuzione avviene all'interno di un processo legittimo, rendendo molto difficile per i prodotti di sicurezza distinguere l'attività malevola dal normale funzionamento dell'applicazione.
La superficie d'attacco è concreta ma circoscritta: 1 gruppo APT documentato, 1 malware noto, e 1 mitigazione ufficiale che ruota attorno al monitoraggio comportamentale degli endpoint. La peculiarità di questa tecnica risiede nel fatto che il payload viene innescato da un semplice messaggio Windows — come un WM_COPYDATA — rendendo il trigger apparentemente innocuo.
La catena d'attacco che replica questa tecnica segue una sequenza precisa di chiamate alla Native API di Windows, ed è perfettamente riproducibile in un laboratorio red team con un compilatore C/C++ e un debugger.
Il primo passo consiste nell'ottenere un handle al processo target — necessariamente un processo GUI che abbia già caricato user32.dll. Processi come explorer.exe o notepad.exe sono candidati ideali. L'apertura avviene tramite OpenProcess() con diritti di accesso PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_QUERY_INFORMATION.
Una volta ottenuto l'handle, si chiama NtQueryInformationProcess() con la classe ProcessBasicInformation per recuperare l'indirizzo del PEB nel processo remoto. Dal PEB, con una ReadProcessMemory(), si legge il campo KernelCallbackTable — un puntatore alla tabella vera e propria. La tabella viene poi letta interamente nella memoria del processo attaccante.
A questo punto si duplica la tabella allocando un nuovo blocco di memoria nel processo vittima con VirtualAllocEx() e vi si copia la tabella originale tramite WriteProcessMemory(). La funzione presa di mira — tipicamente fnCOPYDATA (indice 2 nella tabella) o fnDWORD — viene sovrascritta con l'indirizzo di uno shellcode iniettato in precedenza nel processo target.
Il passo cruciale è l'aggiornamento del PEB: con un'altra WriteProcessMemory() si sovrascrive il puntatore alla KernelCallbackTable nel PEB affinché punti alla copia modificata. Infine, il trigger: si invia un messaggio WM_COPYDATA al processo vittima tramite SendMessage(), che forza l'invocazione della callback sovrascritta e l'esecuzione dello shellcode.
Per il laboratorio, il repository odzhan/injection su GitHub (open source) contiene un'implementazione completa di questa tecnica nel modulo dedicato alla KernelCallbackTable. È un riferimento eccellente per comprendere ogni passaggio a livello di codice sorgente.
In alternativa, si può costruire un PoC minimale in C usando solo le API native elencate sopra. Per il debug passo-passo, x64dbg (open source) permette di osservare la modifica del PEB in tempo reale. Process Hacker (open source) consente di ispezionare il PEB del processo target prima e dopo la sovrascrittura, verificando che il puntatore alla KernelCallbackTable sia cambiato.
Un dettaglio operativo importante: dopo l'esecuzione del payload, il codice malevolo tipicamente ripristina la tabella originale. Nella simulazione red team, implementare anche questa fase è fondamentale per testare la capacità del SOC di catturare la finestra temporale in cui la tabella è alterata.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo