Attackers Break Malware Analysis by Flooding Telemetry
Attacks
A recent paper introduces Telemetry Complexity Attacks, a practical way to blind anti‑malware systems without touching sensors or gaining extra privileges. Instead of sneaking past hooks or modifying agents, the trick is to weaponise the data those sensors produce. By spawning many child processes and creating deeply nested or oversized telemetry records, the researchers force serializers, databases and dashboards to choke, truncate or reject the very evidence defenders need.
The attack targets a mismatch most teams overlook: collection tends to be unbounded but processing is bounded. Common formats and stacks such as JSON, BSON, Python serializers and document databases have limits on depth, size and recursion. The proof of concept uses controlled recursion and volume to hit those limits during ingestion, transformation or storage. The outcome is denial of analysis, not denial of execution; the malicious activity runs, but analysts do not see a complete or any report of it.
The authors tested twelve analysis platforms and endpoint detection and response (EDR) products. Seven showed failures somewhere in the telemetry pipeline. Concrete examples include silent loss of visibility in Wazuh when JSON streams balloon, CAPEv2 hitting BSON 16 MB and nesting limits, reporting failures in Triage caused by oversized documents, and Velociraptor struggling with very large process trees that taxed memory and UI rendering. Two vendors received assigned CVE identifiers, CVE‑2025‑61301 and CVE‑2025‑61303, and several others issued patches or guidance.
Why this matters
This is not a niche academic curiosity. Security monitoring and forensic pipelines are central to incident response, automated triage and AI security analytics. If you can induce errors early in a pipeline, you get blind spots without needing to disable sensors or achieve privilege escalation. The same pattern applies wherever telemetry is collected and parsed, including agent platforms, cloud analysis services and analytics feeding dashboards or Large Language Model (LLM) based assistants. An attacker who can reliably trigger denial of analysis undermines confidence in alerts and may turn incident response into firefighting without evidence.
What to do next
Fixing this requires changes at the collection and processing boundary. Practical mitigations the paper recommends include enforcing strict bounds on telemetry depth, size and rate; normalising and validating inputs at collection points; implementing backpressure, queuing and overflow strategies so a noisy process does not take the whole pipeline down; and isolating telemetry processing so a failure in one path does not corrupt storage or dashboards. Maintain an isolated forensic store for raw artefacts so even if the primary pipeline rejects a document you still retain evidence for offline analysis. Finally, test pipelines with adversarial or fuzzed telemetry to find weak points before attackers do.
None of these are glamorous, and they cost time and engineering budget. Still, they are cheaper than responding to an incident you never saw. Start by auditing telemetry limits across your toolchain, add defensive quotas and alerting for serialization or storage errors, and consider a small, isolated forensic bucket that preserves raw inputs for later review. That combination buys you resilience and, importantly, some peace of mind when noisy or malicious processes start screaming at your collectors.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
Exploiting Data Structures for Bypassing and Crashing Anti-Malware Solutions via Telemetry Complexity Attacks
🔍 ShortSpan Analysis of the Paper
Problem
Anti malware systems rely on sandboxes hooks and telemetry pipelines to monitor program and system behaviour. This paper shows that these data handling components form an exploitable attack surface that can cause denial of analysis without disabling sensors or requiring elevated privileges. It introduces Telemetry Complexity Attacks TCAs a new class of vulnerabilities that exploit the gap between unbounded collection and bounded processing. The method recursively spawns child processes to generate deeply nested and oversized telemetry that stresses serialization and storage boundaries and visualisation layers such as JSON and BSON depth and size limits. Depending on the product this can lead to truncated or missing behavioural reports rejected database inserts serializer recursion and size errors and unresponsive dashboards. In all cases malicious activity is normally executed yet depending on the examined solution it is not recorded or presented to analysts. Therefore rather than evading sensors the pipeline that stores the captured data is broken.
Approach
The authors formalise a threat model and employ a binary proof of concept that recursively spawns child processes to generate high volume telemetry. Depth and rate are controlled and the telemetry is designed to stress serialization libraries document databases and user interfaces. The approach uses a multi layer onion style encryption to reduce static detection and aims to ensure the dynamic behaviour is observable at runtime. Experiments are conducted offline in laboratory environments using open source sandboxes and EDR tools and also include cloud based analysis services to validate cross platform behaviour. The methodology targets data representations rather than sensor tampering or privilege escalation and examines ingestion transformation and storage stages of the telemetry pipeline.
Key Findings
- Telemetry Complexity Attacks can cause denial of analysis by provoking failures at ingestion transformation or storage in the telemetry pipeline.
- Across twelve commercial and open source platforms seven exhibited failure in the telemetry pipeline with outcomes including missing or partial behavioural reports rejected database inserts serializer recursion and memory or UI stalls; two vendors were assigned CVE identifiers.
- Concrete platform level observations include silent loss of visibility on Wazuh where JSON streams ballooned to large sizes preventing actionable telemetry; CAPEv2 showed BSON 16 MB limits and nesting depth limits triggering recursion and reporting failures; Triage also demonstrated denial of analysis by generating deeply nested or oversized data that undermined reporting; Velociraptor exhibited large process trees causing memory and UI rendering issues.
- The attacks do not require elevated privileges and do not modify sensors or hooks, instead they weaponise the data structures used to represent telemetry.
- Mitigations proposed include enforcing bounds on telemetry depth and size, applying backpressure and queuing safeguards, validating inputs at the collection boundary, isolating telemetry processing paths, using robust streaming and error handling in serialization, and maintaining an isolated forensic store for raw artifacts.
Limitations
The authors acknowledge that results may not generalise to all commercial or proprietary solutions given architectural differences in telemetry pipelines and backends. Findings are most directly grounded in platforms using Python MongoDB and JSON BSON and may vary with other languages formats or databases. Some results come from open source pieces where internal implementations are known; for commercial products the analysis relies on external behaviour. The work focuses on high level mitigations and does not provide a full implementation or empirical evaluation across diverse products. It does not aim to achieve persistence privilege escalation data exfiltration or evasion of dynamic capture beyond introducing operational failures in telemetry pipelines.
Why It Matters
The study reveals a new class of denial of analysis that can undermine security monitoring in malware analysis and broader automation contexts including AI security analytics. Adversaries can weaponise telemetry pipelines to create blind spots by flooding pipelines with oversized or deeply nested telemetry, degrading incident response and reporting across multiple platforms. In AI security contexts telemetry and logging used by agents and analytics can be similarly exploited creating untrustworthy dashboards and missed detections. Practical mitigations emphasise strict telemetry bounds backpressure input validation isolated processing paths robust serialization input integrity checks and alerting along with an isolated forensic store to preserve raw data. The work highlights risks to reliability of security monitoring in critical infrastructure and automated systems and suggests future directions such as fuzzing telemetry structures and exploring graph based storage for behavioural data.