ARMORY CASTLE Uses BeyondTrust Zero-Day to Keep Root Access

ARMORY CASTLE exploited a zero-day in BeyondTrust Remote Support in late August, then put a root backdoor on the appliance and used the support application to reach internal endpoints, according to Mandiant’s incident investigation. An exposed Remote Support appliance is a route into the systems its help desk manages, even after the appliance itself receives a patch.

The flaw, CVE-2026-102764, lets an unauthenticated remote attacker perform file operations on an appliance. BeyondTrust’s CVE record describes internal components that inadequately validated the origin of received messages and lists supported Remote Support versions through 26.2.3 as affected. Google attributes this intrusion to ARMORY CASTLE, a suspected PRC-nexus espionage actor formerly called UNC5221. Its warning about possible broader exploitation after disclosure is an assessment; its account of the late-August intrusion comes from incident response.

A webshell reached appliance root

After exploitation, Mandiant saw requests to a staging PHP path and, about 11 minutes after the first request, creation of the SAWFLY webshell at the site’s web root. SAWFLY, mangoapi.php, accepted an obfuscated POST parameter, _c94mfe; requests without that parameter received 404. That behavior makes ordinary web crawling a poor way to find it. The webshell ran as the unprivileged site service account.

The actor copied the system shell to /usr/bin/dbus-authd, made the copy root-owned and set its SUID permission. Executing that copy gave the service account root privileges. Mandiant also saw attempts to read the appliance’s credential vault through its own bt-secrets utility, followed by deletion of /home/bomgar/log/bt-secrets.log. Treat the vault access as an observed attempt when assessing credential exposure; the appliance’s privileged position also put stored and brokered credentials within reach of someone controlling its host.

Boot templates kept privileges alive

For persistence, the actor placed zz-root-persist in /home/bomgar/sbin/post_boot.d. The script changed /ns/config/sudoers.template to grant the site service account passwordless root privileges and ran the appliance configuration utility to regenerate /etc/sudoers. A reboot or configuration reset that rewrites the active sudoers file can therefore recreate the unauthorized privilege from the altered template.

Mandiant also observed BARECLAW, an ingredi_ws tunneler, listening locally on 127.0.0.1:19800. The actor changed /ns/config/haproxy.conf so requests for /uidchanarge passed through the public reverse proxy to that local listener. A perimeter scan aimed only at the listener port would miss this route: the public appliance path was the entrance. The actor repeatedly deleted host, web and application logs, including /ns/log/http-access.log and /var/log/messages.

Support sessions carried the intrusion onward

With compromised administrator credentials, the actor logged into the Remote Support web portal. A recovered user_changed syslog event shows Jump Item and team roles changing from No Access to Administrator. Mandiant then observed a support session to internal endpoints and native file transfers of documents, including software inventories, from a user’s desktop. This is the consequence beyond the appliance: support tooling supplied an authorized-looking path into the endpoints it managed.

For recognition, correlate forwarded syslog user_changed role elevations and session file-transfer records with reverse-proxy or WAF requests for unusual .php paths and WebSocket upgrades, especially /uidchanarge. On a forensic appliance image, look for mangoapi.php (SHA-256 dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb), ingredi_ws (SHA-256 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462), the SUID shell copy and the boot script. Log gaps are worth correlating with perimeter records: this actor removed local logs during the intrusion.

Patch first, preserve the trail

Google’s report quotes Mandiant’s guidance plainly: “Any appliance that was reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until it has been reviewed.” For self-hosted Remote Support 24.3.1 or later, apply the BT26-05-RS patch through /appliance, or verify the automatic update actually landed. Older self-hosted versions need an upgrade to a supported release followed by that patch. Google says BeyondTrust patched Remote Support SaaS tenants on October 9; those tenants still need the credential and configuration review if they were exposed earlier.

For a suspected compromise, preserve a virtual appliance’s memory snapshot and disk before reboot or isolation. For hardware or SaaS, request forensic preservation through BeyondTrust Support. Collect the off-appliance syslog, proxy or WAF, and firewall history for the exposure window. Mandiant recommends perimeter isolation for suspect appliances, then a clean patched rebuild for confirmed or unknown host compromise because host persistence survives reboot and customers cannot inspect the appliance host file system themselves. Coordinate session interruption with the support team.

Verify privileges and downstream access

After patching or rebuilding, compare /login accounts and Jump Item roles with a pre-window baseline and remove unauthorized grants. Have BeyondTrust Support or a forensic team with appliance-host access check the preserved image for changes to /ns/config/sudoers.template, startup scripts and /ns/config/haproxy.conf. Review the appliance’s support-session and file-transfer reports to identify managed endpoints the account touched. Rotate /appliance and /login credentials, API secrets, vault and integrated target-system credentials, and session tokens in the order Mandiant gives, after the appliance is secure. Otherwise fresh secrets can pass through a host the actor still controls.

Check the running patch state and confirm authorized accounts hold the intended Jump Item roles, the proxy routes only expected support paths, and forwarded syslog plus session records cover the review window. Where local logs were erased, use preserved external records to reconstruct the affected sessions and endpoints. The patch stops the file-operation flaw; rebuilding a compromised host and rotating its access address the foothold the actor already established.