The prevailing consensus in modern security operations centers is that the Endpoint Detection and Response (EDR) platform provides an absolute record of events. This assumption is not merely optimistic; it is architecturally flawed. While EDR tools are proficient at monitoring high-level system calls and user-space telemetry, they operate under a fundamental vulnerability: they trust the operating system that they are tasked with monitoring.
In high-consequence security events, the adversary does not remain in the user-space. They descend.
When an actor achieves kernel-level execution, the EDR ceases to be an impartial observer and becomes a compromised witness. The "truth" presented in the management console is no longer a reflection of reality, but a curated narrative maintained by the adversary. The focus is not on alerts. It is on reconstruction of what the system no longer reports.
The Architectural Blind Spot — User-Space vs. Ring 0
To understand why EDR visibility fails, one must analyze the topology of the operating system. Most security agents operate primarily in Ring 3 (User-Mode), with hooks or drivers extending into Ring 0 (Kernel-Mode) to intercept specific actions. This design creates a parity problem. If an adversary gains execution rights at the same privilege level as the security driver, or lower, they can manipulate the telemetry before it ever reaches the EDR’s detection engine.
This is a structural property of the architecture. If the kernel is compromised, every piece of data the EDR receives, process lists, file system modifications, network connections, is filtered through a layer of adversarial control. The EDR sees what the kernel tells it to see.
When we perform a forensic reconstruction, we are not looking at the alerts the EDR generated. We are looking for the absence of an expected alert. This silence is the first forensic artifact of kernel-level persistence.
The BYOVD Vector — Bypassing the Front Door
The most common method for achieving this level of subversion is the "Bring Your Own Vulnerable Driver" (BYOVD) attack. In this scenario, a legitimate, signed driver is introduced into the environment. Because the driver is signed by a trusted authority (such as a hardware manufacturer), it bypasses Microsoft’s Driver Signature Enforcement (DSE).
Once loaded, the adversary exploits a known vulnerability within that trusted driver to gain arbitrary code execution in the kernel. At this point, the security posture of the organization changes instantly:
- Anti-Tampering is Disabled: The adversary can terminate the EDR’s protected processes from the kernel.
- Telemetry is Blunted: The adversary can unhook kernel callbacks, effectively blinding the security agent to new process creations or registry changes.
- The Chain of Custody is Broken: Any logs generated after this point are technically suspect.
From an investigative standpoint, the "event" did not start when the ransomware was deployed. It started weeks prior, when a signed driver for an obscure printer or diagnostic tool was silently loaded into memory. Without forensic readiness, this movement remains invisible.
DKOM: The Art of Disappearing in Plain Sight
Once kernel-level access is secured, adversaries often employ Direct Kernel Object Manipulation (DKOM). This technique involves the direct modification of internal kernel data structures, such as the EPROCESS block, which the operating system uses to keep track of active processes.
By unlinking a malicious process from the system's process list, the adversary makes that process invisible to standard diagnostic tools. If you run tasklist or open Task Manager, the process does not appear. More importantly, if the EDR queries the kernel for a list of active processes to perform its scheduled scan, the kernel, now manipulated, simply omits the malicious entry.
This is kernel-level persistence without observable process attribution. The code is executing, memory is being consumed, and network packets are being sent, but the administrative record shows a clean system.
Forensic reconstruction in this environment requires moving beyond API-based queries. It requires a physical memory acquisition and the manual identification of "orphaned" threads, execution chains that exist in memory but have no corresponding entry in the system’s process table. This is the difference between an automated tool's verdict and a defensible truth.
Why Automated Tool Verdicts Fail
The primary failure of EDR-centric investigations is the reliance on "Negative Evidence." If the tool did not fire an alert, the investigator assumes no compromise occurred. However, in the context of kernel-mode persistence, the absence of an alert is not evidence of absence; it is evidence of a compromised visibility layer.
Consider the following causal chain observed in reconstruction scenarios.
- Ingress: A standard phishing link leads to user-level execution.
- Elevation: A local privilege escalation (LPE) exploit is used to reach Administrator status.
- Kernel Access: A BYOVD attack is executed, loading a known vulnerable signed driver.
- Blinding: The adversary uses the driver to unregister the EDR’s
PsSetCreateProcessNotifyRoutine. - Persistence: A rootkit is installed to maintain DKOM-based invisibility.
- Exfiltration: Data is moved over a period of 60 days.
Throughout steps 4, 5, and 6, the EDR console reported "Healthy." The organization’s internal team, relying on the tool's dashboard, concluded that the initial phishing attempt had been "contained." It was only through a post-incident architectural audit that the magnitude of the exfiltration was discovered.
Establishing a Defensible Truth
When an investigation moves from the IT department to the boardroom or the courtroom, "the tool said so" is an insufficient defense. Every claim must be backed by a validated sequence of telemetry that can withstand scrutiny.
To move beyond the limitations of EDR visibility, organizations must adopt a posture of forensic reconstruction. This involves:
- Independent Telemetry Correlation: Do not rely on a single source of truth. Correlate endpoint logs with network flow data, identity provider (IdP) activity, and cloud control-plane telemetry. If an endpoint is silent but the firewall shows a 50GB transfer, the endpoint's "health" is a fabrication.
- Kernel-Level Auditing: Implement rigorous monitoring of driver load events. Any driver not in a known-good baseline should be treated as a high-velocity threat, regardless of its digital signature.
- Memory Forensics as Standard Practice: In cases of suspected advanced persistence, memory analysis is not an optional "extra." It is the only way to validate the state of the kernel and identify DKOM-based manipulation.
- Forensic Readiness: Ensure that the right telemetry is being retained before the incident. You cannot reconstruct a causal chain if the evidence was never recorded or has already been rotated out of the SIEM.
The Human-in-the-Loop Necessity
Kernel-level persistence invalidates the assumption that endpoint telemetry reflects reality. If the operating system is compromised, the record it produces cannot be treated as evidence without independent validation.
Detection identifies events within a trusted system.
Reconstruction validates whether that system can be trusted at all.
If you cannot answer that question, you are not investigating the incident. You are inheriting the adversary’s narrative.
Tools collect data. Investigators establish truth.
Penny Thorne is an investigative analyst at Caduceus Security Group, specializing in the synthesis of distributed telemetry and the reconstruction of high-consequence security events. She is dedicated to establishing defensible causal chains from fragmented evidence, ensuring every timeline can withstand adversarial scrutiny. Operating in a digital analysis role, she maintains an absolute commitment to human-validated logic and investigative authority.