LAB-05Easy
Import Table Analysis
Read the import table to determine what capability a binary requests.
15 min4 prerequisites6 tools
Investigate
Hints
Hint 1
The three APIs VirtualAllocEx, WriteProcessMemory, CreateRemoteThread form a chain.
Hint 2
A single suspicious API is weak; a cluster is a smoking gun.
Hint 3
Think about what 'remote' and 'ex' (extended) suffixes imply.
Submit Findings
Solution
Import Table Analysis — Solution
All imports resolve from KERNEL32.dll. The cluster is unmistakable:
VirtualAllocEx— allocate memory in a remote process.WriteProcessMemory— write a payload into that memory.CreateRemoteThread— start a thread in the target that runs the payload.OpenProcess— obtain a handle to the target process.
This is the canonical process injection chain. Seeing these four together means the binary is built to inject and execute code in another process.
Prerequisites
- sa2-imports-exports
- f4-executable-formats
- PE Import Directory structure (IAT, INT)
- Common Windows API categories
Methodology
Investigation Methodology
1. Parse the Import Directory
- Open in Ghidra → Window → Imports
- Or use PE-bear / CFF Explorer → Import Table tab
- Identify all imported DLLs and their functions
2. Map APIs to Capabilities
Create a capability matrix:
| Capability | Key APIs | DLL |
|---|---|---|
| Process Injection | VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, OpenProcess, VirtualProtectEx |
KERNEL32 |
| Code Execution | CreateProcess, WinExec, ShellExecute, CreateThread |
KERNEL32, SHELL32 |
| Persistence | RegSetValueEx, CreateService, CopyFile, WriteFile |
ADVAPI32, KERNEL32 |
| Network/C2 | InternetOpen, InternetConnect, HttpSendRequest, WSASocket, connect |
WININET, WS2_32 |
| Anti-Analysis | IsDebuggerPresent, CheckRemoteDebuggerPresent, NtQueryInformationProcess |
KERNEL32, NTDLL |
| Credential Access | LsaEnumerateLogonSessions, CredEnumerate, CryptUnprotectData |
SECUR32, CRYPT32 |
| Discovery | GetSystemInfo, GetVersionEx, EnumProcesses, NetShareEnum |
KERNEL32, PSAPI, NETAPI32 |
3. Identify Clusters
- Single API: Low confidence (legitimate use common)
- 2-3 related APIs: Medium confidence
- Full chain (4+ APIs in sequence): High confidence — indicates intentional capability
4. Analyze Import Characteristics
- Ordinal vs Name imports: Malware often uses ordinals to hinder analysis
- Delayed imports: Loaded on first call — can hide capability
- Forwarded exports: API forwarded to another DLL (e.g.,
NtCreateThread→ntdll) - Missing imports: Statically linked, or resolved dynamically via
GetProcAddress
5. Dynamic Resolution Check
- Search for
GetProcAddress/LoadLibrarycalls in code - Look for hashed API names (common in shellcode)
- Check for manual PE parsing (import table walk)
6. Document & Report
- List DLLs and their imported functions
- Highlight suspicious clusters
- Note any dynamic resolution patterns
- Assess overall capability profile
Common Pitfalls
- Only checking static imports — missing dynamically resolved APIs
- Confusing `VirtualAlloc` (local) with `VirtualAllocEx` (remote)
- Overlooking `OpenProcess` — required precursor for remote operations
- Missing delayed imports (Data Directory [13])
- Not checking for `GetProcAddress` / `LoadLibrary` usage in code
Tools
- Ghidra (Imports window, Decompiler)
- PE-bear / CFF Explorer
- dumpbin /imports /dependents
- pefile (Python): `pe.DIRECTORY_ENTRY_IMPORT`
- dumpbin /exports (for forwarded exports)
- Binary Ninja (Import analysis)
References
- Lesson SA2: Imports & Exports
- Lesson F4: Executable Formats — IAT deep dive
- Microsoft PE/COFF Spec: Import Directory
- MITRE ATT&CK: T1055 (Process Injection) — API mapping
- Windows Internals: DLL Loading & API Resolution
Extensions & Challenges
- Analyze a packed sample — find the OEP and dump imports after unpacking
- Write a script to auto-detect API clusters in a PE file
- Research: How does API hashing work? Implement a resolver
- Compare: Static imports vs. dynamic resolution — detection strategies