Ataki na F5 BIG-IP APM: rootkit Linuksa i bezplikowy webshell utrudniają wykrycie - Security Bez Tabu

Ataki na F5 BIG-IP APM: rootkit Linuksa i bezplikowy webshell utrudniają wykrycie

Cybersecurity news

Wprowadzenie do problemu / definicja

Urządzenia F5 BIG-IP APM odpowiadają za uwierzytelnianie, dostęp zdalny oraz publikację aplikacji, dlatego stanowią jeden z najbardziej wrażliwych elementów infrastruktury brzegowej. Najnowsze analizy pokazują, że po skutecznym przejęciu takich systemów atakujący wdrażają nie tylko prosty kod do zdalnego wykonywania poleceń, ale także zaawansowany implant działający w systemie Linux.

Szczególnie niebezpieczny jest fakt, że złośliwy komponent osadza webshell bezpośrednio w pamięci procesu Apache. Oznacza to, że część ładunku nie istnieje w postaci pliku na dysku, co znacząco utrudnia wykrycie przez klasyczne mechanizmy bezpieczeństwa.

W skrócie

  • Kampania wymierzona jest w urządzenia F5 BIG-IP APM.
  • Atak powiązano z eksploatacją podatności CVE-2025-53521.
  • Po uzyskaniu dostępu wdrażany jest rootkit Linuksa oraz bezplikowy webshell działający w pamięci.
  • Implant przechwytuje mechanizmy ładowania bibliotek i obsługi PHP.
  • Atak utrudnia detekcję, ponieważ legalne pliki pozostają niezmienione na dysku.

Kontekst / historia

Opisane działania wpisują się w rosnący trend ataków na urządzenia perymetryczne, które zapewniają dostęp do kluczowych usług organizacji. W przypadku CVE-2025-53521 szczególne znaczenie miała zmiana oceny zagrożenia — podatność początkowo postrzegana jako problem prowadzący do zakłócenia działania usługi została ostatecznie uznana za wektor zdalnego wykonania kodu.

Taka reklasyfikacja ma ogromne znaczenie operacyjne. Dla zespołów bezpieczeństwa oznacza bowiem przejście od scenariusza awarii do ryzyka pełnego przejęcia urządzenia wystawionego do Internetu. Dodatkowo analiza incydentów sugeruje, że operatorzy ataku korzystają z architektury wieloetapowej, w której osobny komponent odpowiada za osadzenie implantu, a kolejny za trwałość, ukrycie i zdalną obsługę.

Analiza techniczna

Technicznie implant działa w przestrzeni użytkownika Linuksa i integruje się z procesem Apache na bardzo wczesnym etapie jego uruchamiania. Zamiast zapisywać klasyczny webshell w katalogu aplikacji, malware przechwytuje mechanizmy startowe procesu i ładowania modułów, co pozwala uruchomić złośliwy kod jeszcze przed wykonaniem głównej logiki programu.

Kolejnym elementem jest ingerencja w sposób obsługi modułów Apache oraz plików PHP. W praktyce legalne skrypty obecne w systemie mogą pozostać nienaruszone na dysku, ale ich obraz w pamięci zostaje zmodyfikowany tak, aby zawierał dodatkowy kod umożliwiający zdalne wykonywanie poleceń. To właśnie ten model działania sprawia, że standardowe skanery plików i mechanizmy kontroli integralności mogą nie wykryć kompromitacji.

Badacze zwracają również uwagę na ukrywanie ciągów operacyjnych przy użyciu szyfrowania RC4. Sam webshell reaguje wyłącznie na odpowiednio przygotowane żądania, odszyfrowuje przekazaną treść i wykonuje ją po stronie serwera. Dodatkowo odpowiedzi mogą być maskowane jako legalna zawartość CSS oraz zwracane z kodem HTTP 201, co utrudnia ich wychwycenie w dziennikach aplikacyjnych.

Ważnym składnikiem operacji jest też lokalny kanał sterowania. Rootkit tworzy chronione hasłem gniazdo UNIX, przez które może uruchamiać interaktywną powłokę Bash bez otwierania klasycznego portu TCP. Z perspektywy obrony jest to istotne, ponieważ wiele organizacji skupia monitoring na ruchu sieciowym, a nie na lokalnych mechanizmach IPC czy anomaliach procesowych.

Do potencjalnych wskaźników kompromitacji można zaliczyć:

  • nietypowe odczyty map pamięci procesu, takie jak dostęp do /proc/self/maps przez procesy Apache,
  • zmiany ochrony pamięci bibliotek powiązanych z PHP,
  • tworzenie niestandardowych socketów UNIX lub potoków w katalogach runtime,
  • uruchamianie /bin/bash przez procesy serwera WWW,
  • nietypowe żądania POST do plików .php3 powiązanych z portalem APM.

Konsekwencje / ryzyko

Ryzyko dla organizacji jest wysokie, ponieważ kompromitacja BIG-IP APM dotyczy systemu pośredniczącego w dostępie użytkowników i aplikacji. Przejęcie takiego urządzenia może umożliwić trwałe utrzymanie dostępu, manipulację ruchem aplikacyjnym, podsłuch sesji oraz wykorzystanie go jako punktu wejścia do dalszej penetracji środowiska wewnętrznego.

Najgroźniejszą cechą tej kampanii pozostaje bezplikowy charakter części ładunku. W praktyce oznacza to, że samo wdrożenie poprawek po wykryciu podatności może nie wystarczyć. Jeśli system został wcześniej zainfekowany, aktualizacja usunie wektor wejścia, ale niekoniecznie usunie działający już implant ani zmodyfikowane mechanizmy uruchamiania procesu.

Rekomendacje

Organizacje korzystające z F5 BIG-IP APM powinny w pierwszej kolejności potwierdzić, czy ich środowiska były narażone na CVE-2025-53521, a następnie bezzwłocznie wdrożyć poprawki i zalecenia producenta. Jeżeli urządzenie było publicznie dostępne i brak pełnej pewności co do jego historii ekspozycji, należy traktować je jako potencjalnie skompromitowane do czasu zakończenia analizy.

Z perspektywy działań obronnych warto:

  • przeprowadzić threat hunting skoncentrowany na procesach Apache i komponentach PHP,
  • sprawdzić logi pod kątem odpowiedzi HTTP 201 z treścią przypominającą CSS,
  • zweryfikować obecność nietypowych socketów UNIX oraz potoków w katalogach runtime,
  • monitorować uruchomienia powłoki Bash przez procesy usług WWW,
  • zabezpieczyć artefakty pamięci i procesów przed restartem urządzenia, o ile jest to możliwe operacyjnie.

W przypadku potwierdzenia lub silnego podejrzenia kompromitacji bezpieczniejszym podejściem może być pełna odbudowa urządzenia z zaufanego obrazu, rotacja poświadczeń administracyjnych i aplikacyjnych oraz przegląd logów związanych z uwierzytelnianiem i ruchem aplikacyjnym.

Podsumowanie

Ataki na F5 BIG-IP APM pokazują, że współczesne kampanie przeciwko urządzeniom brzegowym coraz częściej łączą eksploatację podatności z technikami ukrycia charakterystycznymi dla zaawansowanego post-exploitation. Rootkit osadzający webshell w pamięci procesu Apache znacząco podnosi próg trudności detekcji i sprawia, że klasyczne kontrole oparte wyłącznie na plikach mogą okazać się niewystarczające.

Dla organizacji kluczowe pozostają trzy działania: szybkie łatanie, aktywne poszukiwanie śladów kompromitacji oraz założenie, że urządzenie perymetryczne mogło zostać wykorzystane jako trwały punkt dostępu. Skuteczna odpowiedź wymaga więc nie tylko aktualizacji, ale również pogłębionej analizy powłamaniowej i walidacji integralności systemu.

Źródła