BeyondTrust Remote Support CVE-2026-102764: ARMORY CASTLE Came Through the Support Session

Most of the organizations that need to act on CVE-2026-102764 do not own a BeyondTrust appliance. They are customers of someone who does.

Google Threat Intelligence Group published the intrusion analysis on October 15. A suspected PRC-nexus espionage actor it tracks as ARMORY CASTLE, previously UNC5221, used an unauthenticated file-operation bug in BeyondTrust Remote Support as a zero-day from August 29. CISA told everyone to patch immediately on October 16 and added the CVE to the Known Exploited Vulnerabilities catalog the same day, with a federal due date of October 19 and a forensic triage requirement attached. BeyondTrust scored it CVSS 4.0 9.3. The NVD record scored it CVSS 3.1 9.8. Both landed on CWE-290, authentication bypass by spoofing.

Root on the appliance took about twenty minutes. Everything after that ran through the product working exactly as designed, and that is the part worth your afternoon.

Whether this one is yours

Four groups, four different answers.

You self-host Remote Support at 26.2.3 or earlier, and the appliance was reachable from the internet at any point between August 29 and the day you installed BT26-05-RS. Treat the appliance as compromised until a forensic review says otherwise. This is the group CISA is talking to.

You are a Remote Support SaaS tenant with no self-hosted appliance. BeyondTrust patched your instance on October 9 and the appliance side is closed for you. The session side is not, so start again at the fourth section.

Your remote support runs on ScreenConnect, SimpleHelp, Splashtop, TeamViewer, or an RMM's built-in session tool. This CVE is not yours. The version numbers below do not apply and you can stop reading here.

And the group the coverage keeps skipping: you run no remote support platform at all, but a managed service provider or an outsourced helpdesk reaches your endpoints through one. You have no appliance to patch and no log to query, and you still carry the exposure, because what ARMORY CASTLE did with root was open support sessions into customer networks. For you this article ends in a conversation rather than a change window.

What BT26-05 closed, and what it leaves behind

The defect lives in an internal messaging component that did not validate the origin of the messages it received. A remote attacker with no credentials could send it spoofed messages and perform file operations on the appliance. Every Remote Support release up to and including 26.2.3 is affected. The fix is the BT26-05-RS patch, which installs on 24.3.1 through 26.2.3 from the /appliance interface. Anything older than 24.3.1 has to be upgraded to a supported release first, and the upgrade does nothing about exposure that already happened.

The exposure window

• August 29, 2026 - first observed exploitation, against one BeyondTrust-hosted and one self-hosted appliance.
• September 28 - BeyondTrust identifies the vulnerability.
• September 30 - the patch is built, then held while other exploitation paths are tested.
• October 8 - BT26-05-RS ships to self-hosted customers.
• October 9 - every Remote Support SaaS tenant is patched.
• October 15 - the advisory and the Mandiant analysis go public.
• October 16 - CISA KEV addition, due October 19 under BOD 26-04.

Forty days passed between the first intrusion and a patch anyone could install, and another week passed before customers were told what the patch was for. A team that applied BT26-05-RS on October 8, the day it shipped, did everything right and still has the entire window sitting behind it.

The patch closes the file-write primitive. It does not reverse what the primitive was used for. ARMORY CASTLE copied /bin/sh to /usr/bin/dbus-authd, set it root-owned and SUID, and dropped a startup script at /home/bomgar/sbin/post_boot.d/zz-root-persist that appends a NOPASSWD: ALL grant to /ns/config/sudoers.template and regenerates /etc/sudoers from it. Because the grant is reapplied from the template at boot, it survives a reboot and a configuration reset. They also edited /ns/config/haproxy.conf to route the path /uidchanarge to a loopback listener on port 19800, where a C SOCKS5-over-WebSocket tunneler Mandiant names BARECLAW was running as /tmp/ingredi_ws. An external port scan sees nothing, because the backend is local-only and HAProxy does the reaching.

The host indicators you cannot check yourself

Here is the inconvenient part of this advisory. A Remote Support appliance does not give its owner a shell, and the log partition is LUKS-encrypted. You cannot run the host checks on a live box. They run against a forensic image, or they run through BeyondTrust support, which means somebody has to ask for them by name. Build the list before you make the call.

# Run against a mounted forensic image of the appliance.
# The live appliance gives customers no host shell; this is not a live-response script.
IMG=/mnt/rs-image

# Root-owned SUID shell copy
find "$IMG/usr/bin" -name 'dbus-authd' -perm -4000 -ls

# Boot persistence that rewrites the sudoers template
ls -l  "$IMG/home/bomgar/sbin/post_boot.d/"
grep -n 'NOPASSWD: ALL' "$IMG/ns/config/sudoers.template"

# HAProxy route to the local tunneler
grep -nE 'uidchanarge|webskd3|127\.0\.0\.1:19800' "$IMG/ns/config/haproxy.conf"

# SAWFLY webshell and BARECLAW tunneler
find "$IMG" \( -name 'mangoapi.php' -o -name 'ingredi_ws' -o -name 'app_*.php' \) -ls

# Missing logs are a finding, not a clean result
ls -l "$IMG/ns/log/"{auth.log,http-access.log,php-fpm.log,proto-handler.log}

The webshell is worth a second look if your forensics provider is scoping effort. Mandiant describes SAWFLY as obfuscated PHP that answers any request without the POST parameter _c94mfe with http_response_code(404) and exits. A scanner walking the web root gets a 404 and moves on. GTIG published a YARA rule for it that keys on the Base32 alphabet, the RC4 setup loop, and that 404 call appearing together in a file under 20 KB.

The evidence that survives is the evidence you forwarded

The actor used sudo to delete the appliance's own logs: /ns/log/auth.log, ssl.log, proto-handler.log, the HTTP access and error logs, the PHP-FPM logs, /var/log/messages, and the site httpd_access.log and httpd_error.log. They also deleted /home/bomgar/log/bt-secrets.log and its rotated copies, after calling the proprietary /ns/sbin/bt-secrets utility three different ways to dump the appliance's credential vault.

Read that last sentence again if you store privileged credentials on the appliance for session injection. Those are gone.

Because the on-appliance record is unreliable, the investigation lives in the telemetry you shipped somewhere else: syslog forwarded to a SIEM, the reverse proxy or WAF in front of the appliance, the perimeter firewall, and EDR on the endpoints support sessions touched. Start with the administrative events, because a role change is the pivot that mattered.

index=remote_support sourcetype=beyondtrust:syslog
  earliest="08/29/2026:00:00:00" latest="10/09/2026:00:00:00"
  ("user_changed" OR "user_added" OR "api_account" OR "security_provider")
| search _raw="*Administrator*" OR _raw="*jump*"
| table _time, host, _raw
| sort 0 _time

Every account that comes back from that search needs a second pass over its sessions. An administrator account that suddenly reaches endpoints it never touched before August 29 is the shape of the lateral movement Mandiant documented.

index=remote_support sourcetype=beyondtrust:syslog
  earliest="08/29/2026:00:00:00" latest="10/09/2026:00:00:00"
  ("session_start" OR "file_transfer")
| stats count AS events, dc(target_host) AS endpoints, values(target_host) AS hosts BY account
| where endpoints > 2
| sort - endpoints

Then check the perimeter for the tunnel path and for web requests outside the known Remote Support URL set. Unknown .php paths and WebSocket upgrades from anything that is not a support client both qualify.

zgrep -hE 'uidchanarge|app_[0-9a-f]+(%2E|\.)php|mangoapi' /var/log/nginx/*access*
zgrep -hiE 'Upgrade: websocket' /var/log/nginx/*access* | grep -v '/nw/'

One more check belongs here and it is the one teams skip: look for gaps in the forwarded stream itself. If syslog from the appliance stops for an hour in September and nobody opened a ticket about it, that silence is the clearest artifact you are going to get.

The support session was the second stage

After root, ARMORY CASTLE logged into the /login web administration portal using a compromised administrator account. They tested temporary membership in the native Administrators group, then made it durable by raising that account's default Jump Item role and its Teams Jump Item role from "No Access" to "Administrator". Mandiant saw it as a user_changed event. Then they opened remote support sessions, got file-system access on internal endpoints, and pulled documents out through the built-in file transfer service. Software inventories, among other things, which is reconnaissance for whatever comes next.

Nothing in that second half looks like an attack in a log. A support account that can reach more endpoints, and sessions that transfer files, is a description of remote support working. The only way to tell the two apart is a baseline of what each role could reach before August 29, and almost nobody has one.

If you own the platform, pull the /login configuration and compare it to a pre-window backup: Jump Item roles, group policies, API accounts, security providers, and the outbound syslog and event destinations. CISA also asks you to review MFA methods registered on privileged accounts during the window, which catches the enrollment an attacker leaves behind for later.

Ask for the patch date before you ask anything else

If your provider runs the appliance, you have no patch to install and three questions to send, in writing, today. First: was the Remote Support appliance self-hosted and internet-reachable between August 29 and the date BT26-05-RS was applied, and what was that date? Second: was a disk and memory image preserved before patching or rebuilding, and did the Mandiant host indicators come back clean against it? Third: which of our endpoints had a Jump Client, and can we have the session and file-transfer log for August 29 through October 8?

If you own the appliance, the order of operations matters. Patch or rebuild first, then rotate, because credentials rotated into a still-compromised appliance are credentials you have donated. Mandiant's sequence is /appliance administrators, then /login users, then API secrets, then security provider bind accounts and SAML signing keys, then vault and privileged remote access credentials rotated at the target system, then integration credentials. Host-level persistence survives a configuration reset and customers cannot audit the filesystem, so for any appliance that was exposed during the window, redeploy from a clean image and restore only pre-window configuration backups.

Either way, the thing to fix after the incident is the same: write down which vendors hold a path into your endpoints, what each one can reach, and who tells you when they get breached. That inventory takes an afternoon and it is the difference between reading this advisory and knowing whether it applies to you.