BeyondTrust CVE-2026-102764: patch, dovezi, apoi rotire

Ce este confirmat

CISA descrie CVE-2026-102764 ca o vulnerabilitate critică de bypass al autentificării în BeyondTrust Remote Support (fost Bomgar), versiunile 26.2.3 și anterioare, pentru instalările găzduite de client. Spune că actori o exploatează activ pentru acces inițial, persistență, escaladare de privilegii și mișcare laterală. CISA nu dă un scor CVSS și nu detaliază cauza tehnică.

Patch-ul este BT26-05-RS, pentru versiunile suportate 24.3.1 și mai noi; sistemele mai vechi de 24.3.1 trebuie actualizate înainte. Instanțele găzduite de BeyondTrust (SaaS) au fost deja reparate, fără acțiune din partea clientului. Potrivit BleepingComputer, BeyondTrust nu a găsit o cale de exploatare pentru Privileged Remote Access (PRA), dar PRA folosește cod comun și compania recomandă patch imediat și pentru PRA găzduit de client.

• ▸CISA — BeyondTrust Remote Support, CVE-2026-102764
• ▸Google Threat Intelligence/Mandiant — ARMORY CASTLE exploatează BeyondTrust
• ▸BleepingComputer — BeyondTrust repară un zero-day exploatat din august
• ▸CISA — catalogul Known Exploited Vulnerabilities

Ce a făcut atacatorul, potrivit Mandiant

Mandiant descrie, dintr-o investigație, un webshell PHP personalizat instalat la aproximativ 11 minute după prima cerere POST, escaladare la root printr-o permisiune de fișier modificată greșit, extragerea seifului de credențiale cu utilitarul intern pentru secrete și ștergerea jurnalelor. Persistența s-a făcut prin modificarea șabloanelor de configurare ale BeyondTrust, astfel încât contul de serviciu să primească root fără parolă; modificarea se reaplică la pornire și supraviețuiește resetărilor de configurație.

Pentru mișcare laterală, atacatorul a ridicat rolurile Jump Item și Team ale unui cont compromis la Administrator, ceea ce i-a dat acces permanent la sistemele din aval, apoi a folosit sesiuni de suport ca să extragă fișiere din stații interne. A folosit și un tunel SOCKS5 prin WebSocket și a modificat configurația reverse proxy-ului ca să-l expună. Mandiant nu a putut recupera fișierul din prima cerere POST și notează că, din cauza ștergerii jurnalelor, amploarea completă poate să nu fie vizibilă pe aparat.

• ▸Google Threat Intelligence/Mandiant — tehnici și detecție

Ce rămâne neconfirmat sau diferă

Atribuirea este „suspectată” și se bazează pe suprapunerea de unelte și tehnici, nu pe o dovadă separată pentru această intruziune. Mandiant nu numește victime, sectoare sau regiuni. Mandiant spune că ARMORY CASTLE a exploatat anterior zero-day-uri în Citrix NetScaler și Ivanti Connect Secure, ceea ce susține profilul actorului, nu intruziunea de față.

Nu am putut citi avizul BeyondTrust BT26-05 (răspuns 403). Sursele diferă ușor: Mandiant datează repararea SaaS pe 9 octombrie, BleepingComputer pe 8 octombrie; un rezumat secundar spune că avizul listează „toate versiunile anterioare lui 26.2.3”, iar înregistrarea CVE spune „până la și inclusiv 26.2.3”. Pentru instalările tale, verifică direct în aviz și în aparat. BleepingComputer citează Shadowserver pentru peste 1.400 de instanțe BeyondTrust expuse, fără să spună câte sunt reparate sau dacă sunt honeypot-uri.

• ▸BleepingComputer — cifre de expunere și cronologie
• ▸Google Threat Intelligence/Mandiant — limite ale analizei

Ordinea pașilor

• ▸Găsește toate instalările Remote Support și PRA găzduite de client, inclusiv cele ale furnizorilor. Notează versiunea și dacă sunt accesibile din Internet.
• ▸Tratează orice aparat accesibil din Internet pe o versiune vulnerabilă în fereastra de exploatare ca posibil compromis până la verificare, cum recomandă Mandiant.
• ▸Înainte de orice modificare, păstrează dovezile: instantaneu al aparatului virtual, cu memorie, sau imaginea discului, plus jurnalele syslog, proxy/WAF și firewall pe toată fereastra de expunere.
• ▸Aplică BT26-05-RS (sau actualizează întâi, sub 24.3.1). Actualizarea închide vulnerabilitatea, dar nu remediază expunerea anterioară.
• ▸Dacă ai indicii de compromitere, izolează, blochează intrarea și ieșirea și reconstruiește dintr-o imagine curată, restaurând doar configurații de dinaintea expunerii.
• ▸Rotește credențialele abia după patch sau reconstruire: Mandiant avertizează că rotirea mai devreme expune credențialele noi unui atacator care încă controlează aparatul. Include administratorii aparatului, utilizatorii /login, secretele API, conturile de furnizor de securitate, credențialele din seif și cele introduse în sesiuni în fereastră.
• ▸Compară utilizatorii, rolurile, conturile API, furnizorii de securitate, Jump Items și destinațiile de evenimente cu o stare de dinainte și elimină ce nu are cerere de modificare sau proprietar.

• ▸Google Threat Intelligence/Mandiant — mitigare și ordine
• ▸CISA — acțiuni recomandate

Ce cauți în loguri

• ▸Evenimente user_changed care ridică rolurile Jump Item sau Team, și modificări user_added, api_account sau security_provider fără cerere de modificare, plus schimbări ale destinațiilor syslog.
• ▸Autentificări reușite la /login din spații rezidențiale sau VPN comercial și autentificări de administrator în afara programului.
• ▸Sesiuni și transferuri de fișiere inițiate de conturi ale căror roluri s-au schimbat în fereastră.
• ▸La proxy sau WAF: căi în afara setului cunoscut de Remote Support, în special PHP neașteptat și upgrade-uri WebSocket din surse neașteptate.
• ▸Pe gazdă: fișiere PHP noi în rădăcina web, binare SUID neașteptate, intrări neautorizate în șabloanele sudoers și modificări ale configurației reverse proxy.
• ▸Întreruperi în redirecționarea syslog mărginite de o singură sesiune, pe care Mandiant le consideră un indiciu puternic de manipulare. Trimite jurnalele în afara aparatului, pentru că un atacator cu acces la gazdă le poate șterge.

• ▸Google Threat Intelligence/Mandiant — ghid de vânătoare

Închide alerta cu dovezi

Pentru fiecare aparat, păstrează versiunea înainte, patch-ul aplicat și data, fereastra de expunere, locul unde sunt păstrate dovezile, rezultatul căutărilor în loguri, lista credențialelor rotite cu data și cine a confirmat, și starea configurației comparată cu o bază. Un termen KEV federal nu se aplică automat companiilor private, dar spune cât de repede se așteaptă remedierea unui aparat de acces privilegiat expus.