4.7. Scan for IAT Hooks (iat)
/iat <*scan_mode>
: Scan for IAT hooks.
*scan_mode:
0 - none: do not scan for IAT Hooks (default)
1 - scan IAT, filter hooks that lead to unpatched system module
2 - scan IAT, filter hooks that lead to ANY system module
3 - unfiltered: scan for IAT Hooks, report all
By default PE-sieve search for inline hooks, and in-memory patches. When this option is chosen, it additionally scans IAT to detect eventual hooks.
If the scan was executed in a filtered mode (scan_mode = 1), the hooks leading to DLLs in system directories (System32, SysWow64) are excluded from the report. The exception from this rule is, if the target DLL was patched/modified and is detected as suspicious. Filtered mode is recommended for the most common usage, in order to avoid noise.
It generates a report in a following format (similar to the inline hooks report):
{thunk RVA};{original function name}->{VA where the hook leads to}[{details}]
The {details} contain additional information about the target, including:
{module base}+{function RVA}:{module name.target function name}:{is the module identified as suspicious}
In the following sample cm_hooked.zip IAT was patched, and the function user32.MessageBoxW has been replaced by a function MBox (starting at RVA 0x100c) from a custom DLL: NagMeNot.dll (which happened to be loaded at the address 0x10000000). The NagMeNot.dll was not modified in memory, so its status is clean (not suspicious).
This is how PE-sieve reports it:
4068;[user32.MessageBoxW #533]->1000100c[10000000+100c:nagmenot.MBox #1:0]
We can see the patched IAT in the dumped sample:
