n0qword/win32k-callback-detouringAbuser du mécanisme de rappel du noyau win32k.sys pour exécuter du code arbitraire
Ce dépôt est fourni strictement à des fins éducatives et de recherche défensive.
Il illustre les mécanismes internes de distribution des callbacks de Windows et les concepts de flux de contrôle liés à KernelCallbackTable dans un contexte de preuve de concept.
L'auteur décline toute responsabilité en cas de mauvaise utilisation.
Cette technique d'injection abuse du chemin de distribution des callbacks du noyau vers l'utilisateur utilisé par le sous-système graphique de Windows (win32k.sys) pour obtenir l'exécution de code dans un processus distant. En localisant la KernelCallbackTabledans leProcess Environment Block (PEB)`, un opérateur peut énumérer les entrées de callbacks et identifier les routines légitimes en mode utilisateur invoquées lors des transitions noyau liées à l'interface graphique.
Plutôt que d'effectuer une injection par KernelCallbackTable traditionnelle, où une entrée de callback est directement écrasée avec l'adresse du shellcode, cette variante hooke la cible de callback légitime référencée par la table et redirige l'exécution vers un shellcode contrôlé par l'attaquant lors de l'invocation. Comme l'exécution est détournée via un chemin de callback existant et attendu, la technique peut constituer une alternative plus furtive aux primitives plus conventionnelles telles que la création de thread distant ou l'injection par APC.
Le sous-système graphique de Windows délègue une partie du traitement lié à l'interface graphique au mode utilisateur via un mécanisme de callback initié depuis le mode noyau. Lorsque win32k.sys a besoin d'exécuter une logique dans le contexte d'un processus GUI, il invoque KeUserModeCallback pour effectuer une transition contrôlée du mode noyau vers le mode utilisateur tout en préservant la frontière d'isolation entre les deux contextes d'exécution.
Cette transition établit le chemin d'exécution légitime par lequel le noyau distribue les callbacks du sous-système graphique en mode utilisateur — le même chemin ensuite abusé par la technique présentée.
Une fois la transition terminée, l'exécution entre dans KiUserCallbackDispatcher, une routine de ntdll.dll chargée de recevoir l'index de callback fourni par le noyau et de distribuer l'exécution au gestionnaire de callback en mode utilisateur correspondant. Cette routine sert de point d'entrée obligatoire pour tous les callbacks initiés via KeUserModeCallback.
Parce que toute la résolution des callbacks converge vers ce dispatcher, KiUserCallbackDispatcher agit comme le pivot central entre les requêtes de callback du noyau et leur exécution finale en mode utilisateur.
Pour résoudre la destination d'un callback demandé, KiUserCallbackDispatcher consulte la KernelCallbackTable stockée dans le PEB du processus cible. Chaque entrée de la table contient un pointeur vers une routine de callback en mode utilisateur associée à une opération spécifique du sous-système graphique, généralement implémentée dans user32.dll.
Les techniques traditionnelles d'injection par KernelCallbackTable écrasent directement une ou plusieurs de ces entrées pour rediriger l'exécution. Bien qu'efficaces, la modification de la table elle-même introduit des anomalies structurelles qui peuvent être trivialement détectées par la validation d'intégrité du PEB ou du contenu de la table de callbacks. La technique présentée évite cela en préservant la structure de la table et en détournant plutôt la cible de callback référencée par l'entrée.
Parmi les entrées disponibles de la KernelCallbackTable, __fnCOPYDATA constitue une primitive de déclenchement particulièrement pratique car elle peut être invoquée de l'extérieur en envoyant un message WM_COPYDATA via SendMessage(). Cela permet de déclencher le callback de manière déterministe sans nécessiter un état inhabituel du processus ni une interaction complexe.
En exploitant une cible de callback naturellement accessible et fréquemment utilisée, la technique obtient une primitive d'exécution fiable tout en restant entièrement dans la chaîne de distribution de callbacks attendue avant la redirection.
La technique commence par localiser le processus cible et lire son PEB pour récupérer l'adresse de la KernelCallbackTable, à partir de laquelle le pointeur de callback pour __fnCOPYDATA est résolu. Une mémoire exécutable est ensuite allouée dans le processus distant, et un shellcode contrôlé par l'attaquant est écrit dans la région allouée. Avant la modification, les octets d'origine de la routine de callback légitime sont préservés pour permettre une restauration ultérieure.
Un hook inline est ensuite installé au début de la routine __fnCOPYDATA résolue, remplaçant son prologue par un saut absolu vers le shellcode injecté. Pour déclencher l'exécution, un message WM_COPYDATA est envoyé à la fenêtre cible, ce qui amène le sous-système graphique de Windows à distribuer __fnCOPYDATA via la chaîne standard de callbacks du noyau vers l'utilisateur. Une fois l'exécution terminée, les octets d'origine du callback sont restaurés pour préserver la stabilité du processus et réduire les artefacts de modification résiduels.
La KernelCallbackTable est située à l'offset 0x58 dans le PEB :
La logique suivante est utilisée pour l'obtenir :
PROCESS_BASIC_INFORMATION pbi;
PEB peb;
KERNELCALLBACKTABLE kct;
if (NtQueryInformationProcess(hProcess, ProcessBasicInformation, &pbi, sizeof(pbi), NULL) != STATUS_SUCCESS)
{
NtClose(hProcess);
return 1;
}
/* Read remote PEB */
if (NtReadVirtualMemory(hProcess, pbi.PebBaseAddress, &peb, sizeof(peb), NULL) != STATUS_SUCCESS)
{
NtClose(hProcess);
return 1;
}
/* Ensure KernelCallbackTable is present */
if (!peb.KernelCallbackTable) {
NtClose(hProcess);
return 1;
}
/* Read KernelCallbackTable contents */
if (NtReadVirtualMemory(hProcess, peb.KernelCallbackTable, &kct, sizeof(kct), NULL) != STATUS_SUCCESS)
{
NtClose(hProcess);
return 1;
}
Le code commence par appeler NtQueryInformationProcess avec la classe d'informations ProcessBasicInformation pour remplir une structure PROCESS_BASIC_INFORMATION, qui expose l'adresse du PEB du processus distant via le champ PebBaseAddress.
Ensuite, NtReadVirtualMemory est utilisé pour lire le PEB distant dans une structure PEB locale, permettant d'extraire le pointeur KernelCallbackTable stocké dans l'environnement du processus. Après avoir validé la présence de la table de callbacks, un second appel à NtReadVirtualMemory copie la structure KERNELCALLBACKTABLE distante en mémoire locale, ce qui permet la résolution directe de cibles de callbacks telles que __fnCOPYDATA pour le détournement ultérieur.