API Hashing: Defending Beyond the Import Table
The Import Address Table (IAT) lists imported functions for many normal PE files. API hashing can replace readable import names with runtime resolution logic, reducing the IAT's value for static triage. It does not hide a program's identity, memory, or behavior from a well-instrumented endpoint.
The IAT as evidence
During normal loading, Windows resolves a PE's imported functions and writes addresses into the IAT. Imports offer analysts immediate context, but sparse imports are not a malware verdict. Plugins, packed applications, custom loaders, and security products can look unusual. Treat static import data as one feature in a wider evidence model.
Detection and investigation
Look for rare, unsigned binaries with unusually thin imports plus suspicious process lineage, abnormal memory activity, service or task creation, or unusual external communication. Validate findings in a sandbox and retain the hash, signer, module map, and timeline. capa can provide capability-oriented static clues; EDR must provide runtime context.
Hardening and CVE context
Application control, Microsoft Defender tamper protection, script restrictions, and careful alert tuning reduce exposure. CVE-2021-40444, an MSHTML remote code execution vulnerability, showed why layered visibility matters after a malicious document is delivered. It is unrelated to IAT design, but it underscores that detection cannot depend only on static strings or imports.
Key takeaways
- The IAT is valuable triage evidence, not a complete behavioral profile.
- Hashing or runtime resolution should cause deeper correlation, not automatic attribution.
- Use application control and EDR timelines to detect harmful effects.