DET0091: Detection Strategy for Dynamic API Resolution via Hash-Based Function Lookups
DET0091 is a detection strategy for finding malware behavior that hides Windows API usage by resolving functions dynamically, including hash-based function...
Analyst context for executives and security teams
DET0091 is a detection strategy for finding malware behavior that hides Windows API usage by resolving functions dynamically, including hash-based function lookups. This matters because it can reduce the value of simple string-based malware triage and make malicious capabilities harder to confirm quickly during an incident.
Executive priority
Treat this as a validation point for malware analysis, EDR, and incident response readiness rather than as a standalone business risk. Leaders should ask whether the SOC can identify stealthy Windows malware that does not expose obvious API strings, and whether IR teams have tooling and expertise to analyze suspicious binaries when static indicators are intentionally obscured.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T1027.007 Dynamic API Resolution, a Windows technique under stealth. Detection engineering should therefore validate coverage for binaries or processes that resolve APIs at runtime instead of exposing clear imports or strings. Because the object provides no official detection text, teams should base implementation on local EDR, sandbox, reverse-engineering, and malware-analysis evidence rather than assuming ATT&CK defines a complete analytic.
Likely telemetry
- Windows endpoint telemetry for process execution and loaded modules
- EDR or sandbox observations of runtime API resolution behavior
- Static malware-analysis artifacts such as import tables, strings, and evidence of absent or obfuscated API names
- Memory or behavioral analysis evidence showing dynamically resolved Windows API calls
- Alert and case data from suspicious binary triage or malware detonation workflows
Detection direction
- Validate that detections are not limited to cleartext API strings or static import-table inspection.
- Correlate static-analysis anomalies with runtime behavior, especially where a binary resolves Windows APIs during execution.
- Tune carefully for legitimate software that uses dynamic loading or runtime resolution to avoid excessive false positives.
- Use this strategy as supporting evidence in malware triage rather than a definitive malicious verdict by itself.
- Document gaps where endpoint tooling cannot expose runtime API resolution or where sandbox execution paths are incomplete.
Mitigation priorities
- Prioritize endpoint visibility and malware-analysis capability for Windows systems relevant to business operations.
- Ensure IR playbooks include escalation from static triage to dynamic or memory-informed analysis when API usage is hidden.
- Maintain controls that reduce execution of untrusted binaries, such as application control or equivalent policy enforcement where appropriate.
- Use findings from this detection strategy to improve SOC triage, reverse-engineering workflows, and evidence collection for incident reporting.
Analyst notes and limits
The ATT&CK object has no official description, detection text, tactics, or platforms of its own. The practical interpretation comes from its name and its relationship to T1027.007 Dynamic API Resolution, which is listed as a Windows stealth technique.
This take does not assert active exploitation, attribution, impact, or guaranteed detectability. Local tooling determines whether runtime API resolution, hash-based lookup patterns, and related malware-analysis evidence are visible enough to support reliable detection.
Detection Strategy for Dynamic API Resolution via Hash-Based Function Lookups
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1027.007 | Dynamic API Resolution Sub-technique | This object detects Dynamic API Resolution. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 69b19fed4561… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0091Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.