As mentioned earlier, the IAT contains the addresses of functions that an application imports from DLLs. In this technique, after a DLL is injected into the target (legitimate) process, the code in the injected DLL (Dllmain() function) hooks the IAT entries in the target process. The following gives a high-level overview of the steps used to perform this type of hooking:

• Locate the IAT by parsing the executable image in memory.
• Identify the entry of the function to hook.
• Replace the address of the function with the address of the malicious function.

To help you understand, let's look at an example of a legitimate program deleting a file by calling the DeleteFileA() API. The DeleteFileA() object accepts a single parameter, which is the name of the file to be deleted. The following screenshot displays the legitimate process (before hooking), consulting the IAT normally to determine the address of DeleteFileA(), and then calling DeleteFileA() in the kernel32.dll:

When the program's IAT is hooked, the address of DeleteFileA() in the IAT is replaced with the address of the malicious function, as follows. Now, when the legitimate program calls DeleteFileA(), the call is redirected to the malicious function in the malware module. The malicious function then invokes the original DeleteFileA() function, to make it seem like everything is normal. The malicious function sitting in between can either prevent the legitimate program from deleting the file, or monitor the parameter (the file that is being deleted), and then take some action:

In addition to blocking and monitoring, which typically happens before invoking the original function, the malicious function can also filter the output parameters, which occurs after the re-invocation. This way, the malware can hook APIs that display lists of processes, files, drivers, network ports, and so on, and filter the output to hide from the tools that use these API functions.

The disadvantage for an attacker using this technique is that it does not work if the program is using run time linking, or if the function the attacker wishes to hook has been imported as an ordinal. Another disadvantage for the attacker is that IAT hooking can be easily detected. Under normal circumstances, the entries in the IAT should lie within the address range of its corresponding module. For example, the address of DeleteFile() should be within the address range of kernel32.dll. To detect this hooking technique, a security product can identify the entry in the IAT that falls outside of its module's address range. On 64-bit Windows, a technology named PatchGuard prevents patching the call tables, including IAT. Due to these problems, malware authors use a slightly different hooking technique, which is discussed next.