Skip to content

4.7. Scan for IAT Hooks (iat)

hasherezade edited this page Jan 24, 2022 · 18 revisions
Option: /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.

Report

It generates a report in a following format:

{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}

Example

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:

IAT Hook report

4068;[user32.MessageBoxW #533]->1000100c[10000000+100c:nagmenot.MBox #1:0]

We can see the patched IAT in the dumped sample:

Patched IAT