A Fileless Linux Implant Built for Stealth and Persistence


Quasar Linux RAT (QLNX): A Fileless Linux Implant Built for Stealth and Persistence

Pierluigi Paganini
May 09, 2026

Researchers uncovered QLNX, a Linux RAT targeting developers to steal credentials, log keystrokes, monitor systems, and enable remote access.

Security researchers discovered a previously undocumented Linux malware called Quasar Linux RAT (QLNX) that targets developers and DevOps environments. The malicious code can steal credentials, log keystrokes, manipulate files, monitor clipboard activity, and create network tunnels for remote access. Experts warn it poses a serious supply chain risk by targeting systems used in software development workflows.

“Quasar Linux RAT (QLNX) is a comprehensive Linux implant that combines remote access capabilities with advanced evasion, persistence, keylogging, and credential harvesting features. The malware carries embedded C source code for both its PAM backdoor and LD_PRELOAD rootkit as string literals within the binary.” reads the report published by Trend Micro. “It dynamically compiles rootkit shared objects and PAM backdoor modules on the target host using gcc, then deploys them via /etc/ld.so.preload for system-wide interception.”

QLNX is a powerful Linux remote access trojan that runs directly from memory to avoid detection, hides its activity using eBPF, wipes logs, and checks whether it is running inside containerized environments. It collects extensive information, including system details, clipboard data, shell history, SSH keys, Firefox profiles, and credentials through a malicious PAM module.

QLNX communicates with attackers through encrypted channels and supports a wide range of commands, including remote shell access, file management, code injection, screenshot capture, keylogging, SOCKS proxies, and network tunneling. The malware also includes several persistence methods, allowing it to survive reboots and maintain long-term access to infected Linux systems.

QLNX is a sophisticated Linux malware designed to operate entirely from memory and avoid leaving traces on disk. After execution, it copies itself into a RAM-backed file using memfd_create, deletes the original binary, and re-launches directly from memory using execveat or /proc/self/fd/<memfd> as a fallback. It uses the _MFD_RE environment variable to prevent infinite re-execution loops.

The malware then profiles the infected system, checking privileges, kernel version, SELinux status, containerization, GCC availability, X11 access, and support for process injection or keylogging. Based on these results, it selectively enables capabilities.

To evade detection, QLNX disguises itself as legitimate kernel threads such as [kworker/0:0] and rewrites process metadata visible in ps, top, and /proc. It also removes forensic environment variables and prevents multiple instances by creating a fake X11 lock file in /tmp.

Once established, QLNX initializes 58 command handlers and connects to its C2 server over a custom TLS-based protocol, HTTPS, or HTTP. It sends a beacon containing system details, privilege level, geolocation, machine fingerprint, hostname, and network data. The malware supports extensive post-compromise functions including shell access, file management, persistence, credential theft, SSH lateral movement, screenshots, keylogging, rootkits, SOCKS proxies, port forwarding, log wiping, PAM credential hooks, eBPF hiding, and in-memory BOF execution.

QLNX supports three communication channels, raw TCP, HTTPS, and HTTP, all carrying the same binary command protocol. TCP and HTTPS are protected with TLS, while HTTP is used in plaintext during analysis or fallback scenarios.

Every session begins with the 4-byte magic value “QLNX” (0x51 4C 4E 58), which identifies and initializes the protocol. In TCP/TLS mode, it is embedded in the initial check-in packet; in HTTPS/HTTP, it is sent as a standalone payload or encoded in requests. After this, the server responds with session state data (e.g., cookies or IDs).

In the default raw TLS mode, QLNX uses a custom length-prefixed binary protocol after disabling certificate validation. A four-step handshake precedes full bidirectional communication, after which a persistent command loop is established.

For HTTP/HTTPS, the malware uses POST requests to send Base64-encoded data and GET requests to poll for commands every five seconds. Session tracking relies on a server-generated hex ID passed via URL and cookies. Before contacting the C2, it queries ip-api.com to obtain geolocation data, which is included in the initial registration packet alongside a machine fingerprint derived from system identifiers.

After registration, the server issues ACK and confirmation packets before enabling command execution. If no commands are available, responses remain empty; otherwise, Base64-encoded payloads are decoded, dispatched via a handler table, executed locally, and results are returned to the C2.

The persistence subsystem includes seven mechanisms such as systemd services, cron jobs, init scripts, XDG autostart entries, and LD_PRELOAD-based injection. Artifacts are tagged with “QLNX_MANAGED” for tracking.

LD_PRELOAD persistence is particularly aggressive: a compiled shared library is injected into all dynamically linked processes, ensuring reinfection on any program execution. Even basic commands like ls or ps can respawn the malware if the preload entry remains.

QLNX also implements two PAM backdoors that compile on the target system, enabling credential harvesting and authentication interception. Logs are stored in hidden files and optionally exfiltrated.

“QLNX incorporates a PAM backdoor with inline hooking, enabling plaintext credential interception during authentication. It uses the hardcoded master password O$$f$QtYJK and XOR-encrypted credential harvesting to /var/log/.ICE-unix.” cotinues the report.

A userland rootkit hides files, processes, and binaries by hooking libc functions via LD_PRELOAD, while an optional eBPF controller manipulates kernel maps to hide processes, files, and ports at kernel level.

Finally, a credential-stealing module extracts SSH keys, browser data, cloud tokens, developer credentials, system secrets, and clipboard content, enabling full compromise of development and cloud environments.

QLNX includes a peer-to-peer (P2P) mesh feature that links infected hosts together, turning individual implants into a distributed network. This design increases resilience because the malware can maintain communication and coordination even if parts of its command infrastructure are disrupted, making full removal from an environment significantly more difficult.

“The QLNX implant was built for long-term stealth and credential theft. What makes it particularly dangerous is not any single feature, but how its capabilities chain together into a coherent attack workflow: arrive, erase from disk, persist through six redundant mechanisms, hide at both userspace and kernel level, and then harvest the credentials that matter most.” concludes the report. “The combination of the rootkit, the PAM backdoor capable of silently intercepting plaintext passwords, and the P2P mesh network allowing implants to relay through each other all compound the difficulty of detection and eradication.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)







Source link

Leave a Reply

Subscribe to Our Newsletter

Get our latest articles delivered straight to your inbox. No spam, we promise.

Recent Reviews


Vibe coding has taken the development world by storm—and it truly is a modern marvel to behold. The problem is, the vibe coding rush is going to leave a lot of apps broken in its wake once people move on to the next craze. At the end of the day, many of us are going to be left with apps that are broken with no fixes in sight.

A lot of vibe “coders” are really just prompt typers

And they’ve never touched a line of code

An AI robot using a computer with a prompt field on the screen. Credit: Lucas Gouveia / How-To Geek

Vibe coding made development available to the masses like never before. You can simply take an AI tool, type a prompt into a text box, and out pops an app. It probably needs some refinement, but, typically, version one is still functional whenever you’re vibe coding.

The problem comes from “developers” who have never written a line of code. They’re just using vibe coding because it’s cool or they think they can make a quick buck, but they really have no knowledge of development—or any desire to learn proper development.

Think of those types of vibe coders as people who realize they can use a calculator and online tools to solve math problems for them, so they try to build a rocket. They might be able to make something work in some way, but they’ll never reach the moon, even though they think they can.

Anyone can vibe code a prototype

But you really need to know what you’re doing to build for the long haul

For those who don’t know what they’re doing, vibe coding is a fantastic way to build a prototype. I’ve vibe coded several projects so far, and out of everything I’ve done, I’ve realized one thing—vibe coding is only as good as the person behind the keyboard. I have spent more time debugging the fruits of my vibe coding than I have actually vibe coding.

Each project that I’ve built with vibe coding could have easily been “viable” within an hour or two, sometimes even less time than that. But, to make something of actual quality, it has always taken many, many hours.

Vibe coding is definitely faster than traditional coding if you’re a one-man team, but it’s not something that is fast by any means if you’re after a quality product. The same goes for continued updates.

I’ve spent the better part of three months building a weather app for iPhone. It’s a simple app, but it also has quite a lot of complex things going on in the background.

It recently got released in the App Store—no small feat at all. But, I still get a few crash reports a week, and I’m constantly squashing bugs and working on new features for the app. This is because I’m planning on supporting the app for a long time, not just the weekend I released it, and that takes a lot more work.

Vibe coders often jump from app to app without thinking of longevity

The app was a weekend project, after all

A relaxed man lounging on an orange beanbag watches as a friendly yellow robot works on a laptop for him, while multiple red exclamation-mark warning icons float around them. Credit: Lucas Gouveia/How-To Geek | ViDI Studio/Shutterstock

I’ve seen it far too often, a vibe coder touting that they built this “complex app” in 48 hours, as if that is something to be celebrated. Sure, it’s cool that a working version of an app was up and running in two days, but how well does it work? How many bugs are still in it? Are there race conditions that cause a random crash?

My weather app has a weird race condition right now I’m tracking down. It crashes, on occasion, when opened from Spotlight on an iPhone. Not every time does that cause a crash, just sometimes.

If a vibe coder’s only goal is to build apps in short amounts of time so they can brag about how fast they built the app, they likely aren’t going to take the time to fix little things like that.

I don’t vibe code my apps that way, and I know many other vibe coders that aren’t that way—but we all started with actual coding, not typing a prompt.


Anyone can be a vibe coder, but not all vibe coders are developers

“And when everyone’s super… no one will be.” – Syndrome, The Incredibles. It might be from a kids’ movie, but it rings true in the era of vibe coding. When everyone thinks they can build an app in a weekend, everyone thinks they’re a developer.

By contrast, not every vibe coder is actually a developer, and that’s the problem. It’s hard to know if the app you’re using was built by someone who has plans to support the app long-term or not—and that’s why there’s going to be a lot of broken apps in the future.

I can see it now, the apps that people built in a weekend as a challenge will simply go without updates. While the app might work for the first few weeks or months just fine, an API update comes along and breaks the app’s compatibility. It’s at that point we’ll see who was vibe coding to build an app versus who was vibe coding just for online clout—and the sad part is, consumers will lose out more often than not with broken apps.



Source link