Nowy backdoor „ted” w HAProxy przechwytuje ruch HTTP i omija logowanie

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali nowy backdoor dla systemów Linux o nazwie „ted”, który został osadzony bezpośrednio w trojanizowanych binariach HAProxy. To szczególnie niebezpieczny scenariusz, ponieważ nie chodzi o wykorzystanie luki w samym oprogramowaniu, lecz o podmianę legalnego pliku wykonywalnego na zmodyfikowaną wersję działającą wewnątrz procesu load balancera.

Taki model ataku daje operatorom możliwość przechwytywania żądań HTTP, modyfikowania odpowiedzi oraz ukrywania komunikacji sterującej w pozornie legalnym ruchu sieciowym. W efekcie kompromitacji ulega kluczowy element infrastruktury brzegowej, przez który przechodzi znacząca część ruchu aplikacyjnego organizacji.

W skrócie

Backdoor „ted” został ukryty w zmodyfikowanych binariach HAProxy.
Kampania dotknęła co najmniej dwie organizacje w Korei Południowej z sektorów motoryzacyjnego i medialnego.
Implant przechwytuje wybrane żądania HTTP jeszcze na poziomie load balancera, zanim trafią do backendu.
Atakujący mogli wykonywać polecenia, przesyłać pliki, aktualizować konfigurację malware i podmieniać treści odpowiedzi.
W środowisku ofiar znaleziono również trojanizowane binaria systemowe, w tym zmodyfikowane wersje crond, sshd, agetty, atd i polkitd oraz komponent curlRAT.

Kontekst / historia

Przypadek „ted” wpisuje się w szerszy trend ataków na komponenty infrastruktury pośredniczącej, takie jak load balancery, reverse proxy czy usługi uwierzytelniające. Dla napastników są to bardzo atrakcyjne cele, ponieważ zapewniają szeroką widoczność ruchu i pozwalają manipulować komunikacją bez konieczności infekowania każdej stacji roboczej czy serwera aplikacyjnego osobno.

Analitycy z umiarkowaną pewnością wiążą aktywność z podmiotami powiązanymi z Koreą Północną. Atrybucja opiera się na podobieństwach infrastrukturalnych i operacyjnych, choć badacze podkreślają, że obecnie nie ma jeszcze podstaw do całkowicie definitywnego przypisania operacji jednej konkretnej grupie. Hipoteza dotycząca początkowego dostępu wskazuje na możliwe wykorzystanie ekspozycji środowisk groupware, co pozostaje spójne z wcześniejszymi kampaniami wymierzonymi w organizacje południowokoreańskie.

Analiza techniczna

Najbardziej wyróżniającą cechą backdoora „ted” jest to, że został skompilowany bezpośrednio do zainfekowanego HAProxy. Dzięki temu malware nie uruchamia się jako osobny proces, co znacząco utrudnia wykrycie na podstawie klasycznych wskaźników, takich jak nietypowe procesy, podejrzane porty czy oczywista komunikacja sieciowa.

Mechanizm dowodzenia i kontroli był aktywowany przez żądanie kierowane do określonej ścieżki obrazu. Po spełnieniu warunków implant przechwytywał komunikację, zapisywał komendę do nazwanego potoku w katalogu tymczasowym i blokował przekazanie żądania do backendu. Odpowiedź wracała jako pozornie poprawna odpowiedź HTTP, co umożliwiało skuteczne ukrycie komunikacji C2 w zwykłym ruchu webowym.

Backdoor zawierał też logikę selekcji ofiar dla modyfikacji odpowiedzi HTTP. Żądania musiały spełniać określone kryteria związane z adresem URL, nagłówkiem Referer, obecnością User-Agent oraz regułami dotyczącymi adresu klienta. Dodatkowo operator mógł ominąć część filtrowania dzięki specjalnemu kluczowi przesyłanemu w nagłówku Accept-Language. Po dopasowaniu reguły implant modyfikował odpowiedź, ustawiał kod 200, korygował typ i długość treści oraz usuwał wybrane nagłówki, aby utrudnić wykrycie manipulacji.

Ważnym elementem operacji była także trwałość i ukrywanie śladów. Stager sprawdzał obecność odpowiednich usług i uprawnienia roota, a następnie nadpisywał legalne binaria systemowe. Zmodyfikowany crond otrzymywał znaczniki czasu przypominające oryginalne pliki, a malware czyścił historię poleceń oraz wybrane logi systemowe, w tym logi uwierzytelniania i audytu. Z kolei trojanizowany sshd miał przechwytywać hasła w postaci jawnej, szyfrować je i zapisywać lokalnie.

Dodatkowym kanałem dostępu był komponent curlRAT. Domyślnie kontaktował się z infrastrukturą sterującą co 12 godzin, ale po zmianie ustawień mógł zwiększyć częstotliwość komunikacji nawet do 30 sekund. Taki sposób działania wskazuje na nacisk na długotrwałą, możliwie cichą obecność w środowisku ofiary.

Konsekwencje / ryzyko

Ryzyko związane z takim atakiem jest bardzo wysokie, ponieważ kompromitowany zostaje centralny punkt obsługi ruchu aplikacyjnego. Atakujący mogą przechwytywać żądania i odpowiedzi, selektywnie podmieniać treści, wykonywać polecenia na serwerze oraz kraść poświadczenia. Co istotne, część aktywności może nie być widoczna ani w logach backendu, ani w standardowej telemetrii aplikacyjnej.

Dla zespołów SOC oraz administratorów oznacza to konieczność szerszego spojrzenia na monitoring. Organizacje, które opierają detekcję głównie na logach serwera WWW, WAF lub APM, mogą nie zauważyć implantu działającego wewnątrz load balancera. Samo zaktualizowanie HAProxy nie powinno być traktowane jako pełna remediacja, jeśli host został już przejęty i zawiera inne zmodyfikowane komponenty systemowe.

Rekomendacje

Organizacje korzystające z HAProxy i podobnych elementów infrastruktury brzegowej powinny wdrożyć ścisłą kontrolę integralności binariów oraz regularne porównywanie sum kontrolnych z zaufanymi artefaktami. Należy monitorować nie tylko aplikacje biznesowe, lecz również warstwę pośredniczącą i usługi systemowe.

Zweryfikować integralność plików wykonywalnych HAProxy, crond, sshd, agetty, atd i polkitd.
Sprawdzić katalogi tymczasowe oraz nietypowe artefakty mogące wskazywać na działanie malware.
Korelować ruch na brzegu z logami backendu w celu identyfikacji żądań niewidocznych po stronie aplikacji.
Analizować pamięć procesów infrastrukturalnych pod kątem anomalii i nieautoryzowanych modyfikacji.
Ograniczyć możliwość podmiany binariów przez konta uprzywilejowane i wzmocnić kontrolę dostępu administracyjnego.
Przeanalizować historyczne logi pod kątem podejrzanej komunikacji i nietypowych odpowiedzi HTTP.
W ramach reagowania przeprowadzić pełne dochodzenie na hoście oraz rotację poświadczeń, zamiast ograniczać się do odtworzenia samego HAProxy.

W środowiskach o podwyższonym poziomie ryzyka warto dodatkowo stosować mechanizmy FIM, centralne potwierdzanie pochodzenia artefaktów oraz reprodukowalne buildy, które ułatwiają wykrywanie nieautoryzowanych zmian.

Podsumowanie

Backdoor „ted” pokazuje, że współczesne operacje APT coraz częściej przenoszą się z klasycznych procesów malware do wnętrza zaufanych komponentów infrastrukturalnych. Osadzenie implantu w HAProxy umożliwia przechwytywanie ruchu, ukrywanie komunikacji sterującej i selektywną manipulację odpowiedziami HTTP przy bardzo ograniczonej widoczności dla standardowych narzędzi bezpieczeństwa.

Najważniejszy wniosek dla obrońców jest jednoznaczny: bezpieczeństwo aplikacji nie kończy się na backendzie. Load balancery, reverse proxy i krytyczne usługi systemowe muszą być traktowane jako pełnoprawne punkty kontroli bezpieczeństwa, objęte rygorystycznym monitoringiem, kontrolą integralności i procedurami reagowania na incydenty.