Unhooking is the removal or bypass of monitoring hooks that security tools or operating systems place on processes, files, registry activity, or memory operations. Malware uses it to blind detection and hide malicious actions. Defenders should watch for tampering, protected process abuse, and mismatches between raw system activity and security telemetry.
How unhooking works
Unhooking removes or bypasses the user-mode or kernel-visible interception points that security tooling relies on to observe process, file, registry, or memory activity. By breaking those observation paths, malware can execute while leaving fewer traces for EDR, AV, or built-in telemetry to see.
It is usually part of a broader defense-impairment chain, not a standalone trick. Attackers may combine it with direct syscalls, AMSI bypass, ETW tampering, or vulnerable-driver abuse to reduce visibility across multiple layers at once.
Why unhooking is effective
Hooking works by placing an observation layer between the operating system and the security product so events can be inspected before they reach the console or alert pipeline. Unhooking targets that layer itself, which is why it can be so disruptive: the sensor may still be installed, but its view of reality is narrowed or altered.
That matters most when defenders assume telemetry from one source is complete. If only the hooked path is monitored, malicious behavior can look normal in logs while the underlying system activity continues unchanged. The gap between raw activity and reported telemetry is the signal defenders must treat seriously.
How organisations detect exposure
Exposure is usually assessed by looking for environments where endpoint sensors, kernel protections, or legacy monitoring components can be tampered with. A strong asset inventory, clear agent ownership, and awareness of where security tooling runs with elevated privileges all help identify where unhooking could matter most.
Security teams should also compare multiple data sources, because unhooking often shows up as disagreement between process creation records, file or registry events, memory inspection, and the security product’s own telemetry. When those sources diverge, the issue is often not missing activity, but missing visibility.
For deeper offensive and defensive context, NHIMG’s EDR Evasion and Defence Guide covers unhooking alongside BYOVD, ETW patching, AMSI bypass, and related blinding techniques.
Mitigation, detection, and recovery
The practical response is to reduce the attacker’s ability to modify or sidestep the observation stack. That means protecting sensor processes, hardening drivers and kernel trust boundaries, and treating tamper-protection gaps as security issues rather than tool-management issues.
Defenders should also investigate post-incident whether telemetry was trustworthy during the suspected compromise window. If unhooking occurred, review whether credentials, sessions, signing keys, or service-account material were used to deepen access, because visibility loss often accompanies lateral movement or persistence.
For control alignment, NIST SP 800-53 Rev 5 Security and Privacy Controls supports integrity, audit, and configuration controls that help detect tampering, while MITRE ATT&CK Enterprise Matrix helps map unhooking to defender-focused detection and adversary tradecraft.
Risk and Threat Considerations
Unhooking is dangerous because it does not need to break the whole endpoint, it only needs to blind the parts defenders depend on. Once monitoring is degraded, an attacker can hide process injection, suspicious memory operations, registry changes, or follow-on payload execution long enough to establish persistence or move laterally.
Failure mechanism: The security product keeps running, but the observation path it uses is altered, removed, or bypassed, so malicious actions no longer generate reliable telemetry.
Impact: Detection delay rises sharply, incident responders lose confidence in endpoint logs, and compromise may persist undetected until secondary evidence or business impact appears.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Unhooking defeats monitoring visibility on endpoints. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Unhooking creates discrepancies between raw activity and logged events. | |
| CM-7 — Least Functionality | Reducing unnecessary attack surface limits tampering paths used to unhook tools. | |
| Recommendation — Monitor for sensor tampering and telemetry gaps that indicate blind spots. Correlate audit sources and investigate missing or inconsistent events. Restrict unnecessary components and privileges that enable monitoring bypass. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Unhooking often shows up as broken or incomplete logging and alerting. |
| Recommendation — Centralise and validate logs so host-side tampering is easier to spot. | ||
| MITRE ATT&CK | T1562.001 — Impair Defenses: Disable or Modify Tools | Unhooking is a defense-impairment technique used to disable or alter security tools. |
| Recommendation — Map observed tampering to defense-impairment detections and hunt for adjacent abuse. | ||
Practitioner Guidance
What to watch for: Treat unexplained drops in endpoint telemetry quality, sensor tampering alerts, and mismatches between host activity and security logs as investigation triggers, not nuisance noise. A security stack that still reports health while missing obvious system activity deserves immediate scrutiny.
Governance implication: Unhooking should be handled as both a detection problem and an integrity problem, with clear ownership for sensor protection, tamper review, and post-incident telemetry validation. If your team cannot prove the sensor view is trustworthy, it cannot confidently prove the host is clean.