BeyondTrust Remote Support zero-day exploited by Chinese spies

How long does a state-backed intrusion crew need inside your remote-support appliance before "we patched it" stops being a sufficient answer? Based on what Mandiant and Google Threat Intelligence Group published this week, the honest answer is about eleven minutes — the time between the first malicious request and a web shell sitting in the appliance's web root.

The vulnerability is CVE-2026-102764, a critical authentication bypass in BeyondTrust Remote Support (formerly Bomgar) versions 26.2.3 and earlier, scored 9.3 on CVSS 4.0. According to The Record, exploitation dates back to August 29 — weeks before anyone noticed — and is attributed to ARMORY CASTLE, also tracked as UNC5221, a group Mandiant and BeyondTrust describe as a Chinese state-sponsored espionage operation. CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 16 and gave federal agencies until October 19 — tomorrow — to remediate. If you run a self-hosted appliance, this is your weekend.

The bug: spoof your way in, then operate on files

CISA's KEV entry describes CVE-2026-102764 as an authentication bypass by spoofing that lets a remote attacker perform file operations on the appliance. Mandiant's reporting, cited by CSO Online, fills in the blast radius: an unauthenticated attacker can chain those file operations into host-level control and reach every credential the appliance stores or brokers. For a box whose entire job is brokering privileged remote sessions, that's the worst possible primitive to hand someone.

BeyondTrust disclosed the flaw in advisory BT26-05 and says it shipped the fix, BT26-05-RS, on October 8 — before public disclosure. There's a catch buried in CISA's alert: patches exist only for supported versions (24.3.1 and later). If your appliance is running anything older, you don't get a hotfix; you get an upgrade project. BeyondTrust-hosted SaaS instances of Remote Support and Privileged Remote Access were patched automatically, and BeyondTrust says those customers need take no further action. The company is withholding technical details of the vulnerability while self-hosted customers patch, so nobody outside the involved parties has published a proof of concept. Everything known about exploitation comes from incident response, not theory.

Eleven minutes from first request to web shell

The post-exploitation chain Mandiant documented is worth walking through, because it's a masterclass in squeezing maximum persistence out of a single appliance bug. BeyondTrust's timeline puts the first exploitation on August 29, against one BeyondTrust-hosted instance and one self-hosted appliance. Roughly 11 minutes after the first malicious request, a PHP web shell Mandiant calls SAWFLY appeared in the appliance's web root, according to Google's write-up.

SAWFLY landed running as an unprivileged service account — a speed bump, not a wall. To escalate, the actor pulled a classic CTF move: copy the shell binary to an innocuous-looking path, hand it to root, flip the SUID bit. Mandiant described the steps, which look like this in essence:

# copy the shell to a path that blends in with system daemons
cp /bin/sh /usr/bin/dbus-authd
# make root the owner and set the SUID bit
chown root /usr/bin/dbus-authd
chmod u+s /usr/bin/dbus-authd
# any user executing it now gets an euid-0 shell
/usr/bin/dbus-authd -p

It's the kind of trick you'd expect in a Hack The Box machine, which is exactly why it works on appliances nobody audits: a SUID binary named dbus-authd doesn't trip anything that isn't looking for it. The actor then planted a startup script that writes a passwordless sudo entry into BeyondTrust's sudoers template — so root survives reboots and configuration resets, not just the current session. That's persistence engineered against the two things an admin would actually try first.

Next came the prize. The actor ran several variations of bt-secrets, BeyondTrust's proprietary command-line utility, to dump the appliance's credential vault — every credential the box stored. Then the help-desk tool got turned against its owner. Using a compromised administrator account, the attacker raised the account's Jump Item and Team permissions from No Access to Administrator.

Mandiant described the consequence plainly: that single configuration change gave the actor standing authorization to launch remote sessions against any system populated in the appliance's Jump Item list — no further exploitation required, because the appliance itself now treated that access as legitimate.

Read that again if you run a help desk: the Jump Item list is the appliance's map of your endpoints. Admin rights over it is legitimate-looking remote access to everything downstream, riding the tool your own IT team trusts. For exfiltration and C2, the actor deployed BARECLAW, a custom SOCKS5 tunneler, and edited the appliance's HAProxy configuration to route traffic to it through a hidden local listener — inbound proxying that looks like normal appliance traffic. To cover the tracks, more than a dozen system, web server and application logs were deleted. Mandiant's bottom line, per The Record: any vulnerable appliance reachable from the internet should be treated as potentially compromised until reviewed.

Who's behind it, and why the Ivanti precedent should worry you

Mandiant tracks the actor as ARMORY CASTLE (formerly UNC5221) and, together with GTIG, attributes it to a suspected PRC-nexus espionage operation; BeyondTrust endorsed that assessment, calling it a "state-sponsored espionage operation focused on long-term intelligence collection." The group has been active since October 2023, with documented targets including legal services, SaaS providers, business-process outsourcers, technology companies and government. Mandiant noted the attackers "leveraged a deep understanding of BeyondTrust appliance internals" — the bt-secrets abuse alone shows they studied the product, not just the bug.

The pattern recognition here matters more than the attribution. ARMORY CASTLE was previously implicated in zero-days against Citrix and multiple Ivanti flaws — CVE-2023-46805, CVE-2024-21887 and CVE-2025-0282. Their playbook, as BeyondTrust described it: use a zero-day selectively against chosen targets, then, once the vulnerability is public, move to broad exploitation of every unpatched instance. In one 2025 case, Mandiant reported the actor took an Ivanti patch for a low-risk flaw, studied it, and reverse-engineered working remote code execution against unpatched appliances. GTIG and Mandiant's warning this week was explicit:

"Organizations should prepare for potential widespread exploitation following this disclosure," Google Threat Intelligence Group and Mandiant said in their blog post.

So the clock isn't just ticking on patching — it's ticking on the gap between disclosure and the spray-and-pray phase, which historically starts fast with this crew.

A month undetected, and an awkward lesson in alert triage

The detection timeline deserves its own scrutiny, because it's the part of this story that generalizes to your environment. Exploitation began August 29. BeyondTrust found the intrusion on September 28 — tipped off only after another vendor's edge appliances were publicly reported compromised and Mandiant sent a brief, non-specific warning that sent engineers hunting. "Our sensors fired in real time when the actor escalated privileges," BeyondTrust wrote — but the built-in triage tool in its third-party detection platform closed those alerts as false positives. The company hasn't named the vendor and says it's working with them so automated triage can't close high-severity signals on its own.

To BeyondTrust's credit, once humans looked, response was fast: the hosted instance was contained 27 minutes after identification. But a month of dwell time on an edge appliance, ended by an external tip and undermined by an auto-closing triage bot, is a scenario every SOC should game out on its own tooling this week. Neither BeyondTrust nor Mandiant has said whether other customers were compromised — that's a confirmed unknown, and given the actor's history, the absence of named victims offers no assurance that there are none.

The upgrade-versus-breach math

Here's the tradeoff in concrete terms. Option A: patch BT26-05-RS — an appliance update, some change-window negotiation, maybe an awkward conversation about why Remote Support lagged a version or two behind. If you're on a version older than 24.3.1, Option A includes a full version upgrade first, which is real work but scheduled work.

Option B is the path CISA laid out for suspected compromise, and it reads like an incident-response invoice: isolate the appliance; snapshot virtual appliances or forensically image physical ones; forward syslog and session events to the SIEM before anything touches them; pull WAF, reverse-proxy and perimeter firewall logs for the entire exposure window; rebuild from a known-good state; then rotate every credential the appliance stored or injected, revoke all active support sessions, and review new MFA registrations on privileged accounts. That last item is the sleeper — credential rotation across everything a support appliance has ever touched is measured in weeks, not hours. Option A is cheaper by an order of magnitude, and it expires tomorrow for federal agencies under the KEV deadline.

What to do this weekend

Detection-first, then remediation — because with a month-long exposure window and a log-wiping actor, patching a compromised box just hands the attacker a freshly patched box. Concrete steps, drawn from CISA's alert and Mandiant's findings:

• Ship appliance syslog and session events to your SIEM before rebuilding, and preserve an image or snapshot for forensics.
• Hunt for the persistence artifacts Mandiant named: a SUID /usr/bin/dbus-authd, passwordless sudo entries in the sudoers template, unexpected startup scripts, and HAProxy configs routing to hidden local listeners.
• Look for the behavior, not just the files: unrecognized privileged sessions, Jump Item or Team permission changes to Administrator, unrecognized script files, and gaps in logs or log forwarding — the actor deleted more than a dozen log files.
• Rebuild from known-good, apply BT26-05-RS, rotate every credential the appliance stored or injected, revoke active support sessions, and review MFA registrations on privileged accounts.
• Reduce the attack surface permanently: limit external access to the services needed to support users, and restrict administrative interfaces to trusted networks.
• Check your triage automation: if your tooling can auto-close high-severity alerts, BeyondTrust's month of dwell time is your cautionary tale.

Edge appliances keep getting picked as the front door because they concentrate trust: credentials, session brokering, a map of downstream endpoints. ARMORY CASTLE has now run this playbook against Ivanti, Citrix and BeyondTrust. Patch, image, hunt, rotate — in that order, and starting now.