
Wprowadzenie do problemu / definicja
eBPF, czyli extended Berkeley Packet Filter, to mechanizm jądra Linuksa pozwalający uruchamiać kontrolowane programy w przestrzeni kernel space bez konieczności ładowania tradycyjnych modułów jądra. Rozwiązanie to od lat wspiera obserwowalność, bezpieczeństwo, analizę ruchu i optymalizację wydajności. Te same możliwości sprawiają jednak, iż eBPF staje się coraz atrakcyjniejszym narzędziem dla autorów zaawansowanego malware.
W praktyce rootkit eBPF może działać z wysokimi uprawnieniami, korzystać z legalnego interfejsu jądra i jednocześnie unikać części klasycznych metod detekcji. To właśnie połączenie elastyczności, uprzywilejowanego działania i niskiej widoczności powoduje, iż ten wektor ataku zyskuje na znaczeniu.
W skrócie
Rosnące zainteresowanie rootkitami eBPF wynika z faktu, iż pozwalają ukrywać aktywność bez ładowania klasycznego modułu jądra. Dla obrońców oznacza to konieczność rozszerzenia monitoringu poza tradycyjne wskaźniki kompromitacji związane z LKM.
- eBPF umożliwia podpinanie logiki do wybranych punktów wykonania w jądrze.
- Złośliwe programy mogą ukrywać procesy, wpisy katalogowe i wybrane połączenia sieciowe.
- Implant może aktywować się dopiero po odebraniu specjalnie spreparowanego pakietu.
- Legalny charakter interfejsu utrudnia odróżnienie zastosowań administracyjnych od działań ofensywnych.
Kontekst / historia
Tradycyjne linuxowe rootkity jądra przez lata opierały się głównie na modułach LKM, które przechwytywały wywołania systemowe albo modyfikowały zachowanie kernela. Tego typu aktywność jest dziś stosunkowo dobrze rozpoznana przez zespoły bezpieczeństwa i wiele narzędzi potrafi wykrywać próby ładowania podejrzanych modułów.
eBPF zmienia ten model, ponieważ pozwala osadzać logikę bez potrzeby korzystania z klasycznego modułu jądra. W poprzednich latach badacze opisywali zarówno backdoory aktywowane przez odpowiednio przygotowane pakiety, jak i bardziej zaawansowane projekty prezentujące hookowanie syscalli, ukrywanie artefaktów czy sterowanie implantem z poziomu warstwy sieciowej.
Istotna zmiana polega dziś na szerszym rozpowszechnianiu tej wiedzy. Techniki znane wcześniej głównie z laboratoriów, publikacji badawczych i niszowych prezentacji coraz częściej pojawiają się w materiałach dostępnych szerzej, co zwiększa ryzyko ich adaptacji przez realnych przeciwników.
Analiza techniczna
Od strony technicznej rootkity eBPF bazują na autoryzowanym interfejsie jądra, zwykle z użyciem wywołania bpf(). Program eBPF może zostać dołączony do różnych punktów wykonania, obserwować aktywność systemową, analizować ruch sieciowy, a w określonych scenariuszach także wpływać na widoczność wybranych artefaktów.
To oznacza, iż proste kontrole oparte na narzędziach takich jak lsmod mogą nie wykazać niczego podejrzanego, mimo iż implant działa już na hoście. Dla zespołów SOC i DFIR jest to istotna zmiana, ponieważ brak modułu jądra nie oznacza już braku zagrożenia na poziomie kernela.
- Ukrywanie procesów lub wpisów katalogowych przez ingerencję w ścieżki związane z getdents64.
- Reagowanie na tzw. magic packets, na przykład pakiety o określonych flagach lub nietypowych parametrach.
- Wykorzystanie XDP albo traffic control do filtrowania, blokowania lub selektywnego maskowania ruchu.
- Szyfrowanie komunikacji C2 i aktywacja wyłącznie po spełnieniu konkretnego warunku sieciowego.
Dodatkowym wyzwaniem są historyczne podatności związane z ekosystemem BPF, w tym błędy w verifierze i komponentach towarzyszących. choćby niedopracowane proof-of-concepty mogą stać się podstawą do dalszego rozwoju bardziej skutecznych narzędzi ofensywnych.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem dla organizacji jest spadek efektywności klasycznych metod wykrywania zagrożeń na hostach linuksowych. o ile monitoring koncentruje się głównie na modułach LKM, anomaliach w przestrzeni użytkownika lub prostych oznakach manipulacji systemem, implant eBPF może pozostać niewidoczny przez dłuższy czas.
Ryzyko operacyjne obejmuje zarówno utrzymanie trwałej obecności na serwerze, jak i selektywne maskowanie działań napastnika. Taki malware może utrudniać analizę incydentu, zniekształcać telemetrię oraz komplikować rekonstrukcję pełnego łańcucha ataku.
- Długotrwała obecność intruza w środowisku produkcyjnym.
- Ukrywanie procesów, połączeń i wybranych artefaktów dyskowych.
- Manipulowanie widocznością ruchu sieciowego.
- Aktywacja backdoora tylko po odebraniu określonego pakietu.
- Utrudnienie pracy narzędzi EDR, DFIR i zespołów reagowania.
Szczególnie narażone są środowiska intensywnie wykorzystujące konteneryzację, nowoczesny stos sieciowy, chmury prywatne i rozwiązania observability. W takich infrastrukturach obecność eBPF jest normalna, co daje atakującym dodatkową warstwę kamuflażu.
Rekomendacje
Organizacje korzystające z Linuksa powinny potraktować eBPF jako pełnoprawny obszar monitorowania bezpieczeństwa. Oznacza to odejście od założenia, iż kontrola modułów jądra i procesów użytkownika zapewnia wystarczającą widoczność.
- Regularnie audytować załadowane programy eBPF, mapy i punkty podpięcia.
- Budować listy dozwolonych komponentów i porównywać stan hostów z baseline’em.
- Ograniczać nieuprzywilejowany dostęp do eBPF oraz kontrolować uprawnienia, takie jak CAP_BPF i CAP_NET_ADMIN.
- Monitorować wywołania bpf() oraz nietypowe attach pointy odnoszące się do krytycznych syscalli.
- Sprawdzać interfejsy sieciowe pod kątem nieoczekiwanych programów XDP.
- Wykrywać anomalie w ruchu TCP, UDP i ICMP, w tym pakiety aktywacyjne.
- Aktualizować kernel i komponenty związane z BPF bez zbędnej zwłoki.
- Korelować telemetrię hostową, sieciową i dane z warstwy orkiestracji.
Warto również przygotować procedury reagowania na incydenty uwzględniające specyfikę eBPF. Obejmuje to zbieranie informacji o programach, mapach i linkach BPF, analizę ich powiązań z procesami oraz porównanie stanu systemu z oczekiwanym profilem środowiska.
Podsumowanie
Rootkity eBPF to wyraźna ewolucja zagrożeń dla Linuksa. Łączą one wysoki poziom uprzywilejowania z relatywnie niską widocznością operacyjną, a ich skuteczność rośnie wraz z upowszechnianiem wiedzy technicznej poza wąskie grono badaczy.
Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia modelu detekcji poza klasyczne moduły jądra i wdrożenia monitoringu natywnego dla eBPF. Im szybciej organizacja zbuduje dojrzałą widoczność w tym obszarze, tym mniejsze ryzyko, iż nowoczesny implant pozostanie aktywny przez długi czas bez wykrycia.
Źródła
- https://www.bleepingcomputer.com/news/security/ebpf-rootkits-why-underground-actors-are-taking-notice/
- https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor
- https://blogs.blackberry.com/en/2022/06/symbiote-a-new-nearly-impossible-to-detect-linux-threat
- https://secoperations.wordpress.com/2022/03/17/triplecross-a-linux-ebpf-rootkit-with-a-backdoor-c2c-library-injection-execution-hijacking-persistence-and-stealth-capabilities/
- https://www.synacktiv.com/en/publications/linkpro-linux-backdoor-stealthy-malware-rust-ebpf




