Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0722: Detection of Hooking

DET0722 is a detection strategy for identifying Hooking in ICS contexts. The business significance is that hooking can alter how legitimate software calls...

ICSDET0722Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Low

DET0722 is a detection strategy for identifying Hooking in ICS contexts. The business significance is that hooking can alter how legitimate software calls shared API functions, which may undermine trust in process behavior and complicate incident response. Because MITRE provides no official detection text, platforms, or tactics for this strategy, leaders should treat it as a coverage-validation topic rather than assume existing monitoring detects it.

Executive priority

Prioritize this as an assurance question for environments where ICS workstations, engineering systems, or supporting Windows-based processes are critical to operations. Ask whether the SOC and incident response teams can prove visibility into suspicious changes to process execution paths, DLL/API usage, and import address table redirection indicators. This is especially relevant for resilience planning and compliance evidence because the absence of explicit ATT&CK detection guidance means local telemetry and tool capability determine whether coverage exists.

Technical view

This strategy detects ATT&CK for ICS technique T0874, Hooking. The related technique description states that adversaries may hook API functions used by processes to redirect calls for execution and privilege escalation, and notes Windows API functions in DLLs and import address table redirection. SOC and IR teams should validate whether endpoint or host-analysis tooling can observe abnormal DLL/API behavior, process memory or module anomalies, and evidence of import address table modification. Since the detection strategy has no official detection field, analytics should be documented as locally derived and tested against approved software behavior to reduce false positives.

Likely telemetry

  • Endpoint process and module/DLL load telemetry where available
  • Process memory or integrity inspection results capable of identifying API hook or import address table anomalies
  • Security tool alerts related to process tampering, suspicious DLL behavior, or execution redirection
  • Application and system logs from ICS-supporting hosts where relevant
  • Incident response forensic artifacts showing loaded modules, process address space, or modified call paths

Detection direction

  • Inventory which ICS-supporting hosts and processes have telemetry capable of identifying hooking-like behavior; do not assume coverage from generic process logging alone.
  • Validate analytics against the relationship-driven indicators: API call redirection, DLL-exported function misuse, and import address table redirection.
  • Tune detections for legitimate software that may use hooking-like mechanisms, such as monitoring, security, compatibility, or engineering tools, to avoid excessive false positives.
  • Document blind spots where platforms are unspecified, endpoint sensors are absent, memory inspection is unavailable, or ICS assets cannot support intrusive collection.
  • Correlate suspected hooking with process lineage, module loads, file changes, and privilege context before escalating as malicious.

Mitigation priorities

  • Start with visibility: confirm which critical ICS-supporting endpoints can provide process, module, and memory-integrity evidence.
  • Harden and monitor software execution paths on systems where API/DLL behavior is operationally important.
  • Use change control and allowlisting concepts where appropriate to distinguish approved engineering or security tooling from unexpected process tampering.
  • Prepare IR procedures for collecting process memory, loaded module, and DLL/IAT evidence without disrupting cyber-physical operations.
  • Maintain audit evidence showing which systems are covered, which are excluded, and what compensating controls exist.
Analyst notes and limits

The useful decision point is not that MITRE names a detection strategy, but whether the organization can actually observe the low-level process manipulation implied by Hooking. For Glexia-style service delivery, this should drive a coverage review across managed detection, IR readiness, asset criticality, and ICS-safe evidence collection.

The supplied ATT&CK object has no official description, detection text, tactics, platforms, or labels. The only behavioral detail comes from its relationship to T0874 Hooking. Any concrete analytic logic, tool capability, affected platform list, or operational risk rating requires local environment evidence and should not be inferred from this object alone.

Official MITRE ATT&CK definition

Detection of Hooking

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
ICS T0874 Hooking This object detects Hooking.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
06507d5e75635e86...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 06507d5e7563…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0722
    Open source URL
Source and licensing

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.