During malware analysis, an analyst observes that a suspicious executable's Import Address Table contains only a handful of imports, yet the binary clearly performs file encryption and outbound network communication at runtime. The analyst suspects the imports are resolved dynamically. Which technique should the analyst use to recover the API names the sample resolves at runtime?
Dynamic API resolution almost always relies on LoadLibrary plus GetProcAddress to locate function pointers at runtime, so these calls leave no static import entries. Breaking on both functions and reading the module name and procedure name arguments from the stack or registers exposes exactly which APIs the malware resolves, which can then be mapped back to the suspicious behaviors observed during execution.
Why this answer
Dynamic resolution through LoadLibrary and GetProcAddress is the standard mechanism behind sparse import tables, so instrumenting those two functions in a debugger recovers the module and procedure names as they are requested. Hash lookups, section size comparisons, and string extraction are triage techniques that do not expose the runtime resolution sequence.
Exam trap
The trap here is expecting the API names to appear as plaintext strings, when malware frequently stores them as hashes that only match after the runtime resolution routine computes them.