Listen to this Post
Introduction: The Most Dangerous Attacks May Be the Ones You Never See
Linux security has become increasingly dependent on deep visibility into the operating system kernel. Modern endpoint detection platforms do not simply watch files and processes from the outside; they increasingly rely on kernel telemetry, eBPF programs, audit data, module-loading events, and other low-level signals to understand what is happening beneath the surface.
That creates a difficult security problem: what happens when the attacker gains enough privilege to interfere with the mechanism producing the security telemetry?
New research into the Singularity Linux rootkit demonstrates exactly why that question matters. The technique reportedly allows a malicious Linux kernel module to evade a specific Elastic Defend detection path by manipulating Elastic’s trusted process tracking through an eBPF map. Instead of shutting down the security product entirely, the approach attempts something considerably quieter: preventing a particular module-load event from being generated in the first place.
That distinction is important.
Security teams often think of endpoint protection as a sensor that continuously watches the machine. But kernel-level attacks challenge that assumption. If an attacker can influence what the sensor sees, the problem is no longer simply whether the security product can recognize malicious code. The deeper question becomes whether the product is receiving trustworthy telemetry at all.
The research therefore offers a valuable lesson extending beyond Elastic Defend or Singularity. Detection is only as reliable as the telemetry beneath it.
The Core Discovery: Silencing the Signal Instead of the Security Product
The research from matheuzsecurity focuses on a technique designed to bypass Elastic Defend’s Linux kernel-module monitoring.
Elastic Defend has used a BPF-based module_load event for monitoring kernel module activity since approximately version 8.14. In version 9.5.0, Elastic expanded that telemetry by adding a taint_flags field and introducing an EQL detection rule called “Kernel Module Loaded with Tainting Flags.”
That development significantly improves visibility into suspicious kernel modules because Linux kernel taint information can provide useful clues about how a module was introduced into the system.
But the research demonstrates that an attacker does not necessarily need to hide the module itself.
Instead, the attacker can attempt to interfere with the telemetry path that reports the module-loading operation.
Why Kernel Module Loading Is So Important
Linux kernel modules are pieces of code that can be dynamically inserted into a running kernel.
Legitimate modules are common. Hardware drivers, filesystem functionality, virtualization components, security software, and third-party applications can all rely on them.
The danger comes from the fact that a malicious kernel module operates with extremely powerful privileges.
A successful rootkit operating inside the kernel can potentially manipulate processes, files, network activity, kernel structures, logs, and other security-relevant information.
This makes kernel-module monitoring particularly valuable.
A security system that observes a suspicious module being loaded can potentially identify the activity before the rootkit becomes deeply integrated into the operating system.
The Singularity research focuses on undermining precisely that visibility.
The Elastic Trusted-PID Mechanism
According to the research,
Conceptually, the flow looks something like this:
Module load request
|
v
Elastic eBPF monitoring
|
v
Identify loader process
|
v
Check trusted PID map
|
+++
| |
Trusted Untrusted
| |
v v
Exit Collect telemetry
|
v
module_load
|
v
EQL rule
The critical point is the trusted-process decision.
If the process responsible for loading the module is considered trusted, the tracing program can reportedly terminate its processing before collecting the relevant module information or generating the expected telemetry event.
That creates an opportunity for abuse.
The
The research claims that Singularity can temporarily cause its loader process to appear trusted before performing the kernel-module load operation.
If successful, the Elastic tracing logic can reportedly treat the operation differently and avoid generating the module_load event that defenders normally expect to see.
This is fundamentally different from simply disabling Elastic Defend.
The security agent may remain installed.
Its processes may still be running.
Other telemetry may continue to arrive.
Yet one particularly important event can potentially disappear.
That is what makes this class of attack especially interesting from a defensive perspective.
Why Dynamic Identification Matters
One technical detail highlighted by the research is the dynamic identification of the relevant Elastic BPF program and map.
Hard-coding a map identifier would be unreliable because identifiers can change after an Elastic Agent restart.
A more adaptable approach can search for the appropriate BPF components at runtime rather than assuming that a particular identifier will remain constant.
This illustrates an important reality of modern Linux security research: attackers increasingly need to understand not just the operating system, but also the internal architecture of the defensive tools operating inside it.
Endpoint security has become a software ecosystem of its own.
Elastic’s Taint Detection Adds Another Layer
Elastic’s addition of taint_flags in version 9.5.0 is significant because kernel taint information can provide additional context around suspicious module activity.
Kernel taint states can indicate circumstances such as unsigned modules, externally built modules, or other conditions that deserve investigation.
The corresponding EQL detection rule gives defenders an analytic specifically designed to identify kernel modules associated with tainting flags.
However, the research illustrates a fundamental weakness in event-driven security analytics:
A detection rule cannot alert on an event that never reaches it.
The rule itself may be correct.
The telemetry pipeline may be the vulnerable component.
Singularity Does Not Stop at eBPF
The research is particularly notable because the project reportedly does not depend on a single evasion technique.
The eBPF telemetry bypass represents one layer.
Singularity also reportedly attempts to address file-based and log-based detection mechanisms.
That matters because a sophisticated rootkit operator understands that defenders rarely rely on a single signal.
If endpoint telemetry is bypassed, investigators may look for the malicious .ko file.
If the file is difficult to identify, they may examine kernel logs.
If the logs are suspiciously incomplete, they may compare them with centralized collection.
A mature rootkit therefore benefits from attacking multiple visibility layers simultaneously.
YARA Detection Creates Another Battlefield
Elastic can use YARA-based scanning to search kernel-module files for known suspicious strings, symbols, function names, and code patterns.
This provides a different detection mechanism from runtime telemetry.
Instead of asking, “Did the kernel report that a module was loaded?” the scanner can ask, “Does this file look like a known malicious rootkit?”
That is an important distinction.
But signature-based detection has its own limitations.
If malicious source code contains distinctive identifiers or strings, static detection becomes easier.
Consequently, the research reportedly includes a source-obfuscation component that can randomize identifiers, rename files, and modify recognizable strings.
The objective is not necessarily to make the rootkit invisible to every scanner.
It is to make straightforward static signatures less reliable.
The Kernel Log Problem
Another defensive layer discussed in the research is traditional kernel logging.
When an unsigned kernel module taints a Linux system, the kernel can generate a corresponding message.
Security tooling can collect such information through system logs and forward it to a centralized platform.
That means defenders may still have a useful trail even if a particular endpoint analytic does not fire.
However, the research claims that Singularity can filter relevant kernel log output, potentially reducing the likelihood that the tainting message reaches Elastic through Filebeat.
This is an important reminder that logs themselves are attack surfaces.
A log collector can only forward what it receives.
And what it receives depends on the integrity of the system generating the log.
DKMS Exclusions Deserve Special Attention
The research also highlights exclusions surrounding kernel-module creation logic, including paths commonly associated with DKMS.
DKMS, or Dynamic Kernel Module Support, is widely used for legitimate third-party kernel modules.
That creates a natural challenge for defenders.
Security products must avoid generating large numbers of false positives from normal driver-building workflows.
But every legitimate exclusion introduces a potential area where malicious activity could attempt to blend into expected behavior.
This is not an argument for eliminating DKMS exclusions.
Instead, organizations should treat them as risk boundaries that require additional context.
A .ko file appearing inside an expected driver-development path is not automatically safe.
Deep Analysis: What the Technique Reveals About Linux Endpoint Security
Telemetry Is Part of the Attack Surface
The most important lesson is that endpoint telemetry itself must be protected.
Security teams traditionally think about protecting applications, credentials, databases, network infrastructure, and operating systems.
But modern endpoint detection creates another critical asset:
the integrity of the security
If an attacker can manipulate the data reaching the detection engine, the organization can have a false sense of security while the endpoint is already compromised.
The Problem With Trust
The trusted-PID mechanism exists for a legitimate reason.
Security software needs ways to distinguish expected activity from suspicious activity.
Trusted processes can reduce noise and improve performance.
But trust creates an interesting security boundary.
A process that is trusted by security telemetry becomes potentially more valuable to an attacker.
The attacker does not necessarily need to become trusted permanently.
Temporary trust at exactly the right moment may be enough.
That is a powerful conceptual shift.
Attackers Are Moving Toward Sensor-Aware Operations
Modern rootkits increasingly need to understand defensive tooling.
The attacker may ask:
What security agent is installed?
Which kernel hooks does it use?
Which eBPF programs are attached?
Which maps store security state?
Which events trigger detections?
Which logs are forwarded?
Which paths are excluded?
That is effectively reverse engineering the
The better the attacker understands the sensor, the more selectively they can attack it.
Event Suppression Can Be More Valuable Than Agent Termination
Completely disabling a security product is noisy.
It can generate service failures, agent health alerts, missing-heartbeat detections, or obvious administrative warnings.
Selective telemetry suppression is potentially much quieter.
The endpoint protection platform can remain operational.
The machine can continue reporting other events.
The attacker only needs to eliminate the signals that expose their specific operation.
This is why telemetry integrity deserves independent monitoring.
eBPF Is Powerful for Both Sides
eBPF has become one of the most important technologies in modern Linux observability and security.
Defenders use it for:
sudo bpftool prog show sudo bpftool map show sudo bpftool link show
These commands can help administrators inspect BPF programs, maps, and links on systems where bpftool is available.
The same visibility is valuable during incident response.
Unexpected programs, maps, or attachments should be investigated in context.
However, defenders should remember that once a system is deeply compromised, local command output cannot automatically be considered trustworthy.
Investigating Kernel Modules
Security teams can establish a baseline of loaded kernel modules with commands such as:
lsmod
More detailed module information can be queried with:
modinfo <module_name>
Administrators can also inspect loaded modules through:
cat /proc/modules
The objective is not to declare every unfamiliar module malicious.
Linux environments often contain legitimate vendor-specific and application-specific modules.
The goal is to identify deviations from the organization’s known-good baseline.
Checking Kernel Taint State
Linux exposes kernel taint information that can be useful during investigations.
For example:
cat /proc/sys/kernel/tainted
A non-zero value does not automatically mean that malware is present.
Kernel taint can have legitimate causes.
But an unexpected change in taint state should become an investigation clue, especially when it coincides with unexplained module loading or other suspicious activity.
Reviewing Kernel Messages
Defenders can inspect recent kernel messages with:
dmesg --ctime | tail -n 100
On systems where journal-based logging is used:
journalctl -k --since "1 hour ago"
Investigators should compare these records with centralized telemetry rather than relying exclusively on the local host.
A suspicious absence can itself be informative.
Comparing Independent Evidence
One of the strongest defenses against telemetry manipulation is redundancy.
For example:
Elastic endpoint telemetry
+
Kernel audit records
+
Centralized logging
+
Filesystem monitoring
+
Package-management history
+
Secure Boot state
+
Module-signing policy
When multiple independent sources agree, confidence increases.
When they disagree, the discrepancy deserves investigation.
Secure Boot Changes the Equation
Organizations running sensitive Linux workloads should consider enforcing Secure Boot where practical and compatible with their architecture.
Module-signing policies can make unauthorized kernel modules significantly harder to introduce.
The important word is enforcing.
A policy that exists only in documentation does not provide the same protection as a cryptographically enforced boot and module-loading chain.
Module Signing Should Be Part of the Baseline
Defenders should establish whether production systems require signed kernel modules.
Where appropriate, organizations should restrict unsigned module loading and monitor attempts to circumvent those controls.
This can substantially raise the difficulty for attackers attempting to deploy kernel-level persistence.
It does not solve every rootkit problem.
But it reduces the attack surface before endpoint detection even enters the picture.
Auditd Can Provide Another Perspective
Linux audit rules can provide additional visibility into sensitive operations.
For example, organizations may monitor module-related system calls according to their kernel and audit configuration.
A conceptual audit investigation could include:
sudo ausearch -m MODULE
The exact available events depend on the distribution, kernel, audit configuration, and logging architecture.
This is another reason centralized, independently collected telemetry matters.
File Integrity Monitoring Matters
A malicious kernel module generally has to originate somewhere.
Organizations can monitor sensitive directories associated with kernel modules and driver workflows.
Common locations may include:
/lib/modules/ /usr/lib/modules/ /usr/src/
The exact paths vary between Linux distributions and configurations.
Unexpected .ko files, unexplained timestamps, unusual ownership, or newly created module dependencies should be correlated with deployment activity.
Package Records Can Expose Inconsistencies
Package-management records can also provide useful context.
For Debian-based systems:
dpkg -S /path/to/module.ko
For RPM-based systems:
rpm -qf /path/to/module.ko
If a suspicious module does not correspond to an approved package, the finding deserves additional investigation.
Again, absence from package records is not definitive proof of malicious activity because legitimate organizations frequently build modules independently.
Context is everything.
DKMS Requires Contextual Monitoring
DKMS makes the situation more complicated because legitimate kernel modules can be generated dynamically.
Security teams should maintain an inventory of approved DKMS packages and expected build processes.
A useful investigation question is not simply:
“Was this module built through DKMS?”
Instead, ask:
“Was this module expected to be built on this host, by this package, at this time, under this change record?”
That approach dramatically reduces the chance that legitimate tooling becomes an automatic blind spot.
Root Privileges Change the Defensive Model
Kernel rootkits require significant privileges, but once an attacker reaches that level, many traditional assumptions become weaker.
A root-level attacker can potentially manipulate processes, files, logs, and security tooling.
Therefore, the best rootkit defense begins before root-level compromise.
Strong identity controls, privilege separation, vulnerability management, application isolation, Secure Boot, signed modules, and behavioral detection all contribute to reducing the probability of reaching that point.
Detection Should Be Designed for Failure
Security architecture should assume that individual sensors can fail.
That does not mean endpoint detection is ineffective.
It means organizations should avoid designing an environment where one endpoint event is the only evidence that matters.
If the module_load signal disappears, what else can tell the SOC that a module appeared?
If kernel logs suddenly stop arriving, what detects the gap?
If Filebeat remains online but its event volume changes dramatically, does anyone notice?
These are architectural questions, not merely product questions.
Telemetry Gaps Can Become Detection Signals
One particularly valuable defensive idea is to monitor the absence of expected telemetry.
Suppose a server normally generates a certain volume of kernel events.
Suddenly, those events disappear while the host continues generating network traffic and application activity.
That discrepancy could itself become an alert.
Security analytics traditionally focus on suspicious events.
Increasingly, they also need to understand suspicious silence.
A Rootkit Does Not Need Perfect Stealth
A sophisticated rootkit does not necessarily have to evade every detection technology.
It only needs to defeat enough of the detection chain to create uncertainty.
If endpoint telemetry says nothing suspicious happened, while another data source suggests kernel activity changed, investigators have a conflict.
That conflict can slow response.
From an
What Undercode Say:
1. The Bigger Story Is Telemetry Integrity
This research is less about one Elastic Defend bypass and more about the future of endpoint security.
2. Security Sensors Are Becoming High-Value Targets
Attackers increasingly understand that defeating visibility can be more efficient than defeating the entire security product.
3. eBPF Creates Tremendous Visibility
At the same time, eBPF gives defenders extraordinarily powerful ways to observe Linux behavior.
4. But Visibility Must Be Protected
A sensor operating at kernel level still needs mechanisms that protect the integrity of its own observations.
5. Trust Lists Are Valuable
Trusted-process mechanisms reduce noise and improve performance.
6. Trust Lists Also Need Hardening
Anything that determines whether telemetry is collected should be treated as security-sensitive state.
7. Selective Evasion Is the Real Threat
Attackers do not necessarily need to switch off endpoint protection.
8. They Can Target One Event
Suppressing one important telemetry source can be enough to defeat a specific analytic.
9. That Makes Detection Engineering More Difficult
A detection can be technically perfect and still fail when its underlying event disappears.
10. Kernel Modules Remain Extremely Sensitive
Few ordinary files deserve the same level of scrutiny as code that executes inside the Linux kernel.
11. Rootkits Exploit That Privilege
Once malicious code reaches the kernel, conventional user-space assumptions become increasingly unreliable.
12. File Detection Is Still Valuable
Static scanning provides a second line of defense against suspicious kernel modules.
13. But Signatures Can Be Attacked
Obfuscation can make recognizable strings and identifiers harder to detect.
14. Logging Is Not Untouchable
Attackers with sufficient privileges may attempt to manipulate local logs.
15. Centralization Helps
Central log collection makes it harder for a compromised host to rewrite the entire historical record.
16. Independent Sensors Are Better
Security teams should avoid putting every detection capability inside the same trust boundary.
17. Secure Boot Deserves Attention
Cryptographic verification can prevent some unauthorized kernel-level modifications before the operating system fully starts.
18. Module Signing Raises the Bar
Signed-module enforcement can make kernel-rootkit deployment substantially more difficult.
19. DKMS Is Not Automatically Dangerous
DKMS is widely used legitimately.
20. But DKMS Paths Need Context
Legitimate exclusions should not become permanent blind spots.
21. Baselines Are Essential
Organizations should know which kernel modules belong on each class of Linux host.
22. Change Management Matters
Unexpected kernel changes should be correlated with approved maintenance activity.
23. EDR Health Monitoring Is Not Enough
A green endpoint status does not prove that every underlying telemetry source is intact.
24. SOCs Need Telemetry-Loss Detection
A missing event stream can itself represent suspicious behavior.
25. Silence Can Be an Indicator
An attacker may reveal themselves through what suddenly stops happening.
26. Cross-Source Correlation Becomes Critical
Kernel, filesystem, network, package, audit, and endpoint telemetry should reinforce one another.
27. No Single Detection Should Be Sacred
Every analytic needs backup evidence.
28. Security Teams Should Test Their Assumptions
Purple-team exercises can determine whether important detections still function when individual telemetry sources fail.
29. Linux Defenders Need Kernel-Level Expertise
Modern endpoint security cannot be understood entirely from a user-space perspective.
30. Security Engineers Must Understand eBPF
Knowing how programs, maps, links, and attachments work is becoming increasingly important.
31. Rootkit Research Helps Defenders
Offensive research exposes assumptions that defensive products may otherwise leave untested.
- Vendor Detection Rules Are Only One Layer
Organizations need their own detection engineering around critical assets.
33. Telemetry Architecture Is Security Architecture
The pipeline carrying security events deserves the same protection as other critical infrastructure.
- Root Privilege Should Be Treated as a Crisis
Once an attacker obtains powerful local privileges, defenders should assume that some host-level evidence may be unreliable.
35. Remote Evidence Becomes More Important
Independent collection can preserve information that a compromised endpoint attempts to suppress.
- Kernel Security Is Becoming a SOC Problem
Kernel events are no longer exclusively the domain of Linux administrators.
37. Detection Must Become More Resilient
The best systems continue providing useful evidence even when one sensor is compromised.
38. Attackers Will Keep Studying Security Products
As endpoint platforms become more sophisticated, attackers have stronger incentives to reverse engineer them.
39. The Defensive Answer Is Diversity
Multiple independent telemetry sources make selective evasion harder.
40. The Final Lesson Is Simple
If your security system cannot tell when its own eyes have been covered, the attacker has already gained a dangerous advantage.
✅ Elastic Defend Uses eBPF-Based Linux Telemetry
The
The research specifically concerns interference with the telemetry path rather than a conventional vulnerability that simply crashes or disables the security product.
✅ Kernel Taint Information Can Provide Valuable Security Context
Linux kernel taint information can indicate conditions that deserve investigation, including situations involving externally built or unsigned modules.
However, a tainted kernel does not automatically mean that malware is present.
✅ Independent Telemetry Is an Important Defense
The recommendation to correlate endpoint events with kernel logs, auditing, filesystem monitoring, package records, Secure Boot, and module-signing controls is sound security practice.
No individual telemetry source should be assumed to be permanently trustworthy after a serious kernel-level compromise.
❌ A Missing module_load Event Does Not Prove a Rootkit Is Present
Telemetry suppression is only one possible explanation for missing events.
Agent configuration changes, software upgrades, service failures, kernel changes, policy modifications, or ordinary operational problems can also cause telemetry gaps.
The correct response is correlation and investigation—not an automatic malware verdict.
Prediction
(+1) Linux Endpoint Security Will Become Increasingly Focused on Telemetry Integrity
As Linux security products rely more heavily on eBPF and kernel instrumentation, future detection platforms are likely to place greater emphasis on protecting and validating the telemetry pipeline itself.
We should expect more mechanisms designed to detect unexpected changes to BPF programs, maps, links, kernel instrumentation, module-loading behavior, and sensor state.
Security teams will also increasingly monitor for missing telemetry, rather than waiting exclusively for suspicious events to appear.
The long-term direction is clear: endpoint security will move from simply asking “What happened?” toward a second question that may be even more important:
“Can we trust that we saw everything we were supposed to see?”
That question could become one of the defining challenges of Linux security as attackers push deeper into the kernel.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.stackexchange.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
