Tag: Linux

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/

Wprowadzenie do problemu / definicja

PCPJack to nowo opisana rodzina złośliwego oprogramowania wymierzona w aplikacje webowe oraz środowiska chmurowe i kontenerowe. Jej szczególnie niebezpieczną cechą jest połączenie klasycznej kradzieży poświadczeń z usuwaniem artefaktów pozostawionych przez wcześniejsze infekcje powiązane z TeamPCP.

Taki model działania może wskazywać na konflikt między aktorami zagrożeń, próbę przejęcia już skompromitowanej infrastruktury albo wykorzystanie cudzej operacji jako punktu wejścia do własnej kampanii. Z perspektywy obrońców oznacza to bardziej złożone dochodzenia i większe ryzyko utraty kontroli nad środowiskiem.

W skrócie

• PCPJack jest aktywny co najmniej od końca kwietnia 2026 roku.
• Malware startuje od skryptu shell dla Linuksa, który przygotowuje host, usuwa ślady TeamPCP i pobiera kolejne moduły.
• Zagrożenie kradnie poświadczenia, tokeny, klucze SSH, pliki konfiguracyjne i dane z usług chmurowych oraz SaaS.
• Framework wspiera ruch lateralny, rozpoznanie środowiska i samodzielne rozprzestrzenianie się.
• Atak szczególnie zagraża organizacjom korzystającym z lokalnie przechowywanych sekretów i słabo kontrolowanych środowisk kontenerowych.

Kontekst / historia

Analiza kampanii sugeruje, że PCPJack działa w środowiskach wcześniej atakowanych przez TeamPCP, grupę kojarzoną z operacjami wymierzonymi w ekosystem open source i infrastrukturę developerską. Zakres zainteresowania nowego malware jest zbliżony do wcześniejszych działań przypisywanych TeamPCP oraz PCPCat, co może oznaczać wykorzystanie podobnej wiedzy operacyjnej i znajomości tych samych celów.

To ważna zmiana w krajobrazie zagrożeń. Zainfekowane wcześniej systemy nie są już wyłącznie końcowym celem eksfiltracji danych, ale stają się zasobem, który może zostać przejęty przez kolejnych napastników. W praktyce prowadzi to do szybszego nadpisywania śladów, większej zmienności artefaktów i trudniejszego ustalania pełnego przebiegu incydentu.

Analiza techniczna

Łańcuch infekcji rozpoczyna się od skryptu shell dla systemów Linux. Jego zadaniem jest sprawdzenie hosta pod kątem procesów i artefaktów związanych z TeamPCP, a następnie ich usunięcie. Po tej fazie malware tworzy środowisko Python virtualenv, pobiera zestaw dodatkowych modułów, zmienia ich nazwy, ustanawia mechanizmy trwałości, uruchamia główny komponent sterujący i usuwa skrypt początkowy, aby ograniczyć ilość dowodów na systemie.

Architektura PCPJack ma charakter modułowy. Poszczególne komponenty odpowiadają za kradzież poświadczeń, rozpoznanie środowiska, ruch lateralny, szyfrowanie komunikacji C2, identyfikację zakresów chmurowych oraz skanowanie kolejnych celów. Taki podział zwiększa elastyczność frameworka i ułatwia operatorom wymianę elementów bez przebudowy całego zestawu narzędzi.

W obszarze eksfiltracji PCPJack skupia się na danych o wysokiej wartości operacyjnej. Dotyczy to między innymi plików .env, lokalnych plików konfiguracyjnych, zmiennych środowiskowych, kluczy SSH, tokenów API, portfeli kryptowalutowych oraz danych dostępowych do usług takich jak AWS, Kubernetes, Docker, Gmail, GitHub, Office 365, Slack i WordPress. Tego rodzaju informacje często umożliwiają dalszą eskalację dostępu bez potrzeby łamania haseł.

Mechanizm propagacji wykorzystuje wiele ścieżek jednocześnie. Z jednej strony malware próbuje wykorzystywać znane podatności w aplikacjach webowych, panelach administracyjnych i popularnych komponentach. Z drugiej strony używa przejętych poświadczeń do przemieszczania się między środowiskami Kubernetes, Docker, Redis, RayML i MongoDB. Klucze SSH mogą następnie posłużyć do zdalnego uruchamiania skryptu startowego na kolejnych hostach. Komunikacja z infrastrukturą sterującą odbywa się przez Telegram i jest szyfrowana.

Badacze zauważyli także drugi zestaw narzędzi wiązany z tym samym aktorem, obejmujący implanty Sliver oraz dodatkowe mechanizmy kradzieży poświadczeń. Sugeruje to, że PCPJack nie jest prostym jednorazowym skryptem, lecz elementem większego i rozwijanego zaplecza operacyjnego.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem infekcji PCPJack jest przejęcie tożsamości w środowiskach wielochmurowych i hybrydowych. Kradzież kluczy, tokenów i sekretów aplikacyjnych może otworzyć napastnikom drogę do kont administracyjnych, pipeline’ów CI/CD, repozytoriów kodu, systemów komunikacji firmowej i zasobów kontenerowych.

Dla organizacji oznacza to wielowarstwowe ryzyko. Przejęte dane mogą zostać wykorzystane do dalszych włamań, oszustw finansowych, rozsyłania spamu, szantażu albo sprzedaży dostępu innym grupom. Dodatkowym problemem jest fakt, że PCPJack usuwa ślady wcześniejszych infekcji, co zaciera oś czasu zdarzeń i utrudnia przypisanie aktywności konkretnemu aktorowi.

Szczególnie narażone są podmioty, które przechowują sekrety lokalnie w plikach lub zmiennych środowiskowych, nie rotują poświadczeń po incydentach, wystawiają panele administracyjne do internetu albo polegają wyłącznie na segmentacji sieciowej bez ścisłej kontroli tożsamości hostów i workloadów.

Rekomendacje

W pierwszej kolejności warto zweryfikować serwery Linux pod kątem nietypowych skryptów startowych, nieautoryzowanych środowisk virtualenv, podejrzanych mechanizmów persistence oraz nieoczekiwanej komunikacji z usługami komunikatorowymi wykorzystywanymi jako kanał C2. Należy także sprawdzić, czy na hostach nie doszło do usuwania artefaktów wcześniejszych infekcji.

Kluczowe znaczenie ma pilna rotacja poświadczeń: kont chmurowych, kluczy SSH, tokenów API oraz sekretów aplikacyjnych zapisanych w plikach .env lub zmiennych środowiskowych. Samo oczyszczenie systemu bez wymiany danych uwierzytelniających nie zamyka ryzyka ponownego dostępu.

• Ograniczyć publiczną ekspozycję paneli administracyjnych i usług webowych.
• Priorytetowo łatać podatności w frameworkach, wtyczkach i komponentach aplikacyjnych.
• Przenieść sekrety do dedykowanych menedżerów zamiast przechowywać je lokalnie.
• Wzmocnić segmentację i kontrolę dostępu między hostami, klastrami i usługami danych.
• Monitorować użycie kluczy SSH oraz nietypowe połączenia między workloadami.
• Wdrożyć detekcję anomalii w dostępie do usług SaaS, IaaS i środowisk kontenerowych.
• Analizować logi chmurowe, kontenerowe i orkiestracyjne pod kątem ruchu lateralnego.

Z perspektywy SOC warto przygotować korelacje obejmujące utworzenie środowiska Python na serwerze produkcyjnym, pobranie wielu modułów z zewnętrznego źródła, szybkie usunięcie skryptu startowego, odczyt plików .env oraz równoległe próby uwierzytelnienia do wielu usług. Taki zestaw zdarzeń może pomóc wykryć PCPJack nawet bez pełnego zestawu wskaźników kompromitacji.

Podsumowanie

PCPJack reprezentuje rosnącą klasę wielofunkcyjnego malware dla środowisk chmurowych i kontenerowych. Łączy kradzież poświadczeń, ruch lateralny, automatyzację propagacji i przejmowanie już naruszonych hostów, przez co stanowi poważne zagrożenie dla nowoczesnych środowisk IT.

Najgroźniejszy aspekt tej kampanii nie ogranicza się do pojedynczej infekcji. Prawdziwe ryzyko polega na możliwości szybkiego przekształcenia jednego naruszenia w szerokie przejęcie tożsamości i zasobów całej organizacji. Ochrona sekretów aplikacyjnych, kluczy maszynowych i konfiguracji chmurowej powinna być dziś traktowana na równi z ochroną kont uprzywilejowanych.

Źródła

1. SecurityWeek – PCPJack Worm Removes TeamPCP Infections, Steals Credentials — https://www.securityweek.com/pcpjack-worm-removes-teampcp-infections-steals-credentials/
2. SentinelOne – PCPJack analysis — https://www.sentinelone.com/

Wprowadzenie do problemu / definicja

PamDOORa to nowo opisany backdoor dla systemów Linux, który wykorzystuje mechanizmy PAM do ingerencji w proces uwierzytelniania. Złośliwy moduł osadzony w tej warstwie może zapewniać napastnikowi trwały dostęp przez SSH, a jednocześnie przechwytywać dane logowania legalnych użytkowników.

Zagrożenie jest szczególnie poważne, ponieważ PAM znajduje się w krytycznej ścieżce autoryzacji i zwykle działa z wysokimi uprawnieniami. W efekcie kompromitacja tego komponentu podważa zaufanie do całego procesu logowania na serwerze.

W skrócie

PamDOORa jest oferowany jako narzędzie post-exploitation przeznaczone dla architektury x86_64. Po wdrożeniu modyfikuje zachowanie stosu PAM tak, aby operator mógł uzyskać ukryty dostęp do hosta przez OpenSSH przy użyciu specjalnego hasła i określonych parametrów połączenia.

• umożliwia trwały dostęp do serwera Linux przez SSH,
• przechwytuje nazwy użytkowników i hasła wpisywane podczas logowania,
• utrudnia analizę incydentu przez manipulację logami uwierzytelniania,
• działa jako implant wdrażany po wcześniejszym przejęciu uprawnień administracyjnych.

Kontekst / historia

Nadużywanie PAM jako mechanizmu trwałości i ukrytego dostępu nie jest nowym zjawiskiem, jednak w ostatnim czasie ten obszar wyraźnie zyskuje na popularności wśród cyberprzestępców. Dla napastników to atrakcyjna metoda, ponieważ pozwala ominąć część klasycznych mechanizmów detekcji skupionych na usługach systemowych, zadaniach startowych czy prostych modyfikacjach kluczy SSH.

PamDOORa wpisuje się w szerszy trend rozwoju implantów ukierunkowanych na systemy Linux, szczególnie te wykorzystywane jako serwery administracyjne, maszyny produkcyjne i hosty dostępne zdalnie przez SSH. W praktyce atakujący, który wcześniej uzyska prawa roota, może osadzić taki moduł w miejscu zapewniającym długotrwałą i trudną do wykrycia obecność.

Analiza techniczna

Pluggable Authentication Modules stanowią warstwę pośrednią wykorzystywaną przez usługi takie jak OpenSSH do realizacji uwierzytelniania. Każda zmiana w tej ścieżce bezpośrednio wpływa na to, czy system zaakceptuje, czy odrzuci próbę logowania.

PamDOORa działa jako implant postkompromisowy, a więc nie jest pierwotnym wektorem wejścia. Jego zadaniem jest utrwalenie dostępu po wcześniejszym przejęciu systemu. Po instalacji malware modyfikuje zachowanie procesu uwierzytelniania SSH w taki sposób, aby zaakceptować specjalnie przygotowaną próbę logowania, niezależnie od standardowej ścieżki autoryzacji.

Mechanizm aktywacji opiera się na użyciu tzw. magicznego hasła oraz określonego warunku sieciowego, opisywanego jako powiązanie z konkretnym portem TCP. Taki model zmniejsza ryzyko przypadkowego ujawnienia backdoora podczas rutynowych testów i sprawia, że złośliwa funkcja może pozostać niewidoczna przez dłuższy czas.

Drugim kluczowym elementem jest kradzież poświadczeń. Ponieważ PAM przetwarza dane uwierzytelniające w trakcie logowania, złośliwy moduł może przechwytywać nazwy użytkowników oraz hasła wpisywane przez administratorów i innych legalnych użytkowników. To otwiera drogę do dalszej eskalacji uprawnień, ruchu bocznego i utrzymania dostępu nawet po częściowym wykryciu incydentu.

Istotną cechą PamDOORa są również funkcje anti-forensics. Z dostępnych analiz wynika, że narzędzie potrafi zacierać lub usuwać ślady nieautoryzowanej aktywności w logach uwierzytelniania. W środowiskach, które nie eksportują logów do centralnego i odpornego na modyfikacje repozytorium, znacząco utrudnia to dochodzenie powłamaniowe.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją użycia PamDOORa jest utrata zaufania do lokalnego procesu uwierzytelniania. Jeśli warstwa PAM została zmodyfikowana, administrator nie może zakładać, że logi, wyniki logowania i kontrola dostępu odzwierciedlają rzeczywisty stan systemu.

• kradzież poświadczeń kont lokalnych i uprzywilejowanych,
• trwały dostęp do serwera przez SSH bez typowych artefaktów,
• możliwość dalszego ruchu bocznego z użyciem przejętych danych,
• utrudniona analiza incydentu z powodu manipulacji logami,
• ryzyko kompromitacji kolejnych systemów przy ponownym użyciu haseł.

Szczególnie narażone są organizacje utrzymujące dużą liczbę serwerów Linux dostępnych administracyjnie przez SSH, środowiska hybrydowe z rozproszonym zarządzaniem tożsamością oraz podmioty, które dopuszczają bezpośredni dostęp do kont uprzywilejowanych bez silnych mechanizmów kontroli i monitoringu integralności.

Rekomendacje

Obrona przed tego typu zagrożeniem wymaga traktowania integralności PAM jako zasobu krytycznego. Każda nieautoryzowana zmiana w bibliotekach modułów, konfiguracji PAM lub ustawieniach OpenSSH powinna być objęta monitoringiem i generować alert wysokiego priorytetu.

• ograniczyć i ściśle kontrolować użycie kont z uprawnieniami root,
• wymusić MFA tam, gdzie jest to technicznie możliwe, szczególnie dla dostępu administracyjnego,
• wdrożyć monitoring integralności plików dla ścieżek związanych z PAM i OpenSSH,
• centralizować logi w systemie odpornym na lokalne modyfikacje,
• regularnie audytować załadowane moduły PAM i ich sumy kontrolne,
• stosować zasadę najmniejszych uprawnień oraz segmentację dostępu administracyjnego,
• analizować anomalie logowań SSH i nietypowe sukcesy autoryzacji,
• przygotować procedury reagowania obejmujące pełną weryfikację zaufania do hosta.

W przypadku podejrzenia kompromitacji samo usunięcie złośliwego modułu nie powinno być uznawane za wystarczające. Jeśli napastnik miał wcześniej prawa roota, bezpieczniejszym podejściem jest odtworzenie systemu ze zweryfikowanego obrazu, rotacja wszystkich używanych poświadczeń oraz przegląd możliwej aktywności bocznej w całym środowisku.

Podsumowanie

PamDOORa pokazuje, że warstwa PAM pozostaje atrakcyjnym miejscem do ukrywania trwałych implantów w systemach Linux. Połączenie ukrytego dostępu przez SSH, kradzieży poświadczeń i manipulacji logami czyni z tego narzędzia poważne zagrożenie dla serwerów administracyjnych i środowisk produkcyjnych.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że detekcja nie może ograniczać się wyłącznie do klasycznych wskaźników kompromitacji. Szczególnym nadzorem należy objąć komponenty odpowiedzialne za uwierzytelnianie, integralność systemu i bezpieczeństwo ścieżek dostępu administracyjnego.

Źródła

1. The Hacker News — https://thehackernews.com/2026/05/new-linux-pamdoora-backdoor-uses-pam.html
2. Flare — Company News / Research references — https://flare.io/learn/news/company-news
3. Group-IB Blog — La dualidad del módulo de autenticación conectable (PAM) — https://www.group-ib.com/es/blog/
4. CyberMaterial — Linux PAM Abused to Create Backdoors — https://cybermaterial.com/linux-pam-abused-to-create-backdoors/

Wprowadzenie do problemu / definicja

Quasar Linux RAT, określany także jako QLNX, to zaawansowane złośliwe oprogramowanie wymierzone w systemy Linux używane przez deweloperów oraz zespoły DevOps. Jego celem jest długotrwałe, ukryte utrzymanie dostępu do hosta, kradzież poświadczeń oraz przejęcie narzędzi wykorzystywanych do budowy, testowania i publikacji oprogramowania.

To zagrożenie wykracza poza klasyczną kompromitację pojedynczej stacji roboczej. W praktyce może prowadzić do przejęcia repozytoriów kodu, rejestrów pakietów, środowisk chmurowych i pipeline’ów CI/CD, a więc uderzać bezpośrednio w łańcuch dostaw oprogramowania.

W skrócie

• QLNX to wcześniej nieudokumentowany implant dla Linuksa ukierunkowany na środowiska deweloperskie.
• Malware działa skrycie, stosuje techniki ukrywania procesów i usuwa ślady z logów.
• Głównym celem jest kradzież sekretów z plików konfiguracyjnych oraz narzędzi używanych przez programistów i administratorów.
• Po infekcji atakujący mogą wykonywać polecenia, przechwytywać dane logowania, tunelować ruch i rozwijać dostęp w infrastrukturze.
• Największe ryzyko dotyczy kompromitacji kont maintainerskich, systemów CI/CD oraz publikacji złośliwych pakietów.

Kontekst / historia

Środowiska deweloperskie od kilku lat znajdują się w centrum zainteresowania cyberprzestępców. Powód jest prosty: jedno przejęte konto programisty, token publikacyjny albo dostęp do automatyzacji wdrożeń może umożliwić dystrybucję złośliwego kodu do bardzo szerokiej grupy odbiorców.

QLNX wpisuje się w rosnący trend ataków supply chain, w których celem nie jest szybki sabotaż, ale cicha i systematyczna kompromitacja środowiska pracy dewelopera. Szczególnie niebezpieczne jest to, że malware koncentruje się na sekretach typowych dla nowoczesnego stacku developerskiego, obejmującego chmurę, kontenery, orkiestrację i automatyzację dostarczania oprogramowania.

Analiza techniczna

Z technicznego punktu widzenia Quasar Linux RAT łączy mechanizmy stealth, persistence i zdalnej administracji. Implant działa bezplikowo z pamięci, co utrudnia wykrycie przez narzędzia opierające się głównie na analizie artefaktów zapisanych na dysku. Dodatkowo może podszywać się pod procesy przypominające legalne wątki systemowe, aby zmniejszyć prawdopodobieństwo wzbudzenia podejrzeń.

Jednym z kluczowych elementów działania malware jest kradzież sekretów z plików o wysokiej wartości operacyjnej. Dotyczy to między innymi danych związanych z menedżerami pakietów, repozytoriami kodu, chmurą, Kubernetesem, Dockerem, Terraformem, Vaultem, plikami środowiskowymi oraz narzędziami CLI wykorzystywanymi do pracy z platformami deweloperskimi.

Po uzyskaniu łączności z serwerem dowodzenia implant oferuje szeroki zestaw funkcji post-exploitation. Operator może wykonywać polecenia powłoki, zarządzać plikami, prowadzić keylogging, monitorować schowek, wykonywać zrzuty ekranu, uruchamiać proxy SOCKS i tunele TCP oraz ładować dodatkowe moduły. Taki zakres możliwości daje praktycznie pełną kontrolę nad zainfekowanym hostem.

Na szczególną uwagę zasługuje przechwytywanie poświadczeń w czasie uwierzytelniania. Malware wykorzystuje mechanizmy powiązane z PAM do rejestrowania danych logowania, a dodatkowo monitoruje wychodzące sesje SSH. To zwiększa wartość operacyjną wykradzionych danych i ułatwia dalszy ruch boczny w organizacji.

Za ukrywanie obecności odpowiada architektura warstwowa. W przestrzeni użytkownika wykorzystywany jest mechanizm LD_PRELOAD do ukrywania procesów i artefaktów przed standardowymi narzędziami systemowymi. Równolegle możliwe jest stosowanie komponentu opartego na eBPF, który maskuje procesy, pliki i porty sieciowe na głębszym poziomie. Taki model znacznie utrudnia analizę incydentu.

QLNX stosuje również wiele metod utrzymywania dostępu. Należą do nich wpisy persistence w systemd, crontabie oraz modyfikacje plików startowych powłoki, takich jak .bashrc. Dodatkowo implant czyści logi systemowe, aby utrudnić rekonstrukcję osi czasu ataku i identyfikację działań operatora.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem infekcji jest ryzyko naruszenia łańcucha dostaw oprogramowania. Jeśli atakujący przejmie konto maintainera, token do publikacji pakietów lub dostęp do pipeline’u CI/CD, może dostarczyć złośliwą aktualizację przez zaufany kanał dystrybucji. W takim scenariuszu incydent na jednym hoście może przerodzić się w problem o znacznie szerszej skali.

Zagrożenie obejmuje także przejęcie zasobów chmurowych, klastrów Kubernetes, konfiguracji Dockera, sekretów aplikacyjnych i repozytoriów kodu. Może to prowadzić do kradzieży własności intelektualnej, sabotażu procesu budowy, manipulacji artefaktami oraz przygotowania kolejnych etapów ataku.

Dla organizacji działających w modelu DevOps ryzyko jest wyjątkowo wysokie, ponieważ jedna stacja robocza często zapewnia dostęp do wielu krytycznych systemów jednocześnie. Koncentracja uprawnień sprawia, że skutki kompromitacji są nieproporcjonalnie duże względem pozornie lokalnego incydentu endpointowego.

Rekomendacje

Organizacje powinny traktować stacje robocze deweloperów i hosty buildowe jako zasoby o podwyższonej krytyczności. Kluczowe jest ograniczenie przechowywania długoterminowych sekretów w plikach lokalnych oraz wdrożenie scentralizowanego zarządzania tajemnicami z rotacją poświadczeń i krótkim czasem życia tokenów.

Niezbędne jest stosowanie wieloskładnikowego uwierzytelniania dla repozytoriów kodu, rejestrów pakietów, środowisk chmurowych i narzędzi administracyjnych. W obszarze CI/CD warto wdrożyć zasadę najmniejszych uprawnień, podpisywanie artefaktów, separację środowisk oraz monitorowanie nietypowych publikacji pakietów i zmian w konfiguracji buildów.

Od strony detekcji należy monitorować użycie LD_PRELOAD, nieautoryzowane zmiany w PAM, podejrzane wpisy persistence w systemd, crontabie i plikach startowych powłoki, a także anomalie związane z eBPF. Warto również zwracać uwagę na procesy podszywające się pod wątki jądra, nietypową komunikację wychodzącą oraz próby czyszczenia logów.

W przypadku podejrzenia kompromitacji konieczna jest pełna rotacja wszystkich sekretów dostępnych z hosta. Samo usunięcie malware nie wystarczy, jeśli atakujący zdążył już przejąć tokeny publikacyjne, klucze chmurowe, dane SSH czy sekrety używane przez pipeline’y automatyzacji. Równolegle należy zweryfikować, czy nie doszło do publikacji złośliwych pakietów lub zmian w infrastrukturze.

Podsumowanie

Quasar Linux RAT to przykład nowoczesnego malware dla Linuksa, zaprojektowanego specjalnie z myślą o środowiskach deweloperskich i atakach na łańcuch dostaw oprogramowania. O skali zagrożenia decyduje połączenie bezplikowego działania, rozbudowanych mechanizmów ukrywania obecności, trwałości, przechwytywania poświadczeń i szerokich możliwości zdalnej kontroli.

Dla firm rozwijających oprogramowanie oznacza to konieczność wzmocnienia ochrony stacji deweloperskich, sekretów i pipeline’ów CI/CD. Kompromitacja pojedynczego hosta może bowiem przełożyć się na incydent obejmujący znacznie większą część organizacji, a nawet jej klientów.

Źródła

1. The Hacker News — Quasar Linux RAT Steals Developer Credentials to Enable Supply Chain Attacks