Your dashboards are green, your EDR is running, your SIEM is ingesting logs, and your SOC is staffed, everything looks healthy, and yet attackers are inside your network right now, they have been for weeks, and nothing has fired.

This is the monitoring gap, and it is not a failure of your tools, it is a structural problem, runtime detection was built to catch certain kinds of attacks, and the attacks that matter most are increasingly designed to avoid exactly the layers where monitoring lives.

Let me walk through why this happens and what you can actually do about it.

Important Disclaimer

This article is intended for educational and defensive purposes only, the techniques described here are shared to help security professionals understand emerging threats so they can better protect their systems.

Do not use these techniques against systems you do not own or do not have explicit written permission to test, unauthorized testing is illegal in most jurisdictions.

The author assumes no liability for any damages, legal consequences, or other outcomes resulting from the use or misuse of this information, always obtain proper authorization before conducting any security testing, and stay legal, stay ethical, stay responsible.

What Runtime Detection Actually Sees

Runtime detection works by watching what happens while a system is running, it hooks into system calls, monitors process creation, tracks file writes, watches network connections, and looks for patterns that match known malicious behavior.

This is powerful, and it catches a lot of attacks, but it only sees what happens at the layers it is watching, and modern attackers have learned to operate at layers below or beside those observation points.

Here is the core issue, runtime detection assumes the attacker will eventually do something observable, they will launch a process, they will write a file, they will make a network connection, and that assumption is no longer safe.

Gap 1: Attacks Below the Monitoring Layer

The most fundamental gap is depth, runtime detection typically lives in user mode, it hooks into APIs and watches what applications do, but attackers who reach kernel mode can operate entirely below that visibility.

A vulnerable driver attack is a perfect example, an attacker loads a signed but flawed driver, they use it to unlink the EDR's kernel callbacks, and suddenly the EDR stops receiving telemetry, the dashboard stays green because the EDR process is still running, but it is blind.

This is not a bug in the EDR, it is a structural limitation, if you control the kernel, you control what the kernel tells the monitoring layer, and there is no amount of user-mode monitoring that can see past that.

The same principle applies to hypervisor-level attacks and firmware implants, each layer deeper than the monitoring layer is a place attackers can hide.

Gap 2: Attacks That Never Touch the Endpoint

Runtime detection is endpoint-centric, it assumes the attack will eventually reach a machine where an agent is running, but a growing number of attacks never do.

Consider a supply chain attack where the malicious code is injected into a software update, the update is signed, it is distributed through official channels, and it runs with full trust, the endpoint agent sees a legitimate process doing legitimate things because that is exactly what it looks like.

The same is true for attacks that live entirely in cloud control planes, an attacker who compromises an IAM role or a misconfigured S3 bucket never touches an endpoint, there is no process to monitor, no file to scan, no network connection that looks unusual.

Runtime detection has nothing to watch.

Gap 3: Attacks That Look Like Normal Behavior

This is the gap that catches the most mature teams off guard, even when the attack is technically visible, it can be indistinguishable from legitimate activity.

Living off the land is the classic example, an attacker uses PowerShell, WMI, and built-in Windows tools to do their work, every command they run is a legitimate administrative command, every process they launch is a signed Microsoft binary, and nothing about the activity is anomalous in isolation.

The context matters, but context is exactly what runtime detection struggles with, a single PowerShell command looks fine, the sequence of a hundred of them across three systems over two hours is suspicious, and most monitoring stacks are not correlating at that level.

Gap 4: Slow and Low Attacks

Detection rules often rely on velocity, too many failed logins in a minute, too many file writes in a second, too much data leaving the network in an hour, and attackers have adapted by slowing down.

A credential stuffing attack that tries one password per account per day will never trigger a rate limit, a data exfiltration that moves a few megabytes per hour will never trip a volume threshold, and a lateral movement that touches one system per week will never look like a campaign.

These attacks are designed to stay below the noise floor, and the noise floor is exactly where detection thresholds sit.

Gap 5: The Logging Problem

Runtime detection depends on logs, and logs have three problems, they can be incomplete, they can be tampered with, and they can be overwhelming.

Incomplete logging is the most common issue, many systems log what they log by default, and that default is rarely enough to reconstruct an attack, Windows, for example, does not log process command lines by default, which means an entire class of attacks is invisible until you turn on the right audit policy.

Log tampering is the second problem, attackers who reach a system with sufficient privileges can delete logs, modify logs, or disable logging entirely, and if the logs never reach a central collector before they are tampered with, the evidence simply disappears.

Log volume is the third problem, modern environments generate so many events that teams cannot review them all, and detection rules tuned to reduce noise inevitably create blind spots.

Real Scenarios

Scenario 1: The Callback Unlink

The Setup

A financial services firm has EDR deployed on every endpoint, the SOC monitors dashboards 24/7, and the team feels confident in their coverage.

The Attack

An attacker gains initial access through a phishing email, they download a vulnerable driver from a legitimate vendor, they load it, and they use it to unlink the EDR's kernel callbacks, the EDR process keeps running, the dashboard stays green, and the SOC sees nothing.

Over the next three weeks, the attacker moves laterally, steals customer data, and establishes persistence, none of it is visible because the telemetry pipeline was severed at the kernel level.

The Result

The breach is discovered months later by a third party, the data is already on the dark web, and the firm cannot determine how long the attacker had access.

The Lesson

Runtime detection that lives above the kernel cannot see attacks that happen in the kernel.

Scenario 2: The Cloud Control Plane

The Setup

A SaaS company runs entirely in the cloud, they have endpoint agents on developer laptops, but their production environment is serverless and containerized, there are no endpoints to monitor in the traditional sense.

The Attack

An attacker compromises a developer's personal access token through a supply chain attack on a dependency, they use the token to assume an IAM role, they enumerate the environment, they find a misconfigured S3 bucket, and they exfiltrate customer data directly from cloud storage.

The Result

No endpoint agent saw anything, no process ran on a monitored machine, no file was written to a watched directory, the entire attack happened through cloud APIs, and the runtime detection stack had nothing to observe.

The Lesson

Endpoint-centric monitoring has nothing to say about cloud control plane attacks.

Scenario 3: The Slow Exfiltration

The Setup

A healthcare organization has DLP tools that alert on large data transfers, the threshold is set at 100 megabytes in an hour, and the team believes this catches exfiltration.

The Attack

An attacker exfiltrates patient records at a rate of 50 megabytes per hour, they do it during business hours, they blend the traffic with legitimate backups, and they run it for three weeks.

The Result

The total data stolen exceeds 25 gigabytes, but no single hour ever crossed the threshold, and the DLP never fired.

The Lesson

Threshold-based detection is trivially bypassed by attackers who are patient.

Scenario 4: The Living Off the Land Campaign

The Setup

A manufacturing company has EDR with behavioral detection, the rules flag known malicious tools and suspicious process trees.

The Attack

An attacker uses only built-in Windows tools, they use PowerShell for reconnaissance, WMI for lateral movement, scheduled tasks for persistence, and certutil for file transfer, every binary they touch is signed by Microsoft, every command they run is a legitimate administrative command.

The Result

The EDR logs the activity but does not alert, because nothing in isolation crosses the threshold for malicious behavior, the campaign continues for months.

The Lesson

Behavioral detection struggles when the behavior is indistinguishable from legitimate administration.

How to Close the Gap

Closing the monitoring gap requires accepting that no single layer is sufficient, and building detection that spans multiple layers and correlates across them.

1. Monitor at the Kernel Level

User-mode monitoring can be blinded, look for tooling that operates at the kernel level or below, hypervisor-based security, eBPF-based monitoring on Linux, and hardware-assisted telemetry all provide visibility that survives user-mode tampering.

2. Extend to Cloud Control Planes

Endpoint monitoring is necessary but not sufficient, ingest cloud audit logs, monitor IAM activity, track API calls, and alert on unusual control plane behavior, most cloud providers offer detailed audit logging, and most teams do not use it to its full potential.

3. Correlate Across Time and Systems

Single events are rarely suspicious, sequences are, build detection that looks at behavior over hours and days, not just seconds, and correlate across systems so that activity spread thin is still visible when aggregated.

4. Tune for Anomaly, Not Just Signature

Signature-based rules catch known attacks, anomaly-based detection catches novel ones, invest in behavioral baselines, user and entity behavior analytics, and models that flag deviation from normal rather than match against known bad.

5. Protect Your Logs

Logs that can be deleted are logs you cannot trust, ship logs to a centralized, append-only store in real time, use immutable storage where available, and monitor for logging gaps that might indicate tampering.

6. Enable the Right Audit Policies

Many attacks are invisible simply because the right logs are not being collected, enable command line auditing, PowerShell script block logging, process creation with command lines, and cloud audit logging, the visibility you get is proportional to the logging you enable.

7. Layer Deception

Deception catches attackers who are otherwise invisible, honeypots, honeytokens, and canary files generate alerts when touched, and attackers who avoid traditional monitoring often walk straight into deception because they do not know it is there.

8. Assume Breach and Hunt

If you assume you are already compromised, you look for evidence rather than waiting for alerts, threat hunting is the practice of proactively searching for signs of compromise that automated detection missed, and it is the single most effective way to close the gap.

Quick Reference: Closing the Monitoring Gap

The Bottom Line

Runtime detection is not broken, it is just incomplete, it sees what happens at the layers it monitors, and modern attackers have learned to operate elsewhere.

They go deeper, into the kernel, they go sideways, into the cloud, they go slower, below the thresholds, and they go quieter, mimicking legitimate behavior.

Closing the gap requires accepting that no single layer is enough, and building detection that spans the kernel, the endpoint, the cloud, the network, and the identities that tie them all together.

The attackers are not waiting for your monitoring to catch up, close the gap before they do.

FAQ Section

What is the monitoring gap?

The monitoring gap is the difference between what your detection tools are capable of seeing and what attackers are actually doing, it exists because detection lives at specific layers and attackers operate at others.

Why does runtime detection miss silent attacks?

Runtime detection watches user-mode activity, attackers who operate in the kernel, in the cloud control plane, or slowly over time can avoid those observation points entirely.

What is a kernel callback unlink?

It is a technique where an attacker uses a vulnerable driver to remove the EDR's kernel callbacks, the EDR process keeps running but stops receiving telemetry.

How do slow and low attacks evade detection?

They stay below thresholds, a small amount of data per hour or one login attempt per day never triggers velocity-based or volume-based rules.

What is living off the land?

It is an attack technique where the attacker uses only built-in system tools, every action looks like legitimate administration, making behavioral detection difficult.

What is the way for closing the monitoring gap?

Kernel-level monitoring, monitoring cloud control planes, correlation through time and space, proper auditing logging, deceptions, and proactive hunting.

Sources:

• MITRE ATT&CK
• OWASP
• NIST