AN1855: Analytic 1855
Monitor for API calls that can be used to install a hook procedure, such as the SetWindowsHookEx and SetWinEventHook functions.[1][2] Also consider analyzing hook chains (which hold pointers to hook procedures for each type of hook) using tools[2][3][4] or by programmatically examining internal kernel structures.[5][6] Verify integrity of live processes by comparing code in memory to that of corresponding static binaries, specifically checking for jumps and other instructions that redirect code flow.
Analyst context for executives and security teams
Analytic 1855 is about watching for software hooks and code-flow redirection that can let one process observe or alter another process’s behavior. For security leaders, the practical value is assurance: if critical operator workstations, engineering systems, or other sensitive endpoints rely only on basic process logging, this kind of in-memory manipulation may be missed. The ATT&CK object is sparse, but it highlights a defensible question: can the organization verify that live process memory still matches trusted binaries, and can it identify suspicious hook installation activity?
Executive priority
Treat this as a coverage-validation item for endpoint and incident response readiness, especially in environments where workstation integrity affects operational continuity. Leaders should ask whether SOC and IR teams can collect and analyze evidence of hook-related API usage, hook chains, and process memory integrity when investigating suspicious behavior. Because no tactics, platforms, or relationships are supplied, this should not drive a standalone risk conclusion; it should inform control assurance, forensic readiness, and audit evidence around endpoint integrity monitoring.
Technical view
The official analytic recommends monitoring API calls that can install hook procedures, specifically SetWindowsHookEx and SetWinEventHook, and analyzing hook chains that contain pointers to hook procedures. It also recommends verifying live process integrity by comparing in-memory code to the corresponding static binaries, looking for jumps or other instructions that redirect code flow. Detection engineers should validate whether their endpoint telemetry, EDR, memory forensics, or IR tooling can observe these events and whether analysts have a repeatable process for reviewing hook chains and memory-to-disk mismatches. Since ATT&CK provides no formal detection field, no platform list, and no relationship context, local testing and baselining are required before operationalizing alerts.
Likely telemetry
- API call telemetry for hook-related functions cited by MITRE, including SetWindowsHookEx and SetWinEventHook
- Endpoint process telemetry showing process identity, loaded modules, and parent/child context around hook activity
- Memory forensic artifacts, including hook chains and pointers to hook procedures
- Process memory versus static binary comparison results
- Indicators of code-flow redirection in memory, such as jumps or other redirecting instructions
Detection direction
- Confirm whether existing endpoint tools can capture or surface hook installation API calls and related process/module context.
- Baseline expected hook usage to reduce false positives, since legitimate software may use hook mechanisms.
- Validate the ability to inspect hook chains during investigations, either through approved tools or programmatic examination of relevant internal structures as described by MITRE’s references.
- Add forensic checks for memory-to-disk integrity mismatches where high-value processes are involved.
- Document blind spots where telemetry does not include API calls, memory artifacts, or live process integrity checks.
Mitigation priorities
- Prioritize visibility first: ensure SOC and IR teams can collect endpoint and memory evidence needed to evaluate hooks and code-flow redirection.
- Define investigation playbooks for suspicious hook activity, including process context review and memory integrity comparison.
- Apply least-privilege and endpoint hardening practices where local policy supports limiting unnecessary process manipulation, while recognizing this specific ATT&CK object does not prescribe mitigations.
- For critical operational environments, identify systems where memory forensic collection is feasible and pre-authorized before an incident.
- Use findings from local validation to support compliance evidence around endpoint monitoring and incident response readiness.
Analyst notes and limits
This is an ICS ATT&CK detection analytic with no supplied tactics, platforms, labels, aliases, or relationships. The usable content comes from the official description and references, which focus on hook-related API monitoring, hook chain analysis, and live process integrity comparison. The cited API names and references provide technical direction, but ATT&CK does not provide a complete detection rule or environmental scope here.
No official detection section, ATT&CK tactics, platforms, mitigations, or relationship context were supplied. This take therefore cannot assert active exploitation, attribution, business impact, or guaranteed detection coverage. Local environment telemetry, tool capability, and baselining are required to determine whether this analytic is actionable.
Analytic 1855
Monitor for API calls that can be used to install a hook procedure, such as the SetWindowsHookEx and SetWinEventHook functions.[1][2] Also consider analyzing hook chains (which hold pointers to hook procedures for each type of hook) using tools[2][3][4] or by programmatically examining internal kernel structures.[5][6] Verify integrity of live processes by comparing code in memory to that of corresponding static binaries, specifically checking for jumps and other instructions that redirect code flow.
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 | 02907777c646… |
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]
Microsoft Hook Overview
Microsoft. (n.d.). Hooks Overview. Retrieved December 12, 2017.
Open source URL -
[2]
Volatility Detecting Hooks Sept 2012
Volatility Labs. (2012, September 24). MoVP 3.1 Detecting Malware Hooks in the Windows GUI Subsystem. Retrieved December 12, 2017.
Open source URL -
[3]
PreKageo Winhook Jul 2011
Prekas, G. (2011, July 11). Winhook. Retrieved December 12, 2017.
Open source URL -
[4]
Jay GetHooks Sept 2011
Satiro, J. (2011, September 14). GetHooks. Retrieved December 12, 2017.
Open source URL -
[5]
Zairon Hooking Dec 2006
Felici, M. (2006, December 6). Any application-defined hook procedure on my machine?. Retrieved December 12, 2017.
Open source URL -
[6]
EyeofRa Detecting Hooking June 2017
Eye of Ra. (2017, June 27). Windows Keylogger Part 2: Defense against user-land. Retrieved December 12, 2017.
Open source URL -
[7]
mitre-attack AN1855Open 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.