Telemetry Complexity Attacks Are Here & They’re Coming for Your Logs

A security product can collect every event and still fail to show an analyst what happened.

Security products are built around a simple assumption. If a sensor records an action, an analyst will eventually be able to see it.

That is not always true.

Between the endpoint and the dashboard, an event has to survive collection, encoding, transport, storage, indexing, queries, and finally whatever interface is supposed to display it. A failure anywhere along that route can separate what the sensor observed from what the analyst receives.

A telemetry complexity attack targets that distance.

It does not necessarily try to become quieter. It creates activity that is valid enough to be collected but too large, too deep, too fast, or too structurally complicated for another part of the security pipeline to handle correctly.

The endpoint agent may remain active. The sensor may record the behavior. The dashboard may still open.

The evidence can disappear somewhere in between.

Researchers Evgenios Gkritsis, Constantinos Patsakis, and George Stergiopoulos presented telemetry complexity attacks at the 2026 USENIX Workshop on Offensive Technologies. Their research examined 18 commercial and open source malware analysis platforms and endpoint security products. Seven failed at different stages of the telemetry pipeline.

Some returned incomplete or missing behavioral reports. Some rejected database entries. Others encountered serialization errors or dashboards that became unresponsive. In certain cases, the tested activity continued running while the evidence never reached the analyst in a useful form.

The researchers call the result denial of analysis.

That phrase is important because the security product does not have to suffer a dramatic crash. A report can be truncated. A process branch can be omitted. A database insert can fail. A dashboard can stall. A sample can even appear harmless because the part of the record containing the malicious behavior never survived long enough to be displayed.

From the analyst’s chair, nothing may look obviously broken.

The research demonstrated the problem by recursively creating child processes. Security products commonly represent those relationships as process trees. One process launches another, which launches another, and the monitoring system attempts to preserve every parent, child, command, timestamp, and associated piece of metadata.

That structure can grow much faster than a flat process count suggests. The resulting telemetry may be converted into JSON or BSON, inserted as a database object, and rebuilt again inside a web interface. Each step has practical limits on object size, nesting depth, memory, queue capacity, or the number of elements that can be rendered.

The operating system may accept the activity while the security product cannot represent it.

This is what separates a telemetry complexity attack from an ordinary process storm. Raw volume is only one part of the problem. Shape matters. Depth matters. The size of each record matters. The rate at which the events arrive matters. A pipeline may cope with a large number of simple events and fail on a deeply nested structure that crosses an unexpected limit.

It also differs from a conventional distributed denial of service attack. A DDoS attack generally floods a service with outside traffic so legitimate users cannot reach it. A telemetry complexity attack can begin with valid behavior on a monitored endpoint and target the systems responsible for explaining that behavior.

The computer may keep running. The malicious process may finish. The failure happens inside the evidence chain.

That makes telemetry itself an attack surface.

Security tools inspect files, processes, network traffic, scripts, and memory for signs of manipulation. The infrastructure carrying the resulting telemetry is often treated as plumbing. It is expected to accept whatever the sensors produce and deliver it intact.

The researchers found that this trust was not always deserved.

Their tests produced failures in serializers, storage systems, application interfaces, and browser based dashboards. The work led to patches, configuration changes, and multiple vulnerability disclosures. More importantly, it exposed a design problem that can exist across products rather than inside one specific security agent.

Collection can be practically unlimited. Processing never is.

That mismatch becomes dangerous when security teams measure visibility by whether an endpoint agent is installed, running, and sending events. A healthy sensor icon does not prove that every event was accepted downstream. A database that is online does not prove it stored the full process tree. A dashboard that loads does not prove the investigation is complete.

Defenders need to monitor the monitoring.

Event counts observed at the endpoint should be compared with the records accepted by the backend and the objects presented to analysts. Serialization failures, rejected inserts, missing process branches, unusual tree depth, sudden indexing gaps, and dashboards that stall during bursts of activity should be treated as security signals.

Failure also needs to be loud.

If a report was truncated, the analyst should be told. If an object exceeded a storage limit, the rejected data should be preserved elsewhere. If the interface cannot render the complete process tree, it should provide a smaller view without pretending the missing evidence never existed.

Raw artifacts matter for the same reason. A polished dashboard is useful, but it should not be the only place where the history of an incident exists. When the presentation layer fails, defenders still need access to what the sensor originally collected.

Security products should also be tested against hostile telemetry, not only recognizable malware. The question is no longer limited to whether a tool can detect a suspicious action. It must also be able to survive the record created by that action.

For years, endpoint security has focused on seeing more. More events, more context, more relationships, and longer histories were treated as better visibility.

Telemetry complexity attacks reveal the other half of the problem.

Can the rest of the system survive everything the endpoint sees?

The sensor may collect the evidence perfectly. If that evidence dies on the way to the screen, visibility is still gone.

Take a TCA, mix it with a ksld.sys (tampered) kernel driver, and a RAT…you’ve got an absolute DoA: denial of analysis. Telemetry pipelines were, in part supposed to cut costs and tame complexity. A TCA turns that promise inside out. It doesn’t merely evade telemetry, it weaponizes it, drowning the pipeline in its own logs until visibility disappears beneath the evidence.