BeyondTrust Remote Support Zero-Day: Detecting and Investigating CVE-2026-102764

For about six weeks, CVE-2026-102764 was a flaw in BeyondTrust Remote Support with no patch, and a suspected China-nexus espionage group already knew how to use it. BeyondTrust shipped a fix on October 8 and disclosed the flaw on October 15. On the appliance Mandiant investigated, the group planted a web shell, gave itself root access, and tried to dump the appliance's credential vault. That vault can hold the passwords, API keys, and endpoint credentials that support staff use to reach other machines.

Prophet AI Threat Hunter has an emerging-threat hunt for CVE-2026-102764. BeyondTrust says it knows of two affected customers so far. One was on a BeyondTrust-hosted instance, and one was on a self-hosted appliance. It also says it has seen no evidence of attacker activity since August. Even so, Mandiant warns that wider exploitation may follow now that the flaw is public. Shadowserver counts more than 1,400 BeyondTrust remote support instances exposed to the internet, although it has no data on how many are patched. Censys counted 9,569 internet-facing hosts running Remote Support or Privileged Remote Access on October 16, though it cannot see which versions they run.

Applying the patch is usually the quick part of the response. Leadership will also ask whether the appliance was breached before it was patched. On Remote Support, that takes extra work to answer. The attacker deleted the appliance's logs as it went, and customers cannot inspect the appliance's file system themselves.

{{ebook-cta}}

What We Know About the BeyondTrust Remote Support Zero-Day

The dates so far:

• Late August 2026: ARMORY CASTLE exploits the flaw as a zero-day, according to evidence Mandiant later found during an incident response engagement. BeyondTrust dates the exploitation of both known victims to August 29.
• September 28: BeyondTrust's own threat hunting finds the activity. Its sensors had fired when the actor escalated privileges, but the triage tool built into its third-party detection platform had closed those alerts as false positives.
• October 8: BeyondTrust releases the BT26-05 patch, which it applies to SaaS instances automatically. Every Remote Support SaaS instance had it by October 9.
• October 15: BeyondTrust discloses CVE-2026-102764, and Google's threat intelligence team publishes its analysis.
• October 16: CISA adds CVE-2026-102764 to its Known Exploited Vulnerabilities catalog and gives federal civilian agencies until October 19 to act.

This BeyondTrust vulnerability is in internal components of the appliance that did not properly check where incoming messages came from. According to Canada's Cyber Centre, an attacker can use it without logging in to upload arbitrary files and perform other file operations on the appliance. That can lead to full compromise of the appliance. BeyondTrust is withholding further detail while self-hosted appliances are still being patched.

BeyondTrust attributes the activity, with moderate to high confidence, to the group Mandiant now calls ARMORY CASTLE and previously tracked as UNC5221. BeyondTrust says CrowdStrike tracks the same group as WARP PANDA. Google has previously observed UNC5221 exploiting zero-day flaws in edge devices, and in 2025 the group exploited a critical flaw in Ivanti Connect Secure.

Mandiant's account of one intrusion shows what the group did after using the BeyondTrust Remote Support zero-day to get in:

• It first sent requests to a staging web shell, and about 11 minutes later it created a second PHP web shell that Mandiant calls SAWFLY. SAWFLY answers any request that lacks its secret parameter with a 404 error, so crawlers and vulnerability scanners see a missing page.
• To keep root access, it copied the system shell to a new file and set that file to run as root. Mandiant does not say how the group first got root.
• Next, it used bt-secrets, the appliance's own command-line tool for stored credentials, to try to dump the credential vault, and then it deleted that tool's log.
• A startup script it added writes passwordless sudo into the appliance's sudoers template, so its root access survives reboots and configuration resets.
• In the admin portal, it logged in with a compromised Administrator account and raised that account's Jump Item and Team permissions from No Access to Administrator. With those permissions, it could open remote sessions to the downstream systems in the appliance's Jump Item list.
• Through support sessions to internal endpoints, it used the built-in file transfer service to take documents, such as software inventories, from a user's desktop.
• It also ran a tunneling tool that Mandiant calls BARECLAW and edited the appliance's HAProxy configuration so the tool could be reached from the internet.
• Throughout the intrusion, it deleted system, web server, and application logs.

Why a Patched Remote Support Appliance Can Still Be Compromised

The BT26-05 patch closes the BeyondTrust Remote Support zero-day, CVE-2026-102764, but any Remote Support appliance that was reachable from the internet while running a vulnerable version since late August should be treated as potentially compromised until it has been reviewed. That is Google's guidance, because the patch is not built to remove what an attacker set up before it went on.

Customers cannot audit the appliance's host file system, so they have no way to find a startup script like the one in Mandiant's report without BeyondTrust's help. The log files where Mandiant found evidence of exploitation sit on an encrypted partition that customers cannot read on their own. For these reasons, Google recommends rebuilding suspect appliances from a clean, fully patched image instead of trying to remove the attacker from them.

The Citrix NetScaler zero-day in September followed a similar pattern, with a web shell on each compromised appliance and cleanup commands that deleted the attackers' traces.

Hunting for CVE-2026-102764 Exploitation

A customer checking for the BeyondTrust Remote Support zero-day has to work mostly from records stored outside the appliance. Those include syslog and session events forwarded to a SIEM, reverse proxy or WAF logs, perimeter firewall logs, and telemetry from the endpoints the appliance connected to. Between them, Google and BeyondTrust list this behavior to look for:

• Account and permission changes: user_changed events that raise a Jump Item or Team role, and user_added, api_account, or security_provider events with no change ticket. Google also flags any change to outbound events or syslog destinations.
• Admin logins from unexpected places: successful logins to /login from residential broadband or commercial VPN addresses, and admin logins outside your support team's working hours. Your own admins may log in from home or over a VPN too, so focus on logins you cannot tie to a known administrator or ticket.
• Session activity: file-transfer events, and sessions started by accounts whose roles changed during the window.
• New web content: requests to .php paths the appliance does not normally serve, unrecognized script files in web directories, and web service accounts spawning shells. Only the first appears in reverse proxy or WAF logs. The other two need host access, so they fall to BeyondTrust support or whoever examines a forensic image.
• Logging gaps: breaks in syslog forwarding that start and end inside a single session, which Mandiant calls a strong indicator of log tampering.
• WebSocket traffic: WebSocket upgrades from addresses outside the ranges your support staff and endpoints use. In the intrusion Mandiant studied, the tunnel used the path /uidchanarge, and the tunneling tool's default path is /wsproxy.

Mandiant also lists file artifacts from the intrusion. These are for BeyondTrust support, or for whoever examines a forensic image of the appliance:

• /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/mangoapi.php (the SAWFLY web shell)
• /usr/bin/dbus-authd (the copied system shell that runs as root)
• /home/bomgar/sbin/post_boot.d/zz-root-persist (the startup persistence script)
• %SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL (the line the script appends to /ns/config/sudoers.template)
• /tmp/ingredi_ws --listen 19800 --token %REDACTED% --obfs -q --ws-path /uidchanarge (the BARECLAW command line)
• acl wswsws path /uidchanarge (one of the lines added to /ns/config/haproxy.conf)
• use_backend webskd3 if wswsws and a backend webskd3 block with server websocks5srv 127.0.0.1:19800 (the rest of the same edit)

Google also published SHA-256 hashes and YARA rules for SAWFLY and BARECLAW, and BeyondTrust offers a threat hunting package through its trust portal. BeyondTrust says the group rotates its infrastructure and tooling for each victim, so indicators from one intrusion are unlikely to match another.

Investigating a Suspected Remote Support Compromise

If a check turns something up, preserve evidence before you patch or rebuild. Patching can erase evidence, and a rebuild replaces the appliance entirely. Google recommends snapshotting a virtual appliance with its memory before any change or reboot and collecting syslog, WAF, and firewall logs for the full exposure window. For B Series hardware and SaaS instances, it says to request forensic preservation through BeyondTrust Support. BeyondTrust asks customers with evidence of exploitation to open a Sev 1 case that cites BT26-05. Its help may also be needed to read the logs on the encrypted partition.

Start the scoping with the appliance's own records. Support session reports and file transfer logs show the endpoints the appliance reached through support sessions during the window, and each of those endpoints needs its own review. On each one, look at the EDR alerts and process activity from the session window, which files were opened or copied, and whether new accounts or scheduled tasks appeared afterward. Anything the group reached through the BARECLAW tunnel would not appear in session reports, so also check firewall or flow logs for connections from the appliance's address.

The size of the response depends largely on what was in the credential vault. If you find evidence of compromise, BeyondTrust says to treat every credential the appliance stored or injected as exposed and to rotate it. It also says to watch those accounts for logins outside a managed session or from unfamiliar locations, and to review new MFA registrations on privileged accounts.

Containment and Recovery After a Remote Support Compromise

• Isolate a suspect appliance first: block inbound traffic to its public address at the firewall rather than in /appliance, so the configuration stays intact for review. Deny outbound traffic except to BeyondTrust's update and licensing endpoints, and log every denied connection. End active support sessions and disable new sessions, Jump Clients, Jumpoints, and API accounts from /login. Disable rather than delete, so the audit trail survives.
• Patch, or confirm the patch: apply BT26-05-RS from the /appliance interface, or confirm that automatic updates applied it. The patch covers versions 24.3.1 through 26.2.3, and older appliances must first upgrade to a supported version.
• Patch Privileged Remote Access too: the product shares the affected code. BeyondTrust's testing found no way to exploit the flaw there, but it released a patch anyway and recommends that self-hosted customers apply it.
• Rebuild suspect appliances: redeploy any appliance with confirmed or unknown compromise status from a clean, fully patched image. Restore only a configuration backup from before the exposure window, or restore the newest backup while the appliance is isolated and finish the credential and configuration review before reconnecting it.
• Rotate credentials only after the appliance is patched or rebuilt: rotating earlier hands the new credentials to an attacker who still controls the appliance. A patch alone is not built to evict an attacker who is already in, so if an appliance's compromise status is confirmed or unknown, rotate after the rebuild. Google gives this order: /appliance admin credentials; /login administrators and local users; API client secrets; security provider bind accounts and SAML signing keys; vault and integrated Password Safe or Privileged Remote Access credentials, rotated at the target system; integration credentials; and any credential typed into a support session during the window.
• Restrict the admin interfaces: limit /login and /appliance by IP address or network segment, require SAML single sign-on with phishing-resistant MFA, and set the default Jump Item role to No Access.
• Keep logs off the appliance: forward appliance syslog and session events to your SIEM over TLS, with retention that covers several months.

A one-time sweep helps answer the question for the BeyondTrust Remote Support zero-day. The checks on Jump Item changes, admin login sources, and log forwarding gaps still work after this campaign ends. They look for what an attacker does on the appliance, so they do not depend on knowing the flaw. Run on a schedule, the same checks are a form of proactive threat hunting, and they can find the next appliance intrusion without waiting for a vendor disclosure. Prophet AI Threat Hunter runs hunts like these on the schedule a team sets and hands suspicious findings to Prophet AI SOC Analyst for a full investigation. See how it works.