BeyondTrust i Mandiant opisują wykorzystanie CVE-2026-102764 w Remote Support przed ujawnieniem podatności. Producent udostępnił poprawkę 8 października, ale jej wdrożenie nie rozstrzyga, czy wcześniej doszło do włamania. Właściciel zdalnego wsparcia potrzebuje oddzielnego wyniku sprawdzenia tego okresu.

Czy status „zaktualizowane” wystarcza, żeby zamknąć sprawę narzędzia, przez które zespół pomaga użytkownikom na ich komputerach? Przy tej podatności poprośmy o dwa potwierdzenia. Pierwsze dotyczy poprawki przypisanej do własnej instalacji. Drugie powinno opisywać zakres oceny wcześniejszego dostępu i jej wynik. Administrator może zakończyć pierwsze zadanie, zanim zespół reagowania zbierze dane do drugiego. W raporcie dla kierownika IT pokażmy ten stan bez dopisywania zapewnienia, którego nikt jeszcze nie potrafi uzasadnić. To proponowany przez redakcję sposób prowadzenia sprawy; sam komunikat o podatności nie dowodzi, że konkretna firma padła ofiarą ataku.

BT26-05 wymaga potwierdzenia konkretnej poprawki

Według biuletynu BeyondTrust z 15 października błąd weryfikacji pochodzenia wiadomości wewnętrznych umożliwia zdalnemu atakującemu operacje na plikach urządzenia. Wektor nie wymaga uwierzytelnienia, a ocena CVSSv4 wynosi 9,3. Podatne są wersje Remote Support do 26.2.3 włącznie. Poprawka BT26-05-RS obejmuje wydania 24.3.1–26.2.3; starsze wymagają wcześniejszego podniesienia wersji. Biuletyn BT26-05

Producent podaje, że do 9 października poprawił wszystkie instancje Remote Support SaaS. Własne instalacje wymagają ręcznego wdrożenia, jeśli nie korzystają z automatycznych aktualizacji. Sam odczyt numeru 26.2.3 nie potwierdza zastosowania BT26-05-RS. Zakres i sposób aktualizacji

Przy odbiorze aktualizacji poprośmy o dowód zastosowania poprawki dla oznaczonej instancji. W firmowym wykazie przyda się oddzielne miejsce na wersję produktu i potwierdzenie pakietu bezpieczeństwa. Jeśli wykonawca przekazał tylko numer wersji, właściciel zadania powinien poprosić o brakujący wynik. Włączenie automatycznych aktualizacji odnotujmy jako ustawienie, a wykonanie konkretnej zmiany potwierdźmy osobno.

Privileged Remote Access otrzymał poprawkę ostrożnościowo ze względu na wspólny kod. BeyondTrust zaznacza, że jego testy nie wykazały sposobu wykorzystania tej luki w PRA. Wyjaśnienie producenta W ewidencji zapiszmy pełną nazwę produktu, aby nie przenieść ustaleń dotyczących Remote Support na inne wdrożenie.

Sierpniowy dostęp wymaga osobnego przeglądu

BeyondTrust podaje ataki z 29 sierpnia na jedną instancję hostowaną przez producenta i jedno urządzenie utrzymywane przez klienta. W aktualizacji z 16 października znał dwóch dotkniętych klientów i nie widział dowodów aktywności po sierpniu. Publiczne ujawnienie nastąpiło 15 października. Chronologia BeyondTrust

Mandiant przypisuje działania ARMORY CASTLE, wcześniej śledzonemu jako UNC5221, i podejrzewa związki tej grupy szpiegowskiej z ChRL. Badacze opisują webshell SAWFLY i tuneler BARECLAW, prawa root, utrzymanie dostępu oraz usuwanie logów. Odnotowali próbę pozyskania sekretów i pobranie dokumentów przez funkcje wsparcia. Raport Mandiant z 15 października

Badacze zalecają traktować urządzenie osiągalne z internetu w podatnej wersji w okresie ataków jako potencjalnie przejęte do czasu przeglądu. Ostrzegają, że utrzymany dostęp może przetrwać restart i reset konfiguracji. Zalecenia dotyczące wcześniejszej ekspozycji

Rozmowę z zespołem reagowania zacznijmy od historii własnej instalacji. Ustalmy, kiedy działała, z jaką wersją i jakie dane o jej dostępności organizacja potrafi przedstawić. W zapisie przeglądu rozdzielmy okres potwierdzony dokumentacją od czasu, którego nie udało się odtworzyć. Ustalenia z dwóch opisanych przez producenta przypadków nie określają pełnej skali ataków ani wyniku sprawdzenia u czytelnika.

Status poprawki i wynik oceny wcześniejszego dostępu powinny mieć oddzielne potwierdzenia.

Właściciel wsparcia powinien określić warunki dalszej pracy

Właściciel Remote Support potrzebuje ustaleń zespołu reagowania oraz opisu potrzeb helpdesku, żeby zdecydować o dalszym działaniu usługi. W tym zapisie można wskazać, które zadania wsparcia zależą od narzędzia i kto uzgadnia ich obsługę na czas prac. Tak przygotowana decyzja dotyczy własnej działalności, zamiast opierać się wyłącznie na ogólnej ocenie podatności.

Kolejność ewentualnego odłączenia, zabezpieczenia dowodów czy przebudowy urządzenia uzgodnijmy ze specjalistami prowadzącymi ocenę. Właściciel usługi powinien otrzymać harmonogram dla swojej instalacji i wyjaśnienie, co zespół zamierza sprawdzić przed kolejną zmianą i jaki wynik pozwoli przejść do następnego etapu. Za akceptację tej kolejności wyznaczmy konkretną osobę.

Do odbioru przeglądu potrzebny jest opis jego zakresu i ograniczeń. Zapis „nie wykryto śladów” powinien wskazywać, jakie dane obejmowała analiza i za jaki okres. Jeśli części danych brakuje, kierownik potrzebuje tej informacji obok wniosku. Dzięki temu akceptuje uzasadnioną ocenę, zamiast przypisywać jej pewność większą niż ta, którą deklaruje wykonawca.

Termin następnej informacji dla kierownictwa ustalmy niezależnie od daty zakończenia oceny. Jeżeli dochodzenie się przedłuży, właściciel usługi nadal potrzebuje aktualnych ustaleń do decyzji o pracy helpdesku.

O przywróceniu zaufania do narzędzia wsparcia decyduje zakres sprawdzenia, za który ktoś odpowiada.

Polski zespół powinien ustalić granicę usługi dostawcy

W polskiej firmie korzystającej z Remote Support rozmowę z dostawcą zacznijmy od nazwania modelu hostingu i konkretnej instancji. Własne urządzenie, usługa producenta i wsparcie świadczone przez pośrednika mogą wymagać innych adresatów pytań. Nie przesądzajmy podziału zadań na podstawie logo widocznego w konsoli. Uzgodnijmy go z podmiotem, który faktycznie utrzymuje daną instalację.

Odpowiedź na pytania o BT26-05 powinna wskazywać wykonawcę aktualizacji i osobę oceniającą wcześniejszy dostęp. Ustalmy, co obejmuje praca każdego z nich. Jeśli dostawca odpowiada tylko za wdrożenie pakietu, własny kierownik IT powinien wskazać wykonawcę pozostałego zadania. Pozwoli to uniknąć zamknięcia sprawy na granicy dwóch umów.

Na spotkanie odbiorowe przynieśmy także listę pytań bez odpowiedzi. Przy każdym wystarczy nazwisko odpowiedzialnej osoby i termin kolejnej informacji. Kierownictwo otrzyma wtedy podstawę decyzji o dalszej pracy Remote Support, wraz z widocznymi ograniczeniami oceny.

Jeżeli organizacja ma narażoną instalację, uruchommy reakcję od razu, zgodnie z firmowym trybem awaryjnym. Poniedziałkowe działania poniżej służą kontroli postępu prac już podjętych.

Co z tym zrobić w poniedziałek

  1. W 30 minut zbierz początkową listę instancji Remote Support, model hostingu i dostępne dowody BT26-05-RS. Przypisz niewiadome właścicielom.
  2. W 30 minut przygotuj z zespołem reagowania pytania o okres ekspozycji i dostępne logi. Ustal, kto skontaktuje się z producentem, jeśli potrzebne będzie wsparcie.
  3. W 30 minut wskaż decydenta odpowiedzialnego za ciągłość wsparcia i zapisz warunki odbioru dalszych prac. Termin ukończenia oceny uzgodnij z jej wykonawcą.

Wdrożenie poprawki powinno mieć własne potwierdzenie, a decyzja o dalszym używaniu Remote Support własne uzasadnienie. Odbiór prac wymaga nazwania tego, co zespół sprawdził i czego jeszcze nie wie. Sama presja na zamknięcie zgłoszenia nie dostarcza brakujących danych.

Źródła

  1. BeyondTrust, biuletyn BT26-05, 15 października 2026 — opis podatności i poprawki.
  2. BeyondTrust, ARMORY CASTLE and BT26-05, aktualizacja 16 października 2026, 12:00 EDT — chronologia oraz rozróżnienie Remote Support i PRA.
  3. Mandiant i Google Threat Intelligence Group, ARMORY CASTLE Exploits BeyondTrust, 15 października 2026 — ustalenia dochodzenia i zalecenia oceny wcześniejszego dostępu.

Redakcja cyberinsight.pl.