Systemy zdalnego wsparcia mają przede wszystkim ułatwiać pracę zespołom wsparcia i administratorom. Jedna konsola pozwala łączyć się z komputerami użytkowników, przesyłać pliki i rozwiązywać problemy bez konieczności fizycznego dostępu do urządzenia. Co jednak, jeśli to właśnie taka konsola stanie się pierwszym systemem przejętym przez atakujących?

Autor: 6 min czytania

Taki scenariusz opisali badacze Mandiant, analizując działania grupy ARMORY CASTLE, która wykorzystała nieznaną wcześniej podatność CVE-2026-102764 w BeyondTrust Remote Support. Luka otrzymała ocenę 9,3 w skali CVSS i została ujawniona publicznie 15 października. Pierwsze potwierdzone ataki miały jednak miejsce już 29 sierpnia, kiedy poprawka nie była jeszcze dostępna. ARMORY CASTLE wykorzystało więc podatność jako zero-day, a przejęcie systemu zdalnego wsparcia okazało się dopiero początkiem dłuższego ataku.

Od podatności do własnego pliku na serwerze

Według advisory BT26-05 podatność wynikała z błędu w jednym z wewnętrznych komponentów Remote Support. System nie weryfikował pochodzenia otrzymywanych wiadomości prawidłowo, co w określonych warunkach pozwalało atakującemu wykonywać operacje na plikach serwera obsługującego rozwiązanie, zwanego appliance.

Co ważne, wykorzystanie podatności nie wymagało wcześniejszego uwierzytelnienia. Napastnik mógł między innymi przesyłać własne pliki na serwer, otwierając sobie drogę do kolejnych działań.

Właśnie z tej możliwości skorzystało ARMORY CASTLE, umieszczając na przejętym urządzeniu skrypt umożliwiający zdalne wykonywanie poleceń.

SAWFLY, czyli niepozorny plik PHP

Badacze Mandiant zidentyfikowali narzędzie nazwane SAWFLY, będące niewielkim webshellem napisanym w PHP. Webshell to złośliwy skrypt umieszczony na serwerze WWW, który pozwala atakującemu wykonywać polecenia za pośrednictwem żądań HTTP. Zamiast standardowego logowania do systemu napastnik może więc sterować serwerem poprzez specjalnie przygotowane zapytania.

SAWFLY wykorzystywał szyfrowaną komunikację, a na żądania niezawierające odpowiedniego parametru odpowiadał błędem 404. Dla przypadkowego użytkownika lub prostego skanera wyglądało to tak, jakby pod wskazanym adresem niczego nie było.

Początkowo webshell działał z ograniczonymi uprawnieniami konta obsługującego usługę WWW. Atakujący wykorzystali jednak mechanizm uprawnień systemu Linux, przygotowując kopię powłoki systemowej, którą mogli uruchamiać z uprawnieniami roota, czyli administratora systemu. W ten sposób uzyskali znacznie większą kontrolę nad przejętym urządzeniem.

Przygotowali również skrypt uruchamiany podczas startu appliance, który przywracał uprzywilejowany dostęp po restarcie urządzenia. W ten sposób zadbali o persistence, czyli utrzymanie dostępu do przejętego systemu.

Z Remote Support dalej do środowiska

Po uzyskaniu uprawnień administratora ARMORY CASTLE zainteresowało się poświadczeniami przechowywanymi przez appliance. Mandiant zaobserwował próby ich pozyskania za pomocą wbudowanego w Remote Support narzędzia służącego do zarządzania hasłami i kluczami.

Grupa zalogowała się również do panelu administracyjnego przy użyciu przejętych poświadczeń administratora. Następnie zmodyfikowała uprawnienia dostępu do urządzeń zarządzanych przez Remote Support, dzięki czemu mogła nawiązywać sesje z systemami, do których wcześniej nie miała dostępu.

Mandiant potwierdził, że atakujący uruchamiali sesje zdalne do komputerów i korzystali z funkcji przesyłania plików. W ten sposób pobierali między innymi zestawienia zainstalowanego oprogramowania, przydatne podczas rozpoznawania środowiska.

W praktyce rozwiązanie przeznaczone do zdalnego wsparcia użytkowników zaczęło służyć napastnikom jako kolejna droga dostępu do infrastruktury organizacji. Szczegółowy przebieg działań opisano w analizie Mandiant.

Odrzucony alarm

Google Threat Intelligence wiąże ARMORY CASTLE z grupą śledzoną wcześniej jako UNC5221, podejrzewaną o działalność szpiegowską powiązaną z Chinami. W przeszłości wykorzystywała ona między innymi podatności w produktach Citrix i Ivanti.

Ciekawym elementem tej historii jest sposób wykrycia incydentu. Podczas ataku na instancję SaaS systemy monitorowania BeyondTrust wykryły eskalację uprawnień, ale automatyczny mechanizm analizy alertów wykorzystywany przez zewnętrzną platformę bezpieczeństwa uznał zgłoszenia za fałszywe alarmy.

Dopiero późniejsze aktywne poszukiwanie śladów włamania doprowadziło 28 września do wykrycia kompromitacji. Jak opisuje BeyondTrust w swoim podsumowaniu incydentu, przejętą instancję udało się odizolować w ciągu 27 minut od wykrycia.

Podsumowanie

Według BeyondTrust znane są dwa przypadki kompromitacji: jeden dotyczący instancji SaaS i drugi instalacji utrzymywanej samodzielnie przez klienta. Podatność dotyczy wersji Remote Support do 26.2.3 włącznie. Producent zabezpieczył już środowiska SaaS i zdecydowanie zaleca zastosowanie poprawki opisanej w BT26-05 w przypadku instancji self-hosted.

Co ciekawe, nie jest to pierwszy raz, gdy BeyondTrust Remote Support pojawia się na Kapitanie w kontekście poważnych podatności. W lutym 2025 roku opisywaliśmy wcześniejsze luki zero-day dotyczące tego rozwiązania, choć tamta sprawa dotyczyła odrębnego incydentu.

Przypadek ARMORY CASTLE pokazuje, jak duże znaczenie dla bezpieczeństwa organizacji mają serwery zapewniające zdalny dostęp, szczególnie gdy pośredniczą w sesjach z podwyższonymi uprawnieniami.

Przejęcie takiego systemu może być zaledwie pierwszym etapem całego łańcucha ataku. Możliwość dotarcia do zapisanych poświadczeń, sesji administracyjnych i kolejnych urządzeń sprawia, że początkowa kompromitacja jednego appliance może otworzyć drogę do znacznej części infrastruktury organizacji.