How to limit the damage when a remote support tool is compromised? Learning from the BeyondTrust Vulnerability

No remote access tool is immune to zero-day vulnerabilities, as the recent BeyondTrust vulnerability exploit (BT26-05) shows. What matters more is how much damage an attacker can do once a tool is compromised.

This post breaks down what happened in the BeyondTrust security incident, why attacks on remote access tools are increasing, and four design choices that help limit the blast radius if a remote support solution is compromised. We also break down how LogMeIn Rescue and LogMeIn Resolve approach each one.

• What happened: A suspected China-linked espionage group (ARMORY CASTLE) exploited an unknown flaw (a zero-day vulnerability) in BeyondTrust Remote Support to compromise customer deployments from late August 2026. BeyondTrust disclosed it on October 15.
• Why it matters: Self-hosted customers must patch on their own, and AI now shortens the time between a public patch and a working exploit.
• What limits the damage: Cloud-only delivery, a second authentication step for unattended access, credentials stored outside the remote access tool, and device-level approval for one-to-many actions.

On October 15, BeyondTrust disclosed a critical vulnerability (CVE-2026-102764) in its Remote Support product, a tool used by IT teams to access employee and customer computers. Google’s Mandiant team found that a suspected China-linked espionage group, tracked as ARMORY CASTLE, had been exploiting the flaw since late August, weeks before anyone knew it existed.

The group exploited the zero-day vulnerability to upload files to the appliance without needing a password and installed a hidden backdoor. It then used the product’s own admin and file transfer tools to reach other systems and pull files from users’ desktops.

BeyondTrust patched cloud customers on October 9th, but self-hosted customers must apply the fix themselves. While the scope is still unclear, BeyondTrust says in their blog that they “are only aware of the two impacted customers,” Mandiant warns organizations to prepare for potential widespread exploitation now that the flaw is public. It is estimated that 1,400 self-hosted Remote Support appliances were internet-reachable at the time of disclosure.

In a world where AI is at everyone’s fingertips, the threat landscape is changing dramatically, and no one is immune. Though BeyondTrust has long been highly regarded for its security reputation, this is the third zero-day vulnerability with the highest CVSS rating of “Critical” that they’ve disclosed in 2026 alone. And they certainly aren’t the only ones. Just this month, Microsoft patched more vulnerabilities than it did in all of 2025, largely because of AI. GTIG also recently published a report documenting the first known zero-day exploit script built with generative AI. While BeyondTrust does not have forensic proof that ARMORY CASTLE used AI to develop exploit chains in this specific attack, it recommends that "defenders plan as though this assessment is accurate."

With this rise in zero-day vulnerability exploits, it’s not surprising when tools fall victim to one of these attacks — even those with the security reputation of BeyondTrust. This is especially the case for remote access tools, as they are prime targets for attackers. As such, the question becomes less “which tool has the least likelihood of being exploited” and more “which tool has the potential to cause the least amount of damage in the event that it is exploited.”

In this blog, we’ll walk through 4 key areas of risk that stood out in this specific incident, and how using a tool like LogMeIn Rescue can minimize those risks. The four areas below are where we see design choices shrink risks the most.

In some cases, yes, and the risks are growing with self-hosting software, as AI enables hackers to become faster. While there are certainly potential security advantages to self-hosting, such as complete data ownership and the ability to implement access controls and isolation that is customized to your organization, the downside of this method is that it makes your team solely responsible for staying aware of and patching your systems. If you don't have the resources to employ full-time staff to monitor networks, patch vulnerabilities, and block attacks around the clock, the security risks of self-hosting will likely outweigh any potential benefits.

While cloud customers are not immune to zero-day exploits, they face the most advantages in the period after, from what is known as “N-day” exploits. These attacks target unpatched customers using known software vulnerabilities in the “N” days after the vulnerabilities have been made public. Because the vendor manages the infrastructure of cloud customers, patches can be deployed to them as soon as they're ready, so cloud customers are usually patched first, before the vulnerability is disclosed to the public. Self-hosted customers on the other hand will sometimes be privately notified before the vulnerability is disclosed to the public, but they often find out when everyone else does. And in many instances, such as this one, the patches are only released for the actively supported versions, meaning customers running older versions must first upgrade to have access to the patch. This combination of factors inevitably leads to some delays, which is why in many cases, such as the ScreenConnect incident in 2024, and even the other BeyondTrust incident earlier this year, most known exploitations come not from zero-day exploits, but from these “N-day” exploits.

Why “N-Day” exploits are now “N-Hour” exploits

With AI, the impact of harm with N-day vulnerabilities is changing dramatically. In fact, according to Anthropic, “N-hour is closer to the reality we now operate in.” Historically, once a patch was released to self-hosted customers, expert hackers would use a technique called “patch diffing” to compare changes in the software before and after a patch to figure out how the vulnerability worked and use that to exploit unpatched customers. But while this used to be slow, specialized work, in June 2026, Anthropic reported that its Mythos Preview model turned a Firefox patch into a working exploit in just under an hour. According to Anthropic, “a lone operator can now turn a month’s worth of patches into working exploits in a single afternoon.”

As the threat landscape evolves with AI, the conversation around the security benefits of self-hosting is changing. In fact, although BeyondTrust was initially a fully self-hosted solution, and didn’t even have a cloud-based offering until 2015, they are now actively encouraging customers to move toward their SaaS/Cloud platforms, and will stop supporting physical appliances at the end of this year.

How LogMeIn Rescue reduces this risk

We built LogMeIn Rescue 20 years ago as a cloud-based solution and have been securing cloud-based customers since day one. Because LogMeIn Rescue has always been SaaS-only, our server-side code and infrastructure stay within our environment. This means there is no appliance or installable server software for an attacker to obtain, take apart, or test exploits against offline, which makes server-side reverse engineering and offline vulnerability research harder. It also means that our patches are applied on our own servers, so all our customers are patched instantly, and no public patch is made accessible to the public or AI.

Organizations deciding to continue to self-host must seriously consider these risks and determine if they have the resources in place to respond promptly and appropriately to the new threat landscape.

Unattended access should always require a second credential beyond the remote support account login, ideally one that is not stored by the remote support vendor. Without one, anyone who steals a technician’s account credentials or compromises a remote support tool can connect to every enrolled device. This highlights an important security gap in BeyondTrust’s unattended workflow, which caused the most amount of damage in this attack.

In BeyondTrust, once a Jump Client (BeyondTrust's term for their unattended access client) is set up, no additional authentication is required to start a remote session. This means that if you have someone’s BeyondTrust credentials, you can connect to an unattended device without needing the local or admin credentials of the device itself or the OS.

LogMeIn Rescue treats unattended access differently. We have 2 ways of approaching unattended access authentication, both of which provide more protection for these kinds of attacks:

1. Require technician to enter the OS admin credentials before starting a session.

   This means that even if an attacker were to gain access to all the credentials in a Rescue account, they cannot connect to any persistent unattended connections unless they also have access to the OS admin credentials. In other words, while the account itself might be compromised, there is not much they can actually do with that access.

2. Require an end user to enter their credentials when establishing an unattended session.

   This method is designed for instances where a reboot and reconnect are needed, not for maintaining persistent access. In this method, an end user enters credentials during an attended session, and the technician can later use those credentials to connect or to reconnect after a reboot. To minimize security risk, we only allow this method for a maximum of 2 weeks, though we recommend users set it to the shortest possible duration. For example, if you only need it for 2 days, set the expiration date to 2 days from now. Once that unattended installer is deployed, it can't be extended later, which helps minimize exposure.

Of course, remember that the safest lock is to have no door. We recommend you don't establish unattended access unless absolutely necessary and instead rely on methods like Calling Card as a System Service for one-click, elevated access to a device. For instances where unattended access is necessary, we recommend setting up time windows and expiration dates whenever possible, which can't be changed after the unattended agent is deployed. We also recommend you require end-user permission to start an unattended session, if it makes sense for your use case.

The short answer is no. When a remote access tool also holds your privileged credentials, one vulnerability can expose both the entry point and the means to use it, giving them an easy path to breach your systems. Keeping credentials in a separate PAM tool limits the damage.

While admin credentials are not required to initiate a remote session in BeyondTrust, they may be required for other things, such as elevating a session, logging in to RDP, VNC, or SSH Assets, or even logging in to the Windows login screen. For these instances, BeyondTrust offers a built-in credential management feature integrated directly into its Remote Support solution, called Vault (not to be confused with their flagship solution Password Safe). This vault stores these credentials and then injects them when needed. While the security benefit of this feature is that it guards against technician misuse by preventing technicians from getting plain text access to passwords, having a password vault built into your remote access tool essentially functions similarly to storing your keys by the door, and can actually serve as a security liability in attacks such as this one.

When describing this specific attack, BeyondTrust writes in their blog “A remote access appliance stores and brokers privileged credentials across an estate, which makes it a credential source and a map of who connects to what. The actor reads the appliance's stored secrets and uses administrative access in the application to reach downstream systems.” According to Mandiant’s report, hackers attempted to expose credentials from this vault, then deleted the log files, making it difficult to determine whether, and to which extent, the attempts were successful. While the Mandiant report says the root level control “gave them access to every credential the appliance stored or brokered”, they don’t confirm whether attackers were successful in harvesting credentials from the vault itself. While BeyondTrust’s description of the attacker “read[ing] the appliance's stored secrets and us[ing] administrative access” does not sound encouraging, they have not shared the specific details at the time of writing.

Regardless of whether they were able to expose credentials or just use them as a regular admin would, this attack highlights the unique risks that come from having both your credential vault (the keys) and your remote access tool (the door) in the same place. If someone were to get access to the door, and have no keys, their potential for attack is limited. Conversely, if they got access to your keys, but not your door, you’re in a slightly better spot than if they were to have both (although, you’re still certainly not in the clear).

This is why Rescue doesn’t have any password vault capabilities in the product. Instead, we recommend relying on a separate tool for password management, such as a Privileged Access Management tool like CyberArk. This tool can be used to store sensitive credentials, automatically rotate passwords, and grant temporary, on-demand administrative rights only when needed. For the specific question of credential injection, we are currently developing an integration with CyberArk that will allow you to leverage the benefits of credential injection, without the risks associated with having both the door and the key in the same place.

For tools that act on many devices at once, require approval at the device level. Even if attackers take over the console, they should not be able to push scripts or start sessions on endpoints.

The common thread throughout these recommendations is to assume that adversaries are already inside your systems, and prepare additional checks and lines of defense, a concept known as Zero Trust. Since Rescue is mostly used for customer-initiated support, you can implement these principles using the security guidelines outlined throughout this blog. However, for tools that offer one-to-many functionality, or that allow users to access devices outside of a remote support session, a different approach is needed.

For example, while hackers in this specific incident used the file manager in a remote support session to compromise BeyondTrust’s customer, they theoretically could have used BeyondTrust’s Endpoint Automation feature to run a Remote Code Execution attack, where they push malicious code to multiple Jump Clients without needing to start a remote support session. This presents even greater risks because of the ability to instantly access many devices.

As Rescue does not offer any form of one-to-many functionality, the risks from these kinds of attacks are mitigated. However, our RMM tool LogMeIn Resolve is built precisely for persistent access and one-to-many automation. As such, we built it from the ground up, as the first RMM with Zero Trust Architecture, to address the unique risks that come with this functionality. Resolve requires an agent to enter a signature key before running sensitive tasks such as remote execution. Unlike the device-level passwords you may see as an option on other remote access tools, this signature key is not stored by us. Instead, the authentication happens on the level of each individual device. What this means in practice is that, even if an attacker were to somehow gain access to all credentials stored on a Resolve account, they would not be able to push out a script or start an unattended session since they still don’t have the signature key. And they can't create a new admin account and signature key, because any new admin’s signature key needs to be approved by another admin using -- you guessed it -- their signature key. This workflow might just seem like an extra step, but incidents such as these, it serves as the final and strongest line of defense between an attacker and all your endpoints.

Incidents like these always serve as a harrowing reminder to take security seriously. If you haven’t already, consider implementing some of the following security measures:

• Strengthen authentication measures: Use SSO with Multi-factor Authentication (MFA) for authentication if possible, so you can leverage the hardening measures of your organization. If you don’t have SSO, you can still use Rescue’s hardening measures, such as MFA, password policies and IP restrictions. While it’s unclear to what extent these measures would have prevented exploit in this instance, there are many other attacks they can protect you from.
• Follow Least Privilege Principles: Only establish unattended access when absolutely necessary, and when possible, use access windows, expiration dates, and forego customer authentication. Additionally, limit technician settings like unattended access, Connect on LAN, file manager, and script deployment to only the technician groups that absolutely need them.
• Keep Desktop Technician Consoles Updated: Not only does staying up-to-date ensure you’re getting access to new capabilities, new technician console versions may contain security updates and improvements. If you don’t want to worry about updates at all, consider switching to our web technician console.
• Store your Keys Somewhere Safe: Use a PAM solution to store credentials, and rotate passwords, using temporary admin passwords when possible.
• Apply Zero Trust for One-to-Many Actions: Finally, if you’re looking for persistent access to endpoints, and to run one-to-many actions, consider using a tool with Zero Trust architecture, such as LogMeIn Resolve.

No tool can guarantee it won't have any vulnerabilities, but how much damage a vulnerability in a third-party tool can cause to your environment comes down largely to design and configuration. Gating unattended access, keeping credentials in a separate system, and requiring approval for sensitive actions all help ensure that one compromised login doesn't become a compromise of everything.

Built as a cloud-only from day one, with a second lock on unattended access and no built-in credential vault. Request a LogMeIn Rescue demo to review the security controls with our team, or learn how LogMeIn Resolve adds zero trust to persistent access and automation for internal IT teams and MSPs.

What is the BeyondTrust BT26-05 vulnerability?

BT26-05 is BeyondTrust’s advisory for a critical zero-day vulnerability in its Remote Support appliance. It let an unauthenticated attacker upload files without a password. Attackers used it to install a backdoor, take control of a customer appliance, and steal files from their endpoints. BeyondTrust disclosed it on October 15, 2026.

Who is ARMORY CASTLE?

ARMORY CASTLE is the name Google’s Mandiant team uses to track a suspected China-linked espionage group. Mandiant found that the group had exploited the BeyondTrust vulnerability since late August 2026, weeks before public disclosure.

Is cloud-based remote support safer than self-hosted?

Cloud-based remote support is not immune to zero-day attacks, but it removes the customer patching burden. The vendor patches its own servers, often before self-hosted customers are notified, and no downloadable patch exists for attackers to analyze. Self-hosting gives more control, but your team must patch quickly.

How can IT teams limit the damage if a remote support tool is compromised?

Add a second authentication step for unattended access, keep credentials in a separate privileged access management tool, use least privilege and expiration dates, and require device-level approval for one-to-many actions. These steps ensure that stolen account credentials alone do not give attackers control of your devices.

Should a remote support tool include a built-in password vault?

A built-in vault is convenient, but it places credentials and the access tool in the same system. If the tool is compromised, attackers may reach both. A separate privileged access management tool keeps them apart and can rotate passwords and grant temporary rights.

What is zero trust architecture in remote IT management?

Zero trust means no user, device, or system is trusted by default. In remote IT management, it means sensitive actions such as running scripts or accessing endpoints must be verified at each device. LogMeIn Resolve does this with signature keys that are not stored by the vendor.