En kritisk sårbarhet i BeyondTrust Remote Support ble utnyttet i reelle angrep før feilen var offentlig kjent. Den 15. oktober publiserte BeyondTrust, Google Threat Intelligence Group og Mandiant koordinerte beskrivelser av CVE-2026-102764. Sårbarheten har en CVSS-score på 9,3 og kan utnyttes av en ekstern angriper uten autentisering.
BeyondTrust Remote Support, tidligere kjent som Bomgar, brukes av IT- og supportteam til å administrere eksterne systemer. Det gjør produktet til et attraktivt mål: Enheten står ofte nær internett, har omfattende tilgang og kan håndtere eller formidle privilegerte legitimasjonsopplysninger. Google og Mandiant advarer derfor om at offentliggjøringen kan bli fulgt av bredere og mer opportunistisk utnyttelse.
Dette er ikke en teoretisk risiko. Mandiant fant spor etter at sårbarheten ble brukt som en zero-day allerede i slutten av august 2026, altså før leverandørens sikkerhetsoppdatering og offentlige varsel.
Hva er CVE-2026-102764?
Ifølge BeyondTrust ligger feilen i interne komponenter i Remote Support. Komponentene kontrollerte ikke godt nok hvor mottatte meldinger kom fra. Under riktige forhold kunne en ekstern angriper bruke dette til å utføre filoperasjoner på appliance-en.
Den korte beskrivelsen kan høres begrenset ut, men den praktiske konsekvensen er alvorlig. Mandiant skriver at vellykket utnyttelse kan gi mulighet til å laste opp vilkårlige filer, oppnå kontroll på vertsnivå og få tilgang til legitimasjonsopplysninger som systemet lagrer eller formidler. Et supportverktøy som skal gi administratorer kontroll over andre maskiner, kan dermed bli angriperens springbrett inn i virksomheten.
Sårbarheten gjelder BeyondTrust Remote Support til og med versjon 26.2.3. BeyondTrust opplyser at SaaS-kunder fikk rettelsen automatisk 9. oktober. Selvhostede kunder må kontrollere at oppdateringen BT26-05-RS er installert. Installasjoner eldre enn versjon 24.3.1 må først oppgraderes til en støttet versjon før patchen kan legges inn.
Utnyttet før offentliggjøringen
Under et hendelsesoppdrag fant Mandiant bevis på at en trusselaktør hadde utnyttet sårbarheten i slutten av august. Google sporer gruppen som ARMORY CASTLE, tidligere UNC5221, og vurderer den som knyttet til kinesisk spionasjeaktivitet. BeyondTrust skriver at CrowdStrike følger den samme aktivitetsklyngen under navnet WARP PANDA.
Attribusjon i cybersikkerhet er sjelden matematisk sikker. Den bygger på en samlet vurdering av infrastruktur, verktøy, arbeidsmåter, målvalg og likheter med tidligere operasjoner. BeyondTrust beskriver vurderingen som moderat til høy konfidens, mens Google Threat Intelligence Group oppgir høy konfidens for at aktøren vil fortsette å bruke zero-day-sårbarheter i perimeterutstyr som inngang til organisasjoner.
Etter den første tilgangen skal angriperne ha vist inngående kjennskap til BeyondTrust-appliance-ens interne arkitektur. Mandiant observerte blant annet misbruk av proprietære kommandolinjeverktøy, oppstartskonfigurasjoner og lokal proxy-ruting. Gruppen brukte også en webshell kalt SAWFLY og et tunnelverktøy kalt BARECLAW for å opprettholde og bruke tilgangen. Samtidig ble logger og andre spor slettet for å gjøre oppdagelse og analyse vanskeligere.
Dette mønsteret forklarer hvorfor det ikke er tilstrekkelig å se at systemet fungerer normalt. En kompromittert appliance kan fortsatt levere den forventede tjenesten mens angriperen beholder en skjult tilgang.
Hvorfor offentliggjøringen øker risikoen
Før en sårbarhet blir kjent, kan én aktør ha et betydelig forsprang. Etter offentliggjøringen begynner andre grupper å analysere patchen, leverandørens varsel og tekniske spor. Målet er å rekonstruere feilen og utvikle egne utnyttelsesmetoder før alle sårbare systemer er oppdatert.
Google og Mandiant fremhever at ARMORY CASTLE tidligere har gått fra selektiv zero-day-utnyttelse til bredere, opportunistiske kampanjer etter offentliggjøring. Det betyr at tidsvinduet for forsvarere er kort. Virksomheter som eksponerer Remote Support mot internett, bør ikke vente på et generelt varsel fra en nasjonal myndighet eller på at sårbarheten dukker opp i en senere revisjon.
Det er også mulig at kriminelle grupper forsøker å kopiere teknikken. De trenger ikke å forstå hele angrepet eller bruke de samme skadevareverktøyene. Hvis de klarer å gjenskape den første tilgangen, kan de kombinere den med egne metoder for løsepengevirus, datatyveri eller utpressing.
Patching er første steg, ikke hele løsningen
Sikkerhetsoppdateringen lukker den kjente sårbarheten, men den fjerner ikke nødvendigvis en tilgang som allerede er etablert. En appliance som var internetteksponert med en sårbar versjon i angrepsperioden, bør derfor behandles som potensielt kompromittert inntil en undersøkelse viser noe annet.
Dette skillet er avgjørende. Sårbarhetshåndtering svarer på spørsmålet «er feilen rettet nå?». Hendelseshåndtering svarer på et annet spørsmål: «ble feilen utnyttet før vi rettet den?». En grønn status på oppdateringssiden kan bare svare på det første.
Mandiant anbefaler en patch-først-tilnærming, etterfulgt av kontroll av eksponering og mulige kompromitteringsspor. Virksomheter bør samtidig planlegge for at enkelte relevante logger kan være slettet. Fravær av åpenbare spor er derfor ikke automatisk det samme som fravær av innbrudd.
Tiltak for selvhostede installasjoner
1. Finn alle Remote Support-installasjoner
Lag en oppdatert oversikt over appliances, versjoner og eksponering mot internett. Ikke stol utelukkende på dokumentasjonen. Kontroller DNS, brannmurregler, eksterne skanninger og skyløsninger for å finne systemer som kan ha blitt etablert utenfor den sentrale oversikten.
2. Installer BT26-05-RS umiddelbart
Selvhostede systemer fra versjon 24.3.1 til og med 26.2.3 skal ha den aktuelle patchen. Eldre installasjoner må oppgraderes før oppdateringen kan brukes. Dersom patchen ikke vises i appliance-grensesnittet, anbefaler BeyondTrust å kontakte support og vise til BT26-05.
Automatiske oppdateringer bør bekreftes, ikke antas. Registrer tidspunktet for installasjonen slik at det kan sammenlignes med perioden systemet var eksponert.
3. Undersøk mulig tidligere kompromittering
Gjennomgå appliance-logger, nettverkstrafikk, identitetslogger og hendelser på systemer som Remote Support kunne nå. Google og Mandiant har publisert tekniske indikatorer og beskrivelser av observerte metoder som sikkerhetsteam kan bruke i jakten.
Fordi angriperen skal ha slettet lokale spor, bør analysen også bruke eksterne datakilder: sentralisert logging, EDR, brannmurer, DNS, proxy-logger, identitetsplattformen og skyløsninger. Data som bare lå lokalt på appliance-en, kan være ufullstendige.
4. Roter legitimasjonsopplysninger og avslutt aktive sesjoner
Dersom en sårbar, internetteksponert appliance kan ha vært kompromittert, bør virksomheten identifisere hvilke kontoer, nøkler, tokens og sertifikater den kunne lagre eller formidle. Berørte hemmeligheter bør roteres, og aktive sesjoner bør tilbakekalles der det er mulig.
En angriper som allerede har hentet gyldige legitimasjonsopplysninger, mister ikke denne tilgangen bare fordi sårbarheten blir patchet.
5. Begrens produktets rekkevidde
Remote Support bør bare kunne nå systemene og nettverkssonene som er nødvendige for supportoppgavene. Administrative kontoer bør være separate, tidsbegrensede og beskyttet med sterk flerfaktorautentisering. Nettverkstilgang fra appliance-en bør overvåkes og begrenses etter prinsippet om minste privilegium.
Hva SaaS-kunder bør kontrollere
BeyondTrust opplyser at alle Remote Support SaaS-miljøer ble oppdatert 9. oktober, og at kundene ikke trenger å installere selve appliance-patchen. Det betyr likevel ikke at alle oppfølgingsaktiviteter kan hoppes over.
SaaS-kunder bør lese leverandørens hendelsesinformasjon, kontrollere om deres konfigurasjon eller tilknyttede legitimasjonsopplysninger krever oppfølging, og gjennomgå unormal aktivitet i egne målmiljøer. Ansvaret er delt: Leverandøren sikrer plattformen, mens kunden fortsatt må kontrollere identiteter, endepunkter og systemene tjenesten har tilgang til.
Et høyt privilegert verktøy må behandles som kritisk infrastruktur
Hendelsen viser hvorfor fjernadministrasjonsverktøy krever en strengere sikkerhetsmodell enn vanlige forretningsapplikasjoner. De er laget for å omgå den fysiske avstanden mellom administratoren og systemet som skal styres. Nettopp derfor kan de gi en angriper uvanlig stor rekkevidde.
Virksomheter bør vite hvilke slike tjenester de bruker, hvem som eier dem, hvilke kontoer de håndterer og hvor raskt kritiske oppdateringer kan installeres. De bør også ha en plan for å undersøke verktøyet dersom leverandøren varsler om aktiv utnyttelse.
CVE-2026-102764 er et konkret teknisk problem med en tilgjengelig rettelse. Den vanskeligere delen er å avgjøre om noen rakk å bruke feilen før rettelsen kom. Organisasjoner som bare patcher, har redusert den fremtidige risikoen. Organisasjoner som også undersøker eksponeringen, roterer hemmeligheter og jakter på tidligere aktivitet, håndterer selve hendelsen.