Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

API Hooking Detection

forensics

Définition

La détection de l'API hooking est une technique forensique permettant d'identifier les modifications malveillantes apportées aux fonctions des DLLs Windows pour intercepter et détourner les appels système. L'API hooking est utilisée à la fois par les logiciels de sécurité légitimes (AV, EDR) et les malwares avancés (rootkits, RATs) pour intercepter les appels d'API et modifier leur comportement. Les principales techniques d'API hooking incluent : l'IAT hooking (modification de l'Import Address Table d'un processus pour rediriger les appels vers du code malveillant), le inline hooking ou splicing (modification des premiers octets de la fonction cible — généralement les 5 premiers octets remplacés par un JMP vers la fonction malveillante), l'EAT hooking (modification de l'Export Address Table d'une DLL), le SSDT hooking (modification de la System Service Descriptor Table pour les appels noyau), et les techniques VEH (Vectored Exception Handling) hooks. Le inline hooking est la technique la plus commune utilisée par les malwares. Ses caractéristiques : les 5 premiers octets d'une fonction ciblée (ex: NtCreateProcess, RegSetValueEx, CreateFile) sont remplacés par un JMP (E9 xx xx xx xx) ou CALL vers un trampoline malveillant. La fonction originale n'est plus directement accessible — un appel normal à cette fonction est détourné vers le code malveillant, qui peut modifier les arguments, les résultats, ou bloquer l'exécution. La détection de l'API hooking repose sur la comparaison des octets en mémoire des fonctions avec leur état attendu (depuis le fichier DLL sur disque). Si les premiers octets d'une fonction montrent un JMP vers une adresse hors de la plage de la DLL, un hook est présent. Des outils comme PE-sieve, Moneta, et SharpBlock effectuent ce scan automatiquement en comparant les sections de code en mémoire avec les DLLs sur disque. Sysmon (EventID 10 — ProcessAccess avec les flags GrantedAccess pour OpenProcess + ReadProcessMemory/WriteProcessMemory) détecte les processus qui tentent d'injecter des hooks dans d'autres processus.

Fonctionnement

Inline hook : remplacer les 5 premiers octets de la fonction cible par E9 (JMP) + offset vers le trampoline malveillant. Le trampoline sauvegarde les octets originaux, exécute le code malveillant, puis peut ou non appeler la fonction originale (via un stub qui réexécute les 5 octets originaux puis saute dans la fonction à l+5). Détection : lire les premiers octets en mémoire, comparer avec les premiers octets lus depuis le fichier DLL sur disque, divergence = hook.

Application DFIR

Détection hooks : 1) PE-sieve.exe --pid [PID] --scanned → scan automatique de toutes les DLLs d'un processus pour hooks inline et IAT hooks, 2) Moneta --mode suspicious → identifie les régions PE avec modifications suspectes (hooks inclus), 3) Volatility malfind + PE scan manuel des fonctions NTDLL, 4) Sysmon EventID 10 (ProcessAccess avec OpenProcess + WriteProcessMemory) → processus qui inject des hooks. Confirmer en désassemblant les octets suspects dans x64dbg.

Outils

PE-sieve (github.com/hasherezade/pe-sieve, scan hooks + injections), Moneta (github.com/forrest-orr/moneta, detection hooks + shellcode), SharpBlock (anti-hooking, peut aussi détecter les hooks existants), mHook/EasyHook (bibliothèques légitimes d'hooking pour comparaison). Live : x64dbg (désassemblage manuel des fonctions hookées), Frida (framework d'instrumentation dynamique). Sigma rules : Sysmon EventID 10 OpenProcess + WriteProcessMemory vers lsass.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis