BeyondTrust Remote Support CVE-2026-102764 (BT26-05): siedem tygodni zero-daya w sejfie poświadczeń. Zabezpiecz dowody, odbuduj, dopiero potem rotuj

15 października BeyondTrust ujawnił CVE-2026-102764 (advisory BT26-05) w Remote Support: nieuwierzytelniony atakujący może wykonywać operacje na plikach appliance. Dzień później CVE trafiło do CISA KEV z terminem na 19 października. Według Google Threat Intelligence Group i Mandiant aktor ARMORY CASTLE wykorzystywał tę lukę jako zero-day od końca sierpnia, czyli przez około siedem tygodni przed ujawnieniem, i to na urządzeniu, które przechowuje poświadczenia do całej infrastruktury i pośredniczy w ich użyciu. Aktor kasował logi przez cały czas trwania incydentu. W takiej sytuacji patch jest konieczny, ale nie wystarczy: trzeba założyć kompromitację.

CVE-2026-102764 (Remote Support, CVSS 4.0 9.3, CWE-290): wewnętrzne komponenty „did not adequately validate the origin of the messages it received”, co pozwala na „file operations on the appliance” (rekord CNA BeyondTrust). Wektor CNA: AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H. NVD dodało własną ocenę CVSS 3.1 9.8.

Threat state: zero-day od końca sierpnia 2026 (GTIG/Mandiant). CISA KEV od 16.10, termin 19.10, forensicTriage: Yes. SSVC (CISA): exploitation active, automatable yes, technical impact total.

Skala skutków: GTIG pisze, że luka może prowadzić do „host-level control and access to every credential the appliance stores or brokers”.

Oś czasu

late Aug 2026 ARMORY CASTLE exploits CVE-2026-102764 as a zero-day (Mandiant IR) 2026-10-09 BeyondTrust patches all SaaS tenants (per GTIG, Canadian Cyber Centre) 2026-10-15 BT26-05 / CVE-2026-102764 disclosed; GTIG blog published 2026-10-16 CISA KEV (dueDate 2026-10-19, forensicTriage: Yes); Cyber Centre AL26-025 2026-10-19 KEV due date

Klienci SaaS dostali poprawkę sześć dni przed ujawnieniem i nie muszą nic instalować. Klienci on-prem dowiedzieli się o luce dopiero 15 października. Dla obu grup okno ekspozycji zaczyna się jednak w sierpniu, a nie w dniu publikacji advisory, więc w SaaS też trzeba przejrzeć audyt sesji i kont z tego okresu.

Attack path według GTIG/Mandiant

POST /app_84304470%2Ephp -> staging webshell (not recovered) ~11 min later: SAWFLY webshell mangoapi.php in .../ingredi/app/laravel/public/ cp /bin/sh -> /usr/bin/dbus-authd, chown root, SUID -> root backdoor /ns/sbin/bt-secrets get ... vault -> dump of the appliance vault rm -f /home/bomgar/log/bt-secrets.log* -> cleanup /home/bomgar/sbin/post_boot.d/zz-root-persist -> sudoers.template, survives reboot + config reset log wiping: /ns/log/auth.log, ssl.log, http-access.log, /var/log/messages, httpd_access/error.log admin portal: Jump Item / Team role No Access -> Administrator -> sessions to downstream hosts BARECLAW /tmp/ingredi_ws --listen 19800 ... --ws-path /uidchanarge /ns/config/haproxy.conf: path /uidchanarge -> 127.0.0.1:19800 -> SOCKS5 over WebSocket from the internet

GTIG przypisuje działanie ARMORY CASTLE, podejrzanemu aktorowi szpiegowskiemu powiązanemu z ChRL (wcześniej śledzonemu jako UNC5221). SAWFLY to lekki, zaciemniony webshell PHP z szyfrowanym kanałem C2 (Base32 + RC4), który bez właściwego parametru zwraca 404, żeby nie wykryły go skanery. BARECLAW to proxy SOCKS5 po WebSocket, słuchające tylko na localhost, ale dostępne z internetu przez dopisaną regułę HAProxy. W fazie lateral movement aktor zalogował się przejętym kontem administratora, nadał sobie pełne uprawnienia do Jump Items i przez sesje wsparcia wyciągał z pulpitów użytkowników inwentarz oprogramowania.

Exposure: wersje i poprawka

Advisory BeyondTrust (trust center i blog) zwracało mi HTTP 403, także przez archiwum, więc nie przeczytałem go bezpośrednio. Zakres wersji pochodzi z rekordu CNA opublikowanego przez BeyondTrust, a szczegóły poprawki z GTIG i Cyber Centre:

Podatne: Remote Support do 26.2.3 włącznie (rekord CNA BeyondTrust; GTIG: „all supported Remote Support versions up to 26.2.3”). Cyber Centre w AL26-025 ostrzega dodatkowo, że w praktyce należy traktować wszystkie wersje jako potencjalnie podatne.

Self-hosted 24.3.1–26.2.3: patch BT26-05-RS (wg GTIG i Canadian Cyber Centre).

Self-hosted starsze niż 24.3.1: najpierw upgrade do wspieranej wersji, potem patch (wg GTIG i Canadian Cyber Centre).

SaaS: załatany 9.10.2026, bez działań po stronie klienta (wg GTIG i Canadian Cyber Centre).

Privileged Remote Access (PRA): niepotwierdzone. Rekord CNA i wpis KEV wymieniają tylko Remote Support. Cyber Centre pisze, że poprawkę zastosowano u klientów SaaS Remote Support i PRA, ale nie wymienia self-hosted PRA jako podatnego. GTIG wspomina PRA tylko przy rotacji poświadczeń. Jeśli masz PRA on-prem, sprawdź to w samym advisory BT26-05, zanim zamkniesz ten wątek.

Dlaczego tu trzeba założyć kompromitację

Długie okno i cenny cel. Około siedmiu tygodni zero-daya na urządzeniu, które trzyma sejf poświadczeń i ma uprawnione sesje do systemów docelowych. Aktor wiedział, co tam jest: celował w bt-secrets i w globalny sejf appliance.
Brak wiarygodnych logów. GTIG: „Mandiant determined that the actor removed logs throughout the incident.” Brak śladów w logach appliance nie oznacza braku włamania.
Hosta nie da się zaudytować. GTIG: „Customers cannot audit the appliance host file system, and host-level persistence survives reboot and configuration reset.” Persystencja przez post_boot.d i sudoers.template przetrwa restart i przywrócenie konfiguracji.
Patch nie cofa skutków. GTIG: „Upgrading closes the vulnerability but does not remediate prior exposure.” Tak samo było przy Ivanti Connect Secure: aktualizacja zamyka wejście, ale nie unieważnia tego, co już wyciekło.

GTIG formułuje regułę wprost: każde appliance dostępne z internetu na podatnej wersji w oknie eksploatacji „should be treated as potentially compromised until it has been reviewed”.

Kolejność: dowody, odbudowa, rotacja

Najważniejsza jest kolejność. Rotacja przed odbudową oddaje nowe hasła aktorowi, który wciąż kontroluje urządzenie. Poniżej zalecenia GTIG/Mandiant w kolejności wykonania:

1. Zabezpiecz dowody: snapshot appliance wirtualnego razem z pamięcią i eksport dysków przed jakąkolwiek zmianą. Zbierz logi reverse proxy/WAF i firewalla, bo „an attacker with host access can delete on-appliance logs”. Podobnie jak przy NetScalerze, patch nałożony przed snapshotem może zatrzeć ślady.

2. Odbuduj, nie czyść: przy potwierdzonej lub nieznanej kompromitacji redeploy z czystego, w pełni załatanego obrazu. Przywracaj tylko kopię konfiguracji sprzed okna ekspozycji i wystaw nowy certyfikat TLS.

3. Rotuj po odbudowie: GTIG: „Rotate credentials only after the appliance has been patched or rebuilt.” Kolejność według GTIG: poświadczenia /appliance, administratorzy /login, sekrety API, poświadczenia z sejfu i PRA. Hasła z sejfu zmieniaj na systemach docelowych, a nie tylko w sejfie.

4. Przejrzyj konfigurację: zdarzenia user_changed podnoszące rolę Jump Item do Administrator, nieoczekiwane konta API, security providers i docelowe adresy syslog.

Co da się sprawdzić

GTIG publikuje w artykule takie artefakty: pliki app_84304470%2Ephp (staging, bez hasha), mangoapi.php (SAWFLY, SHA-256 dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb), ingredi_ws (BARECLAW, SHA-256 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462), a także /usr/bin/dbus-authd, /home/bomgar/sbin/post_boot.d/zz-root-persist, ścieżkę /uidchanarge, port TCP 19800 i modyfikację /ns/config/sudoers.template. Pełna lista IoC jest w kolekcji GTI dla zarejestrowanych użytkowników. Są też reguły YARA G_Hunting_Webshell_SAWFLY_1 i G_Hunting_Backdoor_BARECLAW_1. Na hosta i tak nie zajrzysz, więc polowanie prowadź głównie po zewnętrznych danych. GTIG zaleca szukać logowań do /login z adresów domowych lub VPN, zdarzeń transferu plików, upgrade’ów WebSocket z nieoczekiwanych źródeł, żądań do nieznanych ścieżek .php i przerw w przekazywaniu sysloga. Brak trafień niczego nie wyklucza, bo aktor czyścił logi.

KEV z terminem w poniedziałek

CISA dała trzy dni (16.10 → 19.10), a w requiredAction łączy poprawki z BOD 26-04 i „Forensics Triage Requirements”. Dla SaaS dodaje osobną ścieżkę: stosowanie wytycznych BOD 26-04 dla usług chmurowych albo zaprzestanie korzystania z produktu. Finding dla CVE-2026-102764 w wersji on-prem ma więc cztery warunki zamknięcia: zabezpieczone dowody, appliance odbudowane z czystego obrazu na poprawionej wersji, udokumentowany compromise assessment od końca sierpnia i potwierdzoną rotację sekretów na systemach docelowych. Rotacja dotyczy też systemów za Jump Items, do których aktor mógł otwierać sesje, co przypomina skalę sprzątania po ScreenConnect.

Co powinien zrobić VE

(1) Zinwentaryzuj wszystkie instancje Remote Support (i PRA, póki status jest niepotwierdzony): SaaS czy self-hosted, dokładna wersja, ekspozycja do internetu od sierpnia. (2) Dla self-hosted ustal ścieżkę: patch BT26-05-RS albo upgrade + patch dla wersji poniżej 24.3.1. Najpierw zrób snapshot, potem aktualizację. (3) Otwórz incydent z właścicielem po stronie IR dla każdej instancji wystawionej do internetu, bez czekania na trafienia IoC. (4) Uzgodnij z właścicielami systemów docelowych plan rotacji i wykonaj go dopiero po odbudowie. (5) Dla SaaS przejrzyj audyt kont, ról Jump Item i sesji od końca sierpnia do 9.10. Szerszy kontekst priorytetyzacji urządzeń brzegowych opisywałem w tekście o KEV dla appliance’ów.

Powiązane na blogu

Ivanti Connect Secure CVE-2026-104935 — załatane to nie to samo co naprawione
NetScaler CVE-2026-88771/88772 — patch zamyka RCE, ale może zmienić ślady
ScreenConnect — remediation narzędzia zdalnego dostępu
Cisco FMC CVE-2026-20079 — dlaczego hotfix nie jest końcem remediation

Źródła

BeyondTrust — Security Advisory BT26-05 (15.10.2026; HTTP 403, nieodczytane bezpośrednio) — beyondtrust.com
BeyondTrust — blog BT26-05 (referencja „Vendor Advisory” w rekordzie CNA; HTTP 403, nieodczytane bezpośrednio) — beyondtrust.com
NVD — CVE-2026-102764 (rekord CNA BeyondTrust: CVSS 4.0 9.3, CWE-290, wersje ≤ 26.2.3; SSVC CISA) — nvd.nist.gov
CISA Known Exploited Vulnerabilities Catalog — CVE-2026-102764 (dodane 16.10.2026, termin 19.10.2026, forensic triage) — cisa.gov
Google Threat Intelligence Group / Mandiant — ARMORY CASTLE Exploits BeyondTrust (15.10.2026) — cloud.google.com
Canadian Centre for Cyber Security — AL26-025 Critical vulnerability impacting BeyondTrust Remote Support (16.10.2026) — cyber.gc.ca
Canadian Centre for Cyber Security — BeyondTrust security advisory (AV26-1054) — cyber.gc.ca

Nota redakcyjna: stan informacji 18 października 2026. Advisory BeyondTrust BT26-05 i wpis na blogu producenta zwracały HTTP 403, więc nie przeczytałem ich bezpośrednio. Zakres wersji (≤ 26.2.3) pochodzi z rekordu CVE opublikowanego przez BeyondTrust jako CNA, a patch BT26-05-RS, próg 24.3.1 i data załatania SaaS (9.10) z GTIG i Canadian Cyber Centre. To, czy podatne jest Privileged Remote Access w wersji self-hosted, pozostaje niepotwierdzone w źródłach, które czytałem. Łańcuch ataku, artefakty, hashe i zalecenia (zabezpieczenie dowodów, odbudowa, kolejność rotacji) pochodzą z GTIG/Mandiant. Przed wdrożeniem sprawdź aktualną wersję BT26-05.