AN0389: Analytic 0389
Detects credential harvesting via userland API hooking (e.g., SetWindowsHookEx, IAT, or inline patching) by correlating memory modifications with hook installation functions and suspicious module loads in credential-sensitive processes like lsass.exe, explorer.exe, or winlogon.exe.
Analyst context for executives and security teams
This analytic matters because it focuses on a credential-theft pattern on Windows: userland API hooking in or around credential-sensitive processes such as lsass.exe, explorer.exe, and winlogon.exe. For leaders, the decision value is whether the organization can see suspicious in-memory tampering and module activity before stolen credentials become a broader identity and business-continuity incident.
Executive priority
Prioritize this as an identity-risk and incident-readiness validation item for Windows environments. Executives should ask whether SOC and IR teams collect the endpoint telemetry needed to investigate memory modification, hook installation behavior, and suspicious module loads in sensitive processes, and whether those signals are usable as audit evidence for credential-access monitoring. Because no ATT&CK relationships or tactic mapping are supplied, treat this as a focused detection-engineering control check rather than a complete coverage statement.
Technical view
Validate visibility on Windows endpoints for correlations among memory modifications, hook installation APIs such as SetWindowsHookEx, Import Address Table or inline patching indicators, and suspicious module loads affecting credential-sensitive processes including lsass.exe, explorer.exe, and winlogon.exe. Detection engineering should focus on correlation quality: a single hook-related API call may be benign, but combinations involving sensitive processes, unexpected modules, and process memory changes should be triaged with higher priority. IR playbooks should preserve process, module, memory, and related execution context when this analytic fires.
Likely telemetry
- Endpoint process telemetry for lsass.exe, explorer.exe, winlogon.exe, and related parent/child process context
- API or behavioral telemetry showing hook installation activity such as SetWindowsHookEx where available
- Memory modification events or EDR observations associated with userland patching, IAT changes, or inline patching
- Module load telemetry, including unexpected or unsigned modules loaded into credential-sensitive processes
- File, image, signer, command-line, and hash metadata for suspicious modules and processes
Detection direction
- Confirm that Windows endpoint tooling can observe memory modification and module-load behavior in sensitive processes, not only process creation events.
- Tune for correlation rather than isolated events: hook installation plus memory modification plus suspicious module load is more actionable than any one signal alone.
- Baseline legitimate software that may use hooks or inject modules, such as accessibility, security, monitoring, or endpoint management tools, to reduce false positives.
- Pay special attention to visibility gaps around protected or sensitive processes where collection may be limited by policy, sensor configuration, or operating-system protections.
- Because no official detection logic is provided, require local validation with representative endpoint telemetry before treating this analytic as operational coverage.
Mitigation priorities
- Harden access to credential-sensitive processes and limit administrative privileges on Windows endpoints.
- Ensure endpoint security controls are configured to monitor or restrict suspicious code injection, memory tampering, and module loading behavior where supported.
- Maintain allowlists or trusted baselines for software expected to install hooks or load modules into common desktop processes.
- Use incident response procedures that can quickly isolate affected hosts and preserve volatile evidence when credential-sensitive process tampering is suspected.
- Pair this analytic with identity controls such as credential hygiene, privileged access management, and rapid credential reset procedures for confirmed credential-theft investigations.
Analyst notes and limits
The supplied object is a detection analytic for Windows and describes credential harvesting via userland API hooking. It provides examples of relevant techniques and processes but does not include official detection logic, ATT&CK tactics, related techniques, groups, malware, or campaigns. Treat this as guidance for detection validation and telemetry review, not as proof of current adversary use or complete ATT&CK coverage.
No relationship context, tactic mapping, or official detection content was supplied. The assessment is limited to the official description, platform field, and external reference. Local endpoint sensor capabilities, process-protection settings, baselines, and retention policies will determine whether this analytic is practical in a specific environment.
Analytic 0389
Detects credential harvesting via userland API hooking (e.g., SetWindowsHookEx, IAT, or inline patching) by correlating memory modifications with hook installation functions and suspicious module loads in credential-sensitive processes like lsass.exe, explorer.exe, or winlogon.exe.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | b6f7fe4fb161… |
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 AN0389Open 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.