Backdoor w PAM i OpenSSH: ukryta persystencja w Linuxie ujawnia skalę długotrwałej kampanii - Security Bez Tabu

Backdoor w PAM i OpenSSH: ukryta persystencja w Linuxie ujawnia skalę długotrwałej kampanii

Cybersecurity news

Wprowadzenie do problemu / definicja

Ujawniona kampania pokazuje, że zaawansowane operacje cybernetyczne coraz częściej koncentrują się na modyfikacji zaufanych komponentów systemowych, a nie wyłącznie na uruchamianiu osobnych próbek malware. W tym przypadku celem były mechanizmy logowania w systemach Linux, przede wszystkim PAM oraz OpenSSH. To szczególnie groźny scenariusz, ponieważ kompromitacja dotyczy samej warstwy uwierzytelniania, co daje atakującym możliwość utrzymywania dostępu nawet po wykonaniu standardowych działań naprawczych.

PAM, czyli Pluggable Authentication Modules, odpowiada za obsługę procesu uwierzytelniania w wielu dystrybucjach Linux. Z kolei OpenSSH jest jednym z podstawowych narzędzi zdalnego dostępu administracyjnego. Modyfikacja tych elementów oznacza, że złośliwa logika działa w ramach legalnych, powszechnie używanych usług systemowych.

W skrócie

Badacze opisali wieloletnią operację przypisywaną grupie powiązanej z Chinami, w której modyfikowano komponenty PAM i OpenSSH na systemach Linux. Backdoory miały umożliwiać logowanie przy użyciu ukrytych haseł, przechwytywanie prawidłowych poświadczeń oraz rejestrowanie poleceń wykonywanych po zalogowaniu.

  • Najstarsze ślady aktywności miały sięgać 2016 roku.
  • Atakujący osadzali persystencję w zaufanych plikach logowania.
  • Kompromitacja utrudniała wykrycie i skuteczne usunięcie zagrożenia.
  • Operacja obejmowała także wykorzystanie hostów pośredniczących i systemów brzegowych.

Kontekst / historia

Opisana aktywność wpisuje się w szerszy trend ataków wymierzonych w elementy infrastruktury, które często pozostają poza głównym zakresem klasycznych narzędzi EDR i standardowego monitoringu bezpieczeństwa. Zamiast polegać wyłącznie na typowych implantach uruchamianych jako osobne procesy, operatorzy kampanii mieli wykorzystywać komponenty o wysokim poziomie zaufania operacyjnego.

Z ustaleń badaczy wynika, że grupa utrzymywała obecność również poprzez systemy brzegowe i hosty pośredniczące, aby uzyskiwać dostęp do segmentów sieci bez bezpośredniej łączności z internetem. Taki model działania sugeruje dobrze zaplanowaną, długoterminową operację nastawioną na cichy dostęp, zbieranie poświadczeń i utrzymywanie trwałej obecności wewnątrz środowiska ofiary.

Analiza techniczna

Techniczny rdzeń kampanii polegał na podmianie lub modyfikacji legalnych komponentów odpowiedzialnych za uwierzytelnianie. Jeśli atakujący uzyska możliwość podstawienia własnej wersji modułu PAM, może przechwytywać nazwy użytkowników i hasła bez potrzeby wdrażania widocznego keyloggera czy dodatkowego agenta działającego w przestrzeni użytkownika.

W analizowanym przypadku zidentyfikowano wiele wariantów zmodyfikowanych plików. Część z nich umożliwiała logowanie z użyciem ukrytego hasła, co dawało operatorom bezpośredni dostęp z pominięciem standardowego modelu autoryzacji. Inne warianty przechwytywały prawidłowe dane logowania podczas legalnych sesji użytkowników.

Równolegle modyfikowane miały być również komponenty OpenSSH, co rozszerzało możliwości atakujących o zbieranie poświadczeń i monitorowanie poleceń wykonywanych w sesji powłoki. Tego typu kompromitacja nie wymaga utrzymywania odrębnego procesu malware, który można łatwo wykryć na podstawie anomalii behawioralnych. Złośliwa logika zostaje osadzona w plikach, które i tak są uruchamiane podczas każdego logowania.

W praktyce oznacza to, że aktywność przeciwnika może wyglądać jak zwykła administracja systemem. Dodatkowo operatorzy mieli korzystać z infrastruktury pośredniczącej do tunelowania poleceń i uzyskiwania dostępu do systemów w odizolowanych segmentach sieci. Z perspektywy obrony jest to sygnał, że samo monitorowanie procesów i alertów nie wystarcza. Kluczowe staje się porównywanie binariów i bibliotek z zaufanymi kopiami referencyjnymi.

Konsekwencje / ryzyko

Skutki takiego naruszenia są poważne zarówno operacyjnie, jak i strategicznie. Jeżeli backdoor znajduje się w warstwie uwierzytelniania, samo resetowanie haseł lub zamykanie aktywnych sesji nie rozwiązuje problemu. Nowe poświadczenia mogą zostać ponownie przechwycone natychmiast po ich użyciu.

To oznacza, że organizacja może przez długi czas pozostawać w błędnym przekonaniu, że incydent został opanowany. Ryzyko dotyczy nie tylko pojedynczych hostów, ale całego modelu zdalnego dostępu i zarządzania infrastrukturą.

  • trwała persystencja na serwerach Linux,
  • kradzież poświadczeń administratorów i użytkowników uprzywilejowanych,
  • przejęcie dostępu do systemów odizolowanych od internetu,
  • ukryte poruszanie się boczne w infrastrukturze,
  • utrata integralności krytycznych hostów i mechanizmów dostępowych,
  • poważne utrudnienie działań forensic i incident response.

Szczególnie narażone są środowiska, w których systemy Linux pełnią rolę bastionów administracyjnych, serwerów aplikacyjnych, hostów CI/CD lub punktów dostępowych do segmentów o podwyższonym poziomie zaufania. W takich przypadkach kompromitacja PAM lub OpenSSH może stać się punktem wyjścia do dalszej eskalacji uprawnień i przejęcia kolejnych zasobów.

Rekomendacje

Organizacje wykorzystujące Linux w środowiskach produkcyjnych powinny potraktować tę klasę zagrożeń jako priorytetową i wdrożyć zarówno działania detekcyjne, jak i kontrolne. Kluczowe znaczenie ma monitoring integralności plików związanych z uwierzytelnianiem, w tym modułów PAM, binariów OpenSSH, bibliotek współdzielonych oraz powiązanych plików konfiguracyjnych.

Każda nieautoryzowana zmiana w tych obszarach powinna generować alert wysokiego priorytetu. Warto również prowadzić regularne porównania binariów z referencyjnymi kopiami pochodzącymi z zaufanych pakietów dystrybucyjnych, weryfikować sumy kontrolne, podpisy pakietów oraz stan repozytoriów systemowych.

  • wdrożyć file integrity monitoring dla komponentów logowania,
  • regularnie porównywać pliki systemowe z wersjami referencyjnymi,
  • usunąć zmodyfikowane komponenty przed resetem haseł i wymianą kluczy,
  • rozszerzyć threat hunting o hosty pośredniczące, bastiony i urządzenia brzegowe,
  • testować wymianę komponentów PAM i SSH w środowisku kontrolowanym.

Działania naprawcze muszą przebiegać we właściwej kolejności. Najpierw należy usunąć zmodyfikowane komponenty i potwierdzić integralność ścieżki logowania, a dopiero później resetować hasła oraz odnawiać klucze dostępu. Odwrócenie tej kolejności może doprowadzić do ponownej kradzieży nowych poświadczeń.

Podsumowanie

Opisana kampania przeciwko systemom Linux pokazuje, że warstwa logowania stała się pełnoprawnym celem zaawansowanych operacji cybernetycznych. Modyfikacja PAM i OpenSSH daje atakującym wyjątkowo trwały i trudny do wykrycia dostęp, a jednocześnie pozwala na przechwytywanie poświadczeń oraz ukrywanie aktywności w legalnych komponentach systemowych.

Dla obrońców to wyraźny sygnał, że samo łatanie podatności i monitorowanie procesów nie wystarcza. Kluczowe znaczenie ma dziś weryfikacja integralności zaufanych elementów systemu, szczególnie tych odpowiedzialnych za uwierzytelnianie i dostęp administracyjny.

Źródła

  1. The Hacker News — https://thehackernews.com/2026/06/china-linked-hackers-backdoored-linux.html
  2. Sygnia — Operation Highland — https://www.sygnia.co/threat-reports-and-advisories/operation-highland-velvet-ant/
  3. Linux-PAM Manual Project — https://www.linux-pam.org/Linux-PAM-html/
  4. OpenSSH Manual Pages — https://www.openssh.com/manual.html
  5. NIST NVD — CVE-2024-20399 — https://nvd.nist.gov/vuln/detail/CVE-2024-20399