BeyondTrust Appliance Attack Exposes a High-Risk Chain

BeyondTrust Remote Support appliances occupy a sensitive position in enterprise environments: they authenticate administrators, broker access to endpoints, store or handle credentials, and provide remote-session capabilities. A compromise of the appliance can therefore become more than a device-level incident.

In a report published by Google Threat Intelligence Group (GTIG) and Mandiant, investigators describe the exploitation of CVE-2026-102764 against BeyondTrust Remote Support appliances. The researchers observed a sequence that moved from unauthenticated file operations to webshell access, host-level privilege escalation, credential-vault probing, persistent configuration changes, log deletion, and remote access to downstream systems.

GTIG attributes the activity to ARMORY CASTLE, which it describes as a suspected PRC-nexus espionage actor formerly tracked as UNC5221. That attribution is an assessment by the research organization, not an independently established fact in this analysis. Mandiant’s observations came from an incident-response engagement and should be treated as a model for possible compromise, rather than evidence that every vulnerable appliance was affected.

What the researchers confirmed

BeyondTrust disclosed CVE-2026-102764 on October 15, 2026. According to GTIG and Mandiant, the vulnerability affects supported Remote Support versions up to 26.2.3 and permits an unauthenticated remote attacker to perform file operations on an appliance. The researchers identified evidence of exploitation in access, syslog, messages, thin-scc, brain, and SSL logs. Those records reside on a LUKS-encrypted partition containing the appliance’s home directory.

The observed intrusion began with POST requests to /app_84304470%2Ephp. Mandiant could not recover the file associated with those requests. Approximately 11 minutes later, the appliance filesystem recorded creation of a PHP webshell in the web root under /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/.

The webshell, which Mandiant named SAWFLY and also identified as mangoapi.php, became a primary foothold. The report describes it as a small, obfuscated PHP implant that accepted specially formatted POST requests. It looked for the parameter _c94mfe; requests lacking that parameter received an HTTP 404 response and exited. This behavior reduced the likelihood of discovery by ordinary crawlers and vulnerability scanners.

When the parameter was present, SAWFLY decoded a Base32-encoded payload, decrypted it with a hardcoded 32-byte key using RC4, and executed the resulting PHP code. Returned data was encrypted and encoded before being sent back. These details are confirmed observations from the Mandiant investigation. They do not establish that every deployment of the same filename or parameter is malicious without additional context.

From web access to root control

SAWFLY initially ran as the appliance’s site service account, an unprivileged local user. Mandiant observed the actor copy /bin/sh to /usr/bin/dbus-authd, change ownership to root, and enable the Set User ID permission. Because a SUID executable runs with the privileges of its owner, the renamed shell gave the actor a route to root-level control.

This step materially changed the incident. Root access allowed the intruder to access appliance data, alter protected files, and create changes designed to survive normal maintenance actions. It also meant that simply removing a webshell or rebooting the appliance could not be assumed to eradicate the intrusion.

The appliance’s role as a credential broker made that privilege escalation particularly significant. Mandiant observed attempts to use the native /ns/sbin/bt-secrets administrative utility to retrieve stored secrets. The observed command variations targeted both a site service account’s vault and the broader appliance-level password safe. Afterward, the actor removed bt-secrets log files and archived copies. The report does not state that every attempted vault query succeeded, so credential exposure must be investigated rather than presumed or dismissed.

Persistence and suppression of evidence

For persistence, the actor modified the appliance’s startup configuration. A script named zz-root-persist was placed in /home/bomgar/sbin/post_boot.d. The script checked for, and if necessary added, a passwordless administrative entry for the site service account in /ns/config/sudoers.template. It then invoked the appliance’s configuration utility to rebuild the active sudoers file.

This approach targeted the appliance’s configuration model instead of only changing the live operating-system file. As a result, the access could survive reboot and configuration reset procedures that might otherwise overwrite direct edits to /etc/sudoers.

Mandiant also observed systematic deletion of host, web-server, application, and temporary authentication logs. The affected locations included authentication, SSL, HTTP access and error, PHP, message, and site-specific logs. This anti-forensic activity is important for defenders: an absence of records on the appliance cannot be treated as evidence that no suspicious activity occurred.

Abuse of the management plane

After compromising the appliance host, the actor used an Administrator account to access the Remote Support web administration portal. Mandiant observed changes that elevated the account’s Jump Item and team permissions from “No Access” to “Administrator.” Jump Items represent systems available for remote access through the appliance, so this change created a durable route to downstream endpoints listed in the environment.

The actor then established remote support sessions to internal systems and used native file-transfer functionality to obtain documents, including software inventories from a user desktop. The report characterizes these materials as useful for network reconnaissance. It does not identify specific victims or confirm the full scope of information removed.

This sequence illustrates why an appliance compromise should be investigated as a potential control-plane incident. The relevant question is not only whether the appliance’s operating system was altered, but also which accounts, policies, Jump Items, sessions, endpoints, and credentials could have been reached through the product.

BARECLAW and hidden remote connectivity

Mandiant identified a second custom tool, BARECLAW, a C-based tunneler that provides a SOCKS5 proxy over WebSocket. The tool can support authentication, traffic obfuscation, destination restrictions, upstream proxying, and TLS, although the observed execution used a listening port of 19800, a token, XOR-based obfuscation, quiet logging, and a custom WebSocket path of /uidchanarge. The observed command did not enable TLS.

The actor also modified /ns/config/haproxy.conf. A new access-control rule matched the custom WebSocket path and forwarded matching traffic to a local service on 127.0.0.1:19800. This arrangement kept the tunneler’s listener bound locally while making it reachable through the appliance’s reverse proxy. Defenders should therefore inspect reverse-proxy routing and unexpected WebSocket behavior, not only externally exposed listening ports.

Detection and hunting priorities

Organizations should begin with appliance and perimeter telemetry because local logs may have been deleted. GTIG and Mandiant recommend retaining appliance syslog in a separate SIEM over TLS, along with reverse-proxy or WAF records and perimeter firewall logs. These external sources can preserve request paths, connection attempts, and periods when forwarding from the appliance stopped.

High-value searches include requests for unknown PHP paths, especially the reported staging path, and POST requests containing _c94mfe. Investigators should review for the SAWFLY filename mangoapi.php, the BARECLAW filename ingredi_ws, the custom path /uidchanarge, and unexpected WebSocket upgrades. The reported SHA-256 for mangoapi.php is dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb; the reported SHA-256 for ingredi_ws is 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462.

File and configuration review should include the unexpected /usr/bin/dbus-authd SUID file, the post_boot.d directory, the zz-root-persist script, changes to sudoers.template, and unexpected HAProxy ACLs or backends. Teams using the supplied GTIG YARA content can also look for the SAWFLY code characteristics and BARECLAW strings described in the report. These checks should be performed under the organization’s incident-response process and not treated as a substitute for rebuilding a compromised appliance.

What organizations should do now

1. Patch immediately. Apply BeyondTrust’s BT26-05 remediation. Self-hosted customers should follow the vendor’s supported-version and patch process; upgrading closes the vulnerability but does not remove persistence or address prior exposure. SaaS customers should still complete credential and configuration review.
2. Preserve evidence before changing systems. For virtual appliances, preserve snapshots, memory, and disk data where feasible. Collect SIEM, WAF, reverse-proxy, firewall, and vendor-supported forensic data before rebooting or rebuilding.
3. Assume host-level compromise when warranted. If an internet-reachable appliance was vulnerable during the relevant exposure window, investigate it as potentially compromised. Mandiant recommends rebuilding rather than attempting to clean a host whose filesystem cannot be fully audited.
4. Contain access paths. Block public inbound access at the perimeter, restrict outbound traffic, terminate active support sessions, and disable new sessions, Jump Clients, Jumpoints, and API accounts as operationally appropriate. Preserve records by disabling rather than deleting accounts.
5. Rotate credentials in the right order. Patch or rebuild first, then rotate appliance administrators, local users, API secrets, identity-provider credentials, Remote Support Vault and integrated-system credentials, integration secrets, and credentials entered during affected support sessions.
6. Review the control plane. Examine role changes, Jump Item permissions, API accounts, security providers, Jumpoints, outbound event destinations, file transfers, and all endpoints reached during the exposure window.
7. Reduce future blast radius. Restrict administrative interfaces by network, require phishing-resistant MFA through SAML where possible, minimize local accounts, use default-deny Jump Item permissions, limit API privileges, and prefer external vaulting with credential injection over storing interactive secrets on the appliance.

Conclusion

The incident described by GTIG and Mandiant demonstrates how a vulnerability in a remote-access appliance can become an enterprise-wide access problem. The observed chain combined file upload, a narrowly triggered webshell, SUID-based root access, credential-vault targeting, configuration-driven persistence, administrative-session abuse, and a reverse-proxy-routed tunnel. The most important response principle is to treat the appliance as a privileged control plane: patch it quickly, preserve independent evidence, rebuild when compromise cannot be ruled out, and investigate every account, endpoint, and credential connected to it.

Sources

• Google Threat Intelligence Group and Mandiant: “ARMORY CASTLE Exploits BeyondTrust”