Windows processes often import a number of dynamic link libraries which contain API functions (for example for internet communications, process enumeration and a lot more). You’d be hard pressed to find a windows executable that doesn’t use some sort of imported DLL and windows API calls. With these calls comes a problem, if we’re able to ensure the calls instead call our own code prior to the legitimate code, then we’re able to intercept communication between applications, and as such use the information ourselves.
Citing ATT&CK, Hooking involves redirecting calls to these functions and can be implemented via:
- Hook Procedures, which intercept and execute designated code in response to events such as messages, keystrokes, and mouse inputs.
- Import address table (IAT) hooking, which uses modifications to a process’s IAT, where pointers to imported API functions are stored.
- Inline hooking, which overwrites the first bytes in an API function to redirect code flow
Hooking is used both by AV products and Malware (especially rootkits) to prevent the expected response from a Windows API call. For example if you try and retrieve a listing of running processes through task manager, tasklist, get-process etc, but malware has hooked this call, it could instead present you with all the running processes except the malware itself.
RED TEAM: ATTACK
In this example we create a Hook Procedure for the Windows Keyboard (using PowerShell and .NET) to log keystrokes. Every time a key is pushed it is logged to a file.
We also go out and create custom DLL which uses Microsoft Detours to log any calls sent to the Windows Socket 2 API.
Using T1103 - AppInit DLLs, we ensure that our DLL is loaded by every process which runs. The output in this scenario is a logged file which shows evidence of a Cobalt Strike windows/beacon_http/reverse_http beacon.
BLUE TEAM: DEFEND
With an EDR solution, you’re able to monitor for calls to SetWindowsHookEx and SetWinEventHook functions, and hook chains can be viewed to examine current system hooks.
In addition examine something such as Sysmon event 9 (Image loaded) to detect any DLLs loaded in this fashion (although reflectively loaded DLLs will go amiss), or Sysmon events 17 and 18 which will show named pipes that may have been used to transfer data between the injected application and malware.