Loading story…
Linux kernels mark themselves as tainted when they enter non-standard states, including when unsigned, externally built, or otherwise unsupported kernel modules are loaded. Kernel documentation and DFIR guidance show that investigators can identify this condition through dmesg, /proc/modules, /proc/sys/kernel/tainted, and the kernel-chktaint helper, which decodes taint bits into human-readable reasons.
The guidance highlights that taint status can be an important forensic signal because it may indicate third-party or custom code ran in kernel space, but it also warns that proving which exact .ko file caused the taint can be difficult after the fact. Analysts are advised to correlate taint evidence with shell history, filesystem searches for module files, journal records, and audit logs to reconstruct how a suspicious module was introduced and loaded.
See real exploitation activity before you spend the cycle.
3 events from the most recent confirmed update back to the earliest known activity.
A DFIR blog post explained how to detect and investigate tainted Linux kernels using artifacts such as dmesg, /proc/modules, /proc/sys/kernel/tainted, kernel-chktaint, journalctl, and shell history. It also noted that reconstructing the original file path of a loaded tainting module may be difficult or impossible after the fact.
In the DFIR example, loading a custom kernel module named "dfir" caused the running Linux kernel to become tainted. Kernel messages indicated the module was out-of-tree and failed signature verification, and the taint value was later observed as 12288.
The Linux kernel documentation describes how a kernel becomes tainted when it enters certain non-standard states, such as loading proprietary, unsupported, or unsigned modules, and explains how taint flags are represented and interpreted.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers detailed **Syslogk**, a Linux loadable-kernel-module rootkit that alters kernel execution paths to conceal malware. It inline-hooks `proc_root_readdir` to hide processes associated with `was_sys_relay`, `tcp4_seq_show` to remove selected listening ports from TCP socket listings, and VFS `readdir` operations to conceal files and directories containing `was-patch`. Syslogk also unlinks itself from kernel-module and sysfs listings, frustrating checks using `lsmod` and `/sys/module`; kernel-level investigation and remediation are required to restore visibility. The activity reflects a broader Linux rootkit tradecraft pattern spanning user-space dynamic-linker hijacking through `LD_PRELOAD`, malicious kernel modules, ftrace and syscall hooks, and newer eBPF or `io_uring`-assisted techniques. Recent malware including PUMAKIT has combined memory-resident execution, an LKM rootkit, and an `LD_PRELOAD` shared object for persistence, stealth, privilege escalation, and command execution. Defenders should monitor sensitive linker and SSH configuration changes, suspicious shared objects and kernel modules, loaded eBPF programs, kernel-function and VFS-pointer integrity, tracing/probe activity, and anomalous web-server or system-account behavior.
Sep 9, 2026
Splunk published a detection analytic for Linux systems that identifies suspicious compiler activity building shared objects with initialization functions, a pattern associated with post-exploitation, persistence, and privilege-escalation tradecraft. The analytic looks for `gcc` and related compiler processes using flags such as `-shared` and linker options matching `-Wl,-init,*` while producing `.so` output, and it references **CVE-2025-32463** as a related concern. The rule is disabled by default, runs hourly when enabled, and depends on EDR or Sysmon for Linux process telemetry mapped into Splunk's Endpoint data model. The behavior aligns with several **MITRE ATT&CK** techniques, including **Shared Modules** (`T1129`), **Stage Capabilities** (`T1608`), and **Compile After Delivery** (`T1027.004`). ATT&CK describes adversaries loading malicious functionality through shared libraries and dynamically resolving code at runtime, while staged capabilities can be hosted or prepared on attacker-controlled infrastructure before delivery. Splunk warned that legitimate software development can produce similar compiler activity, so defenders are advised to tune out trusted build workflows while prioritizing unexpected `.so` compilation with initialization routines on production or non-development Linux hosts.
Aug 12, 2026
Security research highlighted a continued shift in attacker tradecraft toward **Linux cloud and container environments**, with stealth-focused malware increasingly abusing modern kernel capabilities. Elastic Security Labs documented the evolution of Linux rootkits from userland hijacking and LKM implants to newer generations that leverage **eBPF** and **io_uring** for stealth and evasion, citing examples including **TripleCross**, **Boopkit**, and **RingReaper**. Separately, reporting on **VoidLink** described a cloud-native malware framework designed to operate inside Linux workloads, detect whether it is running in major cloud providers and in **Docker/Kubernetes**, and adapt its behavior to remain persistent while harvesting sensitive material such as cloud metadata and credentials. Operationally, the same kernel features and observability gaps being leveraged by attackers are also driving defensive tooling improvements. Trail of Bits released *mquire*, an open-source Linux memory forensics tool intended to reduce dependency on external debug symbols by extracting structure and symbol information directly from memory using **BPF Type Format (BTF)** and **Kallsyms** (e.g., `/proc/kallsyms`-style data), then exposing findings through an interactive **SQL** query interface. While *mquire* is not tied to a single named campaign, it is directly relevant to investigating advanced Linux threats (including kernel-level implants and stealthy cloud malware) by enabling more reliable post-compromise analysis of Linux memory dumps across kernel versions.
Jul 12, 2026