al-ice.ai

The Support Appliance Is the Target: ARMORY CASTLE’s BeyondTrust Zero-Day (CVE-2026-102764)

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 15 October 2026, BeyondTrust disclosed CVE-2026-102764, an unauthenticated file-operation flaw in BeyondTrust Remote Support appliances. The next day, two things happened at once: CISA added the CVE to its Known Exploited Vulnerabilities catalog with a remediation deadline of 19 October — this Monday — and Google’s Threat Intelligence Group published the reason why, attributing zero-day exploitation since late August 2026 to ARMORY CASTLE, a suspected PRC-nexus espionage actor. If you run a self-hosted Remote Support appliance that was reachable from the internet on a vulnerable version, Mandiant’s guidance is blunt: treat it as potentially compromised until reviewed, and rebuild rather than clean.

The CVE record itself is spare. NVD carries a vendor description we read first-hand: the flaw exists in internal components of the Remote Support product that did not adequately validate the origin of the messages they received, and under the right conditions an attacker can perform file operations on the appliance. The weakness is CWE-290 (authentication bypass by spoofing), scored CVSS 4.0 9.3 and CVSS 3.1 9.8, network-accessible with no privileges and no user interaction. The affected range is every supported Remote Support version up to 26.2.3; BeyondTrust patched its SaaS tenants on 9 October, six days before disclosure, so this is a self-hosted-appliance emergency. The KEV entry, which we read in the catalog CSV first-hand, names the product line plainly and sets the federal deadline at 19 October 2026.

The intrusion, as Mandiant recovered it

The GTIG report — written by Jayson Frost, Bryce Greathouse, Brian Meyer, John Palmisano, Rajesh Rajeshirke, Steve Rasch and John Wolfram, and read here in full — is valuable because the actor understood the appliance from the inside. After initial exploitation, ARMORY CASTLE issued POST requests to a PHP path on the appliance; eleven minutes later the filesystem recorded the creation of the SAWFLY webshell (mangoapi.php) at the web root. SAWFLY is a small obfuscated PHP shell with bidirectional encrypted command-and-control: it looks for the parameter _c94mfe in incoming POST requests, answers 404 and exits when the parameter is absent — invisible to crawlers and scanners — and otherwise Base32-decodes the payload, decrypts it with RC4 under a hardcoded 32-byte key, evaluates it, and returns the result through the same encrypted channel. That 404-by-default behavior is worth internalising: the foothold is designed to look like nothing at all.

SAWFLY ran as the site’s unprivileged service account. Escalation was crude and effective: the actor copied /bin/sh to /usr/bin/dbus-authd, changed its ownership to root, and set the SUID bit — a persistent root shell hiding under a plausible system filename. From there, the actor went straight for the reason these appliances matter: the credential store. Using the appliance’s own administrative CLI, /ns/sbin/bt-secrets, the actor iterated through vault-dump syntaxes for the site profile and then the global safe, and afterward deleted the tool’s log and its archives. For persistence, the actor created a post_boot.d startup script that appends a passwordless-root sudoers entry for the service account into the appliance’s sudoers template and forces the backend to rebuild the live sudoers file — a change that survives reboots and configuration resets, which would normally wipe hand edits to /etc/sudoers. Understanding the config-generation pipeline, not just the filesystem, is what makes this persistence reboot-proof.

Command-and-control ran through BARECLAW, a custom C SOCKS5 proxy carried over WebSockets, launched in this instance listening on TCP 19800 with token authentication, XOR obfuscation and logging suppressed. Reachability was arranged inside the appliance’s own reverse proxy: the actor added an HAProxy ACL matching the tunneler’s WebSocket path and routed it to a backend pointing at localhost:19800 — so the listener binds only to loopback, is invisible to external port scans, and is reachable from the internet purely through the appliance’s front door. Anti-forensics were systematic: appliance auth, SSL, HTTP access and error, PHP-FPM and host message logs deleted, plus the secrets-tool logs. Finally the actor pivoted into the application layer itself — logging into the admin portal, raising a compromised account’s Jump Item and Team roles from No Access to Administrator, opening support sessions to internal endpoints, and using the appliance’s native file-transfer service to pull reconnaissance documents off user desktops. Every endpoint touched that way is in scope for downstream hunting.

Why this one belongs on an AI-security front page

Remote Support appliances are credential brokers: the Vault, the Password Safe integrations, the session credentials typed into assisted sessions. Mandiant’s remediation section orders credential rotation after rebuild and lists, in dependency order, appliance admins, local users, API secrets, bind accounts and SAML keys, vault and safe credentials rotated at the target systems, and anything typed into a session during the window. That ordering is the article’s real subject: the appliance does not just get owned, it converts its own stored trust into the attacker’s lateral movement, and rotating early merely donates the new secrets too. As support tooling gets driven by AI assistants and automated runbooks — sessions launched, Jump Items enumerated, credentials fetched programmatically — the blast radius of a broker compromise grows with the automation around it, while the detection story stays the same pile of logs the actor already deleted.

The pattern around this CVE is also now a series. February’s CVE-2026-1731 (advisory BT26-02) was an unauthenticated OS command injection in the same product line, added to KEV on 13 February with recorded ransomware use. GTIG assesses with high confidence that ARMORY CASTLE will keep working zero-days in edge devices, and explicitly warns of the 2024 playbook — selective zero-day use followed by broad opportunistic exploitation after disclosure, as happened with CVE-2023-46805 and CVE-2024-21887. CISA’s 19 October deadline is three days after disclosure. The race Mandiant describes is already running.

What to do

  • Patch BT26-05 before 19 October, and treat exposure as compromise. Any appliance reachable from the internet on a vulnerable version during the window — exploitation evidence dates to late August — should be considered potentially compromised until reviewed. SaaS tenants were patched on 9 October and need the credential steps, not the appliance patch.
  • Rebuild, do not clean. Mandiant is explicit: customers cannot audit the appliance host filesystem, and host-level persistence survives reboot and reset. Redeploy from a clean patched image, restore only pre-window configuration, and reissue certificates and Jump Clients.
  • Rotate in dependency order, after rebuild. Appliance admins, local users, API secrets, bind accounts and SAML keys, vault and safe credentials at the targets, then integration secrets — and anything typed into a session during the window. Rotating before rebuild exposes the replacements.
  • Review the application layer against a pre-window baseline. User and role changes — especially Jump Item roles raised to Administrator — group and session policies, API accounts, Jump Items and Jumpoints, and outbound event or syslog destinations. Pull support-session reports including file transfers to scope downstream endpoints.
  • Keep request-path logs the appliance cannot alter. A reverse proxy or WAF with full URI logging in front of the appliance preserves the one record the actor cannot delete from inside, and restrict the /login and /appliance interfaces by source network.
  • Expect broad scanning now. GTIG’s assessment is that ARMORY CASTLE and others will exploit opportunistically post-disclosure. Internet-facing appliances that cannot be patched immediately should be isolated at the perimeter firewall, with egress restricted and every denied connection logged.

Our verification was read-only and external. The CVE ID, description, CWE-290 weakness, CVSS 4.0 9.3 and 3.1 9.8 scores, publication timestamp, affected range and vendor-advisory reference were read first-hand from the NVD 2.0 API; the KEV listing, 16 October date-added, 19 October due date and CWE-290 label were read first-hand from CISA’s KEV catalog CSV, as was the February CVE-2026-1731 entry. The intrusion sequence, tooling details, command lines, configuration snippets and remediation guidance above are Mandiant’s published findings, read here in full from the GTIG report — not independently reproduced. We installed nothing, contacted no appliance, ran no exploit, and quote hashes, keys and tokens only where Mandiant itself redacted them. The infection-path filename is included as a published indicator, consistent with standard threat-intelligence practice.

Sources: