BeyondTrust Remote Support Zero-Day: Armory Castle Appliance Takeover

Key Takeaways

CVE-2026-102764 is a critical (CVSS 4.0 score 9.3) flaw in BeyondTrust Remote Support that allows an unauthenticated remote attacker to perform unauthorized file operations on the appliance, including arbitrary file upload, because of insufficient origin validation in an internal messaging component [1][2][3]. Google Threat Intelligence Group (GTIG) and Mandiant report that a suspected China-nexus espionage actor they track as ARMORY CASTLE (formerly UNC5221, also tracked by CrowdStrike as WARP PANDA) exploited the flaw as a zero-day beginning August 29, 2026, nearly seven weeks before the vendor’s public disclosure [1][4][5].

The exploitation this report describes did not stop at the vulnerable web application. According to Mandiant, the actor escalated to root, installed a custom webshell (SAWFLY) and a SOCKS5 tunneler (BARECLAW), harvested credentials from the appliance, deleted logs, and then used administrator-level access to the Remote Support platform itself to reach internal endpoints and retrieve documents [1]. Because a remote support appliance is a privileged, trusted path into many internal systems, in our assessment appliance compromise should be treated as a potential compromise of everything the appliance can reach.

Mandiant recommends rebuilding suspected appliances from a clean image rather than cleaning them in place, because the actor established host-level persistence that survives reboots and configuration resets [1]. Self-hosted customers must apply patch BT26-05-RS manually (versions 24.3.1 through 26.2.3) or upgrade first if they run an older release [2][3]. GTIG warns that ARMORY CASTLE and other actors are likely to pursue widespread exploitation now that the flaw is public, consistent with the actor’s behavior after earlier Ivanti disclosures [1][10]. Given that forecast, we recommend that organizations patch, hunt, and rotate credentials in that order and without delay.

Background

BeyondTrust Remote Support (formerly Bomgar) is a help-desk and remote-administration product that lets support staff open sessions to endpoints, transfer files, and use stored credentials through a vault and “Jump Item” access model. Customers deploy it either as a BeyondTrust-hosted SaaS service or as a self-hosted appliance. The product’s purpose, which is brokered privileged access to other systems, is also what makes the appliance a high-value target: an attacker who controls the broker inherits some portion of the trust that the organization has delegated to it. A separate critical BeyondTrust flaw, CVE-2026-1731, drew a federal remediation deadline in February 2026, which illustrates the same pattern [6].

BeyondTrust publicly disclosed CVE-2026-102764 on October 15, 2026, and published advisory BT26-05 [2][3]. The flaw is described in the vendor advisory, trade press, and government reporting as improper origin validation, categorized as an authentication bypass by spoofing, and it affects Remote Support versions up to and including 26.2.3 [2][3][7]. The Canadian Centre for Cyber Security issued alert AL26-025 on October 16 and reports that the flaw is being exploited in the wild [7]. BeyondTrust reports that its SaaS tenants were patched as of October 9, 2026, and self-hosted customers must apply the fix themselves [2][3][4].

GTIG describes ARMORY CASTLE as a suspected PRC-nexus espionage group active since October 2023 that specializes in zero-days in edge and security appliances, and whose earlier campaigns involved Ivanti products (CVE-2023-46805, CVE-2024-21887, and CVE-2025-0282) and Citrix devices [1][5]. Reported targets include legal services, SaaS providers, business-process outsourcers, technology companies, and government [5][8]. The combination of an espionage mission and a customer base of service providers is relevant here, because a compromised support platform at a provider can become a path into that provider’s own customers.

Security Analysis

Timeline and Disclosure Gap

The reported sequence shows a substantial gap between first exploitation and customer-facing notice, summarized in the table below. The 41-day interval between August 29 and the October 9 completion of SaaS patching is our own calculation from the reported dates (40 days if the October 8 date reported by one outlet is correct), and it describes the hosted service only. Self-hosted customers had no patch available until the October 8 release, one week before the October 15 public notice [2][3][4]. This note does not establish when BeyondTrust itself learned of the exploitation.

Sources disagree on several details of this chronology. SecurityWeek lists the vulnerability as identified on September 28 and the patch as completed on September 30, which conflicts with the October 8 patch release and October 9 SaaS completion given by the vendor advisory and other outlets [2][3][4]. BleepingComputer places the SaaS patch on October 8 and dates the customer warning to October 16 rather than October 15 [9]. A further outlet lists “public disclosure” on September 27, which cannot be reconciled with an October 15 vendor disclosure. We use the dates in the vendor advisory and the Canadian Cyber Centre alert because they are the primary and government sources, and we treat the others as unresolved discrepancies.

The Hacker News further reports that CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 16 with a federal deadline of October 19 [5]. We could not corroborate the KEV listing against CISA’s own catalog or a second source, so readers should confirm it before relying on the deadline.

Vulnerability Characteristics

The vulnerability class matters for defenders because it determines what pre-exploitation controls could have helped. The vendor advisory and other reporting describe the flaw as insufficient validation of message origin in an internal messaging component, which a remote unauthenticated attacker can abuse to perform file operations on the appliance [2][3][7]. GTIG’s analysis describes the initial request as a POST to an unusual PHP resource, after which a staged file was written to a web-served application directory and a webshell appeared about eleven minutes later [1]. Mandiant was unable to recover the initial uploaded file, so the precise payload that bridged the file operation and code execution is not public [1]. Descriptions of the bug vary between “arbitrary file upload,” “authentication bypass,” and “improper origin validation”; these appear to describe the same underlying condition from different angles, though we note that as an inference.

Post-Exploitation Tradecraft

Mandiant’s analysis documents a sequence of actions aimed at persistence and stealth. The technical details in this section rest on a single vendor-produced source [1]. The SAWFLY webshell (mangoapi.php) is a small obfuscated PHP file that returns an HTTP 404 and exits unless a specific POST parameter is present, which helps it evade scanners; when the parameter is present, it decodes the payload with a custom Base32 layer, decrypts it with a hardcoded RC4 key, and executes the result with eval [1]. BARECLAW (ingredi_ws) is a C-language SOCKS5 tunneler that runs over WebSocket with token authentication and XOR obfuscation, with all logging suppressed. The actor modified the appliance’s HAProxy configuration so that requests to a chosen path are routed to the local tunneler, which turns the appliance into an inbound relay into the internal network [1].

For privilege and persistence, the actor copied a shell to a new filename and set the SUID bit under root ownership, and installed a boot-time script that appends a passwordless sudo rule to the appliance’s sudoers template and triggers a configuration rebuild [1]. Because this persistence lives in the appliance’s own boot and configuration mechanisms, applying the vendor patch does not remove it. This is the reason Mandiant advises rebuilding from a clean image [1]. The actor also attempted to read the appliance’s credential vault with the bt-secrets utility, then deleted its logs and a long list of web, proxy, and system logs [1].

One behavior of particular defensive relevance was the use of the product’s intended function against the customer. Mandiant observed the actor changing a user’s Jump Item role from “No Access” to “Administrator,” logging in with a password, initiating Remote Support sessions against internal endpoints, requesting file-system access, and downloading internal documents useful for reconnaissance [1]. Activity of this kind produces audit records that look like help-desk work, so detection depends on baselining who legitimately holds administrator roles and from which networks they log in.

Exposure and Scope

Public information on victim counts is limited and partly inconsistent. GTIG’s post does not state a victim count or sector breakdown [1]. BeyondTrust’s advisory and SOC Prime report that the observed zero-day exploitation involved one BeyondTrust-hosted instance and one self-hosted appliance [2][4]. BleepingComputer notes that Shadowserver tracked approximately 1,400 exposed instances, though whether those were vulnerable and unpatched was not stated [9]. We therefore treat the confirmed victim set as very small at the time of disclosure and the potential victim set as large. This is an inference from the actor’s reported history of broad exploitation after disclosure, and GTIG itself advises organizations to prepare for that outcome [1]. BeyondTrust and the Canadian Cyber Centre advise treating any internet-reachable appliance on a vulnerable version during the exposure window as potentially compromised until reviewed [7][9].

Recommendations

Immediate Actions

Organizations running self-hosted Remote Support should identify every appliance, confirm its version, and apply BT26-05-RS from the appliance administration interface; installations older than 24.3.1 must be upgraded to a supported version before the patch can be applied [1][3]. SaaS customers do not need to patch, but because exploitation of a hosted instance has been reported by at least one source, they should still review administrator accounts and audit logs for the period since late August [4]. While patching, restrict the /login and /appliance interfaces by source address where operationally possible, and place a reverse proxy or web application firewall with full URI logging in front of the appliance [1].

Any appliance that was internet-reachable on a vulnerable version should be examined for compromise before it is trusted again. Mandiant’s guidance is to snapshot memory and disk before changes, preserve evidence with the vendor, block inbound traffic and restrict egress to BeyondTrust endpoints, terminate active sessions, disable Jump Clients, Jumpoints and API accounts, and rebuild from a clean image [1]. After the appliance has been patched or rebuilt, rotate credentials in the order GTIG gives: appliance administrators, /login administrators, API secrets, security providers, vault credentials, and integration credentials [1]. In our assessment, rotating before the appliance is clean risks handing the new secrets to the same attacker.

Short-Term Mitigations

Hunting should combine file, request, and audit signals. The published indicators include the SAWFLY and BARECLAW file hashes and YARA rules from GTIG, unknown .php request paths, WebSocket upgrades from outside support-staff address ranges, unexpected user_changed events that raise Jump Item roles, administrator logins from residential or commercial-VPN address space, and gaps in syslog forwarding, which Mandiant describes as a strong indicator of log tampering [1]. Forwarding appliance syslog to a SIEM over TLS with multi-month retention matters here because the actor deleted local logs [1].

Reduce what a captured administrator account can do. GTIG recommends SAML single sign-on with phishing-resistant multi-factor authentication for all /login users, MFA on the built-in administrator account, a default Jump Item role of “No Access,” minimally scoped API accounts, default-deny outbound filtering from the appliance, and use of an external vault with credential injection rather than the platform’s own vault [1]. Teams should also review who can change roles and security-provider settings and alert on those changes without a matching change ticket.

Strategic Considerations

This incident reinforces a pattern that CSA has documented in recent rapid-research advisories on SonicWall, Cisco, and Oracle: internet-facing management and access infrastructure is a repeated zero-day target, and compromise of the control plane can exceed the impact of a single endpoint breach [11][12]. Organizations should maintain an inventory that marks which remote-access, support, and management appliances are internet-reachable, assign an owner and a patch service-level objective to each, and plan for a rebuild-from-image procedure before it is needed. For vendors that offer both SaaS and self-hosted deployment, buyers should ask how quickly hosted-tenant fixes translate into notice for self-hosted customers, because the reported interval here left self-hosted operators without information for several weeks.

A second consideration is architectural. Privileged remote access platforms concentrate credentials and session brokering in one place, so network segmentation that limits what the appliance can reach, just-in-time access, and session recording managed outside the appliance can reduce the consequence of a platform compromise. These are design choices rather than quick fixes, but incidents such as this one can inform the case for funding them.

CSA Resource Alignment

CSA’s closest prior work is its series of rapid-research threat intelligence reports on actively exploited edge and access appliances. SonicWall SMA Zero-Days: Edge Appliance Root Returns analyzes chained zero-days enabling unauthenticated root compromise of a remote access appliance, and its guidance on patching, compromise assessment, and credential rotation after appliance compromise maps directly onto the sequence recommended above [11]. Cisco SD-WAN CVE-2026-20245 Zero-Day: Root Access Pre-Disclosure Exploitation addresses a management-plane zero-day exploited before disclosure, which parallels the nearly seven-week exposure window reported for BeyondTrust and the need to assume compromise when a vulnerable system was exposed [12]. Oracle PeopleSoft Zero-Day: ShinyHunters Breaches 100 Universities is a further example, although an enterprise application rather than an access appliance, of how remediation guidance changes when exploitation precedes the patch [13].

For control mapping, CSA’s AI Controls Matrix (AICM) v1.1 provides the Threat and Vulnerability Management and Identity and Access Management domains that apply to patch timelines, privileged access restriction, and logging for support infrastructure [14]. Although this incident is not an AI-specific attack, the same privileged-access platforms often broker administrative access to the systems that host AI workloads, so the platform’s compromise is relevant to AI environments as well.

References

[1] Google Threat Intelligence Group / Mandiant. “ARMORY CASTLE Exploits BeyondTrust Remote Support Zero-Day.” Google Cloud Blog, October 2026.

[2] BeyondTrust. “BT26-05 Security Advisory.” BeyondTrust, October 2026.

[3] SecurityWeek. “Chinese APT Exploited BeyondTrust Vulnerability as Zero-Day.” SecurityWeek, October 2026.

[4] SOC Prime. “CVE-2026-102764: Critical BeyondTrust Remote Support Zero-Day Exploited by China-Linked Hackers.” SOC Prime, October 2026.

[5] The Hacker News. “China-Linked Hackers Exploited BeyondTrust Zero-Day to Take Over Remote Support Servers.” The Hacker News, October 16, 2026.

[6] Threatbeat. “CISA Gives Feds 3 Days to Patch Actively Exploited BeyondTrust Flaw.” Threatbeat, February 2026.

[7] Canadian Centre for Cyber Security. “Alert AL26-025 – Critical vulnerability impacting BeyondTrust Remote Support – CVE-2026-102764.” Canadian Centre for Cyber Security, October 16, 2026.

[8] SC Media. “BeyondTrust zero-day exploited by China-linked group Armory Castle.” SC Media, October 2026.

[9] BleepingComputer. “BeyondTrust patches zero-day exploited in attacks since August.” BleepingComputer, October 2026.

[10] Infosecurity Magazine. “China Espionage Actor Actively Targeting Critical BeyondTrust Flaw, Google Warns.” Infosecurity Magazine, October 2026.

[11] Cloud Security Alliance. “SonicWall SMA Zero-Days: Edge Appliance Root Returns.” CSA, July 20, 2026.

[12] Cloud Security Alliance. “Cisco SD-WAN CVE-2026-20245 Zero-Day: Root Access Pre-Disclosure Exploitation.” CSA, June 27, 2026.

[13] Cloud Security Alliance. “Oracle PeopleSoft Zero-Day: ShinyHunters Breaches 100 Universities.” CSA, June 30, 2026.

[14] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA, 2026.