BeyondTrust Remote Support Zero-Day CVE-2026-102764: Patch, Hunt and Rebuild Guidance

On October 15, 2026, BeyondTrust published security advisory BT26-05, disclosing a critical vulnerability in its Remote Support (RS) software—formerly known to veteran sysadmins as Bomgar—that has been actively exploited as a zero-day since late August 2026. Tracked as CVE-2026-102764 and carrying a CVSS v4 severity score of 9.3, the flaw stems from improper origin validation in an internal messaging component (CWE-290, Authentication Bypass by Spoofing). Under the right conditions, an unauthenticated remote attacker can send spoofed messages to perform arbitrary file operations on an unpatched appliance.

While BeyondTrust’s advisory focuses on the mechanics of the vulnerability and patch availability, an accompanying incident response report from Mandiant and the Google Threat Intelligence Group (GTIG) reveals just how brutal the real-world post-exploitation has been. A suspected China-nexus espionage actor tracked by GTIG and Mandiant as ARMORY CASTLE (formerly UNC5221, and tracked by CrowdStrike as Warp Panda) used this flaw not merely to drop a web shell, but to gain persistent root control, harvest vault secrets, rewrite reverse-proxy configurations, and pivot directly into downstream enterprise systems.

For Windows administrators, help desk managers, and security operations teams, this is not a "patch and move on" situation. If your organization runs a self-hosted BeyondTrust Remote Support appliance that was reachable from the internet between late August and the moment you applied the patch, Mandiant’s guidance is blunt: treat that appliance as potentially compromised until you have proven otherwise.

The Anatomy of CVE-2026-102764 and the Patch Timeline​

Before diving into the forensic weeds, it is important to clarify exactly what is affected and resolve a couple of discrepancies circulating in secondary news reports.

According to BeyondTrust’s official BT26-05 advisory, CVE-2026-102764 specifically impacts BeyondTrust Remote Support (RS) versions 26.2.3 and earlier. Although some early reporting mentioned Privileged Remote Access (PRA) when discussing cloud updates, BeyondTrust’s advisory lists only Remote Support as the impacted product. Furthermore, while some outlets reported that SaaS instances were patched on October 8, both BeyondTrust’s official advisory and Mandiant’s remediation timeline confirm that BeyondTrust applied the remediation patch to all Remote Support SaaS tenants on October 9, 2026.

If you are running a self-hosted Remote Support appliance on version 24.3.1 through 26.2.3, you must install the BT26-05-RS patch via the /appliance interface (or verify that it was successfully installed if automatic updates are enabled). If your organization is running a version older than 24.3.1, you cannot apply the patch directly; you must first upgrade the appliance to a supported version (24.3.1 or later) and then apply BT26-05-RS. If the patch does not appear in your /appliance portal, BeyondTrust instructs administrators to open a support case referencing BT26-05.

Section Summary: CVE-2026-102764 is a critical (CVSS 9.3) authentication bypass in BeyondTrust Remote Support (<= 26.2.3) that allows unauthenticated remote file operations. SaaS tenants were patched on October 9, 2026, while self-hosted administrators must ensure BT26-05-RS is applied immediately.

Inside the Intrusion: How ARMORY CASTLE Owned the Appliance​

Why is an appliance-level file upload flaw such a nightmare for Windows environments? Because a remote support appliance is effectively a privileged jump box with built-in file transfer and remote control tools deployed across your fleet. Mandiant’s forensic investigation of an compromised appliance demonstrates that ARMORY CASTLE arrived with an intimate, pre-existing mastery of BeyondTrust’s internal Linux architecture, proprietary utilities, and configuration templates.

1. Web Shell Staging and SAWFLY (mangoapi.php)​

Following initial exploitation of CVE-2026-102764, Mandiant observed the attackers sending HTTP POST requests to /app_84304470%2Ephp (though the initial staging file itself was not recovered). Roughly 11 minutes later, the file system recorded the creation of a custom PHP web shell named SAWFLY (mangoapi.php) inside the web root path:

/%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/

SAWFLY is designed to stay invisible to automated scanners and casual inspection. When accessed, it checks incoming HTTP POST requests for a specific obfuscated parameter: _c94mfe. If that exact parameter is missing, the script immediately returns a standard HTTP 404 Not Found status code and exits. When the parameter is supplied, SAWFLY decodes the payload using a custom Base32 transport layer, decrypts it with a 256-bit RC4 stream cipher using a hardcoded 32-byte key, and executes the PHP code via @eval(), returning encrypted output back to the operator.

2. From Unprivileged Service Account to Root via SUID​

Initially, SAWFLY executes under the context of the site’s unprivileged local service account. However, ARMORY CASTLE quickly escalated to root control of the underlying Linux host. The attackers copied the standard system shell (/bin/sh) to a deceptive path looking like a system daemon:

/usr/bin/dbus-authd

They changed the binary’s owner to root and enabled Set User ID (SUID) permissions. Because a SUID binary executes with the permissions of its file owner rather than the user invoking it, this simple maneuver gave the unprivileged web shell instant, repeatable root execution on the appliance.

3. Surviving Reboots: Tampering with sudoers.template​

Standard Linux administrators know to check /etc/sudoers for unauthorized changes. Appliance vendors, however, often regenerate system configuration files from master templates during reboots or configuration resets—which normally wipes out an attacker's manual edits.

ARMORY CASTLE knew this. To guarantee their root access survived both reboots and administrative resets, they created /home/bomgar/sbin/post_boot.d (a directory reserved for scripts that run automatically at startup) and dropped a script named zz-root-persist.

This script checks BeyondTrust’s master template at /ns/config/sudoers.template and appends the following rule if it isn't already present:

%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL

The script then runs BeyondTrust’s proprietary /ns/sbin/bt-sysconfig --no-restart misc command, forcing the appliance backend to parse the modified template and rebuild the active /etc/sudoers file on the spot.

4. Raiding the Vault with bt-secrets​

With root access secured, the attackers went after the crown jewels: the credentials stored and brokered by the appliance. Mandiant recovered command logs showing the actor invoking /ns/sbin/bt-secrets, BeyondTrust’s native CLI tool for managing stored passwords, API keys, and endpoint credentials. The attackers iterated through syntax variations to dump both the site service account vault and the global appliance vault:

• /ns/sbin/bt-secrets get -p %SITE_SERVICE_ACCOUNT% vault
• /ns/sbin/bt-secrets get %SITE_SERVICE_ACCOUNT% vault
• /ns/sbin/bt-secrets get vault

Right after running those commands, the attackers attempted to cover their tracks by deleting the secrets audit log:

/usr/sbin/sh -c 'rm -f /home/bomgar/log/bt-secrets.log /home/bomgar/log/bt-secrets.log.* 2>/dev/null;'

While the deleted logs prevent responders from confirming whether every vault extraction command succeeded, any organization hit by this intrusion chain must assume every secret stored on the appliance is compromised.

5. Stealth Tunneling with BARECLAW and HAProxy Hijacking​

To turn the compromised appliance into a covert relay into the victim's internal network, ARMORY CASTLE deployed BARECLAW (/tmp/ingredi_ws), a custom C-based SOCKS5 proxy tunneler that encapsulates TCP traffic over WebSockets and embeds a CivetWeb server. The attackers launched it with the following arguments:

/tmp/ingredi_ws --listen 19800 --token %REDACTED% --obfs -q --ws-path /uidchanarge

Notice the clever operational security here: BARECLAW was bound locally to 127.0.0.1:19800 with logging suppressed (-q). Because it only listened on localhost, external port scans against the appliance would never spot port 19800 open.

So how did the attackers reach it from the internet? They modified /ns/config/haproxy.conf, the configuration file for the appliance’s front-end HAProxy reverse proxy. They added an Access Control List (acl wswsws path /uidchanarge) that intercepted incoming web requests to /uidchanarge, bypassed normal BeyondTrust web services, and silently routed the stream to a custom backend (webskd3) pointing to 127.0.0.1:19800. To the outside world, traffic looked like normal connections hitting the appliance’s standard web port.

6. Pivoting to Endpoints via "Jump Items" and Anti-Forensics​

Rather than relying purely on custom malware to move laterally, ARMORY CASTLE used BeyondTrust’s legitimate features against the victim. Using compromised Administrator credentials, they logged into the Remote Support web administration portal (/login) and modified account permissions, upgrading both Jump Items (remote systems configured for unattended access) and Team permissions from No Access to Administrator.

With unrestricted Jump Item access, the attackers launched legitimate Remote Support sessions onto internal endpoints, requested full file-system access, and used the built-in file transfer tool to exfiltrate reconnaissance files—such as software inventories—directly from user desktops. Throughout the intrusion, they routinely executed sweeping rm -f commands via sudo to wipe /ns/log/*, /var/log/messages, /home/%SITE_SERVICE_ACCOUNT%/ingredi/log/*, and /tmp/sshauth.*.

Section Summary: ARMORY CASTLE demonstrated deep knowledge of BeyondTrust internals, chaining the initial flaw with the SAWFLY PHP web shell, a SUID /usr/bin/dbus-authd root backdoor, sudoers.template manipulation, bt-secrets vault dumping, HAProxy hijacking for the BARECLAW SOCKS5 tunneler, and native Jump Item abuse to reach internal desktops.

Why This Matters Now: The Post-Disclosure Race​

If ARMORY CASTLE (UNC5221) sounds familiar, it should. Active since at least October 2023, this group has built a reputation for zero-day exploitation of network edge appliances—most notably targeting Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887, and CVE-2025-0282) and Citrix NetScaler (CVE-2023-4966).

There is a critical pattern in how this group operates: they typically exploit a zero-day selectively for espionage while it remains secret, and then pivot to widespread, opportunistic mass exploitation the moment the vendor publishes an advisory, racing to compromise unpatched appliances before IT teams can get through change-management approvals. Both GTIG and Mandiant warn that defenders should prepare for similar widespread exploitation attempts targeting CVE-2026-102764 right now.

Actionable Playbook: How to Remediate, Hunt, and Harden​

Because self-hosted customers cannot directly audit the underlying Linux host file system on a standard BeyondTrust appliance—and because ARMORY CASTLE’s persistence mechanisms survive both reboots and configuration resets—simply applying the patch is not enough if your appliance was exposed during the vulnerability window (late August 2026 to present).

Here is the step-by-step defensive playbook synthesized from Mandiant and BeyondTrust guidance:

Step 1: Preserve Evidence Before Rebooting (If Compromise is Suspected)​

Because the threat actor actively deletes local /ns/log/ and /home partition logs, rebooting or modifying a suspected appliance can destroy volatile evidence.

1. Virtual Appliances: Take a full VM snapshot including memory and export the virtual disk before making changes.
2. B Series Hardware or SaaS Tenants: Open an urgent ticket with BeyondTrust Support requesting forensic preservation.
3. External Logs: Immediately secure and preserve your external SIEM/syslog records, Web Application Firewall (WAF) or reverse-proxy logs, and perimeter firewall logs covering late August 2026 to the present. An unexplained gap in syslog forwarding from the appliance during a single session is a strong indicator of log tampering.

Step 2: Patch or Rebuild​

• If no compromise is suspected: Apply patch BT26-05-RS immediately via /appliance (upgrading to 24.3.1+ first if on an older build).
• If compromise is confirmed or suspected: Isolate the appliance by blocking inbound traffic at the perimeter firewall (do not change settings inside /appliance yet, so the configuration remains intact for review). Restrict outbound traffic to deny everything except BeyondTrust update and licensing endpoints. Rebuild rather than clean: Redeploy the appliance from a clean, fully patched image. Restore only a configuration backup predating late August 2026, or restore the newest backup while isolated and audit every setting before reconnecting. Issue a new TLS certificate and redeploy all Jump Clients, Jumpoints, and representative consoles to invalidate existing tokens.

Step 3: Hunt for Indicators of Compromise (IOCs)​

Check your WAF, reverse proxy, SIEM, and forensic images for the following artifacts identified by Mandiant:

Step 4: Audit /login and Rotate Credentials (Post-Patch/Rebuild Only)​

Warning: Never rotate credentials while an attacker still controls the host, or you will simply hand them the new passwords. Once your appliance is patched or rebuilt:

1. Terminate Sessions: End all active support sessions. If investigating an intrusion, disable (rather than delete) suspect Jump Clients, Jumpoints, and API accounts in /login so the audit trail remains intact.
2. Rotate All Secrets at the Target Systems: In dependency order, rotate /appliance admin passwords, /login admin and local user passwords, API client secrets, LDAP/AD security provider bind accounts, SAML signing keys, all credentials stored in the Remote Support Vault (or integrated Password Safe / PRA), SMTP/ITSM integration secrets, and any credential manually typed into a remote support session since late August 2026.
3. Audit Permissions & File Transfers: Compare your /login configuration against a pre-August baseline. Look specifically for user_changed events that elevated Jump Item or Team roles to Administrator, unauthorized api_account or security_provider additions, and changes to syslog/outbound event destinations. Review support session reports for file-transfer events—every internal Windows or Linux endpoint touched by a suspicious session must be treated as a downstream hunting target.

Step 5: Harden the Control Plane​

To keep a future appliance bug from turning into a domain-wide breach:

• Lock Down Admin Interfaces: Restrict network access to /login and /appliance by IP or internal network segment so only representative console, customer portal, and Jump Client traffic is reachable from the internet. Place a WAF or reverse proxy with full URI logging in front of the appliance so attackers cannot wipe the access logs.
• Enforce Phishing-Resistant MFA: Require SAML single sign-on with phishing-resistant MFA for all /login users, enable MFA on the built-in Admin account, and remove local accounts except for a single vaulted break-glass account with strict alerting.
• Minimize Vault Exposure: Set the default Jump Item role in group policies to No Access. Avoid storing high-privilege domain credentials directly in the local Remote Support Vault; instead, use an external vault or Password Safe with credential injection, keeping only non-interactive service account credentials on the appliance itself.

Section Summary: Defenders must preserve volatile memory and external logs before rebooting suspected appliances, rebuild compromised systems from clean images, hunt for mangoapi.php and /uidchanarge traffic, audit Jump Item role elevations, and rotate all brokered credentials only after the appliance is clean.