BeyondTrust Remote Support zero-day: patch it, then check who got in

Attackers broke into BeyondTrust Remote Support in late August, through a flaw the vendor only patched in October. If you run Remote Support on your own appliance, patch it today and then check whether someone got in first. Patching won't remove anything an attacker already planted, so most of this post is about the second part.

A remote support appliance is a very good place for an attacker to stand. It's reachable from the internet by design, it holds admin passwords, and it already has permission to open sessions to machines across the company. Anyone who takes control of it gets a ready-made way in to everything it can reach, and the traffic looks like normal support work.

The attack needs no password and no click from anyone. CISA's own assessment in the CVE record marks exploitation as active, the attack as automatable and the technical impact as total. It went into CISA's catalog of known exploited vulnerabilities on October 16 with a due date of October 19 for federal agencies, and with a flag that reads forensic triagedefinitionA first check of a system for signs of compromise, done before it's cleaned or rebuilt. CISA now requires it for some KEV entries, this one included. required. Under CISA's directive BOD 26-04, that means agencies have to check the appliance for signs of compromise as well as patch it. CISA's directive binds only federal agencies. It's still the right bar for anyone else running one of these boxes.

So far the confirmed victims are few. BeyondTrust says it knows of two compromises, both dating to August 29: one instance it hosted and one appliance a customer ran. Mandiant attributes the work to ARMORY CASTLE, which it describes as a suspected China-nexus espionage group, formerly tracked as UNC5221 (CrowdStrike calls it WARP PANDA). Mandiant also warns that wider exploitation attempts may follow now that the flaw is public. No public proof-of-concept had turned up as of October 16, and BeyondTrust is holding back the technical details while customers patch.

For engineers, Mandiant's report has the detail. The first requests went to an odd path, /app_84304470%2Ephp. The SAWFLY shell (mangoapi.php) answers with a 404 unless a secret parameter is present, which keeps scanners from spotting it. The attacker copied /bin/sh to /usr/bin/dbus-authd with the SUIDdefinitionA Linux file permission that makes a program run with its owner's rights. A copy of the shell owned by root with SUID set gives anyone who runs it root. bit set, dropped zz-root-persist into /home/bomgar/sbin/post_boot.d, and edited /ns/config/haproxy.conf so a WebSocket path, /uidchanarge, forwarded to a tunnel called BARECLAW on local port 19800. Then they ran /ns/sbin/bt-secrets against the vault and deleted bt-secrets.log along with more than a dozen logs.

The part that should worry an identity team comes after that. With a stolen administrator login, the attacker changed an account's Jump Item and Team permissions from No Access to Administrator. In Mandiant's words, that gave "permanent, unrestricted authorization to launch remote sessions to downstream systems." They used support sessions to ask for full file system access and pulled software inventories out. Nothing about that looks strange to a support tool, because opening sessions and moving files is its whole job.

The fix is a patch called BT26-05-RS. BeyondTrust's advisory lists every Remote Support version up to and including 26.2.3 as affected. It applied the patch to all of its hosted Remote Support instances by October 9, so SaaS customers don't have to touch the appliance. Self-hosted appliances on 24.3.1 or later take the patch from the /appliance admin interface. Anything older has to be upgraded to a supported version first, and then patched.

The patch only shuts the door. It doesn't tell you whether anyone came through it while it was open, and the attacker in Mandiant's case built persistence that survives reboots and configuration resets. Mandiant's advice is blunt: treat any internet-reachable appliance that ran a vulnerable version during the exploitation window as possibly compromised until someone has reviewed it.

The review is harder than it sounds. You can't audit the appliance's host file system yourself, so the file-level checks Mandiant lists mean working with BeyondTrust Support. If the patch doesn't show in /appliance, open a support case citing BT26-05. And the attacker deleted logs on the box, so anything you didn't already forward to a SIEM may be gone.

One detail from BeyondTrust's own account is worth reading twice. The company says its sensors fired in real time when the attacker escalated privileges, and the automatic triage in its third-party detection platform closed those alerts as false positives. If a security vendor's own alerts got closed by automation, assume yours could be too. Look again at anything your tooling auto-closed on these appliances since late August.

If you only have time for one check today, make it the account changes. Mandiant's case turned on a stolen admin raising permissions from No Access to Administrator, and that leaves a trail in the appliance's own events even when files on disk are gone. Pull the forwarded events for user_changed, user_added, api_account and security_provider, and match each one to a change ticket.

# example output. Field names differ by SIEM, so rename them to match yours
# 1. Requests to PHP paths support staff never use (reverse proxy or WAF logs)
uri ends_with ".php" and uri not in known_paths
# 2. WebSocket connections on /uidchanarge (used here) or /wsproxy (the tunnel's default)
uri in ("/uidchanarge", "/wsproxy") or header.upgrade = "websocket" and src not in support_ranges
# 3. Gaps where the appliance stopped sending syslog. Someone may have deleted logs
gap(host = rs-appliance, min = 10m)

Remote access appliances will keep getting bugs. Remote Support has had three serious advisories this year. Aim for the next one to cost you a patch night and a quiet log review, and nothing more. Most of the hardening below comes from Mandiant's recommendations for this case. Each item cuts off something the attacker in this intrusion actually used.

Two of these do most of the work. Getting stored credentials off the appliance means a vault dump gets the attacker very little, and the injection model means technicians never see the passwords anyway. Setting the default Jump Item role to No Access means a raised permission stands out as a deliberate change in the logs. Filter egress too: Mandiant suggests allowing only BeyondTrust's own endpoints and your internal syslog and directory servers, so a tunnel like BARECLAW has nowhere to call.

Keep a written list of what the appliance can reach. When the next advisory comes, that list tells you on day one which credentials to rotate and which servers to look at, instead of working it out during the incident. If you already run CyberArk or HashiCorp Vault for other secrets, the same rule applies: the remote access tool should borrow credentials at session time, never keep its own copies.

A note on rotation order, because it's where incident teams usually slip. The instinct is to change every password the moment you suspect a breach. Mandiant warns against it here: until the appliance is patched or rebuilt, an attacker who still controls it can read the new credentials as easily as the old ones. Contain, rebuild, then rotate.

These three are made up, and none of them is a real incident or a Cohash client. They all get the same patch from BeyondTrust. What decides how bad it gets is how each one was set up before August, mostly who could reach the admin page and whether logs left the box.

We work on BeyondTrust estates, mostly Privileged Remote Access, Password Safe and vendor access through jump points. On this advisory we'd start by finding every appliance, then plan the patch and the checks, and only rotate credentials once it's safe. Later we'd move stored passwords to injection and lock the admin pages down. The BeyondTrust page is at /tools/beyondtrust, engineers are at /tools/beyondtrust#hire, and you can book a review through /assessment.