A suspected Chinese espionage crew was exploiting BeyondTrust Remote Support about seven weeks before public disclosure. If you run a self-hosted appliance, patching is only the start: you need to check whether it was already owned.
What happened
On 15 October 2026 BeyondTrust published advisory BT26-05 for CVE-2026-102764, a critical flaw in Remote Support, the remote access product many of us still call Bomgar. The disclosure was coordinated with Mandiant and Google Threat Intelligence Group (GTIG), which say a suspected PRC-nexus espionage group exploited the bug as a zero-day from late August. Google now tracks that group as ARMORY CASTLE; until recently it was UNC5221, and CrowdStrike calls it WARP PANDA.
BeyondTrust’s own timeline says the attackers hit two targets on 29 August: one Remote Support instance hosted by BeyondTrust and one self-hosted appliance. Its own threat hunters only spotted the activity on 28 September, during a hunt prompted by exploitation at another security vendor, and contained the affected instance 27 minutes after first detection. Mandiant passed on matching findings from a self-hosted customer two days later. Fixes shipped on 8 October. SaaS customers were patched automatically, with Mandiant putting completion at 9 October.
The bug affects every supported Remote Support release up to and including 26.2.3. Privileged Remote Access (PRA) shares the vulnerable code. BeyondTrust says its testing found no way to exploit PRA, but it has issued a precautionary patch anyway. According to BleepingComputer, Shadowserver sees more than 1,400 BeyondTrust remote support instances online, though not how many are patched or honeypots.
The technical picture
BeyondTrust and Google have released few details of the flaw itself. BleepingComputer describes it as an authentication bypass. Mandiant says it lets an unauthenticated remote attacker carry out file operations on the appliance, which in practice means writing arbitrary files. What the attackers did after that is better documented, because Mandiant has published the post-exploitation chain:
- Foothold: roughly 11 minutes after the first malicious request, a PHP webshell that Google has named SAWFLY appeared in the web root. Its traffic is RC4-encrypted and it returns a 404 to any request that lacks a specific parameter, so a casual scan will not find it.
- Root: the webshell ran as an unprivileged service account. The actor copied the system shell to an innocuous-looking path under /usr/bin, gave it root ownership and set the SUID bit. That left them a permanent route to root.
- Credentials: with root access, they used BeyondTrust’s own bt-secrets utility to try to dump the appliance vault and then deleted that tool’s log.
- Persistence: they placed a startup script that adds passwordless sudo to the appliance’s sudoers template and then rebuilds the live file. The change therefore survives reboots and configuration resets.
- Onward access: they logged into the admin portal with a compromised administrator account and gave it full Administrator rights over Jump Items and teams, then opened support sessions to internal machines and used the product’s file transfer to take documents such as software inventories.
- Tunnelling: a custom C tool called BARECLAW provided a SOCKS5 proxy over WebSockets. The appliance’s own HAProxy configuration was edited so that one obscure URL path reached it from the internet.
Logs were wiped repeatedly across system, web server and application, which is why off-box logging matters.
Why it matters for UK organisations
Remote Support appliances are normally deployed for IT service desks, outsourced support providers and managed service providers, and the UK has plenty of all three. By design it holds or brokers credentials for the systems it reaches and already has an approved path inside. Root on the appliance gives an attacker most of what they need, hidden in traffic from a tool staff use daily.
There is history here. Earlier in 2026 another Remote Support and PRA flaw, CVE-2026-1731, was used in ransomware intrusions. The group also has form: after the Ivanti Connect Secure disclosures in early 2024, it switched from selective zero-day use to mass opportunistic exploitation. Google warns that the same could happen now that CVE-2026-102764 is public. For UK operators, the window between disclosure and widespread scanning should be measured in days, not weeks.
Under the Cyber Security and Resilience Bill, managed service providers are being brought into scope. A remote-access appliance compromised at an MSP is exactly the supply chain incident that regulators will expect providers to have detected, contained and reported promptly.
Expert view
When we test organisations, remote support and privileged access platforms are among the first things I look for, because they are a shortcut to everything else. This campaign shows why: no noisy lateral movement tooling, just a stolen admin account given more rights and the product’s normal features. Detection depends on spotting legitimate actions by the wrong person.
The detail that worries me most is the persistence. The attackers wrote to configuration templates and startup directories that customers cannot easily inspect, so a patch on its own does not remove them. Mandiant is blunt about this: if an appliance was internet-facing on a vulnerable build during the window, treat it as potentially compromised until a review says otherwise. Where you cannot rule it out, rebuild from a clean image rather than reboot and hope. In my experience that step is often skipped because the appliance seems fine, which is how attackers keep quiet access for months.
Order matters too. Mandiant advises rotating credentials once the box is patched or rebuilt, not before. Rotate first and you hand the fresh secrets to whoever still controls it.
What to do now
- Patch self-hosted appliances today. Apply BT26-05-RS through the /appliance interface, or confirm that automatic updates have installed it. Builds older than 24.3.1 must first move to a supported release. Apply the precautionary PRA fix too. (Cyber Essentials: security update management.)
- Preserve evidence before you change anything. Snapshot virtual appliances and collect perimeter firewall, reverse proxy and syslog data for the whole period since late August. The attackers deleted on-box logs, so these may be your only record.
- Hunt for the published indicators. Look for unexpected PHP files in the web root, SUID binaries that should not exist, new scripts in startup directories, sudoers template changes, unfamiliar HAProxy routes and gaps in syslog forwarding.
- Review the admin plane. Look for Jump Item or team roles raised to Administrator, new API accounts, logins from commercial VPN or residential address space, and file transfers during the exposure window. Every endpoint that was touched is in scope for follow-up.
- Rebuild where in doubt, then rotate. Rotate appliance, admin, API, vault, directory bind and integration secrets only after patching or rebuilding.
- Shrink the exposure. Restrict /login and /appliance to management networks, apply default-deny egress filtering, and enforce SSO with phishing-resistant MFA for all administrators. (Cyber Essentials: firewalls, secure configuration, user access control.)
If you find signs of exploitation, BeyondTrust asks customers to raise a Sev 1 case that cites BT26-05. UK organisations should also consider reporting to the NCSC.
Bottom line
A capable state-linked actor had up to seven weeks of undisclosed zero-day access through a product built for privileged entry into corporate networks. Patch now. Then assume the worst for any internet-facing appliance that was on a vulnerable version, and prove otherwise before you trust it again.
Sources
- Google Cloud (Mandiant/GTIG): ARMORY CASTLE Exploits BeyondTrust
- BeyondTrust: ARMORY CASTLE and BT26-05: What Security Teams Need to Know
- BleepingComputer: BeyondTrust patches zero-day exploited in attacks since August
- GBHackers: Google Warns Chinese Hackers Exploited Critical BeyondTrust Zero-Day to Gain Root Access
- Cyber Security News: Chinese Hackers Exploit BeyondTrust Zero-Day to Gain Root Access and Deploy Backdoors
