DEV Community

kozhevniko
kozhevniko

Posted on

Someone Else's Appliance: Third-Party Remote Support and the Visibility Gap

#zoomeye #thirdpartyrisk #beyondtrust #msp

Someone Else's Appliance: Third-Party Remote Support and the Visibility Gap

BeyondTrust serves over 20,000 customers, including government agencies and, by one widely repeated figure, most of the Fortune 100. A large share of those deployments are not operated by the organisation that depends on them. Managed service providers, integrators and outsourced IT functions run the appliance, hold the credentials and set the patch schedule.
The BeyondTrust zero-day exposes a structural problem in that arrangement. When CVE-2026-102764 was exploited, the party who could observe the compromise and the party who bore the risk were frequently different organisations.

Why outsourced appliances behave differently

Three properties distinguish a partner-operated appliance from one run in-house.
First, the patch decision sits with the operator. BeyondTrust fixed the flaw for SaaS customers on 8 October 2026 and disclosed it on 15 October, and self-hosted installations require manual action unless automatic updates are enabled. In an outsourced arrangement, "we patched" means whatever the contract says it means, on whatever schedule the provider runs.
Second, the credential store belongs to the client. Mandiant's account describes the actor reaching every credential the appliance stored or brokered, including access paths to downstream systems. In a managed arrangement those downstream systems belong to several different customers, which makes the blast radius contractual as well as technical.
Third, the audit trail may be out of reach. The actor deleted system, web server and application logs. A client asking what happened may find that the evidence lived on a device it never administered.

Getting a list when you do not own the list

Clients cannot resolve this with a vendor query alone, and providers cannot answer it from a single dashboard. External measurement helps both sides frame the question. ZoomEye queries on 2026-10-23 returned the following for BeyondTrust-branded interfaces.
| Query executed 2026-10-23 (UTC) | Matching assets |
| --- | ---: |
| title="BeyondTrust" | 966 |
| title="BeyondTrust" && is_domain=true | 584 |
| app="BeyondTrust Privileged Remote Access" | 226 |
| title="BeyondTrust" && port="443" | 269 |
| title="BeyondTrust" && port="80" | 203 |
Public telemetry from Shadowserver adds a second reference, counting more than 1,400 exposed BeyondTrust instances across product lines. Neither dataset distinguishes a provider-operated appliance from a customer-operated one, which is the point: from the outside, they look the same.

Questions that belong in the contract

An incident is the wrong time to discover that the agreement did not assign responsibility for reachability, patch latency or telemetry retention. Five clauses cover most of the ground this incident exposed.

  1. Notification. Who tells whom, within what interval, after a vendor advisory affecting a shared appliance.
  2. Patch obligation. Whether the provider commits to a maximum interval after a vendor fix, and how that is evidenced.
  3. Telemetry. Whether the provider retains firewall, proxy and support-session logs for a defined period, and whether the client can obtain them.
  4. Jump Item governance. Who approves the destinations an appliance may reach, and how often that list is reviewed.
  5. Rebuild authority. Who decides that an appliance must be rebuilt rather than patched, and who pays for the downtime. The fifth is the one most often missing. Google's guidance to redeploy appliances with confirmed or unknown compromise status from a clean, fully patched image is a decision with an owner, and in an outsourced arrangement that owner is not always obvious.

Controls that reduce the shared exposure

Several of the published recommendations work regardless of who runs the appliance:

  • Block inbound traffic to the appliance's public address at the firewall rather than inside the appliance, so reachability is not a configuration someone forgets to change.
  • Restrict /login and /appliance interfaces by IP or network segment at the appliance level.
  • Deny outbound traffic except to vendor update and licensing endpoints, and log every denied connection.
  • Rotate credentials in dependency order, and redeploy Jump Clients, Jumpoints and the representative console after rebuilding.
  • Apply MFA to the built-in administrator account. Each of these shrinks the population an actor can select from. None of them resolves the accountability question, which is why the contract matters as much as the configuration.

What is not known

No victim of this campaign has been named publicly, and no count of compromised appliances exists. Whether credential harvesting succeeded in specific cases is unconfirmed. Attribution is described as suspected rather than formally assigned.
For a client of a managed service, the practical takeaway is narrower than a policy rewrite: ask, in writing, which appliances carry your name, what version they run and when they were last reachable from the public internet. The answers are usually recoverable. The assumption that someone else already asked is the part that fails.

References

Top comments (0)