Commercial Surveillance Vendors on Linux: Exploit Chains, Kernel Escalation, and Browser Delivery

Commercial surveillance vendors (CSVs) are private companies that develop and sell spyware to government clients -- law enforcement agencies, intelligence services, and in many documented cases, authoritarian regimes. The best-known names are NSO Group (Pegasus) and Intellexa (Predator), but the ecosystem is considerably larger. What connects nearly all of them technically is that their exploit chains pass through the Linux kernel at some point: either directly on server and desktop targets, or through the Linux kernel that powers Android.

According to Google's Threat Intelligence Group 2025 annual report, Google tracked 90 zero-day vulnerabilities exploited in the wild across 2025. Of the 42 that were uniquely attributed to a specific threat actor, 18 were definitively or likely attributed to CSVs -- surpassing traditional state-sponsored espionage groups for the first time in the history of Google's tracking. GTIG senior analyst Casey Charrier described the new landscape as "largely defined by expanded access to zero-day capabilities." Understanding how these chains are constructed matters for anyone running Linux infrastructure. The kernel subsystems CSVs exploit are the same ones that commodity ransomware and opportunistic attackers weaponize once CVEs become public knowledge. The attack surface is shared, and the exploitation window is the same regardless of who originally discovered the bug.

What Commercial Surveillance Vendors Are

CSVs occupy a specific market niche: they are not hack-for-hire operations that perform intrusions on demand, and they are not initial access brokers that sell footholds into compromised networks. They build and sell complete surveillance products -- spyware implants combined with the zero-day exploit chains required to deploy them silently, the infrastructure to command and control infected devices, and the tooling to exfiltrate and process collected data. As Google GTIG CTI Analyst James Sadowski told Decipher, these vendors often offer turn-key solutions for the entire attack lifecycle -- not just the technical expertise to build exploit chains, but also the subsequent tools necessary to identify and exfiltrate data from the targeted victim.

The business model depends on a supply chain of vulnerabilities. CSVs either discover zero-days internally, purchase them from vulnerability brokers, or acquire them from third-party exploit developers. Intellexa, for example, has been documented by Google GTIG reusing an iOS exploit framework called JSKit that has appeared across multiple spyware vendors and even Russian state-sponsored campaigns -- suggesting a shared broker market rather than fully independent development for every component. As of December 2025 leaks analyzed by Google, Amnesty International, and Recorded Future, Intellexa had exploited 15 unique zero-days since 2021, accounting for more than 21 percent of all zero-days discovered by Google's security researchers in that period -- across Remote Code Execution, Sandbox Escape, and Local Privilege Escalation classes.

For a broader overview of what commercial surveillance vendors are and how they operate, that resource covers the business and legal landscape in detail. This article focuses on the technical architecture of their exploit chains as they relate to Linux.

Exploit Chain Anatomy

A CSV exploit chain designed to compromise a target device silently via browser requires at minimum three components: a renderer exploit to gain code execution within the browser process T1203, a sandbox escape to break out of the browser's process isolation T1068, and a kernel privilege escalation to elevate from the sandboxed renderer's unprivileged UID to root T1068. On some platforms a fourth component handles persistence T1055. Each stage is an independent vulnerability with its own CVE, and losing any one of them breaks the chain -- which is why CSVs invest heavily in maintaining multiple options at each stage simultaneously.

Chrome's V8 JavaScript engine is the most common entry point. V8's JIT compiler transforms JavaScript into native machine code at runtime. This optimization pipeline is large, complex, and has been a reliable attack surface for years. Type confusion bugs in V8 allow an attacker to craft JavaScript that tricks the engine into treating an object allocated as one type as if it were another, enabling heap corruption and ultimately arbitrary memory read and write within the renderer process.

Intellexa has maintained a reusable Chrome exploitation framework built specifically around vulnerabilities that allow leaking V8's internal TheHole magic object. When accessible, this object provides the primitives needed to construct reliable heap corruption. As documented in Google GTIG's December 2025 analysis, Intellexa applied this same framework across CVE-2021-38003, CVE-2023-2033, CVE-2023-3079, CVE-2023-4762, and -- in June 2025 -- CVE-2025-6554, a type confusion error in V8 observed in a campaign targeting Saudi Arabia, patched in Chrome 138.0.7204.96. The reuse of the same framework across years of distinct CVEs illustrates that a single exploit skeleton can be retargeted to new vulnerability classes as older bugs are patched, dramatically reducing the development cost of maintaining an active exploit capability.

CVE-2025-10585, a separate V8 type confusion bug, was reported by Google TAG on September 16, 2025, and according to HP Wolf Security's 2025 zero-day review, patched within 24 hours of discovery due to active exploitation. It was the sixth Chrome zero-day of 2025. CVE-2025-13223, patched in November 2025 as the seventh Chrome zero-day, was reported by Clément Lecigne of Google TAG. SecurityWeek noted that TAG's discovery implies a commercial spyware vendor likely targeted the bug, consistent with the pattern of CSV operations using TAG-discovered zero-days against journalists and political targets. For detailed analysis of the browser-side delivery mechanism, the article on browser exploits delivered via crafted HTML pages covers the technical mechanics of how V8 exploitation leads to renderer compromise.

What About Firefox and Other Browsers?

The documented CSV exploit chains targeting Linux have focused on Chrome and V8 because Chrome is the dominant browser and because V8's JIT complexity provides a reliable attack surface. That does not mean Firefox or other Chromium-based browsers are structurally safer -- it means they are less frequently documented as primary delivery targets in confirmed CSV campaigns, which is a different statement.

Firefox uses the SpiderMonkey JavaScript engine rather than V8, meaning V8-specific exploit frameworks like Intellexa's TheHole-based approach do not transfer directly. However, Firefox has its own history of exploited JIT vulnerabilities. The sandboxing architecture on Linux differs from Chrome: Firefox uses a multi-layered sandbox model that includes seccomp-bpf filtering but its implementation and the set of permitted syscalls differ. As of Firefox 128, the RLBox isolation framework -- originally developed at UC San Diego and Mozilla -- sandboxes several media libraries (Graphite, Hunspell, OGG) within the renderer itself using WebAssembly-compiled isolation boundaries. This reduces the attack surface for memory corruption bugs in bundled libraries but does not eliminate the renderer-to-kernel escalation path.

Chromium-based alternatives (Brave, Vivaldi, ungoogled-chromium) share Chrome's V8 engine and sandbox architecture. Their exposure to V8-targeting exploit frameworks is structurally equivalent to Chrome, but their patch cadence varies. Brave typically ships security updates within days of upstream Chrome releases. Ungoogled-chromium packaging is community-maintained and has no guaranteed security update timeline. The practical guidance is straightforward: for any Chromium-based browser, patch cadence matters more than brand. A browser running a V8 version that is two weeks behind Chrome's current release may be sitting on a patched zero-day that is actively being used in the wild.

Stage 2: Sandbox Escape

Chrome's renderer processes on Linux run in a sandbox constructed from two kernel mechanisms: seccomp-bpf, which filters the set of syscalls the renderer is allowed to make, and Linux namespaces, which isolate the renderer's view of the filesystem, network, and process tree. The sandbox is designed so that even if the renderer is fully compromised via a V8 bug, the attacker remains trapped in an unprivileged process that cannot reach the host system.

Escaping this sandbox requires a vulnerability in kernel code that is reachable from within the restricted syscall set the renderer is permitted. UNIX domain socket MSG_OOB handling has been one such path. A use-after-free or out-of-bounds condition triggered via MSG_OOB operations on UNIX domain sockets allows a process running inside the browser sandbox to corrupt kernel memory and chain into full kernel privilege escalation. CISA added a vulnerability in this class to the Known Exploited Vulnerabilities catalog in September 2025, with the Linux Journal noting its particular danger: it bridges from a low-privilege sandboxed process to kernel-level compromise, undermining the assumption that sandboxed code is safe.

Watering hole delivery via malicious advertisements is an increasingly documented delivery mechanism for Intellexa. Rather than sending a one-time exploit link via an encrypted messaging app, the operator places a malicious advertisement on a third-party platform. The ad performs device fingerprinting -- OS version, browser version, IP address -- and redirects only matching targets to the exploit delivery server. Linux desktops running a vulnerable Chrome version within a targeted IP range are a viable fingerprint target through this mechanism, with no prior knowledge of the specific individual required.

Stage 3: Kernel Privilege Escalation

Once outside the sandbox, the chain needs to escalate to root. This is where Linux kernel vulnerabilities are directly exploited. The canonical kernel exploit payload calls commit_creds(prepare_kernel_cred(0)), which overwrites the running process's credential structure with root credentials. Getting there requires corrupting kernel memory, which in turn requires a vulnerability in a kernel subsystem reachable from unprivileged userspace.

netfilter / nf_tables is the most heavily targeted subsystem. nf_tables replaced the older iptables backend and manages packet filtering, NAT, and connection tracking. Its internal API processes netlink messages from userspace, and its memory management has a long history of use-after-free and heap overflow bugs. CVE-2024-1086 -- a use-after-free in nf_tables nicknamed "Flipping Pages" by its discoverer, researcher Notselwyn -- had existed in the kernel since version 3.15, first patched in January 2024. CISA added it to the Known Exploited Vulnerabilities catalog on May 30, 2024. In October 2025, CISA issued a further notification confirming the flaw was actively being used in ransomware campaigns. Ransomware groups including RansomHub and Akira weaponized it for post-compromise privilege escalation throughout 2025. CVE-2021-22555, a separate netfilter heap corruption bug over a decade old, was added to CISA KEV in October 2025 -- more than four years after initial disclosure -- following confirmed weaponization.

vsock (Virtual Socket) provides communication between virtual machines and their host. CVE-2025-21756 ("Attack of the Vsock") was a use-after-free triggered by manipulating reference counters during vsock transport reassignment. An attacker inside a VM could corrupt kernel memory during the free and achieve root-level arbitrary code execution on the host. A working proof-of-concept was published alongside disclosure in April 2025. For any infrastructure where VM isolation is a trust boundary -- cloud multi-tenancy, container platforms, hosted virtualization -- this class of vulnerability is particularly severe.

OverlayFS is the filesystem layer used by container runtimes including Docker and Podman. CVE-2023-0386, an improper UID and capability preservation bug in OverlayFS, was added to CISA KEV in July 2025 following confirmed in-the-wild exploitation. Container escapes via OverlayFS T1611 are attractive because many production container deployments run with less hardening than bare-metal systems, and the attack surface is reachable from any code running inside a container. NIST SP 800-190 addresses container host OS hardening and kernel security requirements directly applicable to this attack surface. 800-190

POSIX CPU timers: CVE-2025-38352 is a race condition between handle_posix_cpu_timers() and posix_cpu_timer_del() during task exit. Google confirmed limited, targeted exploitation in its September 2025 Android Security Bulletin. An important scoping note for defenders: the vulnerability's exploitability depends on the kernel configuration flag CONFIG_POSIX_CPU_TIMERS_TASK_WORK being disabled -- a condition found on 32-bit Android kernels but not present by default on 64-bit x86 or ARM64 Linux. The kernel patch (commit f90fff1e152d) addresses it by preventing timer processing on zombie tasks. Android spyware operators chained it with CVE-2025-48543 -- a use-after-free in the Android Runtime (ART) component -- to escape application sandboxes and execute arbitrary code with elevated privileges.

USB driver code: CVE-2024-53104 (UVC uvcvideo out-of-bounds write) and CVE-2024-53197 (USB audio out-of-bounds kernel access) were both added to CISA KEV in early 2025. While physical USB access is required for direct exploitation, emulated USB devices in virtualized environments and the BadUSB attack surface on shared or compromised systems make these relevant beyond laboratory conditions.

Android and the Shared Kernel Surface

Android's kernel is a downstream fork of the mainline Linux kernel with additional Android-specific patches. This means mainline kernel vulnerabilities, once disclosed, need evaluation against Android's kernel trees, and Android kernel patches need backporting by device OEMs before reaching end users. The backport and OEM delivery chain introduces additional lag beyond the mainline patch window -- often months for non-flagship devices.

Predator's architecture, as documented by Cisco Talos, is built specifically around the need to subvert SELinux on Android. Predator's loader component, called Alien, is injected into the Android Zygote process -- the parent of all application processes -- because processes spawned from Zygote inherit its SELinux context. By loading into Zygote, Alien and the Predator modules it downloads run in a context that SELinux treats as legitimate system activity rather than as a restricted application. The kernel privilege escalation component, internally called kmem, handles the actual elevation to root, while tcore handles data exfiltration, camera access, and geolocation.

The SELinux bypass technique is not unique to Predator. Any spyware that needs to run with system-level capabilities on Android needs a path through SELinux, and injecting into a privileged Zygote-spawned process is one of the established approaches. From a Linux desktop perspective, the analogous concern is AppArmor or SELinux confinement for browser and system processes. A renderer that escapes its seccomp-bpf sandbox but is running under a restrictive AppArmor profile still faces mandatory access control restrictions on what kernel interfaces it can reach.

Persistence Mechanisms on Linux

Reaching root via kernel exploitation is only one phase of an operation. An implant that disappears on reboot has limited intelligence value. On Linux server and desktop targets, CSV-class implants have several persistence options, each with different detection signatures and different requirements for the attacker.

Shared library injection via LD_PRELOAD or ld.so.preload T1574.006 is one of the oldest persistence techniques on Linux and remains in use. By writing a path to a malicious shared object into /etc/ld.so.preload, an attacker causes the dynamic linker to load that library into every process started on the system. This gives broad code execution coverage but is detectable: the file is checked during standard integrity audits and its presence is unusual on production systems outside of specific profiling use cases. A more targeted variant uses LD_PRELOAD set in a user's environment files (.bashrc, .profile, systemd user environment) to affect only processes spawned in that session context.

Systemd unit files T1543.002 offer persistence that survives reboots cleanly and blends with legitimate service infrastructure. A malicious service unit placed in /etc/systemd/system/ or the user-level ~/.config/systemd/user/ will restart the implant on login or boot. The unit file name and description can be made to closely resemble legitimate services. Detection requires auditing the full set of enabled units against a known-good baseline rather than just checking for obvious anomalies.

Kernel module persistence T1547.006 is the most powerful and the most detectable technique. A malicious kernel module (rootkit) loaded into the running kernel operates with full kernel privilege, can hide processes and files from userspace inspection tools by hooking the relevant syscalls, and can intercept arbitrary kernel operations. The tradeoff for the attacker is that loading unsigned kernel modules requires either disabling Secure Boot, exploiting a signing key, or using a signed module vulnerability. On systems with UEFI Secure Boot enforcing kernel module signature verification, rootkit deployment requires either a bootloader or firmware-level compromise or a signed module bypass.

Cron and at jobs, SSH authorized_keys injection, and PAM module replacement represent simpler but forensically louder techniques. These are more commonly associated with commodity attackers and post-breach lateral movement than with the precision implants CSVs deploy, but they may appear as secondary persistence mechanisms after initial implant placement.

Delivery Mechanisms on Linux

The primary delivery mechanism for CSV spyware targeting individuals has historically been a one-time URL sent via an encrypted messaging application. The link points to an exploit delivery server that fingerprints the connecting client and serves the appropriate exploit chain for the detected browser and OS version if the target matches. The link is typically deleted from the message thread after delivery. Paragon's Graphite spyware, which WhatsApp accused of targeting nearly 90 journalists and civil society members on January 31, 2025, used WhatsApp's handling of PDF group chat messages as the trigger: adding a target's phone number to a WhatsApp group and sending a malicious PDF caused the application to process the file, triggering a zero-click exploit chain with no user interaction. Citizen Lab confirmed in June 2025 that two separate journalists had their iPhones compromised via a zero-click iMessage attack using the same Paragon infrastructure, patched in iOS 18.3.1 as CVE-2025-43200.

Intellexa has expanded beyond link-based delivery to what internal leaked documents (analyzed by Google, Amnesty International, and Recorded Future in December 2025) describe as the "Aladdin" vector: a remote zero-click infection system that weaponizes the digital advertising ecosystem. Rather than sending a one-time exploit link via an encrypted messaging app, the operator purchases ad placements on third-party platforms through front companies -- Pulse Advertise and MorningStar TEC were identified by Recorded Future -- and uses demand-side platform (DSP) ad requests to target specific devices by IP address or advertising identifiers. The ad performs device fingerprinting and redirects only matching targets to the exploit delivery server. Amnesty International assessed that Aladdin was active in Predator deployments throughout 2024, with development continuing into 2025. The implication for Linux desktop operators is significant: a user browsing a legitimate news site may receive a malicious ad that attempts fingerprinting without any malicious link being sent, without any user interaction, and without the operator needing to know the individual's specific identity in advance.

For a technical look at how commercial surveillance vendors build and weaponize these exploit chains -- covering the full operational pipeline including infrastructure, staging, and delivery evasion -- that resource goes into depth on the operational architecture. The Chrome-specific zero-day landscape continues to evolve rapidly; CVE-2026-5281 in Chrome's WebGPU implementation illustrates how new browser API surfaces create new attack opportunities as graphics and compute APIs are exposed to web content.

CSV exploit delivery servers invest heavily in operational security: CAPTCHA pages requiring human interaction to prevent automated scanning, traffic filtering based on device fingerprinting, code obfuscation in the exploit payload itself, and URL randomization so that a captured link cannot be replayed or shared with researchers. The result is that many CSV exploit chains are never fully captured. Forensic analysis of compromised devices often reveals the spyware implant but not the initial exploit chain, because the delivery server either detected the analysis environment or the one-time link had already expired.

Detection and Hardening on Linux

Kernel exploitation techniques follow a consistent behavioral pattern regardless of the specific CVE being used: a low-privilege process manipulates kernel memory to modify its own credential structure, transitioning from an unprivileged UID to root. This behavior is detectable with the right tooling even without prior knowledge of the vulnerability being exploited. The auditd rules below cover both 64-bit and 32-bit syscall paths, include setresuid alongside setuid to catch both direct and indirect escalation paths, and add kernel module loading events for T1547.006 persistence detection. Rules should be saved to /etc/audit/rules.d/ and loaded persistently via augenrules --load rather than applied only at runtime with auditctl.

# Save to /etc/audit/rules.d/csv-escalation.rules  (loaded persistently via augenrules --load)
# Runtime-only testing: run commands without the leading path prefix

# Detect UID transitions to root from non-root processes (b64 + b32)
$ auditctl -a always,exit -F arch=b64 -S setuid -S setresuid -F a0=0 -F auid!=unset -k root_escalation
$ auditctl -a always,exit -F arch=b32 -S setuid -S setresuid -F a0=0 -F auid!=unset -k root_escalation

# Monitor capability grants (both architectures)
$ auditctl -a always,exit -F arch=b64 -S capset -F auid!=unset -k capability_change
$ auditctl -a always,exit -F arch=b32 -S capset -F auid!=unset -k capability_change

# Kernel module loading/unloading (rootkit persistence -- T1547.006)
$ auditctl -a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel_modules
$ auditctl -a always,exit -F arch=b32 -S init_module -S finit_module -S delete_module -k kernel_modules

# Watch for new mount namespaces (potential sandbox escape -- unshare CLONE_NEWNS=0x00020000)
$ auditctl -a always,exit -F arch=b64 -S unshare -F a0&0x00020000=0x00020000 -k mount_ns_create

# Watch for writes to perf_event_paranoid (lowering this widens LPE attack surface)
$ auditctl -w /proc/sys/kernel/perf_event_paranoid -p w -k perf_paranoid_write

# Watch ld.so.preload for LD_PRELOAD persistence (T1574.006)
$ auditctl -w /etc/ld.so.preload -p wa -k ldso_preload_write

# Make rules persistent (run as root, then reload)
$ augenrules --load && auditctl -l | grep -E 'root_escalation|capability_change|kernel_modules'

Falco, the CNCF runtime security project, runs as a kernel module or eBPF program and can detect privilege escalation in real time. The rule below uses container.id = host (current Falco style) rather than the deprecated not container form, adds user.uid != 0 to exclude root self-transitions that are not attacks, includes the full current output field set per the Falco style guide (proc_exepath, user_loginuid, terminal), and applies MITRE ATT&CK tags for SIEM correlation. The known_root_binaries list should be extended with any site-specific privileged binaries to reduce noise.

- list: known_root_binaries
  items: [sudo, su, newgrp, passwd, sshd, login, polkit, pkexec, unix_chkpwd, gpasswd]

- rule: Unexpected UID 0 Transition Outside Known Binaries
  desc: >
    A process transitioned to UID 0 via setuid without going through a known
    privilege pathway. This is the canonical behavioral signature of a successful
    kernel LPE exploit payload calling commit_creds(prepare_kernel_cred(0)).
  condition: >
    evt.type = setuid
    and evt.arg.uid = 0
    and user.uid != 0
    and container.id = host
    and not proc.name in (known_root_binaries)
  output: >
    Unexpected root transition | evt_type=%evt.type user=%user.name
    user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name
    proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline
    terminal=%proc.tty
  priority: CRITICAL
  tags: [host, mitre_privilege_escalation, TA0004, T1068]
  enabled: true

Kernel live patching -- kpatch on RHEL/CentOS, livepatch on Ubuntu, kGraft on SUSE -- applies kernel security patches without rebooting. This directly addresses the exploitation window between patch availability and deployment. For production servers where maintenance reboots require scheduling windows, live patching can reduce exposure from weeks to hours on the most critical kernel CVEs.

Browser Hardening on Linux

Verify Chrome's sandbox is active -- and check its status for each process type -- at chrome://sandbox. The renderer, GPU, and utility processes should all show sandbox status as active. If any process shows the sandbox as disabled, that indicates either a launch flag override or a missing kernel feature Chrome requires for sandboxing.

The --no-sandbox flag completely disables the process isolation that makes Stage 2 of the exploit chain necessary. It is sometimes added when troubleshooting Chrome startup issues on headless or container environments, but it must never be present on machines handling sensitive work. On AppArmor systems, verify the browser profile is loaded and enforcing:

How to Harden Linux Against CSV-Class Exploit Chains

Step 1: Audit kernel version and patch status against KEV catalog

Check your running kernel version with uname -r and compare it against CISA Known Exploited Vulnerabilities catalog entries for the Linux kernel, focusing on netfilter (CVE-2024-1086, added to KEV May 2024; CVE-2021-22555, added October 2025), vsock (CVE-2025-21756), OverlayFS (CVE-2023-0386), and USB driver CVEs (CVE-2024-53104, CVE-2024-53197). Use apt-get changelog linux-image-$(uname -r) on Debian-based systems or rpm -q --changelog kernel on RHEL-based systems to verify that specific CVEs have been backported into your running kernel version. The CISA KEV catalog is the most operationally useful signal: every entry represents a vulnerability with confirmed active exploitation, not just theoretical risk. T1068 800-40 Rev. 4

Step 2: Harden browser sandbox isolation on Linux

Verify Chrome sandbox status at chrome://sandbox with all process types showing active. Remove any --no-sandbox flags from launch scripts and desktop entries. On AppArmor systems, verify the browser profile is loaded and enforcing with aa-status | grep -i chromium. Configure unattended-upgrades or dnf-automatic to include the Chrome or Chromium repository so browser security updates are applied without manual intervention. T1203 800-40 Rev. 4

Step 3: Deploy kernel-level runtime monitoring for privilege escalation detection

Install Falco or configure auditd rules targeting credential modification syscalls, unexpected capability grants, and UID transitions to root outside known pathways. Monitor for processes that transition from low privilege to UID 0 without going through expected pathways like sudo. Where available, use kernel live patching to apply security patches without rebooting, closing the exploitation window between patch availability and maintenance schedules. T1068 800-53 AU-12

Step 4: Reduce ad-based delivery attack surface on Linux desktops

The Intellexa Aladdin vector -- confirmed active in 2024 and 2025 -- requires no malicious link and no user interaction beyond loading a web page that serves a targeted malicious ad. On Linux desktops handling sensitive work, deploy a DNS-based blocker or browser-native content blocker to reduce ad network exposure. Consider DNS-over-HTTPS with a filtering resolver. On high-sensitivity systems, restrict outbound browser connections to known-good domains using AppArmor network rules or egress firewall policies. Additionally, disabling or blacklisting kernel modules not required by your workload -- for example, blacklisting nf_tables on systems where it is not needed for packet filtering -- removes that attack surface entirely rather than relying on patch coverage alone. T1189 800-53 SC-7 800-128

Step 5: Audit persistence artifact paths against known-good baselines

Check /etc/ld.so.preload -- it should be absent or empty on production systems. Any path written there causes the dynamic linker to load the specified library into every process at startup. Audit enabled systemd units in /etc/systemd/system/ and ~/.config/systemd/user/ against a cryptographic baseline maintained by aide or tripwire. Run lsmod and cross-reference against your kernel's modules.dep tree for any modules not present in the installed kernel package. Also review /etc/cron.d/ and user crontabs, and check ~/.ssh/authorized_keys for unexpected entries. For a complete permission audit methodology including sudoers misconfigurations and SUID/SGID binary auditing, that guide covers the full workflow. T1574.006 T1547.006 800-53 SI-7 800-128

Step 6: Enable Secure Boot and kernel module signature enforcement

Enable UEFI Secure Boot and CONFIG_MODULE_SIG_FORCE to require cryptographic signatures on all loaded kernel modules. This raises the bar for rootkit-class persistence to require a bootloader or firmware compromise rather than a simple file write. For production servers where maintenance reboots are scheduled weeks out, also enable kernel live patching -- kpatch on RHEL/CentOS, livepatch on Ubuntu, kGraft on SUSE -- to apply kernel security patches without rebooting. Live patching directly closes the exploitation window on CISA KEV kernel entries, reducing exposure from weeks to hours without requiring a maintenance window. T1547.006 800-147 800-40 Rev. 4

What CSV Implants Do After Achieving Root

The exploit chain is the delivery mechanism. The implant is the payload. Understanding what a CSV implant does with root access on a Linux target clarifies both the intelligence value CSVs sell to their clients and the forensic artifacts defenders should look for.

File and credential exfiltration is the primary function. With root access, the implant can read any file on the system -- SSH private keys, GPG keys, browser credential stores, password manager databases, email archives, documents. On a developer workstation this means source code, API keys, and infrastructure credentials. On a journalist's machine it means source communications, draft documents, and contact lists. The Predator tcore module documented by Cisco Talos is responsible for data collection and exfiltration; its Linux analogues would have equivalent collection targets.

Communication interception is achievable at the kernel level via network traffic hooking or at the application level via process memory injection. An implant running as root can attach to browser processes via ptrace, read decrypted session data from memory, intercept TLS before encryption by hooking the relevant library calls, or capture audio streams via ALSA or PulseAudio/PipeWire interfaces. On a Linux desktop with a connected microphone, root access is sufficient for ambient audio capture without triggering any hardware LED indicators on most hardware.

Geolocation on Linux desktops is more limited than on mobile -- there is no GPS radio or cell tower triangulation. Implants can infer location from visible Wi-Fi networks (using the same BSSID-to-location databases mobile devices use), from the system's IP address, or from any geolocation data present in locally stored files and browser history.

Keylogging T1056.004 on Linux can be implemented by reading from the keyboard device file directly as root (/dev/input/eventN), by hooking X11 or Wayland input events, or by injecting into the shell or terminal emulator process. X11 provides particularly broad input interception access: any process with access to the X display can capture all keystrokes system-wide via XGrabKeyboard or by installing a passive event listener. The Wayland security model is stricter -- compositors are not required to expose input events to arbitrary clients -- but root access sidesteps these controls by operating below the compositor.

Forensic Indicators on Linux

CSV-class implants are designed to minimize forensic visibility, but root-level compromise on Linux does produce detectable artifacts for defenders who know where to look. Runtime detection (Falco rules, auditd) catches active exploitation as it happens. Post-compromise forensics requires a different checklist.

Process ancestry anomalies are one of the most reliable indicators. A legitimate user process spawned by a browser renderer should have a clear, explainable parent chain: init/systemd → display manager → session → browser → renderer. An implant-spawned process will often have an unusual parent -- a renderer with unexpected child processes, a process with PPID 1 that cannot be explained by system services, or processes whose command line has been cleared or set to a plausible-looking false name. Check with ps auxf or pstree -a -p and look for anomalous branches.

Unexpected kernel module state is a strong indicator of rootkit-class persistence. Compare lsmod output against a known-good baseline. Modules with names that resemble legitimate kernel modules but are not part of the installed kernel package are suspicious. On systems with CONFIG_MODULE_SIG_FORCE, any unsigned module that managed to load should trigger immediate investigation.

File integrity on critical paths covers /etc/ld.so.preload, /etc/systemd/system/, /etc/cron.d/, ~/.config/systemd/user/, and PAM module configuration under /etc/pam.d/. Any unexplained entries in these locations warrant investigation. Tools like aide or tripwire can maintain cryptographic baselines of these paths and alert on changes. For a complete methodology covering sudoers misconfigurations, SUID/SGID binary auditing, and group permission risks across a Linux system, that guide covers the full permission audit workflow.

# Check for ld.so.preload entries (should be absent on clean systems -- T1574.006)
$ cat /etc/ld.so.preload 2>/dev/null && echo "FILE EXISTS -- review contents" || echo "clean"

# List recently modified files in systemd unit directories (T1543.002)
$ find /etc/systemd/system/ ~/.config/systemd/user/ -newer /etc/passwd -type f 2>/dev/null

# List all loaded kernel modules and flag any not present in the running kernel's modules.dep
$ comm -23 <(lsmod | awk 'NR>1 {print $1}' | sort) \
     <(find /lib/modules/$(uname -r)/ -name '*.ko*' | xargs -I{} basename {} | sed 's/\.ko.*//' | tr '-' '_' | sort) \
  | grep -v '^$' || echo "no unexpected modules detected"

# Look for processes with cleared argv (common implant evasion)
$ for pid in /proc/[0-9]*/cmdline; do
  content=$(cat "$pid" 2>/dev/null | tr '\0' ' ' | xargs)
  [ -z "$content" ] && echo "Empty cmdline: ${pid%/cmdline}"
done

# Find SUID/SGID binaries not owned by root (unexpected escalation paths)
$ find / -xdev -perm /6000 ! -user root ! -user bin -type f 2>/dev/null

# Check for unexpected cron jobs and SSH authorized_keys modifications
$ find /etc/cron* /var/spool/cron -newer /etc/passwd -type f 2>/dev/null
find /home /root -name authorized_keys -newer /etc/passwd 2>/dev/null

Network behavior is a useful signal even when the implant successfully hides its process. CSV implants must exfiltrate data to command-and-control infrastructure, which requires outbound connections. Monitoring DNS resolution and outbound HTTPS connections from endpoints against a baseline can surface unexpected beaconing. Tools like ss -tupn and netstat -tupn show current connections, but a rootkit can hide entries; comparing against kernel-level network monitoring via eBPF (using bpftrace or Falco's network rules) bypasses this evasion.

Legal and Regulatory Status of CSVs

A question readers frequently have after reading about CSV capabilities is whether these companies are operating legally. The answer is complicated and jurisdiction-dependent, but there have been significant legal and regulatory actions that have materially constrained some of the most prominent vendors.

NSO Group has faced the most extensive legal pressure. In November 2021, the U.S. Commerce Department added NSO Group to its Entity List, restricting U.S. companies from selling technology to it without a license. In 2021, Apple filed a lawsuit against NSO Group in U.S. federal court; WhatsApp (Meta) had filed a separate lawsuit in 2019 over Pegasus infections of WhatsApp users. In July 2024, a U.S. federal judge ruled that the WhatsApp lawsuit could proceed, finding that NSO's claims of sovereign immunity did not apply. In December 2024, the court granted summary judgment against NSO on the Computer Fraud and Abuse Act and California Comprehensive Computer Data Access and Fraud Act claims. These proceedings are significant because they force disclosure of technical details about how Pegasus operates in a legal setting -- unusual for a commercial spyware vendor.

Intellexa and the Predator consortium were added to the U.S. Entity List in July 2023. In March 2024, the U.S. Treasury Department sanctioned Intellexa Alliance and five associated individuals and entities, prohibiting U.S. persons from transacting with them. The sanctions were the first use of Treasury's Cyber Executive Order (E.O. 13694) authority against a commercial spyware vendor. Intellexa has attempted to restructure corporate entities across multiple jurisdictions -- Greece, Ireland, Hungary -- in response to regulatory pressure, but the U.S. sanctions follow the entity regardless of jurisdictional moves.

The EU regulatory picture is evolving. The European Parliament's PEGA committee, which investigated the use of Pegasus and other spyware against EU citizens and officials, published its final report in May 2023 recommending stronger controls on spyware exports and use within the EU. The dual-use goods regulation covering surveillance technology exports from EU member states requires licenses for exports to third countries, but enforcement has been inconsistent -- several EU member states have been documented using Pegasus against political opponents and journalists domestically.

The Wassenaar Arrangement, the multilateral export control regime, includes intrusion software in its control lists, meaning signatory states are expected to require export licenses for commercial spyware. However, Wassenaar controls are implemented differently in each member state and have significant gaps. The practical effect is that CSVs operating out of non-Wassenaar jurisdictions, or out of EU member states with permissive licensing practices, face limited export control friction.

Frequently Asked Questions

Do commercial surveillance vendors target Linux systems?

Yes. Linux is targeted both directly -- through kernel privilege escalation vulnerabilities used in post-exploitation chains -- and indirectly through the Linux kernel that underlies Android. The same kernel subsystems exploited on Android (nf_tables, vsock, POSIX CPU timers, OverlayFS) run on server and desktop Linux. CVE-2025-38352, confirmed by Google's September 2025 Android Security Bulletin as exploited in limited targeted attacks, is a mainline Linux kernel vulnerability. Note that its exploitability depends on CONFIG_POSIX_CPU_TIMERS_TASK_WORK being disabled -- a default condition on 32-bit Android kernels but not on standard 64-bit x86 Linux.

How do commercial surveillance vendors deliver exploits through browsers on Linux?

The primary delivery mechanism is a renderer exploit -- typically a V8 type confusion or heap corruption bug in Chrome -- that achieves arbitrary memory read and write within the renderer process. Since renderers run in a sandboxed environment on Linux using seccomp-bpf and namespace isolation, a second exploit is required to escape the sandbox. This is commonly achieved via a kernel vulnerability that allows a low-privilege sandboxed process to corrupt kernel memory and escalate to root. CSVs like Intellexa maintain reusable exploit frameworks that apply the same sandbox escape technique across multiple renderer CVEs. Beyond link-based delivery, Intellexa's Aladdin ad-based vector -- confirmed in December 2025 leaked documents -- targets users through malicious advertising without any link being sent.

What Linux kernel subsystems are most frequently targeted by commercial spyware exploit chains?

The netfilter subsystem (particularly nf_tables), the vsock virtual socket interface, OverlayFS, POSIX CPU timers, USB driver code (UVC and USB audio), and UNIX domain socket MSG_OOB handling have all seen active exploitation confirmed in CISA KEV additions between 2024 and 2025. Netfilter is particularly attractive because it runs with high privilege, handles externally influenced data, and has a long history of use-after-free and heap corruption vulnerabilities. CVE-2024-1086 was added to CISA KEV in May 2024; CVE-2021-22555 was added in October 2025, more than four years after initial disclosure.

Can commercial spyware reach Linux systems through advertising networks?

Yes, and this is no longer theoretical. Intellexa's Aladdin delivery system, exposed in December 2025 leaked internal documents analyzed by Google GTIG, Amnesty International, and Recorded Future, weaponizes the digital advertising ecosystem. Operators purchase DSP ad placements through front companies -- Pulse Advertise and MorningStar TEC were identified by Recorded Future -- fingerprint connecting devices, and redirect only targeted devices to exploit servers. No malicious link is sent. Amnesty International assessed Aladdin was active in Predator deployments throughout 2024 and continuing into 2025. A Linux desktop user browsing a legitimate news site within a targeted IP range is a viable attack surface through this mechanism.

How do CSV implants maintain persistence on Linux after achieving root?

The most common mechanisms are shared library injection via /etc/ld.so.preload or per-user environment files, systemd service unit files placed in system or user unit directories, and kernel module (rootkit) persistence for the most sophisticated operators. Rootkit-class persistence requires either disabling Secure Boot or bypassing kernel module signature verification. Defenders should audit /etc/ld.so.preload, enabled systemd units, and loaded kernel modules against known-good baselines as part of regular integrity monitoring.

What do CSV implants collect from a compromised Linux system?

With root access, an implant can read any file on the system -- SSH and GPG keys, browser credential stores, password databases, email archives, and documents. Beyond static data, implants can intercept decrypted TLS traffic by hooking library calls or reading browser process memory, capture audio through ALSA or PulseAudio/PipeWire interfaces, log keystrokes by reading from keyboard device files or hooking X11 input events, and infer geolocation from visible Wi-Fi BSSIDs. The Predator tcore module documented by Cisco Talos on Android provides a reference for the collection capabilities these implants typically carry.

Are commercial surveillance vendors operating legally?

Legality varies significantly by jurisdiction and vendor. NSO Group and Intellexa have both faced major legal consequences in the United States: both were added to the U.S. Commerce Department Entity List, and Intellexa was sanctioned by the U.S. Treasury Department in March 2024 under E.O. 13694 (Cyber Executive Order) -- the first such action against a commercial spyware vendor. U.S. courts ruled in 2024 that the WhatsApp lawsuit against NSO Group could proceed on its merits. The Wassenaar Arrangement covers intrusion software under dual-use export controls, but implementation is inconsistent across member states. These legal measures constrain access to U.S. technology and financing but have not stopped the implants from being deployed.

How do I detect CSV spyware on a Linux system?

Detection requires both runtime monitoring and post-compromise forensics. For runtime: deploy Falco running as an eBPF program with rules watching for UID transitions to root outside known pathways, or configure auditd rules targeting setuid, setresuid, capset, and kernel module loading syscalls. For forensic investigation: check /etc/ld.so.preload for unexpected entries, compare lsmod against your kernel's modules.dep tree for unsigned or unexpected modules, find recently modified systemd unit files, look for processes with cleared argv in /proc/[pid]/cmdline, and monitor outbound connections for unexpected beaconing. Network-layer rootkits can hide connections from ss and netstat; kernel-level monitoring via eBPF bypasses this evasion.

Does kernel live patching protect Linux systems against commercial spyware exploit chains?

Kernel live patching -- kpatch on RHEL/CentOS, livepatch on Ubuntu, kGraft on SUSE -- applies security patches to a running kernel without requiring a reboot. This directly reduces the exploitation window between patch availability and deployment. Standard enterprise patch cycles of 30 to 60 days leave confirmed actively-exploited kernel CVEs (CISA KEV entries) open for weeks; live patching can reduce that window to hours. It does not eliminate vulnerability -- the kernel still needs to receive the patch -- but it removes the operational constraint of scheduling maintenance reboots, which is the primary reason kernel patches are delayed on production systems.