Linux Trojans: How Attackers Compromise the OS the World Trusts

When administrators think about malware, Windows is usually the first platform that comes to mind. That instinct is becoming increasingly dangerous. Linux runs an estimated 96.3 percent of the world's top one million web servers, according to W3Techs data updated in early 2026. It powers nearly every public cloud hypervisor. It runs the routers, the IoT devices, the CI/CD pipelines, and the containers that deliver modern software. Attackers know this, and the Linux threat landscape has evolved accordingly.

A Linux trojan is malicious software that masquerades as something legitimate -- a system utility, a package update, a shared library, or a background service. Unlike a virus, it does not replicate by infecting other files. Unlike a worm, it does not self-propagate across networks autonomously. The trojan's power lies in deception: it gets installed because someone or something trusted it, and then it operates from inside that trust boundary.

Why Linux Is Not the Safe Haven It Used to Be

The old assumption that Linux was inherently secure because of its smaller user base no longer holds. Linux malware submissions to threat intelligence platforms have been rising sharply. In its 2024 annual threat report, CrowdStrike noted a significant increase in Linux-targeted intrusions linked to both financially motivated actors and nation-state groups. Trend Micro's research documented that Linux environments now regularly face sophisticated, multi-stage malware campaigns that rival those targeting Windows in technical complexity.

Adam Meyers, SVP of Counter Adversary Operations at CrowdStrike, stated in the 2024 Global Threat Report that the prevailing assumption of Linux as the safer platform is a misconception -- and that adversaries have fully operationalized Linux exploitation, with the telemetry to prove it.

Several factors have converged to make Linux a more attractive target. First, the attack surface has expanded dramatically: containerized workloads, Kubernetes clusters, and serverless functions all run on Linux, and they often have weaker endpoint detection than traditional servers. Second, Linux systems tend to stay running for long periods without reboots, giving persistent malware a stable environment. Third, root access on a Linux server often means access to everything -- databases, secrets, source code, and lateral movement paths through the network.

A Practical Taxonomy of Linux Trojans

Linux trojans are not a monolithic category. Understanding what each variant does -- and how it hides -- is the foundation of effective defense. These are the primary families you will encounter in the wild.

Backdoor Trojans

The backdoor is the most common objective. After initial compromise, the attacker drops a trojan that opens a persistent communication channel back to infrastructure they control. This may be a reverse shell, an SSH key implanted in ~/.ssh/authorized_keys, a modified sshd binary that accepts a hardcoded master password, or a lightweight agent that beacons out over HTTPS to blend with normal traffic.

Symbiote, documented jointly by Intezer and BlackBerry Research in June 2022 and first observed targeting Latin American financial sector organizations beginning in November 2021, is an example of a particularly stealthy backdoor. Rather than running as a standalone process, Symbiote injects itself into running processes using LD_PRELOAD, a legitimate Linux dynamic linker feature. It hooks the libc and libpcap functions that network tools and process listing utilities call, hiding its own network connections and its own presence from tools like ps, netstat, and ss. It also uses BPF hooking to filter its traffic out of packet captures, making it invisible even to network analysis tools. It captures credentials from SSH, SCP, and cURL processes that happen to run on the infected machine and exfiltrates them via DNS requests to attacker-controlled domains. The domain names observed in Symbiote's infrastructure were crafted to impersonate major Brazilian banks. According to the joint Intezer and BlackBerry analysis, the malware is designed so that performing live forensics on an infected machine may turn up nothing at all -- all file, process, and network artifacts are hidden by the time the investigation begins.

Joakim Kennedy (Intezer) and the BlackBerry Research & Intelligence Team described Symbiote in their June 2022 analysis as unlike any prior Linux malware they had encountered, noting that all its capabilities rely on hooking libc function calls rather than running as a visible standalone process.

Rootkit-Bearing Trojans

Some trojans carry a rootkit payload -- kernel-level code designed to hide the trojan's presence from the operating system itself. User-space rootkits manipulate shared libraries or executables. Kernel-mode rootkits load as Linux Kernel Modules (LKMs), operating at the same privilege level as the kernel and able to intercept any system call.

Diamorphine is an open-source LKM rootkit that has been packaged into several commercial-grade trojan campaigns. It hooks the getdents and getdents64 system calls to hide files and directories, hooks kill to intercept signal-based commands from the operator, and hides processes by manipulating the /proc filesystem. Diamorphine demonstrates a recurring pattern: tools originally released for educational security research get repurposed into operational malware with minimal modification.

Cryptomining Trojans

Cryptomining malware is the most financially motivated and most volumetrically common Linux trojan category. These trojans deploy XMRig or similar Monero miners, consuming CPU and memory resources of compromised cloud instances. The economics are straightforward: compromising thousands of misconfigured cloud VMs and mining Monero at their expense costs the attacker nothing and generates steady revenue.

TeamTNT was a prominent group that targeted Docker APIs, Kubernetes clusters, and exposed Redis instances to deploy miners on cloud infrastructure. AT&T Alien Labs and Trend Micro tracked the group through multiple campaign iterations from 2020 through 2023. TeamTNT's tooling was notable for stealing AWS credentials from instance metadata endpoints and ~/.aws/credentials files -- a detail that illustrates how cryptomining trojans increasingly serve as multi-purpose initial access tools rather than pure miners.

DDoS Bot Trojans

Linux servers and routers, once compromised, become powerful DDoS bots. The Mirai botnet, first observed attacking Krebs on Security and Dyn DNS infrastructure in 2016, demonstrated the scale achievable by compromising embedded Linux devices. Mirai's source code was published shortly after its discovery, and derivatives -- Moobot, Satori, Bashlite, and dozens of others -- have been observed actively recruiting new devices through 2025 and into early 2026. Cloudflare's documentation on Mirai describes the botnet's infection cycle: it scans for devices with default Telnet credentials, installs the bot, then uses the infected device for volumetric UDP and TCP flood attacks.

Remote Access Trojans (RATs)

A Linux RAT gives an attacker a persistent, interactive foothold with capabilities that go beyond a simple backdoor. Modern Linux RATs support file exfiltration, screenshot capture on systems with display servers, keylogging, lateral movement via SSH key harvesting, and proxy functionality that routes attacker traffic through the compromised host. Pupy RAT, an open-source tool with a long history in both red team tooling and nation-state operations, has a fully functional Linux agent and has been attributed to multiple APT groups including APT33 (Elfin) and APT34 (OilRig) in campaigns documented by Palo Alto Unit 42.

How Linux Trojans Get In

Understanding infection vectors is as important as understanding the malware itself. A trojan that cannot achieve initial access cannot execute its payload.

Compromised Supply Chain and Package Repositories

Supply chain attacks against Linux package ecosystems have become a significant concern. In March 2024, a backdoor was discovered in XZ Utils (versions 5.6.0 and 5.6.1), a widely used data compression library present in many Linux distributions. The attacker, operating under the pseudonym "Jia Tan," spent roughly two years building trust as a contributor before inserting malicious code into the liblzma build process. The backdoor targeted OpenSSH on systemd-integrated systems, specifically designed to allow unauthenticated remote code execution. Microsoft engineer and PostgreSQL developer Andres Freund discovered the backdoor almost by accident: he noticed that SSH logins on a Debian testing system were taking around 500ms rather than the normal 100ms, investigated the cause, and traced the slowdown to malicious code embedded in the XZ Utils release tarballs. He reported his findings to the oss-security mailing list on March 29, 2024.

Exposed Services and Default Credentials

Shodan and Censys continuously index millions of Linux services exposed to the public internet. Attackers use the same data. SSH on port 22 with password authentication enabled, Docker daemon APIs accessible without TLS on port 2375, Redis instances without authentication, and Jupyter notebook servers exposed without tokens are all common entry points. Scanning for these takes seconds; exploitation of default or weak credentials takes only slightly longer.

That single command, run on your own infrastructure, may produce results you do not expect. Root login over SSH is disabled by default in modern distributions, but legacy configurations, automated provisioning scripts, and image templates frequently re-enable it.

Malicious or Typosquatted Packages

The npm, PyPI, RubyGems, and other package ecosystems used heavily on Linux development systems have experienced repeated typosquatting attacks. Packages named to resemble popular libraries -- colourama for colorama, python-dateutil versus dateutils -- contain trojanized code that executes on installation. The Snyk security team has documented thousands of such packages. Because package installation often runs with elevated privileges in CI/CD environments, a single malicious dependency in a build pipeline can compromise the entire build system and potentially inject backdoors into software artifacts.

Web Application Exploitation

Many Linux servers run web applications -- WordPress, Drupal, custom Python and Node.js apps -- that contain vulnerabilities. Remote code execution in a web application gives an attacker a shell as the web server user. From there, privilege escalation using a local kernel exploit, a misconfigured SUID binary, or a sudo misconfiguration often leads to root. Once root is achieved, installing a trojan is trivial.

Persistence: How Trojans Stay Installed

Gaining access is only the first step. The trojan needs to survive reboots, admin investigations, and partial cleanup attempts. Linux offers attackers a rich set of persistence mechanisms.

Systemd Service Units

A systemd service is an ideal persistence vehicle. A trojan that installs itself as a service unit in /etc/systemd/system/ will start automatically on boot, restart if killed, and appear in systemctl list-units -- where it may blend in among dozens of legitimate services if given a plausible name like systemd-network-helper.service or polkitd-extended.service.

[Unit]
Description=Network Diagnostic Helper
After=network.target

[Service]
Type=simple
ExecStart=/usr/lib/systemd/systemd-nethelper
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

The binary at the ExecStart path looks like a legitimate systemd component. The name is designed to be skipped over during a cursory audit. The Restart=always directive means killing the process just causes it to restart after 30 seconds.

Cron Jobs and At Schedules

Cron is a time-honored persistence mechanism. Attackers add entries to /etc/cron.d/, /var/spool/cron/crontabs/, or /etc/crontab that re-download and execute the trojan payload at regular intervals. This provides resilience: even if the running process is killed and the binary deleted, the next cron execution re-fetches and re-installs it. Checking all cron locations -- including per-user crontabs for every account on the system -- is essential during an incident response.

LD_PRELOAD and Shared Library Hijacking

The LD_PRELOAD environment variable, and its system-wide counterpart /etc/ld.so.preload, instruct the dynamic linker to load a specified shared library before all others. Malware that adds itself to /etc/ld.so.preload will be loaded into every dynamically linked process on the system. This is how Symbiote achieves its pervasive hooking capability. Inspecting /etc/ld.so.preload for unexpected entries should be a standard part of any Linux security audit.

On a clean system this file is typically empty or absent. Any content warrants immediate investigation.

SSH Authorized Keys and Host Keys

Implanting an SSH public key in ~/.ssh/authorized_keys for root or a privileged account gives the attacker persistent, credential-independent access that survives password changes. More sophisticated attacks replace or supplement /etc/ssh/ssh_host_*_key files, giving the attacker the ability to decrypt previously captured SSH sessions. Monitoring authorized_keys files for unauthorized additions is a basic but often overlooked control.

Kernel Module Persistence

An LKM rootkit that adds itself to /etc/modules or drops a .conf file in /etc/modules-load.d/ will be loaded by the kernel on every boot. At that point the rootkit is operating at ring 0 -- it has higher privilege than any user-space detection tool. The only reliable way to detect an active kernel-mode rootkit is to compare the running system's kernel memory against known-good state, or to boot from trusted external media and examine the filesystem offline.

Notable Linux Trojans in the Wild

Several specific trojans merit attention both for their technical sophistication and for what they reveal about attacker methodology.

BPFDoor

BPFDoor is one of the most technically sophisticated Linux backdoors ever analyzed. PwC Threat Intelligence first identified it in 2021 while tracking the Chinese state-sponsored group they designated Red Menshen -- also tracked as Earth Bluecrow by Trend Micro and as DecisiveArchitect and Red Dev 18 by other researchers. PwC published their public analysis in May 2022. It uses the BPF subsystem -- a legitimate kernel feature for high-performance packet processing -- to monitor raw network traffic for a magic packet that activates the backdoor. This allows BPFDoor to receive commands without ever opening a listening port. Standard port scans and network connection audits will not detect it. PwC's analysis noted that BPFDoor had been present in some environments for years before discovery -- in some cases for up to five years.

Earth Bluecrow remains actively operational. Trend Micro's April 2025 report documented ongoing BPFDoor campaigns targeting telecommunications, finance, and retail sectors across South Korea, Hong Kong, Myanmar, Malaysia, and Egypt throughout 2024 -- and added a significant discovery: a previously unseen controller component that allows Earth Bluecrow operators to open encrypted reverse shell sessions, redirect traffic, and perform lateral movement across compromised networks. The controller prompts the operator for a password before sending a magic packet to the infected host; BPFDoor then calculates an MD5 hash of the password against hardcoded values to authenticate before complying. Trend Micro attributes the controller and associated campaign to Earth Bluecrow with medium confidence, noting that since BPFDoor's source code leaked in 2022, no other threat groups have been conclusively linked to using it. A December 2025 Ericsson technical analysis documented a BPFDoor intrusion at a Southeast Asian mobile operator where multiple BPFDoor variants were used to establish backdoors inside the carrier's 4G core network -- including the Home Subscriber Server (HSS) -- exposing millions of subscribers' USIM data and remaining undetected for an extended period.

PwC Threat Intelligence, in their May 2022 BPFDoor analysis, noted that the backdoor opens no ports, uses no reverse shell, and can disguise itself as any Linux process -- making it effectively undetectable by conventional network monitoring tools.

OrBit

OrBit, documented by Intezer in July 2022, represents a further evolution of the LD_PRELOAD hooking technique. It intercepts and hijacks functions from three major shared libraries -- libc, libpthread, and libcap -- allowing it to evade detection by tools that rely on those libraries for process enumeration, network connection reporting, and privilege inspection. OrBit persists either via /etc/ld.so.preload or by patching the ELF interpreter directly in targeted binaries, a technique that survives even if /etc/ld.so.preload is cleaned.

XorDDoS

XorDDoS is a trojan with a long operational history, first documented in 2014 by the white-hat research group MalwareMustDie and still actively deployed. It targets Linux x86, x64, and ARM systems -- including Raspberry Pi devices and similar ARM-based servers -- and assembles them into a DDoS botnet. Its name comes from its use of XOR encryption for C2 communications (the XOR key BB2FA36AAA9541F0 is embedded in its binary), and it employs a rootkit component to hide its files and processes. In May 2022, Microsoft's 365 Defender Research Team published an analysis documenting a 254 percent increase in XorDDoS activity over the preceding six months, with the United States as the primary target. Microsoft also found that devices first infected with XorDDoS were subsequently infected with the Tsunami backdoor, which in turn deployed the XMRig Monero miner -- illustrating XorDDoS's role as an initial access broker for further payloads.

XorDDoS has not slowed down. Cisco Talos research published in April 2025 documented that 71.3 percent of XorDDoS infection attempts between November 2023 and February 2025 targeted the United States, making it the single most targeted nation. Talos also identified in 2024 a new "VIP" version of the XorDDoS sub-controller and a corresponding central controller with a builder, indicating the malware is being sold as a product to multiple operators. Critically, XorDDoS has expanded beyond traditional Linux server environments to actively target Docker containers and IoT devices. The language settings of the controller tools strongly suggest Chinese-speaking operators. Recent variants persist via init.d, cron, and systemd.

Syslogk

Syslogk, analyzed by Avast in June 2022, uses a kernel rootkit approach to hide an embedded backdoor called Rekoobe. It patches the kernel's module list to hide itself from lsmod, hides its associated files from the filesystem, and wakes up Rekoobe only when it receives a specially crafted TCP packet -- similar in concept to BPFDoor's magic packet activation. Syslogk demonstrates the pattern of combining a kernel rootkit for stealth with a backdoor for functionality, each component protecting the other.

Detection: Finding What Is Hiding

Detecting Linux trojans requires layering multiple approaches, because no single tool is sufficient against a well-implemented rootkit.

File Integrity Monitoring

Tools like AIDE (Advanced Intrusion Detection Environment) and Tripwire maintain cryptographic hashes of critical system files. Any modification to files in /bin/, /sbin/, /usr/bin/, /lib/, or /etc/ triggers an alert. The critical caveat is that the baseline must be established on a known-clean system, and the AIDE database must be stored somewhere the attacker cannot modify it -- typically read-only external storage or a remote integrity monitoring service.

# Check for recently modified files in system directories
# find /bin /sbin /usr/bin /usr/sbin /lib /lib64 -newer /etc/passwd -type f 2>/dev/null

# Check for SUID/SGID binaries -- compare to known baseline
# find / -perm /6000 -type f 2>/dev/null | sort

# Verify RPM package integrity (RHEL/CentOS/Fedora)
# rpm -Va 2>/dev/null | grep "^..5"

# Verify dpkg package integrity (Debian/Ubuntu)
# dpkg --verify 2>/dev/null | grep "!!"

Network Traffic Analysis

Many trojans require outbound network communication -- for C2 beaconing, data exfiltration, or receiving commands. Establishing a baseline of normal outbound connections and alerting on deviations is a high-value detection strategy. Tools like Zeek (formerly Bro) provide deep network protocol analysis. Unexplained DNS queries to recently registered domains, TLS connections to IP addresses that do not correspond to known business services, and high-volume ICMP or UDP traffic to single destinations are all worth investigating.

Process and Memory Inspection

User-space rootkits hook the system calls that ps uses, but they cannot hide from direct inspection of /proc if done carefully, and they cannot hide from kernel-level tools that bypass the hooked library functions.

# Compare processes visible to ps against /proc entries
# Discrepancy indicates userspace hooking
# ls /proc | grep -E '^[0-9]+$' | sort -n > /tmp/proc_pids.txt
# ps -eo pid --no-headers | sort -n > /tmp/ps_pids.txt
# diff /tmp/proc_pids.txt /tmp/ps_pids.txt

# Check for deleted binaries with active file descriptors
# A running trojan that deleted its own binary shows up here
# ls -la /proc/*/exe 2>/dev/null | grep deleted

# Check loaded kernel modules against expected list
# lsmod | awk '{print $1}' | sort > /tmp/current_modules.txt

Endpoint Detection and Response (EDR)

Modern EDR solutions with Linux support -- including CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint -- use kernel-level sensors that hook system calls at a level below where user-space rootkits operate. They record process creation, network connections, file operations, and memory allocation events into a telemetry stream that is difficult for user-space malware to tamper with. For high-value Linux systems, deploying an EDR sensor is the single highest-impact defensive investment available.

Defense: Reducing Attack Surface

Detection matters, but prevention is cheaper. Several controls meaningfully reduce the probability of a successful Linux trojan deployment.

Disable unnecessary services. Every service that is not needed is a potential entry point. Use systemctl disable --now on anything not required for the system's function. On a web server, the Bluetooth service, the printer spooler, and the NFS client have no business running.

Enforce SSH key authentication. Password authentication over SSH is brute-forceable at scale. Disable it in /etc/ssh/sshd_config with PasswordAuthentication no and PermitRootLogin no. Use short-lived certificates where possible, managed through a tool like HashiCorp Vault's SSH secrets engine or Teleport, rather than long-lived authorized keys files.

Apply kernel hardening. Enable CONFIG_MODULE_SIG_FORCE to require that all kernel modules be signed with a trusted key, preventing unsigned rootkit modules from loading. Set kernel.modules_disabled=1 in /etc/sysctl.d/ after boot to prevent any further module loading. Enable CONFIG_LOCKDOWN_LSM (available since kernel 5.4) for additional restrictions on kernel modification.

Use immutable infrastructure. Container-based deployments that replace instances rather than patching them in place dramatically limit the persistence horizon for any malware. A trojan that installs itself on a container that is replaced every 24 hours has a very short operational window.

Monitor /etc/ld.so.preload and LD_PRELOAD. Use auditd to log any writes to /etc/ld.so.preload and any process launch that includes LD_PRELOAD in its environment. These are not common events in normal operations.

# Alert on writes to ld.so.preload
-w /etc/ld.so.preload -p wa -k ld_preload_modification

# Alert on new files in systemd system unit directory
-w /etc/systemd/system/ -p wa -k systemd_unit_modification

# Alert on changes to cron directories
-w /etc/cron.d/ -p wa -k cron_modification
-w /var/spool/cron/ -p wa -k cron_modification

# Alert on changes to SSH authorized_keys for root
-w /root/.ssh/authorized_keys -p wa -k ssh_key_modification

# Alert on insmod / modprobe execution
-a always,exit -F arch=b64 -S init_module,finit_module -k lkm_load

Incident Response on a Compromised Linux System

If you suspect a Linux trojan is present, the response approach depends on whether preserving forensic evidence is a priority and whether the system can be taken offline.

The first decision is whether to contain and analyze, or to contain and rebuild. For systems with a kernel-level rootkit, the analysis must be done offline -- the running OS cannot be trusted. Shut down the system, take a disk image using trusted hardware, and analyze the image in a clean environment. For suspected user-space trojans without kernel modification, live analysis of the running system is feasible but should use statically compiled binaries brought from a known-clean source to avoid using any hooked library functions.

Collect volatile evidence first -- network connections, running processes, loaded modules, open file descriptors -- before shutting the system down, as this information is lost at power-off. Tools like LiME (Linux Memory Extractor) can capture a full memory dump as a kernel module from trusted external media, preserving process memory, kernel structures, and potentially the trojan binary itself.

Richard Bejtlich, in The Practice of Network Security Monitoring (No Starch Press), makes clear that when a Linux rootkit is suspected, imaging the disk from outside the running OS is the only forensic action that can be trusted -- everything else risks being compromised by the very system under investigation.

After analysis and recovery, the root cause of the initial compromise must be identified and addressed before bringing a rebuilt system back online. Rebuilding without closing the initial access vector simply invites re-compromise.

The Takeaway

Linux trojans are not a theoretical concern or a secondary consideration behind Windows threats. They target the infrastructure that runs the internet, and they do so with increasing sophistication -- exploiting legitimate kernel features, hijacking the dynamic linker, persisting through supply chain compromises, and evading standard detection tools by operating below the level at which those tools function.

The defenders who fare best are those who treat their Linux systems with the same rigor they apply to Windows: file integrity monitoring, endpoint detection, network traffic baselining, audit logging, and a clear incident response plan. The assumption that Linux is safe by default, or that attackers prefer other targets, is a position the threat landscape no longer supports.

Sources referenced in this article: CrowdStrike 2024 Global Threat Report (crowdstrike.com); Trend Micro Linux Threat Analysis H1 2023; Intezer and BlackBerry Research: Symbiote Deep-Dive, June 2022 (intezer.com); Intezer OrBit analysis, July 2022 (intezer.com); PwC BPFDoor Threat Intelligence analysis, May 2022 (pwc.com); Trend Micro BPFDoor Hidden Controller analysis, April 2025 (trendmicro.com); Ericsson BPFDoor telecom operator analysis, December 2025 (ericsson.com); Avast Syslogk analysis, June 2022 (avast.io); Microsoft XorDDoS activity report, May 2022 (microsoft.com); Cisco Talos XorDDoS controller and Docker expansion analysis, April 2025 (thehackernews.com/Talos); Andres Freund CVE-2024-3094 disclosure, oss-security mailing list, March 29, 2024 (openwall.com); NVD CVE-2024-3094 advisory (nvd.nist.gov); Red Hat and CISA CVE-2024-3094 XZ Utils advisories; Palo Alto Unit 42 Pupy RAT attribution reporting (unit42.paloaltonetworks.com); Cloudflare Mirai botnet documentation (cloudflare.com); W3Techs web server market share data, 2026 (w3techs.com); Snyk malicious npm package research (snyk.io); Richard Bejtlich, The Practice of Network Security Monitoring, No Starch Press.

How to Defend Against Linux Trojans

Step 1: Establish file integrity monitoring and audit logging

Deploy AIDE or a comparable file integrity monitoring tool with a baseline covering /usr/bin/, /usr/sbin/, /lib/, /etc/ld.so.preload, /etc/systemd/system/, and cron directories. Configure auditd with rules that alert on writes to ld.so.preload, new systemd unit files, cron modifications, SSH authorized_keys changes, and kernel module load syscalls.

Step 2: Detect active trojans using process and network inspection

Compare process IDs visible to ps against /proc entries to identify discrepancies caused by userspace hooking. Check for running processes whose binary has been deleted using ls -la /proc/*/exe | grep deleted. Baseline normal outbound network connections with a tool like Zeek and alert on unexplained DNS queries, TLS connections to unrecognized IPs, or regular small-packet beaconing to external hosts.

Step 3: Respond to a suspected Linux trojan compromise

Collect volatile evidence first — network connections, running processes, loaded kernel modules, and open file descriptors — before taking the system offline. For suspected kernel-level rootkits, shut down the system, take a forensic disk image from trusted external hardware, and analyze offline. For userspace trojans, live analysis using statically compiled binaries from a known-clean source is feasible. Identify and close the initial access vector before rebuilding to prevent re-compromise.

Frequently Asked Questions

What is a Linux trojan and how does it differ from a virus or worm?

A Linux trojan is malicious software that masquerades as something legitimate — a system utility, a package update, a shared library, or a background service. Unlike a virus, it does not replicate by infecting other files. Unlike a worm, it does not self-propagate across networks autonomously. The trojan's power lies in deception: it gets installed because someone or something trusted it, and then it operates from inside that trust boundary.

Why is BPFDoor so difficult to detect with a port scan?

BPFDoor does not open any listening port. It attaches a BPF socket directly to the network interface and inspects raw traffic, waiting for a magic packet that contains a specific value. Because no port is opened, a port scan will always come back clean — there is nothing for the scanner to find. Detection requires looking for raw socket file descriptors on running processes, anomalous BPF program attachments, and correlating with threat intelligence feeds.

How do you recover a Linux trojan binary that deleted itself from disk?

When a process deletes its own binary, the kernel keeps the file's inode and content alive in memory as long as the process has an open file descriptor to it. The binary is still accessible at /proc/[pid]/exe and can be copied to a safe location before the process is killed. The full process memory space is also available via /proc/[pid]/mem. This makes self-deleting trojans more recoverable than they appear — as long as the process is still running when discovered.