{
	"id": "22d7e1eb-172f-4fc0-9fc2-eed0933bbab8",
	"created_at": "2026-05-06T02:03:25.163845Z",
	"updated_at": "2026-05-06T02:03:52.834465Z",
	"deleted_at": null,
	"sha1_hash": "8d0ebd640cb6eca350f2d0d983a05cfbbad53141",
	"title": "Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM Backdoor, Credential Harvesting Capabilities",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5912964,
	"plain_text": "Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a\r\nFull-Featured Linux RAT With Rootkit, PAM Backdoor, Credential\r\nHarvesting Capabilities\r\nPublished: 2026-05-04 · Archived: 2026-05-06 02:00:55 UTC\r\nKey takeaways\r\nQuasar Linux RAT (QLNX) is a comprehensive Linux implant that combines remote access capabilities with\r\nadvanced evasion, persistence, keylogging, and credential harvesting features. The malware carries embedded C\r\nsource code for both its PAM backdoor and LD_PRELOAD rootkit as string literals within the binary. It dynamically\r\ncompiles rootkit shared objects and PAM backdoor modules on the target host using gcc , then deploys them via\r\n/etc/ld.so.preload for system-wide interception.\r\nQLNX targets developers and DevOps credentials across the software supply chain. Its credential harvester extracts\r\nsecrets from high-value files such as .npmrc (NPM tokens), .pypirc (PyPI credentials), .git-credentials ,\r\n.aws/credentials , .kube/config , .docker/config.json , .vault-token , Terraform credentials, GitHub CLI\r\ntokens, and .env files. The compromise of these assets could allow the operator to push malicious packages to\r\nNPM or PyPI registries, access cloud infrastructure, or pivot through CI/CD pipelines.\r\nQLNX incorporates a PAM backdoor with inline hooking, enabling plaintext credential interception during\r\nauthentication. It uses the hardcoded master password O$$f$QtYJK and XOR-encrypted credential harvesting to\r\n/var/log/.ICE-unix .\r\nQLNX includes a P2P mesh capability that transforms individual implants into a resilient network, making complete\r\neradication significantly more difficult.\r\nTrend Vision One™ detects and blocks the specific indicators of compromise (IoCs) mentioned in this blog entry,\r\nand offers customers access to hunting queries, threat insights, and intelligence reports related to the QLNX RAT.\r\nIn previous research, we have demonstrated how AI can be used to improve detection accuracy when new malware families\r\nemerge, particularly those that reuse or share code from open-source repositories. A clear example is our earlier work “AI-Automated Threat Hunting Brings GhostPenguin Out of the Shadows,” where AI-driven threat hunting helped us expose the\r\npreviously elusive GhostPenguin backdoor.\r\nIn this blog entry, we present another compelling finding from the same approach. Our platform recently flagged an unusual\r\nLinux implant with low detection, which caught our attention and prompted a deeper investigation. What followed was the\r\ndiscovery of Quasar Linux (QLNX), a previously undocumented Linux remote access trojan (RAT) with rootkit capabilities\r\nand a notably minimal detection footprint.\r\nThreat landscape overview\r\nSupply-chain attacks targeting open-source package ecosystems like PyPI and npm have become one of the most effective\r\nattack vectors available to threat actors today. By compromising a maintainer's account through phishing, credential theft, or\r\na misconfigured CI/CD pipeline, an attacker can inject malicious code into a legitimate and widely trusted package and\r\ninstantly reach its entire audience — as seen in recent npm-focused compromises such as the axios package incident.\r\nWhile the open-source ecosystem is supported by a mix of enterprise teams and independent contributors, attackers\r\nfrequently target the developer's workstation. Security controls across these decentralized endpoints can vary significantly,\r\nmeaning not all workstations benefit from uniform, enterprise-grade solutions such as EDR, XDR, or advanced network\r\nmonitoring. This variability creates potential blind spots that make certain developer endpoints highly attractive targets and,\r\ncritically, makes it much harder to detect a breach after the fact — allowing attackers to maintain silent access for extended\r\nperiods.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 1 of 32\n\nQLNX attack surface and impact\r\nThis is precisely the threat environment that QLNX was built for. QLNX's credential harvesting module targets the files and\r\ntokens that provide authenticated access to development tools, package registries, and cloud environments: this includes\r\nAWS credentials and configuration files, Kubernetes service account tokens and kubeconfig files, Docker Hub credentials,\r\nGit configuration and access tokens, NPM authentication tokens, and PyPI API keys.\r\nAn attacker who successfully deploys QLNX against a package maintainer gains access to that maintainer's publishing\r\npipeline. A single compromise can be silently leveraged to trojanize packages, inject backdoors into build artifacts, or pivot\r\ninto cloud environments where production infrastructure lives.\r\nTable 1 summarizes its complete capability set across eight operational categories.\r\nCategory Capabilities\r\nExecution and\r\nevasion\r\nFileless execution via memfd_create + execveat\r\nSelf-deletion\r\nProcess name spoofing\r\nSingle-instance mutex\r\nRootkit and hiding\r\nTwo-tier rootkit architecture: userspace LD_PRELOAD hooks ( readdir , stat ,\r\nopen , fopen ) and kernel-level eBPF maps hiding PIDs, filenames, and TCP ports\r\nfrom the kernel directly.\r\nPersistence\r\nsystemd (system + user services)\r\ncrontab @reboot\r\ninit.d script \r\nXDG autostart .desktop files\r\nLD_PRELOAD bootstrap .so\r\n.bashrc injection\r\nCredential and\r\ndata harvesting\r\nSSH private keys\r\nBrowser login databases (Chrome, Chromium, Firefox)\r\nCloud configuration files (AWS, Kubernetes, Docker, Git, NPM, PyPI)\r\nShell history (Bash, Zsh, MySQL, PSQL)\r\nPlaintext PAM passwords via pam_security.so hook; /etc/shadow (root)\r\nClipboard content\r\nSurveillance\r\nKeylogger (raw /dev/input events + X11 fallback)\r\nScreenshot capture\r\nClipboard monitoring with SHA256 deduplication and periodic exfiltration\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 2 of 32\n\nNetworking and\r\ntunnelling\r\nTCP tunnel; port forwarding\r\nPort scanning; raw packet capture\r\nSSH lateral movement execution\r\nPeer-to-peer mesh network with routing table for agent-to-agent C\u0026C relay\r\nRemote control\r\nInteractive PTY reverse shell\r\nFull file manager (list, read, write, rename, delete, mkdir)\r\nFile upload/download; process listing and termination\r\nTCP connection listing and killing; power control (shutdown/reboot/suspend)\r\nPrivilege escalation via Sudo/pkexec\r\nAdvanced\r\noffensive\r\nIn-memory .so reflective loading (memfd/shm/tmpfile)\r\nProcess injection via /proc/pid/mem and ptrace\r\nBeacon Object File (BOF/COFF) in-memory execution\r\nReal-time filesystem event monitoring via inotify\r\nTimestamp manipulation (timestomping)\r\nTable 1. Overview of QLNX capabilities\r\nQuasar Linux (QLNX) analysis\r\nProperty Value\r\nName quasar-implant\r\nMD5 70f70743f287a837d17c56933152a8a6\r\nSHA1 b0f2c668cbdd63a871c90592b6c93e931115872e\r\nSHA256 ea1d34b21b739a6bbf89b3f7e67978005cf7f3eda612cefc7eac1c8ead7c5545\r\nMagic ELF 64-bit LSB pie executable, x86-64\r\nFile size 147.91 KB (151,464 bytes)\r\nTable 2. Identifying information on QLNX\r\nSummary\r\nQLNX is a full-featured RAT that targets the Linux platform. The malware executes filelessly from memory, spoofs its\r\nprocess name, profiles the system to detect containerized environments, utilizes eBPF to hide specific processes, files, and\r\nnetwork ports, and wipes system logs.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 3 of 32\n\nQLNX performs extensive data collection. It gathers system information, clipboard contents, shell history, SSH keys,\r\nFirefox browser profiles, and credentials via a malicious Pluggable Authentication Module (PAM) injected through\r\nld.so.preload .\r\nQLNX communicates with the attacker and sends the collected information via TLS (custom protocol over TLS), HTTPS, or\r\nHTTP. The malware contacts a remote server and receives commands. The supported commands allow the malware to\r\nexecute shell commands, manage files, inject code into processes via /proc/pid/mem and ptrace, capture screenshots, log\r\nkeystrokes, establish SOCKS proxies and TCP tunnels, manage a peer-to-peer mesh network, and execute Beacon Object\r\nFiles (BOFs).\r\nQLNX supports multiple persistence mechanisms across both user and system scopes. These include creating systemd\r\nservices, adding crontab reboot entries, installing init.d scripts, deploying XDG autostart desktop files, modifying the user's\r\n.bashrc file, and injecting a shared object via the /etc/ld.so.preload file. These options allow the operator to adjust\r\npersistence based on the environment.\r\nQLNX internal logic\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 4 of 32\n\nFigure 1. QLNX internal architecture\r\nUpon execution, QLNX copies itself into an in-memory file, re-executes from that memory copy, and deletes the original\r\nbinary from disk, leaving no on-disk footprint. To achieve this, the malware first inspects readlink(“/proc/self/exe”) for\r\nsubstrings “memfd:” or “(deleted)” to determine if it is already running from memory.\r\nBefore performing this check, it reads the _MFD_RE environment variable, which serves as a re-execution guard. If the\r\nvariable is set, it is cleared and the function returns immediately to prevent an infinite execution loop.\r\nIf neither memory condition is met, the malware opens /proc/self/exe for reading and calls memfd_create (syscall 319)\r\nto create an anonymous RAM-backed file descriptor. The binary is then read in 8 KB chunks and written into the memory\r\nfile descriptor. Once the copy is complete, the close-on-exec flag is cleared from the memory file descriptor via fcntl , the\r\noriginal binary is deleted from disk with unlink , and the environment variable _MFD_RE is set to “1”  to signal the re-execution guard.\r\nQLNX then attempts to re-execute itself directly from memory via execveat (syscall 322), passing the memory file\r\ndescriptor directly. If that fails — such as on older kernels that do not support execveat — execution falls back to execv\r\nusing the /proc/self/fd/\u003cmemfd\u003e path.\r\nFollowing this, the malware profiles the infected host by reading system state and probing available resources. The results\r\nare stored in a set of global flags that govern which capabilities are available later in the session:\r\nFlag Source Purpose\r\ng_is_root getuid() == 0\r\nGates root-only capabilities\r\nthroughout\r\ng_kernel_version[2] uname() Major and minor kernel version\r\ng_memfd_supported memfd_create syscall (319) probe\r\nRequired for fileless in-memory\r\nexecution\r\ng_has_proc_mem_write Kernel ≥ 3.2 check\r\nIndicates /proc/pid/mem is\r\nwritable for process injection\r\ng_yama_ptrace_scope /proc/sys/kernel/yama/ptrace_scope\r\nGoverns whether ptrace-based\r\ninjection is permitted\r\ng_selinux_enforce /sys/fs/selinux/enforce\r\nIndicates whether SELinux is in\r\nenforcing mode\r\ng_has_devinput Readable event* device under /dev/input\r\nRequired for raw device\r\nkeylogger\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 5 of 32\n\ng_has_x11 DISPLAY environment variable present\r\nRequired for X11 keylogger and\r\nscreenshot\r\ng_has_gcc\r\nProbe of /usr/bin/gcc , /usr/local/bin/gcc ,\r\n/usr/bin/cc\r\nRequired for LD_PRELOAD\r\nrootkit and PAM hook runtime\r\ncompilation\r\ng_is_containerized\r\n/.dockerenv or /proc/1/cgroup contains docker ,\r\nlxc , kubepods , containerd\r\nDetects container runtime\r\nenvironment\r\nTable 3. QLNX runtime profiling flags used to detect host capabilities and selectively enable functionality based on\r\nprivilege level, kernel features, security controls, and available tooling.\r\nName spoofing process\r\nNext, the malware attempts to evade detection by randomly selecting one of the following fake kernel thread names:\r\nFake Name Legitimate Kernel Thread It Mimics\r\n[kworker/0:0] Kernel worker thread\r\n[kworker/u8:2] Unbound kernel worker thread\r\n[migration/0] CPU migration thread\r\n[ksoftirqd/0] Soft IRQ handler thread\r\n[rcu_sched] RCU scheduling thread\r\n[watchdog/0] Kernel watchdog thread\r\nTable 4. Kernel thread name spoofing used by QLNX for process masquerading\r\nQLNX applies the name consistently across three process metadata locations to ensure consistency across all process\r\ninspection tools:\r\nargv[0] overwrite — The entire original argument string in memory is zeroed and replaced with the chosen name.\r\nThis changes what ps and /proc/pid/cmdline report.\r\nprctl(PR_SET_NAME) — Sets the kernel-visible thread name to the chosen name. This is what top and htop\r\nread from the scheduler.\r\n/proc/self/comm — The name is written directly to this file after stripping the surrounding [ and ] brackets and\r\ntruncating to 15 bytes to comply with the kernel's TASK_COMM_LEN limit.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 6 of 32\n\nIn addition to process name spoofing, QLNX removes shell-populated environment variables that could reveal its original\r\nexecution context. The malware clears the _ and OLDPWD variables via unsetenv . These variables are automatically\r\npopulated by the shell at the moment it launches any process. _ is set to the full path of the executed binary, and OLDPWD\r\nis set to the previous working directory. Both values are stored in the process environment block and are readable by anyone\r\nwith access to /proc/pid/environ , making them valuable forensic artifacts if left intact.\r\nTo prevent multiple instances from running simultaneously, the malware implements a single-instance mutex using file\r\nlocking. It computes a DJB2 hash of the string “quasar_linux”  (result: 0x752e2ca1 ) and constructs a lock file path\r\ndisguised as an X11 socket lock: /tmp/.X752e2ca1-lock . This path is designed to blend in with legitimate X server lock\r\nfiles. The file is created using open(path, O_CREAT|O_RDWR, 0600) , followed by an attempt to acquire an exclusive, non-blocking flock(fd, LOCK_EX|LOCK_NB) . If the lock cannot be acquired — meaning another instance is already running —\r\nthe process terminates immediately. When successful, the file descriptor is intentionally left open for the lifetime of the\r\nprocess, so the kernel holds the lock until the process exits.\r\nWith its execution safeguards in place, QLNX then initializes its command dispatch mechanism by registering a large set of\r\ncommand handlers into a global handler table. Each entry maps a numeric command identifier to a corresponding routine,\r\nenabling the malware to dynamically route incoming C\u0026C instructions to the appropriate functionality.\r\ntypedef struct {\r\n        __int16  command_id;    \r\n        char     _pad[6];       \r\n         void    *handler;       \r\n} command_handler_entry_t;   \r\nFigure 2. QLNX initiates commands\r\nOnce the malware completes its foothold and installation on the compromised system, it transitions into its primary\r\noperational phase, entering a persistent loop that continuously attempts to establish and maintain communication with the\r\nC\u0026C server.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 7 of 32\n\nThe implant supports multiple communication channels, including a custom TCP-based protocol over TLS, as well as\r\nHTTPS and HTTP protocols. In this sample, the configuration is set to use the custom TCP protocol. Upon a successful\r\nconnection, it constructs and transmits an initial beacon packet (Command ID 1).\r\nThis beacon contains a serialized byte buffer including the malware version (1.4.1), OS version, privilege level (Admin or\r\nUser), geolocation data (retrieved from ip-api.com ), a unique machine fingerprint (SHA256 hash of the MAC address or\r\n/etc/machine-id ), the current username, hostname, and active IPv4 interfaces.\r\nIf the connection fails or the C\u0026C server does not respond, the malware implements a randomized sleep mechanism to\r\nevade network beaconing detection. It calculates a base sleep time between 3,000 and 15,000 milliseconds using\r\n/dev/urandom , then applies a 30% jitter to this value, ensuring the sleep duration is unpredictable before attempting to\r\nreconnect.\r\nThe following traffic is the initial decrypted beacon sent by the QLNX. We provide a more detailed breakdown in the\r\n“Network communication” section.\r\nFigure 3. QLNX TCP handshake - SSL Decrypted packet\r\nOnce the C\u0026C connection is established and the beacon is acknowledged, the malware enters a blocking receive loop. The\r\nnetwork protocol uses a 6-byte header consisting of a 4-byte little-endian payload length followed by a 2-byte command\r\nidentifier. Upon receiving data, the malware reads this header, allocates memory for the incoming payload, and then routes\r\nthe data through an internal dispatch mechanism which iterates over a table of registered handlers and executes the routine\r\nassociated with the received command.\r\nIn total, QLNX registers 58 distinct commands, covering a broad range of post-compromise functionality, including file\r\nsystem manipulation, network tunneling, credential harvesting, and rootkit management. The complete list of registered\r\ncommands and their corresponding handlers is detailed in Table 5:\r\nCommand ID Description\r\n0x10 Spawns an interactive PTY shell (bash, zsh, or sh) and binds I/O to the C\u0026C\r\n0x20 Parses /proc/mounts to enumerate mounted filesystems\r\n0x22 Enumerates files in a directory, returning names, sizes, and timestamps\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 8 of 32\n\n0x24 Deletes a file via unlink or recursively via /bin/rm -rf\r\n0x25 Renames or moves a file using the rename function\r\n0x26 Creates a new directory using mkdir\r\n0x27 Reads a file up to 10MB into memory and transmits it to the C\u0026C\r\n0x29 Writes provided text data to a specified file path\r\n0x30 Reads a file in 64KB chunks and streams it to the C\u0026C\r\n0x31 Receives file chunks from the C\u0026C and writes them to disk\r\n0x33 Aborts an active file upload or download task\r\n0x40 Gathers CPU, RAM, GPU, disk usage, and network interface statistics\r\n0x42 Enumerates running processes by reading /proc/[pid]/comm\r\n0x44 Downloads a payload via curl/wget or executes a local binary via execvp\r\n0x45 Terminates a specified process using kill(pid, 9)\r\n0x50 Parses /proc/net/tcp to list active network connections\r\n0x52 Terminates a specific TCP connection using ss --kill\r\n0x60 Reboots, suspends, or halts the system using shutdown or systemctl\r\n0x61 Sets the session reset flag to force a C\u0026C reconnection\r\n0x62 Identical to reconnect; tears down the current socket\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 9 of 32\n\n0x63 Triggers the self-destruct sequence, removing persistence and the binary\r\n0x64 Attempts to restart the malware as root using sudo or pkexec\r\n0x65 Opens a URL silently via curl/wget or visibly via xdg-open\r\n0x66 Displays a desktop notification using notify-send\r\n0x70 Scans systemd, crontab, init.d, bashrc, and ld.so.preload for malware entries\r\n0x72 Installs the malware into a specified persistence mechanism\r\n0x73 Removes the malware from a specified persistence mechanism\r\n0x80 Opens a raw TCP socket to a target host and port for proxying\r\n0x82 Sends raw data through an established TCP tunnel\r\n0x83 Closes an active TCP tunnel\r\n0x90 Extracts SSH keys, browser databases, cloud tokens, and clipboard data\r\n0xA0 Performs a multi-threaded TCP port scan against a target IP range\r\n0xA2 Captures the screen and sends the image\r\n0xB0 Starts capturing keystrokes via /dev/input or X11\r\n0xB1 Stops the active keylogger thread\r\n0xB3 Injects shellcode into a target PID using ptrace or /proc/pid/mem\r\n0xB5 Loads a shared object directly from memory\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 10 of 32\n\n0xB7 Executes commands on remote hosts using harvested SSH credentials\r\n0xB9 Parses SSH config and keys to map lateral movement targets\r\n0xBB Injects a malicious PAM module to capture credentials\r\n0xBD Installs a user-space rootkit via /etc/ld.so.preload\r\n0xC0 Evaluates success probability of exploits/modules\r\n0xD0 Executes a Beacon Object File (BOF) in memory\r\n0xD4 Binds a local port and forwards traffic to a remote destination\r\n0xD6 Sends data through an active port forwarding rule\r\n0xD7 Closes an active port forwarding rule\r\n0xD8 Starts a SOCKS proxy server on the infected host\r\n0xD9 Stops the active SOCKS proxy server\r\n0xDC Starts continuous clipboard and screen monitoring\r\n0xDD Stops continuous monitoring\r\n0xE0 Loads eBPF maps to hide PIDs, files, and network ports\r\n0xE4 Manages peer-to-peer routing tables\r\n0xE6 Sends file browser data through the P2P mesh network\r\n0xE8 Clears system logs ( auth.log , syslog , wtmp , bash_history )\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 11 of 32\n\n0xEA Installs or removes the PAM authentication hook\r\n0xEE Sets up real-time filesystem monitoring on a given path using inotify (create, delete, modify, move)\r\n0xEF Removes all active inotify watches\r\n0xF2 Modifies file timestamps using utimensat\r\nTable 5. List of registered commands and their corresponding handlers\r\nNetwork communication\r\nQLNX supports three transport backends: raw TCP, HTTPS, and HTTP. All three transports carry the same underlying\r\nbinary command protocol. Both the TCP and HTTPS channels are secured using TLS, ensuring that command and data\r\nexchanges are encrypted during network communication.\r\nThe QLNX magic identifier\r\nAll three transport modes begin their session by sending the 4-byte magic value 51 4C 4E 58 , which spells “QLNX” in\r\nASCII. This value serves as the protocol identifier and session initiator. Its role varies depending on the transport:\r\nTransport How QLNX Magic Is Used\r\nCustom\r\nTCP/TLS\r\nSent as the first 4 bytes of the Check-In packet, combined with the framing header and payload in\r\na single TLS write\r\nHTTPS\r\nSent as a standalone 4-byte HTTP POST body before the Check-In — server responds with a\r\nsession cookie\r\nHTTP Same as HTTPS but over plaintext\r\nTable 6. Role of the QLNX Magic Identifier across the three transport modes\r\nTransport 1 — Raw TLS (Default)\r\nThis is a fully custom binary protocol running directly over TLS. There is no HTTP layer involved. The implant connects to\r\nthe C\u0026C, performs a TLS handshake with certificate validation disabled, and then exchanges length-prefixed binary frames.\r\nThe session follows a strict 4-step handshake before entering the command loop:\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 12 of 32\n\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 13 of 32\n\nFigure 4. Four-step handshake sequence before entering the command loop\r\nOnce this handshake completes, the session becomes fully interactive, supporting bidirectional command and response\r\ntraffic.\r\nIn Figure 5, we show an example of malware communication to the C\u0026C server. \r\nFigure 5. TCP full handshake\r\nThe CheckIn packet is used to register the infected host with the C\u0026C and establish a session context, as illustrated in Figure\r\n6.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 14 of 32\n\nFigure 6. Check-in request packet structure.\r\nHTTP/HTTPS\r\nAlthough the analyzed version of QLNX communicates by default over encrypted TLS, it also supports HTTP and HTTPS\r\nas communications options. We successfully rebuilt the C\u0026C and emulated malware communications over HTTP for\r\nanalysis.\r\nThe packet structure remains identical across all three protocols. The malware uses POST requests to push data to the C\u0026C\r\nand GET requests to poll for incoming commands, with all traffic Base64-encoded before hitting the wire. Session tracking\r\nrelies on a server-generated hex ID that gets passed redundantly in both the sid= URL parameter on GETs and the Cookie\r\nheader on POSTs. A dedicated thread polls the C\u0026C every five seconds for new commands.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 15 of 32\n\nBefore contacting the C\u0026C, the implant resolves the victim's geographic location by querying the public ip-api.com\r\nservice. The country name and country code are included in the registration packet. QLNX then initiates contact by sending\r\na POST request containing base64-encoded magic header “QLNX”  to /api/v1/update . The handshake request does not\r\ncontain the Cookie header. The C\u0026C responds with a session ID that tracks this victim for the rest of the session.\r\nFigure 7. HTTP/HTTPS handshake and initial registration\r\nOnce connected, the malware registers itself with the C\u0026C by sending a registration packet containing a full system profile.\r\nAmong the 13 fields is a machine fingerprint — a SHA hash computed from /etc/machine-id (falling back to\r\n/var/lib/dbus/machine-id ), MAC addresses, CPU info, and hostname. This gives the C\u0026C a stable identifier for the\r\nvictim even if the IP changes between sessions.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 16 of 32\n\nFigure 8. QLNX C\u0026C registration\r\nAfter registration, the polling thread kicks in and starts sending GET requests to the C\u0026C. On the next poll cycle, the server\r\nresponds with an ACK packet indicating whether the registration was accepted. If the C\u0026C accepts, the implant fires back a\r\ntwo-part Confirmation — a split-packet that acts as a gate signal, telling the server “I'm ready, start sending commands.” \r\nThe C\u0026C must hold off on issuing any commands until it receives this confirmation.\r\nServer authentication and command loop\r\nOnce the acknowledge signal is sent, the malware enters its main command loop. The malware continues sending GET\r\nrequests every 5 seconds. If the C\u0026C has a command, it responds with a Base64-encoded packet in the GET response body;\r\notherwise, the response comes back empty and the implant waits for the next cycle.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 17 of 32\n\nFigure 9. Server authentication\r\nWhen a command does arrive, the malware decodes and parses it, then looks up the command type in a handler table and\r\nroutes it to the matching function. The handler executes locally, builds a response packet, and sends the result back to the\r\nC\u0026C. This loop runs until the connection drops or the C\u0026C sends a shutdown command.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 18 of 32\n\nFigure 10. HTTP/HTTPs command loop\r\nPersistence\r\nQLNX supports seven persistence mechanisms. Table 7 shows all persistence techniques.\r\nType Method Artifact Path Privilege\r\n0 Systemd system service /etc/systemd/system/{name}.service Root\r\n1 .bashrc shell injection ~/.bashrc User\r\n2 Crontab @reboot crontab User\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 19 of 32\n\n3 Systemd user service ~/.config/systemd/user/{name}.service User\r\n4 SysVinit init.d script /etc/init.d/{name} Root\r\n5\r\nLD_PRELOAD shared\r\nlibrary\r\n/etc/ld.so.preload /\r\n/usr/lib/libsecurity.so.1\r\nRoot + gcc\r\ncompiler\r\n6 XDG desktop autostart ~/.config/autostart/{name}.desktop User + desktop\r\nTable 7. QLNX persistence mechanisms\r\nPersistence is entirely operator-controlled. The C\u0026C can issue a scan command to fingerprint the target's init system,\r\nprivilege level, desktop environment, and toolchain availability, then the operator selects which methods to install. Methods\r\ncan be stacked on a single host for layered survivability. Every persistence artifact — service files, crontab entries, shell\r\nlines, init scripts, desktop entries — contains the string QLNX_MANAGED embedded as a comment. The malware uses this to\r\ndistinguish its own entries from legitimate system services during enumeration.\r\nFigure 11. QLNX Persistence\r\nLD_PRELOAD shared library persistence\r\nLD_PRELOAD shared library is a sophisticated persistence method in the arsenal. Instead of writing configuration files or\r\nscripts, the malware compiles a shared library on the target host, causing the library to be loaded into every dynamically\r\nlinked process on the system.\r\nUnlike other persistence methods that trigger boot or login, LD_PRELOAD triggers every program execution. Even if the\r\nmalware process is terminated, the next time any command runs — even ps to check for it — the preload library spawns a\r\nnew instance. The only way to stop the malware is to remove the /etc/ld.so.preload entry first, then kill the process.\r\nRemoving the process without clearing the preload will immediately respawn it.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 20 of 32\n\nFigure 12. LD_PRELOAD Shared Library persistence installation process\r\nEvery dynamically-linked program triggers LD_PRELOAD: ls , cat , ssh , sudo , bash — ALL trigger the malware.\r\nFigure 13. LD_PRELOAD Shared Library persistence trigger logic\r\nPAM backdoor\r\nQLNX contains two distinct PAM backdoor implementations, each serving different operational purposes but sharing the\r\nsame compile-on-target design approach and LD_PRELOAD delivery mechanism. Both implementations are shipped as\r\nembedded C source code rather than precompiled binaries. Compiling locally on the target host produces a shared library\r\nthat matches the target's architecture, glibc version, and PAM headers exactly, avoiding compatibility issues that commonly\r\narise when deploying precompiled binaries across different Linux distributions.\r\nPAM inline-hook backdoor\r\nThe inline-hook PAM backdoor is a sophisticated, multi-function interception library that provides plaintext credential\r\nharvesting from every authentication event, a master password ( O$$f$QtYJK ) bypass, and silently logs outbound SSH\r\nsession data for lateral movement surveillance — all from a single shared object. The malware writes the source code to a\r\ntemporary file /tmp/.pam_src_XXXXXX , compiles it with gcc , producing pam_security.so , then installs it via\r\n/etc/ld.so.preload , ensuring it is loaded into every dynamically-linked process that starts on the system, and timestomps\r\nitself against the real pam_unix.so to defeat forensic timeline analysis.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 21 of 32\n\nFigure 14. PAM backdoor C source code\r\nThis module supports three actions:\r\nInstall: Compiles and installs the backdoor, registers it in /etc/ld.so.preload .\r\nUninstall: Removes the .so file and strips its entry from /etc/ld.so.preload .\r\nHarvest: Reads captured credentials from the log files, XOR-decrypts them, and sends them back to the C\u0026C.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 22 of 32\n\nWhen the module is installed, it intercepts the PAM authentication process to harvest plaintext credentials, XOR-encrypts\r\nand stores them in /var/log/.ICE-unix for SSH and /var/log/.Test-unix for SSH, SCP, SU, and sudo, which can be\r\nsent to the C\u0026C if the attacker performs a harvest action.\r\nPAM credential logger\r\nThe malware also supports a simpler PAM credentials logger, which is embedded as C source code. The malware writes the\r\nsource code to a temporary file /tmp/.pcs_XXXXXX , compiles it with gcc , producing /usr/lib/.libpam_cache.so , then\r\ninstalls it via /etc/ld.so.preload , ensuring it is loaded into every dynamically linked process that starts on the system. On\r\neach successful authentication, it extracts the service name, username, and authentication token and stores them in plaintext\r\nto /tmp/.pam_cache .\r\nFigure 15. QLNX PAM backdoor credentials logger.\r\nRootkit analysis\r\nUserland LD_PRELOAD rootkit\r\nQLNX includes a command handler for deploying a userspace rootkit through the Linux dynamic linker's LD_PRELOAD\r\nmechanism. Unlike the eBPF rootkit controller (which manages kernel-level BPF maps), this component operates entirely in\r\nuserspace by hijacking standard C library functions at the shared library level. The rootkit is not shipped as a pre-built\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 23 of 32\n\nbinary. Instead, QLNX carries the full C source code as embedded string literals and compiles it directly on the target using\r\nthe host's own gcc .\r\nBefore attempting installation, the handler checks two prerequisites: root privileges (required to write to\r\n/etc/ld.so.preload ) and the presence of gcc on the system. If either check fails, the command is rejected with a\r\ndescriptive error message.\r\nThe handler accepts three actions from the C\u0026C:\r\nAction\r\nID\r\nPurpose Details\r\n0 Install rootkit Generates C source, compiles to shared object, registers in /etc/ld.so.preload\r\n1\r\nRemove\r\nrootkit\r\nRemoves the .so file and cleans the /etc/ld.so.preload entry\r\n2 Status query\r\nReports whether the .so exists, whether /etc/ld.so.preload is configured, SELinux\r\nstate, and gcc availability\r\nTable 8. Command actions supported by the QLNX userland LD_PRELOAD rootkit handler\r\nInstallation process\r\nWhen the install action is received, the handler performs the following steps:\r\nCreates a temporary file via mkstemp(\"/tmp/.hide_src_XXXXXX\") and renames it with a .c extension.\r\nWrites the full rootkit C source code into the file using fprintf . The source is parameterized with the implant's\r\nown binary path, its current PID, and the names of files it needs to hide.\r\nForks a child process and invokes execlp(\"gcc\", \"gcc\", \"-shared\", \"-fPIC\", \"-Wl,-\r\nsoname,libsecurity_utils.so.1\", \"-o\", \"/usr/lib/libsecurity_utils.so.1\", \u003csource\u003e, \"-ldl\") to compile the\r\nshared object.\r\nDeletes the source file immediately after compilation.\r\nChecks whether /etc/ld.so.preload already contains an entry for libsecurity_utils.so.1 . If not, appends it.\r\nCopies the atime and mtime timestamps from /usr/lib/libc.so.6 onto the newly created .so file using\r\nutimensat , making the rootkit's file timestamps match the system's C library to avoid standing out during forensic\r\ninspection.\r\nRootkit hooks\r\nThe generated shared object intercepts eight libc functions using dlsym(RTLD_NEXT, ...) to resolve the original\r\nimplementations. When any of these functions is called with a path or name matching the rootkit's hidden list, it returns\r\nENOENT (file not found) or skips the entry, effectively making the target invisible to userland tools:\r\nHooked Function Effect\r\nreaddir /\r\nreaddir64\r\nSkips directory entries matching hidden file names or hidden PIDs (checked via\r\n/proc/PID/comm )\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 24 of 32\n\nstat / lstat Returns ENOENT for hidden paths\r\n__xstat / __lxstat Same as above (legacy glibc stat wrappers)\r\nopen Returns ENOENT for hidden paths\r\nfopen Returns NULL with ENOENT for hidden paths\r\naccess Returns ENOENT for hidden paths\r\nTable 9. libc functions hooked by the QLNX userland LD_PRELOAD rootkit and their effects.\r\nThe hidden names and paths are hardcoded into the generated source at compile time. They include the implant's own\r\nbinary, the rootkit .so file itself ( libsecurity_utils.so.1 ), the PAM backdoor module ( pam_security.so ), and the PAM\r\ncredential log files ( .ICE-unix and .Test-unix under /var/log/ ). The rootkit also hides the implant's own PID by\r\nreading /proc/PID/comm for each numeric directory entry and comparing it against the hidden process name.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 25 of 32\n\nFigure 16. QLNX LD_PRELOAD embedded C code\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 26 of 32\n\nBecause the rootkit is loaded via /etc/ld.so.preload , it is injected into every dynamically linked process on the system,\r\nincluding ls , find , stat , ps , and any other standard tools an administrator or forensic investigator might use.\r\neBPF rootkit controller\r\nQLNX includes a built-in command handler that acts as the userland controller for an eBPF-based rootkit. It is important to\r\nnote that this component does not contain the kernel-side eBPF program itself. Its role is limited to creating and managing\r\nBPF maps — kernel data structures designed to hold the list of items that should be hidden from the system. Upon receiving\r\ninstructions from the C\u0026C server, the implant leverages the Linux kernel's BPF subsystem to conceal processes, files, and\r\nnetwork ports from standard userland tools such as ps , ls , and netstat .\r\nBefore processing any hiding request, the handler performs three prerequisite checks:\r\nRoot check: Verifies that the implant is running with root privileges. If not, the command is rejected immediately.\r\nKernel version check: Parses the kernel release string and requires kernel 4.18 or higher, which is the minimum\r\nversion supporting the BPF map types used by this feature.\r\nBPF availability probe: Attempts a test BPF map creation syscall. If the call fails (for example, when BPF support is\r\ndisabled in the kernel configuration), the command is aborted.\r\nOnce all checks pass, the handler reads two fields from the incoming C\u0026C packet: an action ID (integer) and a string\r\nargument. The action ID determines the operation to perform:\r\nAction\r\nID\r\nPurpose Argument Details\r\n1 Hide a process PID Inserts the PID into a BPF hash map (up to 64 entries)\r\n2 Unhide a process PID Removes the PID from the same map\r\n3 Hide a file File path Inserts the path into a BPF LRU hash map (up to 64 entries)\r\n4 Unhide a file File path Removes the path from the file map\r\n5\r\nHide a network\r\nport\r\nPort\r\nnumber\r\nInserts the port into a BPF array map (up to 32 entries)\r\n6\r\nUnhide a network\r\nport\r\nPort\r\nnumber\r\nRemoves the port from the port map\r\n7 Hide a connection N/A\r\nNot implemented; returns a message indicating this feature is not yet\r\navailable\r\n8 Status query N/A\r\nReturns a JSON object listing kernel version, BPF availability, and\r\nhidden PIDs, files, and ports\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 27 of 32\n\nTable 10. Actions supported by the QLNX eBPF rootkit controller\r\nAfter each action, the handler sends a response packet back to the C\u0026C containing a success flag and a status message.\r\nFigure 17. QLNX ePBF rootkit controller internal\r\nQLNX credential theft\r\nWhen the C\u0026C operator triggers command 0x90 (credential harvest), QLNX executes a single routine that collects every\r\nsecret on the host in one sweep. It runs four specialized sub-harvesters back-to-back:\r\nThe first grabs SSH private keys ( id_rsa , id_ed25519 , id_ecdsa , id_dsa ), known_hosts , and\r\nauthorized_keys .\r\nThe second pulls login databases and cookies from Chrome, Chromium, and Firefox.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 28 of 32\n\nThe third walks a hardcoded table of developer and cloud config files including AWS credentials and config,\r\nKubernetes kubeconfig, Docker's config.json , Git credentials and gitconfig, NPM's .npmrc , PyPI's .pypirc ,\r\nGitHub CLI tokens from .config/gh/hosts.yml , HashiCorp Vault tokens, Terraform credentials, and any .env\r\nfile in the user's home directory.\r\nThe fourth reads /etc/shadow when running as root, along with shell history and additional token files. As a final\r\ntouch, it even captures the current X11 clipboard contents via xclip / xsel .\r\nEvery collected item is tagged with its category, application name, file path, and raw content, and exfiltrated to the C\u0026C\r\nserver.\r\nOn a typical developer workstation, this single command can: compromise entire cloud environments through stolen AWS\r\nand Kubernetes credentials; gain access to private source code repositories via Git and GitHub CLI tokens; hijack package\r\npublishing pipelines through NPM and PyPI auth tokens; and pivot laterally to every server in the user's SSH key chain. The\r\nbreadth of this harvest means that a single infected developer system can become the entry point for a full-scale supply chain\r\nor cloud infrastructure breach.\r\nFigure 18. QLNX steals credentials from victim system\r\nFiles of interest\r\nTables 11 and 12 list the persistent files and temporary files used by QLNX.\r\nPath Description\r\n/usr/lib/libsecurity_utils.so.1 LD_PRELOAD rootkit .so\r\n/usr/lib/.libpam_cache.so PAM credential hook .so\r\n/etc/ld.so.preload Modified (both .so paths appended)\r\n/tmp/.pam_cache Plaintext credential log\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 29 of 32\n\n/var/log/.Test-unix Hidden log file for captured SSH passwords\r\n/var/log/.ICE-unix Hidden log file for captured PAM passwords\r\n/tmp/.X\u003c8+digits\u003e-lock Single instance lock file (e.g., /tmp/.X12345678-lock )\r\n~/.config/systemd/user/quasar_linux.service Systemd user service persistence file\r\n~/.config/autostart/quasar_linux.desktop XDG autostart persistence file\r\n/etc/systemd/system/quasar_linux.service Systemd system service persistence file\r\n/etc/init.d/quasar_linux init.d script persistence file\r\nTable 11. Persistent files used\r\nPath Description\r\n/tmp/.hide_src_*.c LD_PRELOAD rootkit source\r\n/tmp/.pcs_* PAM hook source\r\n/tmp/.pam_src_* Temporary source file for PAM backdoor\r\nTable 12. Temporary files deleted after use\r\nConclusion\r\nThe QLNX implant was built for long-term stealth and credential theft. What makes it particularly dangerous is not any\r\nsingle feature, but how its capabilities chain together into a coherent attack workflow: arrive, erase from disk, persist\r\nthrough six redundant mechanisms, hide at both userspace and kernel level, and then harvest the credentials that matter\r\nmost.\r\nQLNX systematically targets the files that underpin modern software development and cloud infrastructure: .npmrc (NPM\r\nregistry tokens), .pypirc (PyPI upload keys), .git-credentials , .aws/credentials , .kube/config , and\r\n.docker/config.json . These are the keys to the software supply chain. A single compromised developer workstation could\r\ngive the attacker the ability to publish trojanized packages to NPM or PyPI, inject backdoors into container images, or pivot\r\nfrom a personal laptop into production cloud environments.\r\nThis is not a theoretical risk. The LiteLLM supply chain compromise in March 2026 followed exactly this pattern: stolen\r\ncredentials from one tool were used to trojanize a Python package with 3.4 million daily downloads. QLNX's capability set\r\nmaps directly to every step of that kill chain.\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 30 of 32\n\nThe combination of the rootkit, the PAM backdoor capable of silently intercepting plaintext passwords, and the P2P mesh\r\nnetwork allowing implants to relay through each other all compound the difficulty of detection and eradication.\r\nTrend Vision One customers are protected against the indicators of compromise documented in this analysis, with access to\r\nhunting queries, threat insights, and intelligence reports related to QLNX.\r\nProactive security with Trend Vision One™\r\nTrend Vision One™ is the only AI-powered enterprise cybersecurity platform that centralizes cyber risk exposure\r\nmanagement and security operations, delivering robust layered protection across on-premises, hybrid, and multi-cloud\r\nenvironments.\r\nTrend Vision One™ Network Security\r\n47135: HTTP: Backdoor.Linux.QLNX.A Runtime Detection\r\n47136: TCP: Backdoor.Linux.QLNX.A Runtime Detection\r\nTrend Vision One™ Threat Intelligence\r\nTo stay ahead of evolving threats, Trend customers can access Trend Vision One™ Threat Insightsopen on a new tab (opens\r\nin a new tab) which provides the latest insights from Trend Research on emerging threats and threat actors.\r\nTrend Vision One™ Threat Insights\r\nEmerging Threats: Quasar Linux (QLNX): Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM Backdoor, Credential Harvesting and More\r\nTrend Vision One™ Intelligence Reports (IOC Sweeping)\r\nQuasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM\r\nBackdoor, Credential Harvesting and More\r\nHunting queries\r\nTrend Vision One™ Search App\r\nTrend Vision One™ customers can use the Search App to match or hunt the malicious indicators mentioned in this blog post\r\nwith data in their environment.\r\nLinux Hunting query for QLNX:\r\n# Implant Binary Execution\r\neventSubId:(2 OR 5) AND processFilePath:“quasar-implant”\r\n# Mutex Lock File\r\nobjectFilePath:“/tmp/.X752e2ca1-lock”\r\n# LD_PRELOAD Rootkit Module\r\nobjectFilePath:“/usr/lib/libsecurity_utils.so.1”\r\n# Hidden SSH password log / Hidden PAM password log\r\nobjectFilePath:(“/var/log/.Test-unix” OR “/var/log/.ICE-unix”)\r\n# PAM Hook Source Dropper\r\neventSubId:(101 OR 103) AND objectFilePath:/\\/tmp\\/\\.pcs_[A-Za-z0-9]{6}/\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 31 of 32\n\n# PAM Hook Compilation Activity\r\nprocessFilePath:/.*\\/gcc/ AND processCmd:“-shared” AND processCmd:” “-fPIC”\r\nAND processCmd:“/usr/lib/.libpam_cache.so” AND processCmd:“-lpam”\r\nSHA256 File Name Detection\r\nea1d34b21b739a6bbf89b3f7e67978005cf7f3eda612cefc7eac1c8ead7c5545 Quasar-implant Backdoor.Linux.QLNX.A\r\n82DAA93219BA40A6E41CDF3174BA57EB5D3383D1CD805584E9954EB0200182A1 libsecurity_utils.so.1 Backdoor.Linux.QLNX.A.co\r\n42D0C420EB5FE181388F2E4F0B7D7C0D302971E7A06FDC1BEC481B68C8CCAE1F pam_security.so Backdoor.Linux.QLNX.A.co\r\nC99CF0DC1EF1057D713CB082ACAF42E4DF4656809C91741752BDDCAB39BBFACA hide_src_39ZzHo.c Backdoor.Linux.QLNX.A.co\r\nEA89CAAB82181881D971BE312412795051F6322B105C8B9D29CFB5729FAB8D33 pam_src_51YyC3.c Backdoor.Linux.QLNX.A.co\r\n417430b2d4ae8d005224a9ff5dcb4007d452338acbcbcbb62c4e8ed1a70552dd libpam_cache.so Backdoor.Linux.QLNX.A.co\r\nd55549d5655e2f202e215676f4bdb0994ea08a93d15ec4ded413f64cfa7facc8 pcs_a3kf9x.c Backdoor.Linux.QLNX.A.co\r\nSource: https://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nhttps://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html\r\nPage 32 of 32",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html"
	],
	"report_names": [
		"quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html"
	],
	"threat_actors": [],
	"ts_created_at": 1778033005,
	"ts_updated_at": 1778033032,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8d0ebd640cb6eca350f2d0d983a05cfbbad53141.pdf",
		"text": "https://archive.orkl.eu/8d0ebd640cb6eca350f2d0d983a05cfbbad53141.txt",
		"img": "https://archive.orkl.eu/8d0ebd640cb6eca350f2d0d983a05cfbbad53141.jpg"
	}
}