QLNX: bezplikowy linuxowy RAT ukierunkowany na skrytość, trwałość i kradzież poświadczeń

Wprowadzenie do problemu / definicja

QLNX, określany jako Quasar Linux RAT, to zaawansowany trojan zdalnego dostępu dla systemów Linux, zaprojektowany z myślą o długotrwałym ukryciu się w środowisku ofiary. Wyróżnia go architektura bezplikowa, uruchamianie z pamięci oraz szeroki zestaw funkcji obejmujących zdalne sterowanie hostem, keylogging, kradzież poświadczeń, tunelowanie ruchu i mechanizmy trwałości.

Szczególnie istotne jest ukierunkowanie tego zagrożenia na stacje robocze deweloperów oraz środowiska DevOps. Kompromitacja jednego hosta w takim otoczeniu może otworzyć drogę do naruszenia repozytoriów kodu, systemów CI/CD oraz poufnych sekretów używanych w infrastrukturze chmurowej.

W skrócie

QLNX to nowo opisany implant dla Linuksa, który działa z pamięci RAM i minimalizuje ślady pozostawiane na dysku. Malware wykorzystuje wiele kanałów komunikacji z serwerem C2, obsługuje szyfrowane połączenia TLS, potrafi ukrywać procesy i artefakty zarówno w przestrzeni użytkownika, jak i bliżej jądra systemu, a także wdraża kilka równoległych metod utrzymania dostępu po restarcie.

• działa w modelu bezplikowym i uruchamia się z pamięci,
• wspiera zdalne sterowanie, keylogging i kradzież danych,
• wykorzystuje mechanizmy ukrywania aktywności, w tym LD_PRELOAD i eBPF,
• stosuje wielowarstwową trwałość poprzez systemd, cron, autostart i biblioteki współdzielone,
• celuje w poświadczenia deweloperskie, klucze SSH i tokeny chmurowe.

Kontekst / historia

W ostatnich latach Linux stał się jednym z głównych celów operacji wymierzonych w zespoły inżynierskie, środowiska chmurowe oraz platformy automatyzacji. To właśnie na linuksowych stacjach roboczych i serwerach pomocniczych często znajdują się klucze SSH, tokeny do repozytoriów, dane uwierzytelniające do usług cloudowych, sekrety aplikacyjne oraz historia pracy administratorów i programistów.

QLNX wpisuje się w ten trend, ale wyróżnia się modularnym podejściem. Nie jest to prosty backdoor, lecz implant, który po uruchomieniu profiluje host i aktywuje tylko te funkcje, które są przydatne w danym środowisku. Oznacza to, że jego zachowanie może różnić się w zależności od poziomu uprawnień, konfiguracji systemu, dostępności narzędzi kompilacyjnych, obecności X11 czy wykrycia mechanizmów konteneryzacji.

Analiza techniczna

Najważniejszym elementem QLNX jest model wykonania bezplikowego. Po uruchomieniu próbka kopiuje siebie do obiektu działającego w pamięci z użyciem memfd_create, usuwa oryginalny artefakt binarny, a następnie ponownie uruchamia się bezpośrednio z pamięci z wykorzystaniem execveat lub mechanizmu opartego na ścieżkach procfs. Taki schemat znacząco utrudnia analizę opartą na artefaktach dyskowych.

Po inicjalizacji implant przeprowadza lokalny rekonesans. Sprawdza między innymi poziom uprawnień, wersję jądra, konfigurację SELinux, obecność kompilatora gcc, możliwość przechwytywania wejścia z klawiatury, dostęp do X11 oraz warunki wdrożenia komponentów odpowiedzialnych za ukrywanie aktywności. Na tej podstawie dobierane są aktywne moduły operacyjne.

Warstwa ukrywania została zaprojektowana wielopoziomowo. QLNX może podszywać się pod legalne wątki systemowe, modyfikować metadane procesu widoczne w narzędziach administracyjnych i czyścić wybrane artefakty środowiskowe. Istotnym komponentem jest rootkit działający w przestrzeni użytkownika przez LD_PRELOAD, który przechwytuje funkcje biblioteczne w celu ukrywania procesów, plików i binariów. W bardziej zaawansowanym wariancie opisywany jest również komponent eBPF, zdolny do manipulowania widocznością procesów, plików i portów na poziomie bliższym jądru systemu.

Komunikacja z infrastrukturą dowodzenia i kontroli obsługuje trzy tryby: surowy TCP, HTTPS oraz HTTP. W wariantach TCP/TLS i HTTPS ruch jest chroniony przez TLS, choć wyłączona walidacja certyfikatów upraszcza zestawianie połączeń operatorowi ataku. Po rejestracji hosta malware utrzymuje cykl odbioru poleceń, ich lokalnego wykonania i odsyłania wyników do serwera C2.

Zakres poleceń dostępnych dla operatora jest szeroki i obejmuje zdalną powłokę, zarządzanie plikami, keylogging, wykonywanie zrzutów ekranu, przekierowania portów, proxy SOCKS, tunelowanie sieciowe, iniekcję kodu oraz czyszczenie logów. To zestaw typowy dla dojrzałych narzędzi post-exploitation, ale w przypadku QLNX jego siła wynika ze ścisłego połączenia z mechanizmami trwałości i ukrywania obecności.

Persistence należy do najmocniejszych elementów implantu. Opisano kilka metod utrzymania dostępu, w tym usługi systemd, zadania cron, skrypty startowe, wpisy autostartu XDG oraz infekcję opartą na LD_PRELOAD. Szczególnie groźny jest ostatni wariant, ponieważ pozwala wstrzykiwać przygotowaną bibliotekę współdzieloną do wszystkich dynamicznie linkowanych procesów, co może skutkować ponownym odtworzeniem aktywności malware nawet podczas rutynowych działań administracyjnych.

Krytycznym komponentem jest także backdoor PAM. Malware zawiera osadzony kod źródłowy modułów, które mogą zostać skompilowane bezpośrednio na hoście ofiary przy użyciu lokalnego gcc. Umożliwia to przechwytywanie poświadczeń w postaci jawnej w trakcie procesu uwierzytelniania, co znacząco zwiększa ryzyko przejęcia kont uprzywilejowanych, serwisowych i administracyjnych.

Moduły kradzieży danych obejmują klucze SSH, historię powłoki, profile przeglądarki Firefox, tokeny chmurowe, poświadczenia deweloperskie, dane schowka i inne sekrety przechowywane lokalnie. W środowiskach inżynierskich taki zestaw pozwala przejść od pojedynczej infekcji do ruchu bocznego, przejęcia repozytoriów, uzyskania dostępu do pipeline’ów CI/CD oraz dalszej kompromitacji środowisk produkcyjnych.

Na uwagę zasługuje także funkcja P2P mesh. Zainfekowane hosty mogą tworzyć rozproszoną siatkę komunikacyjną, dzięki czemu zakłócenie części infrastruktury C2 nie musi oznaczać utraty kontroli nad kampanią. Taka architektura zwiększa odporność operacji i utrudnia pełną eradrykację zagrożenia w większych środowiskach.

Konsekwencje / ryzyko

QLNX stanowi wysokie ryzyko dla organizacji utrzymujących zespoły programistyczne, administracyjne i chmurowe pracujące na Linuksie. Najpoważniejszym skutkiem nie jest sam zdalny dostęp, lecz możliwość połączenia wielu technik w jeden spójny łańcuch ataku: ukrycia obecności, przejęcia poświadczeń, utrzymania dostępu, ruchu bocznego i dalszej eskalacji.

• przejęcie kont uprzywilejowanych i serwisowych,
• kompromitacja kluczy SSH oraz tokenów dostępowych,
• naruszenie repozytoriów kodu i pipeline’ów build/deploy,
• osadzenie trwałych mechanizmów ponownej infekcji,
• utrudnienie analizy śledczej przez brak artefaktów dyskowych i czyszczenie logów,
• częściowa niewidoczność aktywności dzięki rootkitowi i eBPF,
• utrzymanie łączności nawet po zakłóceniu centralnego C2.

Z perspektywy łańcucha dostaw oznacza to, że pojedynczy zainfekowany host deweloperski może stać się punktem wejścia do modyfikacji artefaktów wdrożeniowych, kradzieży sekretów automatyzacji lub przejęcia procesów związanych z publikacją oprogramowania.

Rekomendacje

Organizacje powinny traktować ochronę linuksowych stacji roboczych deweloperów i serwerów pomocniczych jako priorytet równorzędny z ochroną systemów produkcyjnych. W praktyce oznacza to potrzebę rozbudowy monitoringu behawioralnego, kontroli integralności oraz ochrony poświadczeń wysokiej wartości.

• ograniczyć możliwość lokalnej kompilacji i uruchamiania nieautoryzowanych binariów tam, gdzie nie jest to konieczne,
• monitorować użycie memfd_create, execveat, wykonania procesów z przestrzeni procfs oraz nietypowe wykorzystanie LD_PRELOAD i /etc/ld.so.preload,
• objąć ścisłym nadzorem mechanizmy trwałości w Linuksie, takie jak systemd, cron, skrypty init, autostart XDG i modyfikacje PAM,
• regularnie kontrolować integralność stosu uwierzytelniania PAM oraz konfiguracji odpowiedzialnej za ładowanie bibliotek dynamicznych,
• wzmacniać ochronę sekretów deweloperskich przez MFA, krótkotrwałe tokeny, rotację kluczy SSH i ograniczanie lokalnego przechowywania wrażliwych danych,
• rozbudować detekcję o zachowania sieciowe, w tym nietypowe połączenia wychodzące, beaconing, tunelowanie i nagłe uruchomienie funkcji proxy.

W przypadku podejrzenia infekcji wskazane jest natychmiastowe odłączenie hosta od sieci, pozyskanie obrazu pamięci, analiza artefaktów uruchomieniowych i konfiguracji systemu, przegląd zmian w PAM oraz mechanizmach LD_PRELOAD, a następnie pełna rotacja poświadczeń, zwłaszcza kluczy SSH, kont uprzywilejowanych i tokenów wykorzystywanych w CI/CD oraz chmurze.

Podsumowanie

QLNX to przykład nowoczesnego linuxowego implantu, który łączy bezplikowe wykonanie, zaawansowane ukrywanie aktywności, przechwytywanie poświadczeń i wielowarstwową trwałość. Jego znaczenie wykracza poza pojedynczy incydent malware, ponieważ uderza w samo centrum współczesnego łańcucha dostaw oprogramowania: stacje robocze deweloperów, systemy automatyzacji i sekrety dostępowe do środowisk produkcyjnych.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że monitoring Linuksa musi obejmować nie tylko klasyczne wskaźniki kompromitacji, lecz przede wszystkim zachowania pamięciowe, manipulacje mechanizmami ładowania bibliotek, integralność PAM oraz ochronę poświadczeń o wysokiej wartości.

Źródła

1. Quasar Linux RAT (QLNX): A Fileless Linux Implant Built for Stealth and Persistence — https://securityaffairs.com/191898/malware/quasar-linux-rat-qlnx-a-fileless-linux-implant-built-for-stealth-and-persistence.html
2. Trend Micro report on Quasar Linux RAT (QLNX) — https://www.trendmicro.com/