Executive summary

Mandiant's October investigation describes exploitation of BeyondTrust Remote Support followed by persistent administrative access and movement into customer environments. BeyondTrust's earlier vulnerabilities and service incident make this a recurring exposure that deserves an estate-wide review, with each product and incident kept distinct. We assess that closing the initial vulnerability alone is likely to leave material uncertainty about downstream access where compromise occurred: Likely (B2), based on the documented permission changes, credential targeting and additional access mechanisms. The useful SolarWinds comparison concerns trusted management systems, concealed activity and recovery scope; it does not establish a shared actor, a compromised BeyondTrust software build, or equivalent victim numbers.

Why the trust relationship matters

Remote Support, formerly Bomgar, gives support teams access to remote endpoints, as Mandiant explains. For defenders, the consequential inventory is therefore more than a list of appliance addresses. It should describe who administers each instance, which customer or business networks it can reach, what privileges sessions receive, and which credentials or integrations depend on it. Treat these relationships as part of the asset record.

Include supplier-operated access in that exercise. Ask service owners to identify the instance supporting the organisation, its hosting model and its authorised endpoint population. A supplier's generic assurance that it has patched “BeyondTrust” is insufficient evidence for a particular deployment. Request the product, release, applied advisory, completion time and scope of any compromise investigation. Keep patch verification and investigation closure as separate decisions, each with a named owner.

This approach also avoids treating every product carrying the vendor's name as interchangeable. Distinguish Remote Support (RS) from Privileged Remote Access (PRA), and vendor-hosted software as a service (SaaS) from customer-operated appliances. Apply each advisory to the relevant product and release branch. A patched hosted service does not answer whether a separate appliance, integration account or previously accessed endpoint needs attention.

For practical scoping, maintain a matrix linking each support identity to its permitted endpoint groups and credential sources. Record whether those permissions are permanent, inherited from a group or granted for a specific task. During an incident, compare the current matrix with the last independently verified baseline and investigate unexplained differences. Include dormant accounts and emergency access procedures in that review. A nominally unused account should still have an owner, a purpose and a reason to retain its reach.

Repeated weaknesses, different incidents

BeyondTrust's completed investigation into its December 2024 incident says 17 Remote Support SaaS customers were affected. A compromised infrastructure application programming interface (API) key enabled local application password resets. The vendor traced the initial access to a zero-day in a third-party application within its cloud environment; it separately discovered the two product vulnerabilities below. This does not justify describing both product flaws as the proven initial route into every customer.

The US Cybersecurity and Infrastructure Security Agency (CISA) confirmed its work with Treasury and BeyondTrust on 6 January 2025. At that time, it reported no indication that another federal agency had been affected. Treasury is consequently a confirmed incident context, while that statement supplies neither a full customer impact count nor a finding about the separate 2026 operation.

Advisory and vulnerability Vendor's affected product scope Vendor's remediation route
BT24-10: CVE-2024-12356, unauthenticated command injection RS and PRA 24.3.1 and earlier BT24-10-ONPREM1 or ONPREM2, depending on release; versions below 22.1 need upgrading before patching.
BT24-11: CVE-2024-12686, command injection requiring existing administrative privileges RS and PRA 24.3.1 and earlier Release-specific BT24-11-ONPREM1 through ONPREM7; versions below 22.1 need upgrading before patching.
BT26-02: CVE-2026-1731, pre-authentication command execution RS through 25.3.1; PRA through 24.3.4 RS: BT26-02-RS for 21.3–25.3.1, or 25.3.2 onward. PRA: BT26-02-PRA for 22.1–24.x; see the release discrepancy below.
BT26-05: CVE-2026-102764, insufficient validation of message origin permitting file operations RS through 26.2.3 BT26-05-RS for 24.3.1–26.2.3; earlier releases require upgrading before patching.

For BT26-02, the vendor's fixed-version table lists PRA 25.1 and later, while its mitigation paragraph specifies 25.1.1 and later. Record this discrepancy rather than silently choosing one statement; seek confirmation for the deployed build or use the applicable patch. The vendor says both SaaS products were patched by 2 February 2026 and describes exploitation attempts against internet-facing self-hosted deployments left unpatched before 9 February.

Huntress's 17 April report illustrates the downstream stakes. It observed ransomware delivered from a dental software company's compromised Bomgar instance affecting three downstream companies, and a separate managed service provider incident involving additional remote-access tools. Huntress considered CVE-2026-1731 the likely cause, while explicitly acknowledging that it lacked further insight into the root cause. Its observed account creation and additional management tools are useful hunting leads without turning that qualified vulnerability association into certainty.

The October disclosure and its boundaries

In its update dated 16 October, BeyondTrust identifies two affected customers: one hosted RS instance and one self-hosted appliance, exploited on 29 August 2026. The vendor says it detected the hosted incident on 28 September and contained that instance 27 minutes later; it reported no observed adversary activity after August.

The same update says PRA shares affected code, but internal testing had found no exploitation path in PRA. Its PRA patch was precautionary. That distinction matters when communicating exposure: shared code and a patch recommendation are not evidence that PRA customers suffered the reported exploitation.

BeyondTrust's blog dates patch release to 8 October; the BT26-05 advisory says all RS SaaS customers were patched by 9 October. Preserve those separately stated milestones when checking deployment records. For self-hosted RS, 24.3.1 is the minimum release that can receive this patch, not a declaration that unpatched 24.3.1 is safe. Verify patch installation explicitly.

Persistence extends beyond the vulnerable component

Mandiant attributes the operation to ARMORY CASTLE, formerly tracked by Google as UNC5221, which it assesses as a China-nexus espionage actor. It describes the SAWFLY webshell, BARECLAW tunnelling, root-level access and altered startup configuration designed to survive reboots and configuration resets. It also observed attempted credential-vault extraction and log deletion.

Within the application, Mandiant reports that an account's local and team Jump Item permissions changed from No Access to Administrator. Jump Items represent remotely accessible systems. The attacker used native support sessions and file transfer to obtain internal documents. These observations connect appliance control to access beyond the appliance; they do not establish that every reachable system was compromised.

Our analytical distinction is between three recovery objects: the appliance's executable state, its authorisation state, and the downstream estate. An update addresses the vulnerable software. A permissions review asks whether access still matches policy. Endpoint investigation asks what happened through that access. Require evidence for each object before declaring the incident closed. A successful update, a clean malware scan or a password reset should not substitute for the other two reviews.

Dwell time needs more than one clock

The interval between BeyondTrust's reported 29 August exploitation and 28 September detection is 30 calendar days. That calculation describes an exploitation-to-detection interval, not proof of uninterrupted activity or a measured dwell time on both customers. The reported 27 minutes starts at detection. Using it as the duration of the compromise would discard the earlier exposure entirely.

BeyondTrust also says automated triage dismissed privilege-escalation alerts as false positives. Audit alert disposition alongside sensor coverage. Its hypothesis about attacker use of artificial intelligence lacks forensic proof; technical sophistication does not establish that hypothesis. BeyondTrust's account supports both qualifications.

For comparison, FireEye's SUNBURST analysis describes a randomly selected 12–14-day threshold based on the malicious assembly's last-write time before execution proceeds. That is a malware activation condition, not a universal SolarWinds victim dwell time. Detection delay, inactive malware, active operator sessions and the survival of stolen credentials should occupy separate fields in an incident timeline.

What the SolarWinds comparison establishes

FireEye's original investigation identified trojanised SolarWinds Orion updates carrying SUNBURST in a digitally signed component. It described subsequent lateral movement, data theft and a preference for legitimate credentials and remote access. The initial trust failure was in software supplied to customers. The BeyondTrust cases discussed here instead concern a compromised service credential or exploitation of an appliance.

Comparison point Defensible operational lesson Limit of the comparison
Trusted management reach Include management systems and their downstream access in threat models. Similar reach does not identify the same attacker.
Legitimate activity used after compromise Examine permission changes, sessions and data movement alongside malware. A native support session is not automatically malicious.
Evidence and timing Preserve independent telemetry and distinguish each incident's clocks. Neither a delayed activation timer nor a detection interval measures every victim's dwell.
Software and service assurance Review update provenance and privileged service relationships separately. Appliance exploitation does not demonstrate a poisoned vendor build.

The comparison is useful for exercising recovery assumptions. In an exercise, give responders a correctly signed management application, an apparently valid administrator session and incomplete local logs, then ask what independent evidence would establish legitimacy. The test should assess the control team's ability to challenge inherited trust without making support operations impossible.

For suppliers, request evidence about build and update integrity where software delivery is in scope, and about privileged support access where service delivery is in scope. Build attestations cannot answer whether a valid support credential was stolen. Conversely, rotating service credentials does not establish the integrity of a software distribution process. Procurement and incident response should avoid accepting one category of assurance as proof of the other.

Detection should test authorisation and provenance

The following are our defensive recommendations, derived from the observed behaviours rather than claims that every deployment exhibits them. Baseline permitted administrators, remote endpoints, support hours, approved file-transfer purposes and management tools. Join session records to change tickets and endpoint telemetry so an apparently normal support action has an accountable owner.

Prioritise unexpected privilege increases followed by remote sessions, newly installed remote-access tools, unexplained file transfers and interruptions in log forwarding. Review the surrounding sequence before dismissing an isolated event as routine administration. A legitimate administrator can make an unusual change; the investigation must establish authorisation and purpose, rather than relying on the executable's publisher or an account name alone.

Keep security telemetry outside the appliance's administrative boundary. Test that a service interruption or unauthorised forwarding change generates a separate alert. Retain raw events behind automated decisions and periodically sample closed high-severity cases. For each suspected session, construct an evidence bundle covering the initiating account, its permissions at that time, the destination, transferred files and endpoint activity. Record missing evidence as a limit on the conclusion.

Recovery should restore trust in stages

Use a coordinated response plan with the help desk, appliance owner, identity team and affected service providers. Preserve evidence, restrict suspect access and arrange a clean recovery environment with the vendor. Where compromise is established, rebuild from a trusted image and scrutinise restored configuration; avoid reintroducing unexplained accounts or permissions from a convenient backup. Plan replacement support capacity before disabling a shared service wherever circumstances permit.

Revoke affected sessions, API credentials and enrolment tokens. Re-enrol trusted agents and consoles from the recovered service, then rotate potentially exposed downstream secrets at their authoritative systems. Sequence that work so freshly issued credentials do not pass through infrastructure still under investigation. Include credentials used during support sessions in the scope review, not only secrets deliberately stored on the appliance.

Before restoring broad access, validate a small authorised endpoint group and verify that session activity appears in independent logs. Apply segmentation between customer or business environments, time-limited privileged access and explicit approval for sensitive destinations. Test the ability to suspend one supplier's access without disabling unrelated administration. These are recovery acceptance criteria and preventive controls, not evidence that a particular attacker has been removed.

Set a review date for exceptions accepted during recovery. Document which evidence remains unavailable, who accepted the resulting uncertainty and what additional observation would change the decision to reconnect. This makes the residual risk reviewable after the urgency has passed.

Our forward assessment is that an unresolved trust relationship remains a realistic route back into an estate after appliance repair: A realistic possibility (B3). The basis is observed durable permissions and supplementary access tools; public reporting does not prove that such access survived a particular customer's remediation. Close the case against documented access paths and monitoring coverage, with explicit residual uncertainties, rather than a single “patched” status.

Related reading in our archive: the earlier BeyondTrust vulnerability analysis and SolarWinds retrospective. Separate coverage includes our APT28 profile and EDK2 pre-boot exposure article; these links imply no common attribution.

Further reading