Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali kampanię, w której złośliwy kod został osadzony bezpośrednio w HAProxy — popularnym load balancerze i reverse proxy wykorzystywanym do obsługi ruchu HTTP oraz HTTPS. Taki scenariusz jest szczególnie groźny, ponieważ kompromitacji ulega komponent stojący na brzegu infrastruktury, a sama usługa może nadal działać pozornie normalnie.
W praktyce oznacza to możliwość prowadzenia ukrytej komunikacji z serwerem dowodzenia, przechwytywania danych, zdalnego wykonywania poleceń i manipulacji ruchem bez typowych symptomów widocznych na poziomie aplikacji backendowych. To pokazuje, że warstwa pośrednicząca przestała być wyłącznie elementem wydajnościowym i stała się pełnoprawnym celem zaawansowanych operacji cyberwywiadowczych.
W skrócie
- Atak przypisano z umiarkowaną pewnością operatorom powiązanym z Koreą Północną.
- Celem były podmioty z Korei Południowej, głównie z sektorów motoryzacyjnego i medialnego.
- Backdoor „ted” został skompilowany jako część HAProxy, a nie uruchamiany jako osobny proces.
- Malware przechwytywał żądania HTTP, ukrywał własne ślady i umożliwiał zdalne wykonywanie poleceń.
- Kampanii towarzyszyły trojanizowane binaria Linuksa, m.in. crond, agetty, atd i sshd.
Kontekst / historia
W ostatnich latach rośnie znaczenie ataków na elementy pośredniczące w ruchu sieciowym, takie jak reverse proxy, load balancery, urządzenia edge oraz systemy terminujące TLS. W wielu organizacjach to właśnie serwery aplikacyjne, stacje robocze i systemy tożsamości były dotąd traktowane jako główne obszary monitoringu, podczas gdy warstwa pośrednia często pozostawała poza centrum uwagi zespołów bezpieczeństwa.
Opisana kampania pokazuje zmianę podejścia po stronie napastników. Zamiast wdrażać klasyczny web shell lub odrębnego agenta działającego obok legalnej usługi, operatorzy zintegrowali implant z zaufanym komponentem infrastruktury. To znacząco utrudnia detekcję, ponieważ złośliwa aktywność może zostać ukryta w normalnym cyklu obsługi ruchu przez HAProxy.
Analiza techniczna
Najważniejszą cechą kampanii była głęboka integracja backdoora z HAProxy 2.8.12. Złośliwy komponent działał jako niestandardowy filtr osadzony w kodzie usługi, co pozwalało mu analizować i modyfikować ruch HTTP jeszcze przed przekazaniem go do systemów backendowych. Dzięki temu atakujący uzyskali kontrolę nad przepływem żądań bez konieczności uruchamiania podejrzanego procesu, który mógłby zostać łatwo wykryty przez narzędzia obronne.
Mechanizm aktywacji opierał się na specjalnie przygotowanych żądaniach kierowanych do pozornie nieszkodliwej ścieżki imitującej plik graficzny. Taki request przełączał filtr do trybu command-and-control. Następnie polecenia były zapisywane do named pipe, a ślady operacji usuwane z liczników i buforów HAProxy. W efekcie żądania nie trafiały do backendu i mogły nie pozostawiać użytecznych artefaktów ani w logach aplikacyjnych, ani w części statystyk samego load balancera.
To odróżnia opisywany implant od klasycznych web shelli. Malware nie działał na poziomie aplikacji, lecz kończył obsługę żądania już na warstwie pośredniej. Dla zespołów SOC oznacza to istotne ryzyko, ponieważ korelacja oparta wyłącznie na logach backendowych może całkowicie pominąć aktywność napastnika.
Backdoor umożliwiał również bardziej zaawansowane operacje, w tym wstrzykiwanie złośliwego kodu do odpowiedzi HTTP oraz podmianę treści stron dla wyselekcjonowanych ofiar. Selekcja mogła opierać się na adresie IP, odcisku przeglądarki lub ukrytym znaczniku przesyłanym w nagłówkach. Taki model działania mógł przekształcić legalną infrastrukturę ofiary w platformę typu watering hole, służącą do dalszych infekcji lub przechwytywania sesji.
Na uwagę zasługuje także sposób maskowania manipulacji odpowiedziami. Malware dbał o ukrycie różnic w długości treści oraz usuwał elementy nagłówków, które mogłyby ujawnić niespójności podczas obsługi odpowiedzi po stronie klienta. To wskazuje na bardzo dobrą znajomość wewnętrznych mechanizmów HAProxy i praktyczne doświadczenie operatorów w pracy z ruchem HTTP.
Kampanii towarzyszył również zestaw trojanizowanych binariów Linuksa. Zmienione wersje usług systemowych zachowywały normalne funkcje administracyjne, a jednocześnie rozszerzały możliwości operatora. Jedna z komponent przechwytywała hasła wpisywane podczas logowania SSH, a inny moduł, określany jako curlRAT, komunikował się okresowo z infrastrukturą atakujących i zawierał funkcje utrudniające analizę, w tym podstawowe sprawdzanie środowiska wirtualnego.
W zakresie atrybucji badacze wskazali na powiązania infrastrukturalne i taktyczne z aktywnością grup związanych z Koreą Północną. Ocena została przedstawiona ostrożnie, jako przypisanie z umiarkowaną pewnością, co pozostaje zgodne z dobrymi praktykami analizy wywiadowczej.
Konsekwencje / ryzyko
Ryzyko wynikające z takiej kompromitacji jest bardzo wysokie. Po pierwsze, złośliwy kod działa w punkcie o uprzywilejowanej widoczności ruchu sieciowego, często zanim dane trafią do aplikacji backendowej. Po drugie, implant może usuwać własne ślady, co znacząco utrudnia wykrycie incydentu i wydłuża czas obecności napastnika w środowisku.
Po trzecie, możliwość modyfikowania odpowiedzi HTTP otwiera drogę do przejęcia sesji, wstrzykiwania skryptów, kierowania złośliwych ładunków do wybranych odbiorców oraz kompromitacji użytkowników końcowych. Dla organizacji oznacza to naruszenie poufności, integralności i wiarygodności usług internetowych, a także podważenie wartości dowodowej logów, jeśli firma polega głównie na telemetrii generowanej przez sam komponent edge.
Rekomendacje
Organizacje wykorzystujące HAProxy, reverse proxy i inne systemy brzegowe powinny traktować je tak samo jak krytyczne serwery aplikacyjne. Kluczowe znaczenie ma wdrożenie kontroli integralności binariów, modułów i plików konfiguracyjnych oraz regularne porównywanie artefaktów wdrożeniowych z zaufanymi buildami.
Niezbędne jest również rozszerzenie monitoringu poza tradycyjne logi aplikacyjne. W praktyce warto korelować telemetrię sieciową, logi z urządzeń pośredniczących, dane EDR dla hostów Linux oraz metryki behawioralne pozwalające wykrywać odstępstwa w pracy usług edge.
- Audytować binaria takie jak sshd, crond, atd i agetty.
- Weryfikować spójność pakietów z repozytoriami producenta.
- Rotować poświadczenia po wykryciu podejrzanej aktywności.
- Przeglądać sesje i tokeny, które mogły zostać przechwycone.
- Segmentować dostęp do warstwy edge.
- Ograniczać możliwość lokalnej kompilacji i modyfikacji usług produkcyjnych.
- Monitorować nietypowe żądania HTTP kończące się na load balancerze bez przekazania do backendu.
Zespoły bezpieczeństwa powinny również przyjąć założenie, że brak śladów w logach backendowych nie oznacza braku incydentu. W przypadku podejrzenia kompromitacji konieczne jest porównywanie ruchu wejściowego z ruchem faktycznie przekazywanym do aplikacji oraz analiza rozbieżności pomiędzy telemetrią sieciową a zapisami usługowymi.
Podsumowanie
Kampania oparta na backdoorze ukrytym w HAProxy pokazuje nowy poziom dojrzałości operacyjnej napastników. Zamiast ukrywać malware obok legalnej usługi, osadzili oni implant bezpośrednio w zaufanym komponencie obsługującym ruch sieciowy. Takie podejście zapewnia wysoki poziom skrytości, możliwość przechwytywania i modyfikowania ruchu oraz skuteczne zacieranie śladów.
Dla obrońców najważniejszy wniosek jest jednoznaczny: load balancery, reverse proxy i inne elementy warstwy edge muszą być chronione z taką samą rygorystycznością jak serwery aplikacyjne, systemy tożsamości i kluczowe usługi produkcyjne. Integralność tych komponentów oraz niezależna telemetria z ich działania stają się dziś jednym z podstawowych warunków skutecznej obrony.