Cowry Tech News
Security

BeyondTrust zero-day: what to ask if an outside IT provider supports you through Remote Support

BeyondTrust has patched a critical Remote Support flaw that Mandiant says a suspected PRC-nexus espionage group exploited as a zero-day from late August, and CISA added it to its known-exploited list on 16 October. What self-hosted customers must do, and the questions to ask any IT provider that supports you through the tool.

By Arjun Mehta · 18 Oct 2026 · 13 min

Cowry Tech News text card: Security and Trust, BeyondTrust zero-day
Cowry Tech News

Most companies never log in to a BeyondTrust appliance. They meet it from the other side. A help desk technician, a managed service provider or a software vendor’s support engineer sends a link, a session opens, and someone outside the building is looking at a desktop or a server. That is what remote support tools are for, and it is also why the flaw BeyondTrust disclosed on 15 October matters to more organisations than its own customer list.

BeyondTrust says the vulnerability, CVE-2026-102764, affects every version of its Remote Support product up to and including 26.2.3. Mandiant, Google’s incident response unit, says a group it calls ARMORY CASTLE, which it describes as a "suspected PRC-nexus espionage threat actor" (BeyondTrust’s own post says "suspected China-nexus"), exploited the flaw as a zero-day in late August, before any patch existed. The US Cybersecurity and Infrastructure Security Agency (CISA) added the CVE to its Known Exploited Vulnerabilities (KEV) catalogue on 16 October, with a remediation deadline of 19 October for federal civilian agencies. CTN’s Brief item on the KEV addition has the short version.

BeyondTrust’s hosted (SaaS) customers were patched automatically. Self-hosted customers have to apply the fix themselves. Everyone else, meaning the organisations that are supported through someone else’s appliance, has a different job: finding out whether their provider has done the work.

This piece sets out what the vendors and CISA have published, what is still unknown, and the questions to put to a provider. It is written for IT managers, compliance leads and the people who sign managed-service contracts.

What BeyondTrust and CISA have confirmed

BeyondTrust’s advisory, BT26-05, rates the flaw 9.3 on version 4 of the Common Vulnerability Scoring System, which puts it in the critical band. The company describes it as improper origin validation in an internal messaging component. In plain terms, parts of the appliance accepted messages without checking properly where they came from. “Under the right conditions,” the advisory says, that could let an attacker “perform file operations on the appliance”. The weakness is catalogued as CWE-290, authentication bypass by spoofing.

The fix is a patch called BT26-05-RS. It applies to Remote Support versions 24.3.1 through 26.2.3. Appliances older than 24.3.1 have to be upgraded to a supported version first and then patched.

BeyondTrust says the patch reached all SaaS Remote Support customers by 9 October. Its timeline says the patch shipped to SaaS and self-hosted customers on 8 October, with hosted instances of both Remote Support and Privileged Remote Access (PRA) patched automatically. PRA is BeyondTrust’s separate product for privileged access to servers and network gear. The company says its testing has not found a way to exploit the flaw in PRA, but PRA shares the affected code, so it released the patch for PRA as well and recommends self-hosted PRA customers apply it.

CISA’s alert of 16 October says threat actors are using the flaw to gain initial access and then establish persistence, escalate privileges and move laterally. It tells organisations with self-hosted appliances to patch, to limit what parts of the appliance are reachable from the internet, and to keep administrative interfaces on trusted networks.

CISA then adds a second list for organisations that suspect compromise: isolate the appliance, take a snapshot or forensic image, forward logs to a security information and event management (SIEM) system, investigate, rebuild from a known-good state, patch, and only then rotate every credential the appliance stored or injected.

The KEV catalogue entry, version 2026.10.16, lists the date added as 16 October and the due date as 19 October. Its field for known use in ransomware campaigns reads “Unknown”. The 19 October deadline binds US federal civilian agencies under Binding Operational Directive 26-04. For everyone else it is a useful yardstick. CISA “encourages all organizations” to prioritise KEV entries, and a three-day window says how urgent the agency considers this one.

The same KEV update added a second flaw, CVE-2025-61624, a path traversal vulnerability in several Fortinet products, with the same due date. It is a separate issue from a separate vendor. Anyone with Fortinet equipment should check Fortinet’s own advisory.

What Mandiant says happened

Mandiant’s report, published on 15 October alongside BeyondTrust’s disclosure, describes an intrusion it investigated on a self-hosted appliance. CTN has not independently verified any of the technical findings below. They are Mandiant’s account, and BeyondTrust says its investigation of an affected hosted instance matched it.

According to Mandiant, after exploiting the flaw the attackers planted a small PHP web shell, which Mandiant has named SAWFLY, on the appliance’s web server. They then copied the system shell to a new file and set it to run with root privileges, which gave them a persistent way back to full control of the host. Mandiant says that level of access gave them “access to every credential the appliance stored or brokered”.

Mandiant says the group then went after those credentials directly, using a built-in BeyondTrust command-line tool to try to read the appliance’s credential vault. The attackers changed a startup template so their account kept passwordless administrator rights after reboots and configuration resets, deleted logs at several points, and installed a custom tunnelling tool, BARECLAW, that let them route traffic through the appliance. They also changed the appliance’s reverse-proxy configuration so the tunnel could be reached from the internet.

The part that matters most for customers of IT providers came next. Mandiant says the group used a compromised administrator account inside the Remote Support application to raise that account’s permissions on Jump Items, the saved list of systems a technician can connect to, from “No Access” to “Administrator”. It then opened remote support sessions to internal machines and used the product’s own file transfer feature to download documents such as software inventories.

Once the appliance was taken, the attackers used it as designed, to reach the computers it was trusted to reach.

Who is affected, as far as anyone has said

BeyondTrust’s timeline names two affected customers. On 29 August, it says, the actor exploited the flaw against one BeyondTrust-hosted Remote Support instance and one self-hosted appliance. As of the blog’s latest update, on 16 October at 12:00 p.m. EDT, BeyondTrust says it knows only of those two and has not seen adversary activity since August.

Google’s threat intelligence group is more cautious. Kelli Vanderlee, a senior analyst there, told Cybersecurity Dive: “We are aware of only a small number of impacted organizations at this time, but given the stealth of the activity, and the use of a zero-day, it is possible that additional organizations were also compromised prior to the disclosure.”

Both statements can be true. A small confirmed count is the honest figure today. The caution is about what is still unconfirmed. Mandiant also warns that ARMORY CASTLE, which it previously tracked as UNC5221, has in past campaigns moved to broad exploitation of unpatched devices once a flaw it had used quietly became public. BeyondTrust says the same. Neither company has reported such a wave for this flaw so far. Their advice is to patch as if one is coming.

Mandiant attributes the activity to ARMORY CASTLE based on tooling and techniques that match earlier intrusions. BeyondTrust says it assesses “with moderate to high confidence” that the activity belongs to the same cluster, which CrowdStrike tracks as WARP PANDA. CTN reports this attribution as the companies’ assessment. Attribution in espionage cases rests on behaviour and is rarely provable in public.

The trust problem: your provider’s appliance is your perimeter

Remote support tools sit in an awkward place in most risk registers. The organisation being supported did not buy the tool, may not know which version is running, and often cannot see its logs. Yet the appliance holds credentials for that organisation’s systems and can open sessions into them.

Mandiant’s write-up shows why that matters. The attackers did not need to break into each downstream machine separately. They took the appliance, read what it stored, gave themselves broader access in the application, and used normal support sessions.

That makes the provider’s appliance part of the customer’s attack surface, whether or not the contract says so. NIST’s security control catalogue, SP 800-53 Revision 5, has a name for the relevant controls. SA-9, External System Services, covers what an organisation should require of providers that operate systems on its behalf. AC-17, Remote Access, covers how remote connections are authorised and monitored. SR-6, Supplier Assessments and Reviews, covers checking suppliers rather than trusting them by default. ISO/IEC 27001:2022 covers the same ground in Annex A controls 5.19 to 5.22 on supplier relationships and supplier service monitoring, and 8.8 on management of technical vulnerabilities.

None of those controls says “ask your MSP about BeyondTrust”. They do say that a supplier’s security is a customer’s problem, and this incident is a concrete reason to act on that.

Questions to ask your IT provider or vendor this week

If an outside party supports you through BeyondTrust Remote Support or PRA, these are reasonable questions to put to them in writing. A good provider will have answers ready. Vague answers are a signal in their own right.

  1. Which BeyondTrust product and hosting model do you use to reach our systems? BeyondTrust-hosted instances were patched by BeyondTrust by 9 October. Self-hosted appliances were not, unless the provider applied the patch or had automatic critical updates switched on.
  2. On what date did you apply BT26-05-RS, and to which version? Ask for the date. “We’re patched” without one is not an answer. If the appliance was older than 24.3.1, ask when it was upgraded.
  3. Was the appliance reachable from the internet on a vulnerable version between late August and the patch date? Mandiant says any appliance in that position “should be treated as potentially compromised until it has been reviewed”.
  4. Have you reviewed the appliance for compromise, and against which guidance? Look for a reference to BeyondTrust’s BT26-05 blog, CISA’s alert of 16 October, or Mandiant’s hunting guidance, including its file hashes and YARA rules.
  5. Are the appliance’s logs forwarded off the box? Mandiant and BeyondTrust both say the group deleted local logs. If syslog was not going to a SIEM, the provider may not be able to show what happened during the window. NIST SP 800-53 control AU-9, Protection of Audit Information, exists for this reason.
  6. Which of our credentials does the appliance store or inject, and will you rotate them? This includes vault entries, service accounts, API keys and anything a technician typed during a session. Mandiant’s guidance is to rotate only after the appliance is patched or rebuilt, so that new credentials do not land on a box an attacker still controls.
  7. Who can open sessions to our systems, with what role, and what changed recently? Mandiant’s detection advice singles out changes that raise Jump Item or team roles. Ask the provider to confirm that no such changes were made without a ticket.
  8. Do your technicians sign in with phishing-resistant multi-factor authentication? Mandiant recommends single sign-on with phishing-resistant MFA for all admin users, and removing local accounts except one monitored break-glass account.
  9. When would you have told us? If the answer to question 3 is yes, find out what the contract says about notifying you. Nigeria’s Data Protection Act 2023 and similar laws elsewhere place breach-notification duties on organisations that control personal data and on the processors that handle it for them. A provider that finds evidence of access to your environment should be telling you, not waiting for you to ask.

If you run your own self-hosted appliance, the order is simpler and comes from the vendors and CISA: patch first, restrict the administrative interfaces to trusted networks, get the logs off the box, hunt for the behaviours Mandiant describes, and rebuild and rotate if anything looks wrong.

The detection lesson BeyondTrust published about itself

One section of BeyondTrust’s blog stands out because it describes the company’s own miss. BeyondTrust says its sensors fired in real time when the attacker escalated privileges on the hosted instance, but “the built-in triage tool in our third-party detection platform closed those alerts as false positives”. The compromise was found on 28 September by a threat hunt that BeyondTrust started after another vendor’s zero-day became public on 27 September. BeyondTrust says it contained the instance within 27 minutes of finding it.

The company says it is working with the detection vendor so automated triage cannot close high-severity alerts on its own, and it recommends other defenders set the same default. That is a practical point for any organisation buying managed detection, and a fair question for a provider: when an automated system closes a high-severity alert, does a person see it?

The patch timeline is also on the record. BeyondTrust took from 28 September to 8 October to ship the fix. The company says it used that time for variant analysis, looking for other routes to the same weakness, and fixed those too before release. It held back technical details of the flaw while self-hosted appliances were still being patched, and coordinated disclosure with Mandiant on 15 October. Customers can judge that trade-off for themselves.

What we still don’t know

Several things remain open as of 17 October:

  • How many organisations were affected. BeyondTrust has confirmed two. Google says the true number could be higher. Neither has named the victims, and CTN will not speculate about them.
  • Who the “other security device provider” is. BeyondTrust says a separate zero-day campaign against another vendor’s edge appliances became public on 27 September. It does not name the vendor.
  • The technical detail of the flaw. BeyondTrust is withholding it until self-hosted customers have had time to patch.
  • The status of PRA. BeyondTrust says it has found no way to exploit PRA but has patched it because the code is shared.
  • The claim about AI. BeyondTrust says its “working assessment” is that the actor uses an AI system loaded with product knowledge to build exploit chains, and states that it has no forensic proof of this. CTN reports it as the company’s assessment and nothing more.

CTN has not yet asked BeyondTrust, Mandiant or CISA for comment on this piece. We will update it if any of the three adds to the public record.

The short version for a busy week

If you own a self-hosted BeyondTrust Remote Support or PRA appliance, apply BT26-05-RS now, or upgrade and then apply it, and work through CISA’s compromise checklist if the appliance was exposed.

If you are supported through someone else’s appliance, send your provider the questions above and keep their answers on file. The control frameworks already tell you to manage supplier risk. This week, there is a specific flaw, a specific date range and a specific patch to ask about.

Sources