Architectural Limits of Kernel-Level EDR:
Detecting In-Memory Execution in Modern Windows Systems

Kernel callbacks are episodic - they fire once per process, once per image load, once per thread. Between those events an adversary can freely allocate, write, decrypt, and re-protect memory without triggering any callback. Static PE parsing is also inherently blind to payloads that are never written to disk.

This is a structural property of the callback model, not an implementation defect. Closing the gap requires telemetry sources - ETW Threat-Intelligence, AMSI, user-mode stubs - that sit outside the conventional kernel callback set.

Protection laundering refers to a memory region transitioning from writable to executable and back again in the window between two scans. Because event-driven scanning is triggered by thread creation rather than continuous monitoring, a transition that occurs and reverts between scan events leaves no trace for the scanner to observe.

Closing this window generally requires streaming telemetry - such as the ETW Threat-Intelligence provider - rather than point-in-time scans.

PE import tables use relative virtual addresses (RVAs), which are only valid once the loader has mapped the image into memory. On disk, section data sits at file offsets that don't correspond to those RVAs. Dereferencing a disk-buffer offset as though it were an in-memory offset reads from the wrong location entirely - which, in kernel mode, risks touching pool guard pages and triggering a Bug Check rather than a recoverable fault.

The standard fix is to inspect imports from the mapped image via PsSetLoadImageNotifyRoutine instead of parsing them from a disk read.

PatchGuard (Kernel Patch Protection) periodically verifies that core kernel structures and read-only pages haven't been modified, and Bug Checks the system if it detects unauthorized modification - killing any EDR that relies on inline-hooking syscall handlers or SSDT patching within minutes.

HVCI (Hypervisor-Protected Code Integrity) goes further: pages can't be both writable and executable, dynamic code generation is prohibited, and unsigned drivers are refused. Modern kernel EDR drivers must rely exclusively on documented callback registration, be compiled with /INTEGRITYCHECK, and be signed with an EV certificate cross-signed by Microsoft.

Three sources complement the kernel callback spine:

• ETW Threat-Intelligence provider: streams memory-operation events (VirtualAlloc, VirtualProtect, WriteProcessMemory) that no kernel callback surfaces.
• AMSI: inspects script content (PowerShell, JScript, macros) just before interpretation - covering in-memory execution staged as text rather than bytes.
• Minimal user-mode telemetry stubs: hook a small set of high-value APIs and forward parameters to the kernel via a shared section, adding operation-level granularity.

Together with the kernel callback spine, these form a layered sensor where no single component needs to catch everything on its own.

Vendor claims and product datasheets aren't evidence - the only reliable way to know is to test the deployed configuration against the same techniques described in this post: reflective loading, process hollowing, manual mapping, and RW→RX protection transitions in private memory, executed the way a real adversary would chain them.

This is precisely what a Red Team Assessment is designed to answer. Rather than a checklist review, ISECURION's red team operators emulate real adversary TTPs mapped to MITRE ATT&CK, run them against your live EDR and SOC, and report exactly which techniques were detected, which were missed, and why - so you know your actual detection coverage, not your assumed coverage.

Penetration testing typically answers "can this system be compromised?" within a defined, often noisy, scope - it's optimized for finding as many vulnerabilities as possible in a fixed window. It doesn't tell you whether your detection stack would have noticed.

Red Teaming answers a different question: "would my people, process, and technology detect and respond to a real, stealthy adversary?" It's goal-oriented, avoids unnecessary noise, and specifically exercises the detection and response chain - EDR alerting, SOC triage, escalation - rather than just the initial exploit. For organisations that already have a kernel EDR deployed, Red Teaming is the more relevant exercise. Learn about ISECURION's Red Team Assessment methodology →

Because fileless techniques avoid disk artifacts, the signals are behavioral rather than file-based. Common indicators include: unexplained child processes spawned from powershell.exe, rundll32.exe, or mshta.exe; processes with network connections but no corresponding image on disk; EDR alerts referencing RWX or RW→RX memory regions that were dismissed as noise; unexpected LSASS access; and endpoints that are unusually slow or show high, sustained CPU from a process with no clear business purpose.

If you're seeing any of these and aren't fully confident in what happened, don't wait for confirmation - early containment matters more than certainty. ISECURION's Incident Response (DFIR) team can rapidly triage, determine scope, and contain active threats, including memory-resident and fileless intrusions. Reach out immediately if you suspect a live incident →

Yes, though it requires different techniques than traditional disk forensics. Memory forensics captures and analyzes RAM to recover injected code, decrypted payloads, network artifacts, and process/thread relationships that never existed as files. Combined with ETW traces, Windows Event Logs, and EDR telemetry captured at the time of the incident, investigators can frequently reconstruct the full attack chain - initial access, injection technique, and lateral movement - even when nothing was ever written to disk.

The catch is timing: volatile memory evidence degrades quickly, and once a compromised host is rebooted or the process exits, much of it is gone. This is why engaging DFIR specialists as early as possible in a suspected incident materially improves the odds of a conclusive investigation and a regulatory-ready report.

At minimum, annually - and additionally after any material change: a new EDR vendor or version, a SOC/MDR provider change, significant infrastructure changes, or following any real security incident. Detection coverage isn't static; EDR vendors patch gaps, adversaries develop new evasion techniques, and your own environment changes constantly, so a red team result from eighteen months ago tells you very little about today's actual exposure.

Organisations with a mature security programme often move to a continuous or twice-yearly cadence. ISECURION scopes Red Team engagements from a single detection-validation exercise up to a comprehensive 3-6 week full-scope adversary simulation - get a customised assessment plan and timeline →

Don't reboot or reimage the affected host if you can avoid it - that's frequently the single biggest mistake made in the first hour, and it destroys the volatile memory evidence needed to determine what actually happened. Instead: isolate the host at the network level (not by powering it off), preserve logs and EDR telemetry, and avoid taking remediation actions until scope is understood, since premature cleanup can tip off an attacker who still has access elsewhere in the environment.

ISECURION's Incident Response team provides rapid breach assessment, forensic investigation, and regulatory-ready reporting for ransomware, business email compromise, and intrusions involving memory-resident malware. Contact our IR team now → - early engagement materially reduces both dwell time and total incident cost.