BeyondTrust Zero-Day Turns Remote Support Into A Lateral-Movement Path

BeyondTrust and Google Threat Intelligence Group disclosed CVE-2026-102764 on October 15 after a suspected China-nexus espionage actor exploited the flaw as a zero-day on August 29. The critical Remote Support vulnerability lets an unauthenticated remote attacker perform file operations through an internal messaging component that did not adequately validate message origin. Mandiant observed the actor turn that primitive into a webshell, root persistence, a covert tunnel, administrative access to Remote Support, and sessions into downstream systems. BeyondTrust says the confirmed activity involved one company-hosted Remote Support instance and one self-hosted appliance.

All Remote Support versions through 26.2.3 are affected. BeyondTrust shipped the BT26-05 patch on October 8 and says all Remote Support SaaS instances were patched by October 9. Self-hosted customers on 24.3.1 or later must confirm the BT26-05-RS patch in the /appliance interface; older deployments must first upgrade to a supported release. Patching closes the entry path but does not remove persistence, restore deleted evidence, or make brokered credentials trustworthy. Any internet-reachable appliance that ran a vulnerable version during the exposure window needs a compromise review built on off-box logs and downstream identity and endpoint evidence.

BeyondTrust dates the confirmed exploitation to August 29. Its public timeline says the actor reached a single BeyondTrust-hosted Remote Support instance and a single self-hosted Remote Support appliance. On September 28, a proactive hunt across BeyondTrust telemetry surfaced the hosted event after a separate edge-appliance campaign and a non-specific Mandiant notification raised attention. BeyondTrust says it contained that instance within 27 minutes of detection and reproduced the entry vector later that day.

Mandiant shared findings from the self-hosted customer on September 30. BeyondTrust completed variant analysis and shipped BT26-05 to SaaS and self-hosted customers on October 8, then had all Remote Support SaaS instances patched by October 9. The coordinated advisory, CVE record, vendor account, and Mandiant analysis arrived on October 15. That sequence matters to defenders: compromise preceded public disclosure and the general patch notice by weeks, so a clean post-patch scan cannot answer what happened earlier.

The two confirmed appliances are a lower bound, not a population estimate. Google Threat Intelligence Group attributes the observed operation to ARMORY CASTLE, formerly tracked as UNC5221, and assesses that this suspected PRC-nexus actor may move from selective zero-day use to broader exploitation after disclosure. That is an intelligence forecast based on prior behavior, not evidence that every exposed appliance has been attacked. Organizations should separate the confirmed incidents, the actor attribution, and the forecast when briefing leadership.

BT26-05 describes improper origin validation in an internal Remote Support messaging component. Under the right conditions, an unauthenticated remote attacker can perform file operations on the appliance. BeyondTrust is withholding further vulnerability mechanics while customers patch. Mandiant describes successful exploitation as arbitrary file upload, which is consistent with the observed placement of a webshell, but defenders should not invent a request format or exposure condition that the public record does not provide.

The affected set is broad within Remote Support: all supported versions up to and including 26.2.3. Self-hosted systems from 24.3.1 through 26.2.3 can receive the BT26-05-RS patch through the /appliance interface. Older systems must be upgraded before applying it. An administrator should record the full running version and patch inventory from the appliance itself, not treat a downloaded package, an update subscription, or a scheduled maintenance ticket as deployment proof.

Privileged Remote Access requires a precise distinction. BeyondTrust says Remote Support was confirmed vulnerable. Its internal testing has not identified a way to exploit Privileged Remote Access, but PRA shares the affected code, so the company issued and recommends the companion patch as a precaution. The security advisory formally lists Remote Support as the impacted product. Cloud and self-hosted ownership also differ: BeyondTrust handled the SaaS appliance patch, while each self-hosted customer must verify its own update.

Mandiant found that the actor created the SAWFLY PHP webshell about 11 minutes after the first observed exploit-related request. SAWFLY hid behind a normal 404 response unless an obfuscated parameter was present, then decoded and executed encrypted PHP supplied by the operator. The webshell initially ran as the site service account. The actor copied a shell binary to another path with the set-user-ID bit and later modified an appliance sudoers template, forcing the product configuration utility to rebuild active sudo policy with passwordless root access for that service account.

Persistence was designed to survive operations that might remove a one-off file change. The actor altered a startup script and a configuration template, then systematically deleted host, web, application, and temporary SSH logs. It installed BARECLAW, a custom SOCKS5 tunneler, and changed HAProxy configuration so a specific public web path forwarded to a local-only listener. That design let the tunnel sit behind the appliance's existing web service rather than expose a separately scannable port.

Appliance control became a downstream access path. Mandiant observed the actor use compromised administrator credentials, change Jump Item and Team permissions from No Access to Administrator, open a Remote Support session to an internal endpoint, and use the native file-transfer feature to collect documents useful for network reconnaissance. The public report confirms document exfiltration in the investigated environment. It does not establish which data, systems, or credentials were reached at other organizations.

A Remote Support appliance is valuable because it mediates trusted sessions between technicians and many endpoint types. BeyondTrust documentation describes it as the focal point for session traffic, with the ability to manage Jump Items, transfer files, integrate with directories, and inject credentials from an endpoint credential manager or the appliance's own vault. Those normal functions expand incident scope when the control plane itself is compromised.

Scoping therefore cannot stop at the Linux host. Build an inventory of every Jump Group and Jump Item reachable during the exposure period, every local or federated administrator, every vault or external credential-manager integration, and every support session initiated by the appliance. Review whether permissions changed, whether new accounts or multifactor methods appeared, and whether managed endpoints accepted connections outside known tickets. Session identity, source network, target, transferred files, and technician approval should reconcile.

Network placement matters after patching as well. Limit public exposure to the services customers actually need, keep /appliance administration on trusted paths, constrain appliance egress to documented destinations, and monitor both directions. These controls do not repair a vulnerable build or prove historical cleanliness. They reduce the routes available to an attacker and make deviations from normal support traffic easier to see.

Start with the patch because continued exposure makes every other response step unstable. Confirm BT26-05-RS on supported self-hosted versions and upgrade anything older than 24.3.1 before applying it. If the patch is absent from the appliance interface, BeyondTrust and Mandiant direct customers to open a support case. Record the installation time, successful service state, and external reachability before and after maintenance.

Then answer the historical question. Mandiant says exploit evidence can appear in access, syslog, messages, thin-scc, brain, and SSL logs stored on the encrypted /home partition. The observed actor also deleted local records. Preserve the appliance before invasive work when compromise is plausible, but prioritize copies already forwarded to syslog, SIEM, identity, firewall, DNS, proxy, endpoint, and ticketing systems. BeyondTrust supports up to three remote syslog servers and TLS transport, making off-box retention a design control rather than an incident-only workaround.

Hunt behavior as well as hashes. Review web service accounts spawning shells, unexpected scripts in web roots, changes to sudoers templates and startup configuration, unknown administrative sessions from residential or commercial VPN addresses, Jump Item or Team permission escalation, HAProxy changes, log-forwarding gaps, and endpoint support sessions without matching tickets. Mandiant publishes hashes and YARA rules for SAWFLY and BARECLAW, but both Google and BeyondTrust warn that the actor rotates infrastructure and tooling.

If any credible sign is present, treat appliance content and brokered trust as exposed. Image or snapshot the system according to the response plan, coordinate a clean recovery with BeyondTrust, and do not rely on deleting the named webshell or tunnel. Validate boot and configuration templates, local accounts, certificates, integrations, and reverse-proxy rules from trusted baselines. Reconnect the appliance only after the patch and hardening state are independently verified.

Rotate every credential the appliance stored, injected, or could retrieve, including local and federated administrators, vault integrations, service accounts, API keys, directory binds, support credentials, and relevant certificates. Review new multifactor registrations and authentication by those identities outside managed support sessions. Where the appliance opened sessions or transferred files, inspect the target endpoints for follow-on activity and determine whether secrets present on them also need rotation.

Finally, test the evidence pipeline. Generate a controlled administration change and support session, confirm that the events arrive off the appliance with usable timestamps and identity fields, and alert if forwarding stops. Retain alerts that automated triage closes, especially high-severity privilege and appliance events. BeyondTrust says its sensors fired during the hosted intrusion but a third-party triage tool closed the alerts as false positives. A verdict is not a substitute for preserved telemetry and an independent hunt.