SIEM Log Collection on Linux Systems and a Stealth-Oriented Telemetry Research
Have you ever wondered how SIEM tools collect logs on Linux systems? We did. And we conducted a serious research on this topic.
In modern security architectures, the concept of stealth has become increasingly critical. Detection is no longer only about whether an action occurs, but also about how visible that action is to monitoring systems.
When we examine existing approaches, several techniques stand out.
1. Disabling agent connectivity
The first approach involves disrupting or disabling the communication channel of endpoint agents to prevent logs from being forwarded to centralized systems.
While this method may create a form of silence, it introduces two major problems:
- A sudden interruption in log flow
- Immediate detection due to degraded or unhealthy agent status
In practice, this does not produce "clean stealth." Instead, it generates a strong anomaly signal that is quickly flagged by defensive teams.
2. RAM exhaustion-based log disruption (Wazuh example)
Another approach, especially in agent-based solutions like Wazuh, relies on intentionally exhausting system memory using legitimate processes.
The idea is simple:
- RAM pressure is increased
- Event processing slows down or fails
- Log forwarding becomes incomplete or delayed
However, this approach has a critical drawback: it produces significant system-level noise.
Memory pressure, CPU spikes, process slowdowns, and overall system instability become highly visible signals. In many cases, these indicators are detected before any stealth benefit is achieved.
Problem definition
Both approaches share a common limitation:
They attempt to reduce visibility but introduce artificial system anomalies.
This contradiction became the starting point of our research. We aimed to explore a model that reduces visibility without degrading system behavior or generating detectable noise.
Encountering eBPF
During this investigation, we came across eBPF (extended Berkeley Packet Filter).
eBPF is a powerful Linux kernel technology that allows sandboxed programs to run inside the kernel space without modifying kernel source code or loading external kernel modules.
Key properties include:
- Safe execution environment inside the kernel
- Verification layer ensuring program safety
- Attachment to hooks such as system calls, tracepoints, kprobes, and network events
- Efficient communication with user space via maps
- Wide adoption for observability, tracing, and security monitoring
In essence, eBPF creates a programmable visibility layer directly inside the kernel.
Classical telemetry pipeline
In traditional SIEM / EDR architectures, event flow typically looks like this:
- An event occurs on the system
- The event is stored or staged in RAM
- The agent collects the event from memory
- The event is normalized and sent to SIEM
- Correlation and detection logic is applied
This model relies on a key assumption:
Events remain unchanged before reaching the agent.
Critical observation: the RAM transition layer
Our focus was precisely on this assumption.
Telemetry data exists in a transient state in memory before being consumed by the agent. This short lifecycle is governed by:
- Event buffering mechanisms
- Kernel to user-space transitions
- Queue flushing behavior
This region is not strictly deterministic. It is influenced by timing, system load, and scheduling behavior.
eBPF hook-based approach
The strength of eBPF lies in its ability to attach to kernel-level hooks and observe or interact with events before they reach higher-level security agents.
At this stage, the key idea is:
The event is still in a state where it has not yet been consumed by the security pipeline.
If modification occurs at this point:
- The original signature can be altered
- Detection rules may no longer match
- The downstream security context changes
Emergence of a stealth model
This behavior is fundamentally different from traditional bypass techniques.
The goal is not to disable a security product, but to operate within the natural data flow of the system while reducing visibility.
We can define this as:
Runtime-level telemetry transformation before detection ingestion
In this model:
- The event is executed on the system
- It is modified before reaching detection systems
- The security stack processes incomplete or transformed context
Conclusion
This research highlights a key limitation in modern security architectures:
It is not only about what is detected, but also about when and in what form it is detected.
Telemetry may exist, but without correct timing and integrity, it can lose its meaning for detection systems.
This work represents the foundation of a new red team technique focused on low-visibility execution through runtime behavior rather than explicit product bypassing.
Links
Website: https://mileniumsec.com LinkedIn: https://www.linkedin.com/company/milenium-security/ YouTube: https://www.youtube.com/