Stealthy Linux rootkit found in the wild after going undetected for 2 years

Outbound traffic and egress control

• Several comments focus on the malware’s hidden outbound ports and note most environments heavily restrict inbound traffic but allow almost all outbound.
• Suggested mitigations:
  • Log and baseline common outbound ports, then block the rest and see what breaks.
  • Reduce “background noise” (e.g., constant DNS pings, external NTP) and move services internal.
  • Apply time-of-day firewall rules so nothing talks to the internet overnight, but with emergency overrides.
• Some argue many incidents (e.g., Log4Shell exploitation) would have been far less damaging with stricter egress policies.

Command-and-control (C2) channels

• Multiple comments say real-world malware often hides C2 over HTTPS on port 443 and through large providers (Cloudflare, big clouds, Google services).
• Proposals like “only allow HTTPS to FAANG or Cloudflare” are criticized as ineffective because attackers can front C2 through those very providers.
• There are reports and examples of Cloudflare Workers and similar infra used for C2 and DDoS, with claims takedowns are slow; others push back asking for concrete evidence, which is partially provided via linked reports.
• Domain fronting, use of Google Drive/Docs/Apps Script, and “weird protocols” (e.g., SCTP) are cited as C2 evasion techniques.

Infection vectors and targeting

• The article’s researchers reportedly don’t know the initial infection path; possible vectors listed include vulnerability exploitation, credential theft/guessing, and trojanized installers/updates.
• Other likely avenues: weak/unauthenticated SSH on IoT Linux devices and bugs in web apps/frameworks.
• Some suggest this RAT is a later-stage persistence mechanism after earlier compromise, making original entry hard to reconstruct years later.
• Targeting telecoms and using novel protocols leads some to speculate about state actors; others note it could also be “low-hanging fruit” or commercial crime.

Rootkits and persistence techniques

• Commenters note Linux rootkit patterns haven’t changed much since the late 1990s: binary replacement, kernel syscall hooking, and userland hooking (e.g., LD_PRELOAD).
• Maintaining kernel rootkits across many kernel versions is described as painful; some operators instead favor simpler userland backdoors.
• Tricks mentioned include renaming processes via prctl to look like kernel threads and creating hard-to-spot filesystem artifacts (e.g., ... directories).
• Secure Boot, unless very tightly configured, is seen as insufficient once attackers already have ring-0 execution.

Linux desktop security posture

• There is debate whether desktop Linux is “easier” for nation-state actors because many users lack AV/EPP and install software via curl | sudo bash or language-specific package managers.
• Several argue AV is largely ineffective against unknown rootkits/APTs and mainly matches known patterns; attackers can trivially recompile to evade signatures.
• Others counter that modern Endpoint Protection uses heuristics/ML and behavioral indicators, blocking many commodity payloads and raising the bar, especially on Windows.
• Multiple comments highlight structural weaknesses of typical Linux desktops:
  • X11 allows global keylogging.
  • Any app running as the user typically has full access to the home directory.
  • No mainstream, user-friendly per-app file permission model like modern macOS/Windows.
• Once malware can write to a user’s home directory, it can alter shell startup files, wrap sudo, steal SSH keys, or hijack configs, often making root escalation only a matter of time or unnecessary for data theft.

Antivirus / EPP on Linux

• There is disagreement over whether running AV/EPP on Linux desktops is worthwhile.
  • Critics: AV must run with very high privileges, increasing attack surface, and offers little defense against capable adversaries.
  • Supporters: security is layered; even if imperfect, EPP can catch many known payloads and common toolkits (Metasploit, re-encoded binaries) and is relatively low-friction on desktops.
• Ubuntu’s support for ClamAV is mentioned; however, it’s characterized as mostly signature-based and focused on known malware (often Windows), with limited value against fresh Linux threats.

Package management and supply-chain risk

• Several comments contrast distro package managers (with GPG-signed repositories) to ecosystem tools like pip/npm/cpan, which often rely only on TLS and have weaker provenance.
• Compromising distro repos is seen as harder and more visible (many keys, GPG validation, potential use of Certificate Transparency), whereas language-level packages can be more easily hijacked or replaced.
• The risk of malicious updates or abandoned packages (e.g., “left-pad” style incidents) is raised; lockfiles help but also delay security patches.
• For high-end adversaries, interception via rogue TLS certs is mentioned as a concern, but GPG signing and CT logs complicate such attacks.

Detection tools and alternative architectures

• Traditional tools like chkrootkit are considered of limited modern use; sophisticated malware can evade simple signature-based scanners.
• Some look toward architectural solutions:
  • Qubes OS (strong VM isolation per task/app), though adoption and codebase size are concerns.
  • ChromeOS for its locked-down model, albeit tightly coupled to Google.
  • “Minimax” Debian with most user apps running inside dedicated VMs.