Trend Micro ha scoperto nel maggio 2026 un RAT Linux precedentemente non documentato, denominato QLNX, progettato per infiltrarsi silenziosamente nelle workstation di sviluppatori e operatori DevOps. L'obiettivo non è il furto di dati classici, ma l'acquisizione delle chiavi di accesso ai sistemi di pubblicazione software: token npm e PyPI, credenziali cloud, chiavi SSH e configurazioni Kubernetes. Da queste posizioni, un attaccante può inserire backdoor in pacchetti pubblici, compromettere pipeline CI/CD e muoversi verso ambienti di produzione. La scoperta, pubblicata il 4 maggio 2026 dai ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim, rappresenta uno dei più completi esempi di malware orientato alla supply chain mai osservato su piattaforma Linux.
- QLNX esegue in modalità fileless tramite memfd_create e execveat, eliminando il binario originale dal disco subito dopo l'infezione
- L'architettura di occultamento è dual-tier: un rootkit LD_PRELOAD in userspace intercetta chiamate a readdir, stat, open e fopen, mentre un modulo eBPF a livello kernel nasconde PID, file e porte TCP
- Un backdoor PAM con master password hardcoded 'O$$f$QtYJK' cattura credenziali in chiaro e le memorizza con XOR encryption in /var/log/.ICE-unix
- Il modulo di furto prende di mira file specifici dello sviluppo software: .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, Terraform credentials, GitHub CLI tokens e file .env
Come QLNX scompare dal disco e resiste alla bonifica
La prima fase di QLNX è l'esecuzione fileless. Il malware si copia in un file descriptor anonimo in RAM mediante memfd_create, cancella il binario originale con unlink, e verifica la propria condizione tramite readlink su /proc/self/exe cercando le sottostringhe 'memfd:' o '(deleted)'. Questa tecnica elimina la traccia forense più elementare: il file eseguibile sul filesystem.
La persistenza è polimorfica e ridondante. Trend Micro documenta almeno 7 meccanismi: servizi systemd a livello sistema e utente, crontab con direttiva @reboot, script init.d, file .desktop XDG autostart, bootstrap tramite LD_PRELOAD con libreria condivisa .so, e iniezione in .bashrc. Questa sovrapposizione garantisce che la compromissione sopravviva a bonifiche parziali: rimuovere un meccanismo non neutralizza gli altri.
Il malware maschera i propri processi come thread kernel, assumendo nomi come kworker o ksoftirqd. Questa scelta non è estetica: strumenti di monitoring comuni filtrano o aggregano i thread kernel come noise, riducendo la visibilità operativa su attività anomale.
L'architettura rootkit che rende invisibile persino agli strumenti più comuni
QLNX implementa un'architettura di occultamento a due livelli descritta esplicitamente da Trend Micro come "Two-tier rootkit architecture". Il primo livello opera in userspace tramite LD_PRELOAD: una libreria condivisa intercetta le chiamate di sistema readdir, stat, open e fopen, filtrando le voci relative ai file, ai processi e alle connessioni di rete del malware. Il secondo livello scende nel kernel mediante eBPF, manipolando mappe che nascondono PID specifici, nomi di file e porte TCP aperte.
La combinazione è rara nel panorama Linux contemporaneo. La maggior parte dei rootkit commerciali o open source si ferma al livello userspace; l'aggiunta di eBPF fornisce resilienza contro strumenti che ignorano LD_PRELOAD o eseguono query kernel dirette. La compilazione dinamica on-target è un altro tratto distintivo: QLNX incorpora codice sorgente C embedded per il rootkit LD_PRELOAD e il backdoor PAM, compilandoli con gcc direttamente sulla macchina vittima prima del deployment via /etc/ld.so.preload. Questo adattamento contestuale evita la distribuzione di binari precompilati che potrebbero essere rilevati per firma.
Il furto mirato di credenziali DevOps e il pivoting verso la supply chain
Il modulo di credential harvesting di QLNX non è generico: è progettato per riconoscere e estrarre credenziali da file specifici dell'ecosistema di sviluppo software. L'elenco documentato da Trend Micro include .npmrc per il registro npm, .pypirc per PyPI, .git-credentials per repository Git, .aws/credentials per Amazon Web Services, .kube/config per cluster Kubernetes, .docker/config.json per registri container, .vault-token per HashiCorp Vault, file Terraform, token GitHub CLI e configurazioni .env.
L'obiettivo operativo è chiaro: con queste credenziali, un attaccante può pubblicare versioni compromesse di pacchetti software ampiamente utilizzati, inserire backdoor in artefatti di build automatizzati, o muoversi lateralmente da ambienti di sviluppo a infrastrutture di produzione. Il contesto settoriale fornisce una scala di riferimento: pacchetti come Axios superano i 400 milioni di download mensili, secondo Hive Security. La compromissione delle credenziali di un singolo maintainer con accesso a repository così diffusi amplifica l'impatto da incidente singolo a catastrofe settoriale.
Il backdoor PAM completa il quadro con un meccanismo di accesso parallelo: inline hooking sul sistema di autenticazione Linux con master password hardcoded 'O$$f$QtYJK'. Le credenziali intercettate vengono memorizzate in /var/log/.ICE-unix con crittografia XOR, un percorso che mimetizza directory di sistema legittime e sfugge a controlli superficiali.
"QLNX targets developers and DevOps credentials across the software supply chain" — Trend Micro researchers Aliakbar Zahravi e Ahmed Mohamed Ibrahim, citati da The Hacker News
La rete P2P mesh che complica l'eradicazione e il rilevamento
QLNX integra capacità di networking peer-to-peer con routing table per relay agent-to-agent del comando e controllo. Questa architettura P2P mesh elimina la dipendenza da server C&C centralizzati: ogni nodo compromesso può fungere da relay per gli altri, rendendo inefficaci le tecniche di blacklisting IP e complicando l'analisi dell'infrastruttura sottostante. La rete rimane operativa anche se singoli nodi vengono isolati o bonificati.
Il RAT supporta 58 comandi distinti per il controllo remoto completo della macchina compromessa, secondo quanto riportato da The Hacker News citando Trend Micro. Questa granularità permette operazioni che vanno dal semplice esfiltrazione di file alla manipolazione del sistema in tempo reale, senza necessità di strumenti aggiuntivi.
Cosa fare adesso
- Verificare la presenza degli hash SHA256 ea1d34b21b739a6bbf89b3f7e67978005cf7f3eda612cefc7eac1c8ead7c5545 e SHA1 b0f2c668cbdd63a871c90592b6c93e931115872e negli ambienti di sviluppo Linux, attraverso i sistemi di rilevamento endpoint
- Monitorare l'accesso a file credenziali da parte di processi non interattivi, con particolare attenzione a .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, token GitHub CLI e file .env
- Ispezionare le configurazioni di persistenza multipla: servizi systemd utente e sistema, crontab @reboot, init.d, XDG autostart, /etc/ld.so.preload e .bashrc, cercando anomalie nei percorsi e nei nomi dei binari
- Utilizzare Trend Vision One per il rilevamento e il blocco degli IoC specifici documentati nel report Trend Micro, verificando che la piattaforma sia configurata per rilevare occultamento tramite eBPF e mascheramento di processi come thread kernel
I limiti del dossier e i punti ancora da verificare
Trend Micro non specifica il vettore di infezione iniziale di QLNX. Non emerge come il malware raggiunga la prima macchina compromessa: phishing, supply chain precedente, accesso iniziale tramite credenziali esposte o altre tecniche rimangono non documentati. L'attribuzione a un gruppo threat actor specifico è altrettanto assente: nessuna sovrapposizione infrastrutturale con campagne note viene dichiarata nelle fonti primarie.
La scala dell'infezione reale non è quantificata. Non è chiaro se QLNX sia stato osservato in-the-wild su larga scala, se il campione analizzato rappresenti un'unica osservazione o una campagna attiva. La geografia delle vittime e il periodo di attività precedente alla scoperta del 4 maggio 2026 non sono riportati. Non è inoltre documentata l'esistenza di patch o mitigazioni specifiche oltre al rilevamento IoC: il brief non elenca aggiornamenti di sicurezza da applicare per eliminare vulnerabilità sfruttate dal malware.
La relazione con il RAT Quasar esistente per Windows non è stabilita. Nonostante la denominazione, nessuna evidenza di relazione codice o famiglia malware è riportata nelle fonti analizzate.
QLNX rappresenta un'evoluzione significativa nella minaccia alla supply chain software: non attacca i repository direttamente, ma le workstation che li alimentano. La combinazione di persistenza estrema, occultamento kernel e furto mirato di credenziali DevOps richiede un ripensamento delle difese, spostando il focus dal rilevamento di malware su disco al monitoraggio comportamentale dei processi che toccano i segreti dello sviluppo. La domanda non è più se un ambiente di sviluppo sia compromesso, ma se si sia in grado di rilevarlo prima che le credenziali finiscano in un pacchetto distribuito a milioni di installazioni.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://www.trendmicro.com/tr_tr/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html
- https://www.trendmicro.com/en_us/research/26/e/quasar-linux-qlnx-a-silent-foothold-in-the-software-supply-chain.html
- https://thehackernews.com/2026/05/quasar-linux-rat-steals-developer.html
- https://socprime.com/active-threats/qlnx-linux-rat-uses-rootkit-and-pam-backdoor/
- https://hivesecurity.gitlab.io/blog/quasar-linux-qlnx-supply-chain-rat/
- https://hivesecurity.gitlab.io/blog/github-npm-staged-publishing-supply-chain-defense-2026/
- https://hivesecurity.gitlab.io/blog/npm-supply-chain-attack-axios-teamcp-2026/
- https://hivesecurity.gitlab.io/blog/shai-hulud-github-actions-supply-chain-attack/
- https://hivesecurity.gitlab.io/blog/rapid-compromise-triage-linux-windows/
- https://hivesecurity.gitlab.io/blog/linux-privilege-escalation-attack-detect-2026/