New Linux Malware in 2026: What's Targeting Your Servers Right Now

For years, Linux malware occupied a strange blind spot in enterprise security thinking. Windows got the attention, the antivirus market, the incident response playbooks. Linux, the assumption went, was inherently safer. That assumption has aged very badly.

The threat landscape for Linux systems has undergone a structural shift. Attackers have invested seriously in kernel-level rootkits, fileless execution chains, and persistent implants that exploit the very features administrators rely on -- cron, LD_PRELOAD, systemd, and legitimate cloud tooling. The families documented below are not theoretical. They are actively circulating in 2025 and into 2026, targeting cloud VMs, containerized workloads, IoT endpoints, and enterprise Linux servers alike.

PUMAKIT: An LKM Rootkit Built for Evasion

In December 2024, Elastic Security Labs researchers Remco Sprooten and Ruben Groenewoud published an analysis of PUMAKIT, a sophisticated Linux rootkit that stood out for its multi-stage architecture and its use of the Linux kernel's ftrace hooking mechanism to intercept system calls at the kernel level. The samples were first spotted during routine threat hunting on VirusTotal -- a binary named cron uploaded on September 4, 2024 with zero detections at the time of upload.

A critical technical detail that the original article understated: PUMAKIT is a loadable kernel module (LKM) rootkit, not merely a shared object. Its rootkit component is named puma.ko -- a kernel module -- and its infection chain has five distinct components: a dropper (cron), two memory-resident ELF executables (/memfd:tgt and /memfd:wpn), the LKM rootkit (puma.ko), and a userland shared object called Kitsune (lib64/libs.so) that handles command-and-control communication from user space.

Elastic Security Labs researchers Remco Sprooten and Ruben Groenewoud described PUMAKIT as a sophisticated LKM rootkit deploying advanced stealth mechanisms to conceal itself while maintaining encrypted C2 communication.

-- Elastic Security Labs, Remco Sprooten and Ruben Groenewoud, "Declawing PUMAKIT," December 12, 2024

The rootkit loader (/memfd:wpn) disguises itself by mimicking the /usr/sbin/sshd executable rather than running as a recognizable foreign binary. (1036.005 Masquerading) Before deploying the kernel module, it evaluates environmental conditions: Secure Boot must be disabled and specific kernel symbols must be available. If those conditions are not met, the loader exits without leaving artifacts. This conditional deployment behavior makes sandbox detection unreliable.

One of the technically distinctive aspects of PUMAKIT is its kernel version targeting. The rootkit uses kallsyms_lookup_name() to resolve kernel symbols for ftrace hooking. That function was unexported from the Linux kernel after version 5.7 to prevent misuse by unauthorized modules. PUMAKIT circumvents this on targeted pre-5.7 kernels by embedding a fraudulent MODULE_LICENSE("GPL") declaration -- this fake license bypass allows the module to access the unexported function, because the kernel's licensing checks are based on the declared string rather than any cryptographic verification. Modern rootkits targeting kernels 5.7 and above use kprobes for equivalent symbol resolution; PUMAKIT's deliberate avoidance of kprobes is itself a signal that it was purpose-built for older, unpatched infrastructure. This targets a specific but still very large population: systems running RHEL 7, CentOS 7, and older Ubuntu LTS releases.

Once deployed, PUMAKIT uses ftrace to hook 18 system calls and several kernel functions including prepare_creds and commit_creds, enabling privilege escalation 1068 and core behavioral manipulation. Files and directories with names prefixed by zov_ are hidden from getdents() and getdents64() calls 1564.001. The rmdir() syscall -- normally used to remove directories -- is repurposed as a covert command interface 1205: sending the string zarya.0 grants root privileges to the calling process, while zarya.c.0 retrieves the rootkit's configuration. This unconventional use of a benign syscall as a control channel is an evasion technique designed to avoid detection rules that monitor unusual syscall sequences.

The Kitsune userland component intercepts user-level system calls and alters the output of ls, ps, netstat, top, htop, and cat to hide files, processes, and network connections associated with the rootkit 1014. C2 communication is handled by Kitsune over encrypted channels 1573 to the known C2 domain rhel.opsecurity1.art (IP: 89.23.113.204).

Perfctl: Three Years Undetected in the Wild

Perfctl (also written as perfctl) became one of the widely discussed Linux threats of 2024, and active infections were still being reported into early 2025. Aqua Security's Nautilus team published a full technical analysis in October 2024 documenting how the malware had evaded detection across thousands of Linux servers for what researchers estimated to be approximately three years.

The name is derived from its binary, which masquerades as perfctl -- a plausible-looking system performance tool 1036.004. Its persistence mechanism is particularly layered: it copies itself to multiple locations 1547, installs a rootkit via LD_PRELOAD 1574.006 to hide its network activity and processes, and registers itself as both a systemd service 1543.002 and a crontab entry 1053.003 to survive reboots through either path.

The Aqua Security Nautilus Team documented that perfctl routes external C2 traffic through Tor while using Unix sockets for local communication, and halts all mining activity the moment an administrator session is detected — resuming only after the session ends.

-- Aqua Security Nautilus Team, "Perfctl: A Stealthy Malware Targeting Millions of Linux Servers," October 2024

Perfctl's primary payload is a cryptominer running XMRig to mine Monero 1496, but Aqua's researchers noted that the access it establishes could trivially be repurposed for data exfiltration or as a foothold for more targeted attacks. The initial infection vector in observed cases was exploitation of misconfigurations in exposed services 1190 -- particularly Polkit (CVE-2021-4034, also known as PwnKit) and misconfigured Redis, Kubernetes API servers, and exposed environment variable files containing credentials.

The detection-evasion behavior of pausing activity when a user session is active is a design decision that speaks to the operational sophistication of the threat actors involved. An administrator running top or htop will see normal CPU usage. The mining resumes within seconds of the session closing.

Persistence Locations Used by Perfctl

# Binary copies
/tmp/.X[random]/perfctl
~/.config/[random]/perfctl
/usr/bin/perfctl

# LD_PRELOAD hook
/etc/ld.so.preload   # injected shared library path

# Crontab entry (appended silently)
*/30 * * * * ~/.config/[random]/perfctl

# Systemd service unit
/etc/systemd/system/perfctl.service

KadNap: Edge Devices and Peer-to-Peer C2

One of the more technically distinctive malware families discovered in 2025 is KadNap, documented by Lumen's Black Lotus Labs. First detected in August 2025, by early 2026 it had infected over 14,000 edge networking devices -- primarily Asus routers -- with more than 60% of victims located in the United States, followed by concentrations in Taiwan, Hong Kong, Russia, the United Kingdom, Australia, Brazil, France, Italy, and Spain.

What makes KadNap technically notable is its command-and-control architecture. Rather than connecting to a static C2 server over TCP or HTTP -- both patterns that network security tools monitor for -- KadNap uses a custom implementation of the Kademlia Distributed Hash Table (DHT) protocol to conceal its C2 infrastructure's IP address within a peer-to-peer network. Kademlia is the same DHT protocol underlying BitTorrent, which means KadNap's C2 traffic structurally resembles legitimate P2P traffic. However, Black Lotus Labs identified a notable weakness in this implementation: rather than behaving as a true decentralized peer-to-peer system where the final peer changes over time, every infected device in the KadNap network consistently routes through the same two final hop nodes before reaching the C2 servers. Those two persistent nodes -- 45.135.180[.]38 and 45.135.180[.]177 -- gave researchers a reliable tracking point that undermined the ostensible resilience of the DHT design.

Lumen Black Lotus Labs found that KadNap uses a custom Kademlia DHT implementation to bury its C2 infrastructure inside peer-to-peer traffic, making the command channel effectively invisible to conventional network monitoring tools.

-- Lumen Black Lotus Labs, "Silence of the Hops: The KadNap Botnet," March 2026

The infection begins with a shell script (aic.sh) downloaded from the attacker's infrastructure. The script creates a cron job 1053.003 that retrieves itself every hour at the 55-minute mark, renames itself to .asusrouter, and runs it. It then pulls a malicious ELF binary, renames it to kad, and executes the KadNap payload. The malware supports both ARM and MIPS processor architectures, covering the full range of consumer and small-business routers that run embedded Linux.

Compromised devices are enrolled into a proxy service called Doppelganger (operating as doppelganger[.]shop) 1090.002, which markets residential proxy access in over 50 countries. Black Lotus Labs assessed Doppelganger as a probable rebrand of Faceless, a proxy service previously linked to the TheMoon malware botnet -- which also targeted Asus routers. The operational continuity between these campaigns suggests the same threat actor ecosystem has been systematically harvesting router populations for several years, swapping tools and brand names while maintaining infrastructure. Lumen blocked all network traffic to and from the known KadNap control infrastructure at the time of disclosure and published IOCs for independent defenders.

SSHStalker: Old Tricks, Disciplined Execution

Discovered and analyzed by Flare in February 2026, SSHStalker is a botnet campaign that had compromised approximately 7,000 Linux machines by the end of January 2026 through SSH brute-forcing, with roughly half of those systems located in the United States. The campaign's operational fingerprint shows overlaps with the threat actor tracked as Outlaw (also known as Dota and Maxlas), suspected to be of Romanian origin based on language patterns found in IRC channel configurations and attack wordlists -- though Flare found no direct link to canonical Outlaw artifacts and assessed this as a derivative or copycat operator.

SSHStalker is not technically novel -- it does not use zero-days, new rootkits, or sophisticated evasion frameworks. What it demonstrates instead is operational discipline at scale: systematic mass-compromise workflows using a Go-based SSH scanner disguised as nmap 1110.003, efficient infrastructure recycling, and persistent footholds maintained across heterogeneous Linux environments. The malware deploys multiple C-based IRC bot variants and a Perl IRC bot for command-and-control 1102, compiles binaries directly on compromised hosts using GCC 1027.004, and uses cron jobs running every 60 seconds as a watchdog persistence mechanism 1053.003. The exploit arsenal consists of Linux 2.6.x kernel exploits from 2009-2010 -- outdated, but still effective against the "long-tail" of legacy infrastructure.

Flare's analysis of SSHStalker concluded that the campaign's power lies not in technical novelty but in disciplined execution — systematic mass-compromise workflows, infrastructure recycling, and durable persistence across heterogeneous Linux environments, achieved without a single zero-day.

-- Flare, "Old-School IRC, New Victims: Inside the Newly Discovered SSHStalker Linux Botnet," February 2026

The SSHStalker campaign is a useful counterpoint to the sophisticated kernel-level threats: a significant portion of Linux server compromises in 2026 still result from password-based SSH access left enabled on internet-facing machines. Security professionals covering the campaign noted that leaving password SSH open in 2026 is functionally an open invitation to credential-spraying botnets. If your environment still relies on password-based SSH, the practical steps for hardening SSH authentication are covered in detail on this site.

Goldoon: D-Link Devices and Botnet Infrastructure

In April 2024, Fortinet's FortiGuard Labs documented Goldoon, a botnet-building malware targeting Linux systems on D-Link routers -- specifically those running unpatched firmware for the D-Link DIR-645 model. The vulnerability exploited is CVE-2015-2051 (CVSS 9.8), a nearly decade-old remote code execution flaw in D-Link's Home Network Administration Protocol (HNAP) interface that allows remote attackers to execute arbitrary commands via crafted HTTP requests. Despite being patched in 2015, the flaw remained exploitable across a large population of unpatched devices still in service.

Goldoon drops a downloader script on affected devices, which fetches a bot binary compiled for the target architecture. D-Link gear runs on a variety of MIPS, ARM, and x86 embedded Linux variants, and Goldoon's operators compiled binaries for multiple CPU architectures to maximize coverage. The dropper identifies itself with a hard-coded HTTP User-Agent header reading FBI-Agent (Checking You) when retrieving the final payload -- an unusual operational signature that helped researchers fingerprint the campaign.

FortiGuard Labs researchers Cara Lin and Vincent Li documented that a successful Goldoon infection hands attackers full device control — system enumeration, C2 registration, and the ability to launch downstream attacks including DDoS campaigns against third-party targets.

-- Cara Lin and Vincent Li, FortiGuard Labs, "New Botnet Goldoon Targets D-Link Devices," May 2024

What makes Goldoon operationally notable is the scope of its DDoS capability: the malware includes 27 distinct DDoS attack methods, covering DNS, HTTP, ICMP, TCP, and UDP flooding protocols, with some methods still showing placeholder code at the time of analysis -- suggesting the operators were actively developing the toolkit. The Goldoon case is a reminder that "Linux malware" is not limited to server infrastructure. Devices that have reached end-of-life and no longer receive security patches become durable, essentially permanent members of botnet infrastructure because there is no detection or patch management pipeline touching them.

NerbianRAT and MiniNerbian: Linux RATs in Active Campaigns

NerbianRAT is a remote access trojan deployed against Linux servers as part of targeted intrusion campaigns attributed by Check Point Research and Censys to a threat actor tracked as Magnet Goblin. Campaigns documented in March 2024 exploited one-day vulnerabilities 1190 -- freshly disclosed CVEs that had not yet been patched across the target population -- including flaws in Ivanti Connect Secure (CVE-2024-21887) and Apache ActiveMQ (CVE-2023-46604).

NerbianRAT for Linux supports file system operations, arbitrary command execution 1059.004, process management, and configuration updates from the operator. It uses raw TCP sockets with a custom protocol for C2 communications, encrypting traffic with AES or RSA 1573.002 depending on the data type being transmitted. The Linux variant, first observed in May 2022, is notably sloppily compiled -- it retains DWARF debugging information, exposing function names and global variable names to analysis -- yet it remained effective precisely because it operated on edge devices that received no endpoint security tooling.

Accompanying NerbianRAT in several observed deployments was MiniNerbian, a stripped-down variant used to maintain backdoor access on compromised Magento servers, which Magnet Goblin repurposed as C2 infrastructure. MiniNerbian communicates via HTTP POST requests rather than raw TCP sockets, making it lighter and less conspicuous on web-facing systems. It supports three core functions: executing a command from the C2 and returning results, updating its activity schedule, and modifying its configuration.

GTPdoor: Targeting Telecom Infrastructure

Discovered and published by security researcher HaxRob in February 2024, GTPdoor is a Linux backdoor designed to operate inside mobile telecommunications networks -- targeting systems adjacent to the GPRS Roaming Exchange (GRX). It uses the GTP protocol (GPRS Tunneling Protocol) as its covert communication channel, making it essentially invisible to conventional network monitoring tools focused on TCP/UDP traffic.

HaxRob's analysis identified GTPdoor as a lightweight Linux backdoor purpose-built for telecom environments, embedding commands inside GTP-C packets so that its traffic is indistinguishable from legitimate roaming signaling and passes through firewalls without inspection.

-- HaxRob, "GTPdoor: A Linux Backdoor Concealed With GTP," February 2024

GTPdoor can receive commands embedded in raw GTP packets 1095, execute shell commands 1059.004, and relay results back through the same protocol channel. Attribution was linked by HaxRob to indicators associated with Earth Lusca, a Chinese state-aligned threat actor that has historically targeted telecommunications companies across Southeast Asia and Europe. The targeting of GRX-adjacent systems suggests intelligence collection 1119 rather than financial motivation.

KrustyLoader: Rust-Based Malware Chaining Ivanti Exploits

January 2024 brought the discovery of KrustyLoader, documented by Synacktiv, a Rust-written downloader deployed onto Ivanti Connect Secure appliances through CVE-2023-46805 and CVE-2024-21887. These two vulnerabilities -- authentication bypass and command injection -- were being exploited in the wild before patches were available.

The choice of Rust as the implementation language is significant. Rust binaries are harder to reverse engineer than C-based malware because the standard library functions are statically linked, making function identification more labor-intensive 1027.002. KrustyLoader's job is narrow: it retrieves and executes a Sliver command-and-control implant 1105. Sliver is a legitimate open-source red team framework -- using it means attackers leave fewer unique malware signatures 1072 and benefit from a tool actively maintained by its open-source community.

MITRE ATT&CK TTP Reference

The families documented in this article map across a consistent set of MITRE ATT&CK techniques. No single family uses all of them, but the overlap is striking: the same persistence mechanisms, the same evasion patterns, and the same post-exploitation paths appear repeatedly. The table below consolidates the key technique mappings for quick cross-reference.

What About Containers and Kubernetes?

The article so far has focused primarily on threats to Linux servers and network appliances, but readers running containerized workloads face a related and underexplored question: are these threats relevant to containerized environments, and does running workloads inside containers provide meaningful protection?

The short answer is: it depends on the malware family and the container configuration, but containers offer less protection than operators typically assume.

Perfctl explicitly targeted Kubernetes API servers as one of its initial access vectors. A misconfigured or exposed Kubernetes API server is treated by perfctl the same way it treats any other vulnerable service -- as an entry point. Once inside a container or pod, perfctl can use LD_PRELOAD injection within the container's filesystem and attempt to escape via known container breakout techniques if the runtime is misconfigured or running as root.

PUMAKIT requires kernel module loading, which is blocked in standard container deployments -- containers do not have access to insmod or modprobe by default, and the kernel is shared but protected from module insertion by container security policies. However, this protection only holds if Secure Boot and kernel module signing are enforced on the host. An operator running containers on a host with Secure Boot disabled and module signing unenforced has negated this control entirely.

SSHStalker and Goldoon target the host layer, not containers specifically. A compromised host running containers means all containers on that host should be treated as potentially compromised, because the attacker controls the underlying kernel. Container isolation does not survive host-level kernel rootkits.

For Kubernetes environments specifically, defenders should audit for exposed API servers, disable anonymous authentication, enforce network policies that restrict pod-to-pod communication, and use admission controllers to block privileged container deployments. The attack surface for Linux malware in a Kubernetes cluster is the union of the attack surface of every node in the cluster, not just the workloads themselves.

Attribution: What We Know and What We Don't

Attribution is handled inconsistently across these families, and the article is stronger for naming it explicitly rather than leaving gaps.

GTPdoor has the most confident attribution of any family covered here. HaxRob's analysis linked behavioral and infrastructure indicators to Earth Lusca (also tracked as TAG-22 and Bronze University), a Chinese state-sponsored threat group with a documented history of targeting telecommunications, government, and education sectors across Southeast Asia, Europe, and North America. The GPRS Roaming Exchange targeting is consistent with signals intelligence collection objectives.

SSHStalker shows overlaps with the Outlaw group (also called Dota or Maxlas), assessed by multiple researchers as Romanian-origin based on language patterns in IRC configurations and attack tooling comments. However, Flare explicitly noted they found no direct artifact link and assessed this as a derivative or copycat campaign rather than the same operators. Attribution here should be treated as low-to-moderate confidence.

NerbianRAT and MiniNerbian are attributed to Magnet Goblin, a financially motivated threat actor tracked by Check Point Research. Magnet Goblin is assessed as a distinct group from state-sponsored actors -- their targeting of Magento e-commerce servers, the use of compromised infrastructure for C2, and their rapid one-day exploitation tempo are consistent with financially motivated cybercrime rather than espionage.

PUMAKIT, Perfctl, KadNap, and Goldoon all lack confident public attribution at this time. PUMAKIT's deliberate targeting of legacy RHEL/CentOS infrastructure, its operational sophistication, and the use of a dedicated C2 domain suggest an organized threat actor rather than a commodity campaign, but no research group has publicly linked it to a named group. Perfctl's three-year operational run without disclosure suggests significant operational security discipline, again inconsistent with low-tier commodity operators.

Why Don't Standard Security Tools Catch These?

A natural question for defenders encountering this material is: why is commercial AV and EDR coverage so limited on Linux? The answer involves structural gaps, not just missed signatures.

Linux endpoint security tooling lags Windows by roughly a decade of commercial investment. The major EDR platforms -- CrowdStrike Falcon, SentinelOne, and Carbon Black -- all have Linux agents, but their rule depth, machine learning models, and behavioral detection coverage are substantially less mature than their Windows counterparts. This is partly because the commercial incentive historically followed the Windows desktop market, and partly because Linux systems are highly heterogeneous: the range of distributions, kernel versions, init systems, and application stacks makes building reliable behavioral baselines significantly harder.

Userland rootkits via LD_PRELOAD defeat most signature-based scanners entirely because they intercept the system calls that scanners themselves use to enumerate files and processes. A scanner running in the same userland as a LD_PRELOAD rootkit is asking the rootkit's hooks what is present on the system -- and the rootkit lies.

LKM rootkits like PUMAKIT operate below the userland entirely. Unless an agent uses eBPF or kernel-resident instrumentation that loads before the rootkit, it will observe only what the rootkit permits it to observe. This is why the recommendations throughout this article emphasize eBPF-based runtime security tools like Falco: eBPF programs load into the kernel and can observe system call behavior at a level that userland hooking cannot intercept.

Network appliances, routers, and IoT devices receive essentially no commercial AV coverage. There is no EDR agent for an Asus router's ARM/MIPS firmware environment. Detection for these devices must come from network-level monitoring -- analyzing traffic patterns, firmware integrity checking at boot, and automated alerting on unexpected outbound connections from device management interfaces.

If You Find One of These: Incident Response Basics

Detection sections describe how to find malware. This section addresses what to do once you have found it -- a question the article has left unanswered until now.

The first and most important principle: do not attempt to clean an active rootkit infection in place. LKM rootkits like PUMAKIT and userland rootkits delivered via LD_PRELOAD have both subverted the system tools you would use to perform the cleanup. Any command you run on a compromised system runs through the attacker's hooks. You cannot trust the output of ls, ps, find, or netstat on a rooted system. The only reliable remediation path is to image the disk for forensic analysis, then rebuild from a known-good baseline.

For network appliances compromised by KadNap or Goldoon, factory reset is the appropriate remediation path. Firmware on consumer and small-business routers is not designed to support forensic analysis or partial cleanup. Reset, apply the latest firmware, change all administrative credentials, and disable remote management interfaces that are not required.

How to Detect Linux Malware Using Behavioral Indicators

Step 1: Check for LD_PRELOAD injection

Run cat /etc/ld.so.preload to look for unexpected shared library entries. Any entry you did not add is a strong indicator of userland rootkit injection. Also run grep -r LD_PRELOAD /proc/*/environ 2>/dev/null to list all processes with that variable set in their environment.

Step 2: Hunt for memfd-based anonymous execution

Run ls -la /proc/*/exe 2>/dev/null | grep memfd to find processes executing from anonymous memory file descriptors rather than from a file on disk. This is the PUMAKIT infection pattern and indicates memory-resident malware execution.

Step 3: Audit new systemd unit files and crontabs

Run find /etc/systemd/system/ -newer /etc/passwd -name '*.service' to identify service unit files created after your last known-good state. Also run crontab -l and cat /etc/cron.d/* to check for unauthorized scheduled tasks. Entries pointing to binaries in /tmp, /dev/shm, or user home directories should be treated as suspicious.

Step 4: Check for unexpected kernel modules

Run lsmod and compare against a known-good baseline. For PUMAKIT specifically, look for modules without a legitimate package owner. Any unsigned or unpackaged kernel module warrants immediate investigation, particularly if it was loaded after system initialization. Additionally, run grep -r "MODULE_LICENSE" /sys/module/*/taint 2>/dev/null and cross-reference with your package manager -- PUMAKIT uses a fraudulent MODULE_LICENSE("GPL") declaration to bypass kernel licensing checks, so a module claiming GPL license with no matching signed package should be treated as highly suspicious on any pre-5.7 kernel system.

Step 5: Monitor for Tor and unusual outbound connections

Run ss -tulpn to list all listening and established connections, then cross-reference unexpected outbound connections against known Tor exit node lists. Perfctl specifically routes C2 traffic through Tor. High CPU processes with names resembling system utilities -- kthreadd, perfctl, kworker variants -- should also be investigated, particularly if they appear when no user session is active.

Step 6: Hunt for dormant-persistence indicators (SSHStalker pattern)

Run the following to enumerate all user crontabs and flag sub-minute execution intervals: for u in $(cut -d: -f1 /etc/passwd); do crontab -u $u -l 2>/dev/null | grep -v '^#' | grep -v '^$' | sed "s/^/$u: /"; done. Any cron job running every minute (*/1 * * * *) that invokes a binary in an unusual path is the SSHStalker watchdog persistence pattern. Also check for outbound IRC-protocol connections with ss -tnp | grep ':6667\|:6697\|:7000\|:7001', and alert on compiler execution on production servers via ausearch -x gcc -ts recent 2>/dev/null or an equivalent auditd rule -- SSHStalker compiles its C-based bot components directly on compromised hosts.

# Step 1: Check for LD_PRELOAD injection
$ cat /etc/ld.so.preload
$ grep -r LD_PRELOAD /proc/*/environ 2>/dev/null | strings

# Step 2: Hunt for memfd anonymous execution (PUMAKIT pattern)
$ ls -la /proc/*/exe 2>/dev/null | grep memfd

# Step 3: Find new systemd units not installed by packages
$ find /etc/systemd/system/ -newer /etc/passwd -name '*.service'
$ crontab -l && cat /etc/cron.d/*

# Step 4: Check kernel modules -- flag fake-GPL unpackaged modules (PUMAKIT pattern)
$ lsmod | sort > /tmp/lsmod_now.txt
$ diff /tmp/lsmod_baseline.txt /tmp/lsmod_now.txt
$ grep -r "MODULE_LICENSE" /sys/module/*/taint 2>/dev/null

# Step 5: List all active connections; look for Tor exit nodes (perfctl pattern)
$ ss -tulpn
$ ss -tnp | awk '{print $5}' | cut -d: -f1 | sort -u

# Step 6: Hunt dormant-persistence indicators (SSHStalker pattern)
$ for u in $(cut -d: -f1 /etc/passwd); do crontab -u $u -l 2>/dev/null | grep -v '^#' | grep -v '^$' | sed "s/^/$u: /"; done
$ ss -tnp | grep ':6667\|:6697\|:7000\|:7001'
$ ausearch -x gcc -ts recent 2>/dev/null

What Defenders Actually Need to Do

The threats above share structural properties that should shape defensive priorities. They exploit legitimate OS mechanisms for persistence (systemd, cron, LD_PRELOAD). They use encrypted channels, often over protocols that blend with legitimate traffic. They target known-CVE vulnerabilities, frequently within days of public disclosure. And they are often deployed against the seams of infrastructure — network appliances, telecom gear, and IoT devices that receive little security attention.

Generic advice like "use eBPF tools" or "patch faster" is structurally correct but operationally incomplete. What follows goes further: specific configurations, enforcement mechanisms, and deployment decisions that address the precise techniques documented in this article.

Kernel and System Integrity: Beyond "Enable Secure Boot"

Secure Boot is a verified mitigation against PUMAKIT — the rootkit checks for it and aborts — but enabling it is only the first step. The deeper control is the Linux Integrity Measurement Architecture (IMA) combined with the Extended Verification Module (EVM). IMA measures files before execution and compares them against a policy-defined set of known-good hashes. EVM extends this to protect file metadata and extended attributes from tampering. Together, they can enforce a kernel module loading policy that rejects any module not signed by a trusted key in the kernel's keyring.

On RHEL 9 and Ubuntu 22.04+, this means configuring /etc/ima/ima-policy to include a rule such as appraise func=MODULE_CHECK appraise_type=imasig, which requires a valid IMA signature before any kernel module loads. This is categorically different from relying on the kernel's MODULE_LICENSE string check — which PUMAKIT defeats with a fraudulent GPL declaration. IMA signature verification uses cryptographic keys, not string matching, and cannot be bypassed by a module-level declaration. On systems where deploying IMA is not immediately feasible, the intermediate control is enabling lockdown=integrity mode in the kernel, which restricts unsigned module loading without the full IMA policy infrastructure.

eBPF-based runtime security (Falco, Tetragon) deserves equivalent specificity. Deploying Falco without tuned rules leaves defenders with noisy output and alert fatigue. The behavioral patterns documented in this article map directly to specific rule conditions. For example: a Falco rule matching evt.type = open AND fd.name = /etc/ld.so.preload AND user.name != root catches unprivileged LD_PRELOAD injection attempts. A rule matching evt.type = execve AND proc.exepath contains memfd catches PUMAKIT's anonymous memory execution pattern. Tetragon goes further than detection: its in-kernel enforcement mode can terminate a process in-kernel the moment a policy violation is observed, before the process has time to complete its injection. For environments where a kernel rootkit is the primary concern, Tetragon's enforce mode against module loading syscalls (finit_module, init_module) provides a hard enforcement layer that sits below userland.

Patch Velocity: SLA Enforcement, Not Just Policy

Multiple families documented above were deployed through one-day exploits — CVEs that were public before the target population had patched. Standard 30-day patch cycles are not adequate for internet-facing services and network appliances. The 2025 Verizon DBIR reported a median time-to-exploit of zero days against network devices. Organizations should establish a tiered patching policy: CVSS 9.0+ CVEs affecting internet-facing systems require emergency patching within 48-72 hours, not the next monthly maintenance window.

The harder operational problem is not writing the policy — it is enforcing it. Vulnerability management programs frequently have good SLA documents and poor SLA compliance. Three mechanisms that close this gap in practice: first, integrating your vulnerability scanner output directly into your ticketing system with automated escalation rules tied to CVSS score and asset exposure tier, so that a CVSS 9.8 CVE on an internet-facing host creates a P1 ticket with automatic executive notification if it remains open past 72 hours. Second, implementing compensating controls through network segmentation that can be activated within hours while the patch is staged — blocking inbound traffic to the affected service port at the perimeter buys time without requiring a maintenance window. Third, for network appliances specifically, building a firmware inventory into your asset management system with automated CVE correlation: if you do not know what firmware version your 300 edge devices are running, you cannot know which ones are vulnerable within hours of a CVE disclosure.

SSH Hardening: Past Key-Based Auth to Certificate Infrastructure

Disabling password-based SSH authentication is the correct baseline, and SSHStalker's 7,000-host botnet demonstrates that this baseline is still not universally implemented. But authorized_keys files are themselves a persistence vector: an attacker who gains write access to a user's home directory can inject an SSH public key and maintain persistent access that survives password resets and most incident response procedures. The Goldoon and KadNap families both establish persistence mechanisms in user-writable directories for precisely this reason.

The more robust control is SSH certificate authority infrastructure using OpenSSH's built-in CA functionality. Instead of trusting individual public keys via authorized_keys, you configure servers to trust certificates signed by your internal CA (TrustedUserCAKeys in sshd_config). Certificates can carry short validity periods — 8 or 16 hours — meaning a stolen private key is useless after the certificate expires. The CA can issue new certificates on-demand after re-authentication. This architecture also provides centralized revocation: compromising a single server no longer means hunting for injected keys across hundreds of hosts. HashiCorp Vault's SSH secrets engine and Netflix's BLESS are two production-grade implementations of this pattern. For environments that cannot deploy a full CA, the intermediate improvement is auditing authorized_keys files with an automated job that alerts on any addition outside of your provisioning toolchain — catching SSHStalker-style key injection before the access is used.

Crontab Integrity: Baseline Comparison as a First-Class Control

T1053.003 (Scheduled Task/Job: Cron) maps to four of the eight families covered in this article. It is not a coincidence — cron requires no kernel access, works across all distributions, and survives reboots automatically. Despite this, crontab integrity monitoring is treated as a secondary audit item in many environments rather than a primary detection signal.

The practical implementation is straightforward: use AIDE (Advanced Intrusion Detection Environment) or Tripwire to baseline the contents of /var/spool/cron/, /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, and /etc/crontab. Any modification outside of a known package manager operation should generate an alert. For cloud environments, this can be implemented without a dedicated agent using auditd rules that watch these paths and stream events to your SIEM — a rule like -w /var/spool/cron -p wa -k crontab_modification in /etc/audit/rules.d/ will generate an audit event on any write or attribute change. SSHStalker's 60-second watchdog cron job creates a modification event the first time it writes — catching that event is the difference between a dormant-persistence infection and a detected incident.

Monitoring What Matters: Behavioral Signals, Not Just Tool Names

Several behavioral signals appear consistently across these malware families. A robust detection strategy covers all of the following, with specific detection logic rather than tool names alone:

• New or modified systemd unit files in /etc/systemd/system/ outside of package manager operations — auditd watch rule on that directory path, correlated against a package manager activity log to suppress false positives from legitimate deployments
• Changes to /etc/ld.so.preload or new shared objects in standard library paths — any entry in this file that was not placed by a known package should be treated as an active compromise, not a warning
• Crontab modifications, especially for non-root users and the system-wide /etc/cron.d/ directory — see the dedicated subsection above
• Processes communicating over Tor exit nodes or unusual ports — a regularly refreshed Tor exit node blocklist fed into your NGFW or Suricata ruleset, combined with an alert on outbound connections to ports 9050 and 9150 from unexpected process names
• High CPU utilization from processes with names resembling system utilities (kthreadd, perfctl, kworker variants) — process name masquerading is caught by comparing /proc/PID/comm against /proc/PID/exe; a process named kthreadd whose executable path is not a kernel thread should alert immediately
• Binaries executing from /tmp, /dev/shm, or user home directories — a Falco rule on execve where proc.exepath starts with these paths covers fileless staging across multiple families
• Anonymous /memfd: process execution (PUMAKIT's pattern) — ls -la /proc/*/exe 2>/dev/null | grep memfd run as a scheduled job, or a Falco rule matching fd.name contains memfd on open events
• Unexpected outbound P2P DHT traffic from router or edge device firmware processes — a Zeek script that alerts on UDP traffic to port 6881 or DHT protocol signatures from devices that have no business participating in BitTorrent networks
• Compiler execution on production servers — auditd rule watching /usr/bin/gcc and /usr/bin/cc for execution, which should be absent on production hosts; SSHStalker compiles its IRC bot directly on compromised hosts as part of staging
• Outbound IRC-protocol connections on ports 6667, 6697, 7000, and 7001 — these ports have essentially no legitimate use on a production Linux server and should be blocked at egress; any connection attempt should be treated as a confirmed indicator

Network Appliances and Embedded Linux: Firmware as a Security Domain

The Goldoon, KadNap, and GTPdoor cases make a point that deserves explicit emphasis: network devices are Linux systems and need to be treated as such. This means maintaining firmware update schedules for routers, firewalls, VPN concentrators, and NAS devices with the same urgency applied to servers. Devices that have reached end-of-life and no longer receive security updates should be replaced, not left in place.

Beyond patch management, the architectural control that addresses the KadNap compromise pattern specifically is management interface isolation. Router and switch management interfaces — web UIs, SSH, Telnet, SNMP — should be accessible only from a dedicated, firewalled management VLAN with no direct internet routing. KadNap's initial shell script assumes it can reach the device remotely; removing remote management exposure eliminates this entry path entirely rather than relying on patch timing. For devices that have already been deployed at scale without this segmentation, the compensating control is egress filtering: a firewall rule that blocks all outbound traffic from router management IP space to internet destinations, except for explicitly whitelisted update servers. This does not prevent compromise but breaks the C2 callback that makes the compromise operationally useful to the attacker.

For organizations with the infrastructure maturity to go further, TPM-based firmware attestation provides a cryptographic guarantee of boot integrity for managed network devices. Cisco's TrustAnchor module, Juniper's Trusted Platform Module support, and the IETF RATS (Remote Attestation Procedures) framework all provide mechanisms to verify that a device booted from an expected, unmodified firmware image. This capability is particularly relevant for telecom environments facing GTPdoor, where the attack is specifically designed to persist silently across device reboots. A device whose firmware hash does not match its expected value at boot triggers an out-of-band alert before any network traffic flows through it.

Finally, formal EOL tracking deserves more rigor than most organizations apply. Goldoon was still exploiting a CVE from 2015 against D-Link hardware in 2024. The practical outcome of running unpatched EOL network devices is not theoretical risk — it is permanent enrollment in botnet infrastructure with no remediation path available. EOL tracking for network appliances should be a scheduled, recurring audit item tied to procurement replacement cycles, not a reactive task triggered when a researcher publishes an IOC list that includes your device model.

Aqua Security's 2024 Cloud Native Threat Report concluded that the expansion of IoT and edge devices has dramatically widened the Linux attack surface, with threat actors systematically targeting these largely unmonitored systems precisely because of their predictable software stacks and long replacement cycles.

-- Aqua Security, "2024 Cloud Native Threat Report," 2024

Frequently Asked Questions

What Linux kernel versions does PUMAKIT target?

PUMAKIT targets Linux kernels before version 5.7. It relies on the kallsyms_lookup_name() function to resolve kernel symbols for ftrace hooking -- a function unexported after kernel 5.7 to prevent misuse. On targeted older kernels, PUMAKIT works around this restriction by embedding a fraudulent MODULE_LICENSE("GPL") declaration that tricks the kernel's licensing check into granting access to the unexported function. Modern rootkits targeting kernels 5.7 and above use kprobes for equivalent symbol resolution; PUMAKIT's deliberate avoidance of kprobes signals it was purpose-built for legacy infrastructure -- systems running RHEL 7, CentOS 7, and older Ubuntu LTS releases.

How does perfctl avoid detection when an administrator logs in?

Perfctl monitors for active user sessions and immediately pauses its cryptocurrency mining activity whenever an administrator logs in. CPU usage drops to normal levels, so tools like top or htop show nothing suspicious. Mining resumes within seconds of the session ending. It also hides its network traffic using Unix sockets for local communication and the Tor network for external C2 communications.

What is KadNap and why is it hard to detect?

KadNap is a 2025 Linux malware family targeting edge networking devices, particularly Asus routers, documented by Lumen's Black Lotus Labs. It uses a custom implementation of the Kademlia Distributed Hash Table (DHT) protocol -- the same peer-to-peer technology underlying BitTorrent -- to conceal the IP address of its command-and-control infrastructure within a decentralized peer-to-peer network. Traditional network monitoring tools do not flag DHT traffic as suspicious because it blends with legitimate P2P traffic. However, Black Lotus Labs found a significant implementation weakness: KadNap's DHT is not truly decentralized. Every infected device consistently routes through the same two final hop nodes before reaching the C2 servers, which allowed researchers to track the infrastructure despite the apparent P2P obfuscation. By early 2026 the botnet had infected over 14,000 devices, with more than 60% of victims in the United States.

What is SSHStalker's "dormant persistence" behavior and why does it matter?

SSHStalker, documented by Flare in February 2026, established footholds on approximately 7,000 Linux systems -- predominantly cloud-hosted servers -- and then sat idle. At the time of analysis, the botnet was maintaining persistent access across thousands of machines without executing DDoS attacks, deploying cryptominers, or exfiltrating data. Flare called this "dormant persistence." The IRC C2 channels showed only bots connecting and disconnecting, with no observable operator commands being issued. This behavior is particularly dangerous from a detection standpoint because it generates no anomalous CPU load, no unusual outbound data volume, and no impact-phase indicators. The botnet maintained a toolkit that could do all of these things -- including an AWS credential harvester -- it simply had not been activated yet. Defenders cannot rely on impact-phase detection against this threat class; the access has to be caught during the initial compromise phase or through behavioral indicators like IRC-style outbound connections and cron jobs running every 60 seconds.

Do my containers protect me from these threats?

Partially, and only for specific families. PUMAKIT requires loading a kernel module, which standard container security policies block. But this protection holds only if the host has Secure Boot enforced and module signing enabled -- if the host does not, containers offer no protection against PUMAKIT. Perfctl explicitly targeted Kubernetes API servers as an entry vector and operates entirely in userland, meaning it can run inside a container. SSHStalker and Goldoon target the host layer, not containers: a compromised host means all containers on that host should be treated as compromised because the attacker controls the shared kernel. The practical guidance is that container runtime security (Falco, Tetragon) must be combined with host-level hardening -- neither alone is sufficient.

Which of these is the hardest to fully remove?

PUMAKIT. An active LKM rootkit has subverted the system calls used by every tool you would reach for during cleanup -- ls, find, ps, and lsmod all lie when a kernel-level rootkit is present. There is no reliable in-place removal path. The correct remediation is isolation, volatile memory capture, disk imaging, and full OS rebuild from a clean baseline. Perfctl is a close second for complexity, because its layered persistence across multiple locations, LD_PRELOAD hooks, systemd units, and crontab entries means that missing even one removal step typically results in reinfection within minutes. Network device infections (KadNap, Goldoon) are straightforward to remediate -- factory reset -- but the open question is whether the device had a firmware update path to begin with. Many end-of-life devices have no update available, making permanent compromise the practical outcome.

What initial access vectors appear most frequently across these families?

Three patterns dominate. The first is exploitation of misconfigured or vulnerable public-facing services (T1190): perfctl via Polkit and exposed Redis/Kubernetes endpoints, NerbianRAT and KrustyLoader via Ivanti and Apache ActiveMQ one-day CVEs, Goldoon via a nine-year-old D-Link HNAP flaw. The second is SSH brute force against password-authenticated accounts (T1110.003): SSHStalker's entire compromise methodology. The third is firmware vulnerability exploitation on embedded Linux devices (T1195): KadNap and GTPdoor both target specific device classes. The defensive implication is that patching public-facing services promptly and disabling password-based SSH access would have prevented the majority of infections documented in this article.

Is standard Linux AV sufficient to detect these threats?

No -- and this deserves a direct answer rather than a diplomatic one. Signature-based AV running in userland cannot detect an active LD_PRELOAD rootkit because the rootkit intercepts the same system calls the scanner uses to enumerate files and processes. PUMAKIT's LKM rootkit operates below the userland layer entirely. Perfctl's session-aware CPU throttling defeats heuristic detection based on resource anomalies. The families that signature-based AV can reliably detect are the ones with known and stable binary signatures -- Goldoon and SSHStalker, whose toolkits are relatively well-documented. For the more evasive threats, the required tooling is eBPF-based runtime security (Falco, Tetragon) combined with kernel integrity monitoring and network behavioral analysis, not traditional AV.

The Bigger Picture

The maturation of Linux malware reflects a rational response by attackers to where the valuable infrastructure now lives. Cloud compute, containerized workloads, telecommunications backbone systems, and network appliances all run Linux. The enterprise security industry's historical focus on Windows endpoints left a gap, and that gap has been systematically exploited.

None of the families covered here are exotic proof-of-concept research. PUMAKIT uses kernel hooking techniques that have been understood for years. Perfctl exploits LD_PRELOAD, a decades-old Linux mechanism. GTPdoor abuses a legitimate network protocol. KadNap repurposes BitTorrent's DHT as a C2 layer. SSHStalker brute-forces SSH passwords -- the same way attackers have operated since the early 2000s. The sophistication is not always in novel techniques -- it is in operational discipline, careful evasion, and the targeting of specific blind spots in enterprise Linux security programs.

The defensive response has to match that operational reality. Kernel-level visibility through eBPF instrumentation, fast patch cycles for critical CVEs, behavioral monitoring rather than signature matching, Secure Boot enforcement, key-based SSH authentication, and genuine inclusion of network appliances in vulnerability management programs -- these are the structural requirements. The threat landscape is not going away, and it is not getting less sophisticated.

Where to Start: A Prioritized Action List

If you are reading this and wondering where to spend the next sprint, the evidence above points to a clear priority ordering.

This week: Disable password-based SSH authentication on every internet-facing Linux system in your environment. SSHStalker's 7,000-host botnet was built entirely through this vector. Key-based authentication is not exotic hardening -- it is the baseline. Then check cat /etc/ld.so.preload on your most sensitive servers. Any entry you did not put there is an active compromise indicator.

This month: Enable Secure Boot with kernel module signing on your Linux server fleet, starting with internet-facing systems. This is a verified mitigation against PUMAKIT -- the rootkit explicitly checks for Secure Boot and aborts if it is enabled. Audit firmware update status for every network appliance in your environment. Any device running firmware older than 12 months that has a published CVE against it should be treated as potentially compromised, not just unpatched.

This quarter: Deploy Falco or an equivalent eBPF-based runtime security tool with rules covering the behavioral patterns documented in this article: /memfd: process execution, LD_PRELOAD modifications, compiler execution on production hosts, and outbound connections to IRC ports. Establish a kernel module baseline so you have a known-good reference point for lsmod comparison. Review your patch SLAs -- any policy that allows more than 72 hours for CVSS 9.0+ CVEs affecting internet-facing systems is structurally misaligned with the exploitation tempo documented here.