BeyondTrust PRA and Remote Support: how to check the risk from CVE-2024-12356

CVE-2024-12356 lets a remote, unauthenticated attacker inject commands into BeyondTrust Privileged Remote Access and Remote Support. The vulnerability is listed in the CISA Known Exploited Vulnerabilities catalog, so an organization that runs these systems needs to identify the affected instances, check their network reachability and confirm that the fix has been applied.

On 19 December 2024, CISA added CVE-2024-12356 to KEV. The requiredAction field calls for applying the mitigations the vendor specifies, or discontinuing use of the product if mitigations are not available; the date in the dueDate field is 27 December 2024. Inclusion in the catalog means CISA has information about known exploitation of the vulnerability. (CISA KEV, CVE-2024-12356 entry)

BeyondTrust states that CVE-2024-12356 affects Privileged Remote Access and Remote Support versions 24.3.1 and earlier. The vendor fixed cloud instances itself. Owners of on-premise systems need to install the BT24-10 fix. A patch is available for versions 22.1 and later; earlier versions have to be upgraded to a supported version first. (BeyondTrust BT24-10, sections Affected Products, Affected Versions and Remediation)

None of this supports the conclusion that every BeyondTrust portal is published on the internet. The network vector describes how a reachable system can be attacked, while the reachability of a particular instance depends on where it is hosted and how its network is configured. A practical check therefore has to join three facts: where the portal sits, whether it can be reached from an external network, and which fix has been applied.

What CVE-2024-12356 actually allows

The vendor defines the vulnerability as command injection without authentication. A remote attacker can inject commands that are executed with the privileges of the site user. The CVE record indicates a network attack vector, no required privileges and no user interaction. An existing account in PRA or Remote Support is not needed. (BeyondTrust BT24-10, Summary section; CVE-2024-12356, Metrics section)

The case that matters most to an organization is an on-premise instance on an affected version that is reachable from outside. No single data source can confirm that combination. An external check shows whether the service answers on a public address at the moment of observation. The version and the state of BT24-10 are established from the management data of the instance itself.

That distinction shapes the outcome of the check. A portal answering on a public address does not yet mean that what you are looking at is an affected version without the patch. At the same time, no answer from one external vantage point does not remove the need to check the version of a recorded local instance: the system may be reachable at a different address, only from certain networks, or only from the internal segment.

What the primary sources say

The BeyondTrust BT24-10 advisory defines the affected products and versions and separates the course of action for cloud and local installations. It is the source of the 24.3.1-and-earlier boundary, of the availability of a patch for the 22.1 and later branches, and of the requirement to upgrade older releases first. (BeyondTrust BT24-10)

The CVE record formalizes the properties of the defect: a network attack, no required privileges, no user interaction, and the ability to execute injected commands. It describes the vulnerability, but it does not replace the vendor's update procedure. (CVE-2024-12356)

The CISA KEV entry reports known exploitation and sets the required action and its due date. It contains no information about the topology of a particular organization, the versions it has installed, or the reachability of its portals. (CISA KEV, CVE-2024-12356 entry)

The primary sources therefore define the technical scope of the vulnerability and the measures foreseen for it. The list of specific instances and their external reachability is established from the organization's own data.

Cloud and on-premise call for different confirmations

For cloud instances the advisory states that BeyondTrust applied the fix. For local systems the action sits with the owner: install the BT24-10 patch if the version in use is 22.1 or later, or first upgrade an earlier version to a supported release and then apply the fix. (BeyondTrust BT24-10, Remediation section)

An entry that reads "BeyondTrust Remote Support is present" is therefore not enough to choose an action. The register needs at least the following for each instance:

• product — Privileged Remote Access or Remote Support;
• hosting model — BeyondTrust Cloud or on-premise;
• domain name or public address, if the service is published;
• version of the local instance;
• state of the BT24-10 fix;
• system owner.

If the hosting model is unknown, the vendor's statement about fixed cloud instances cannot be carried over to a portal you have found. First determine whether it belongs to BeyondTrust Cloud or to a self-hosted deployment run by the organization.

The version determines not only whether an instance falls inside the scope of the advisory, but also the order of the work. For an on-premise 24.3.1 system on a supported branch, the BT24-10 patch applies. For an instance below 22.1, a ticket for that patch alone is not enough: the advisory requires moving to a supported version first.

Working branches by hosting model and version

• BeyondTrust Cloud — confirm that the portal belongs to BeyondTrust cloud hosting.
• On-premise 22.1–24.3.1 — confirm that BT24-10 is installed.
• On-premise below 22.1 — confirm the upgrade to a supported version and the BT24-10 install that follows it.
• On-premise newer than 24.3.1 — confirm the exact version and where it sits relative to the affected range.
• Hosting model or version unknown — identify the instance before assigning it any status.

This split means an old local version cannot be closed with a patch ticket alone, and a portal that merely looks like a cloud service from the outside is not automatically treated as fixed.

How to establish external reachability

The check starts from the list of known PRA and Remote Support deployments. For each of them, record the declared domain names and public addresses, the hosting model, the owner, the version and the state of BT24-10.

Reachability is then checked from an external network. A practical result has to tie the observation to a specific vantage point and time:

• which domain name was checked;
• which IP address it resolved to;
• whether a network connection was established;
• whether an application-layer response was received;
• when and from where the check was run.

If a connection was established and the service responded, the address belongs to the observed external perimeter. If there was no response, the correct result is stated as an absence of confirmed reachability from the chosen vantage point at the stated time.

Known names need not be the limit, if the approved scope of the assessment covers the public domains and addresses that belong to the organization. That is how a working portal missing from the original inventory can come to light. The service that is found is then matched to an owner and to an asset record.

Four working outcomes

• In the inventory, externally reachable — a known asset confirmed in the external perimeter.
• In the inventory, not externally reachable — the asset is recorded, but no external path was confirmed at the time of the check.
• Not in the inventory, externally reachable — an external service was found with no matching record.
• Not in the inventory, not externally reachable — neither a record nor an external response in the sample that was checked.

After this classification, the next steps follow from the hosting model, the local version and the state of BT24-10. Those are the facts that separate a merely published portal from an affected on-premise instance with no confirmed fix.

Four situations instead of an abstract checklist

Suppose an external check finds the portal support.example.com. It answers at the published address, and the owner confirms that it is a BeyondTrust Cloud instance. Both facts stay in the working record: the portal is reachable from outside, and it uses the cloud model. For remediation, the BeyondTrust statement about the work the vendor completed applies. There is no need to assign a local BT24-10 install to the owner of such a portal.

A second portal, remote.example.com, also answers from the external network, but it is hosted in the organization's own data center. The system reports version 24.3.1, and there is no confirmation of BT24-10. This is an affected on-premise instance that needs the patch installed. The external observation records the exposure; the system's own data confirms that the advisory applies.

The third case is a local PRA running version 21.x that is reachable only from the internal network. The order of remediation follows from the version: first the move to a supported release, then BT24-10. The absence of confirmed external exposure changes how network reachability is characterized, but it does not take the system out of the scope of the BeyondTrust advisory.

In the fourth case, a portal is found on a public address of the organization but is absent from the CMDB. Until the asset is identified, no hosting model, version or BT24-10 status can be assigned to it. The first action is to establish the owner and the link between the address and a real deployment. If identification shows a local instance on version 24.3.1 or earlier, the matching BT24-10 branch is chosen for it.

The records these situations produce

• Reachable BeyondTrust Cloud portal — external reachability confirmed; cloud model established; the fix was applied by the vendor.
• Reachable on-premise 24.3.1 without BT24-10 — an affected published instance; the patch is required.
• Internal on-premise below 22.1 — an affected instance; an upgrade and then the patch are required.
• External portal with no owner and no hosting model — identification is required; the fix status is undetermined.
• Recorded portal with no answer from outside — external reachability not confirmed; version and fix are checked against the asset data.

These examples show why the same external interface does not lead to the same decision. For a cloud portal the key confirmation is the hosting model; for a local node it is the version and BT24-10; for an unknown address it is first of all the link to a specific asset.

Which instances to work through first

The highest priority goes to an on-premise instance where three circumstances are confirmed at once:

1. the installed version is 24.3.1 or earlier;
2. the service is reachable from an external network;
3. the application of BT24-10 is not confirmed.

Information about known exploitation is already in the KEV entry. Once this combination is found, choose the remediation branch that BeyondTrust prescribes and record that it was carried out.

Next come local instances on affected versions whose external reachability is not confirmed. They are also within the scope of BT24-10 and need to be fixed. What separates them from published systems is an established external path, not the applicability of the advisory.

A queue of its own holds portals found from outside whose owner or hosting model is unknown. They cannot be correctly assigned either to fixed BeyondTrust Cloud or to a local system until identification is complete. Without it, both the fix status and the order of required actions remain unknown.

Restricting exposure and installing the patch produce different results. The first changes the network reachability of the service; the second carries out the measure foreseen for the affected software. If both the exposure and the fix state change for a local portal, both results are recorded in the asset entry.

How to read the CISA due date

The KEV entry sets the date added as 19 December 2024 and the due date for the required action as 27 December 2024. The required action is to apply the vendor's mitigations, or to discontinue use of the product if mitigations are not available. (CISA KEV, fields dateAdded, requiredAction and dueDate)

It does not follow from these fields that the date is automatically binding on every organization. Whether the deadline applies is determined by the regime in force for that organization, by contractual requirements or by an internal standard; those documents are not part of the sources discussed here.

The working result therefore states separately the decision on the KEV required action and the deadline adopted for the specific system owner. This does not change the technical scope of BT24-10, but it does set the order of execution and escalation inside the organization.

If the KEV deadline is binding for the organization, the record has to make it possible to see not only that a general CVE task exists, but also the state of each instance as of the set date. One closed cloud portal should not hide a local node without the patch, and a fixed on-premise instance should not hide an unidentified service on a public address.

What should confirm that the work is closed

For a cloud portal, the closing confirmation is established membership in BeyondTrust Cloud, taken together with the vendor's statement that the fix has been applied.

For an on-premise instance on version 22.1 or later, confirmation that BT24-10 was installed is required. For a version below 22.1, evidence of the move to a supported version and of the patch that followed is needed. If the service was reachable from outside and its exposure was changed, the result of the external check after that change is recorded separately.

The final record for an instance should contain:

• product and owner;
• hosting model;
• installed version;
• state of BT24-10;
• domain name or public address;
• result of the external check, with its date;
• decision on the KEV required action;
• the deadline that applies to the organization.

For a portal that has been found but not yet identified, an assumption about its cloud or local nature cannot count as closing the discovery stage. A link to an owner and to a deployment is needed. After that, the portal goes through the same fork: BeyondTrust Cloud, or on-premise with a version and BT24-10 check.

For a local instance, a general "update completed" mark is not enough if it does not show whether the required sequence of actions was followed. For a version below 22.1, the record has to show both the move to a supported branch and the patch that followed it.

The outcome of the check: a specific decision for each instance

The check ends by assigning each PRA or Remote Support instance one of a defined set of states:

• BeyondTrust Cloud, hosting model confirmed — the advisory branch about fixed cloud instances applies;
• on-premise, affected version, BT24-10 confirmed — the vendor's measure has been carried out;
• on-premise, affected version, BT24-10 not confirmed — remediation under BT24-10 is required;
• on-premise below 22.1 — an upgrade to a supported version and then the patch are required;
• external portal not identified — the owner and the hosting model have to be established;
• version or fix state unknown — the check is not complete;
• external reachability not confirmed — the result applies to the vantage point and time that were checked, and the state of the local version is considered separately.

In the final list, the instances counted as internet-reachable are the portals for which an external response was recorded together with a name or address, a time and a vantage point. But the action on the CVE is not assigned on the strength of that response alone: for every portal found, the hosting model, the version and the state of BT24-10 are established.

If an on-premise instance on version 24.3.1 or earlier answers from outside and there is no confirmation of BT24-10, the resulting action is unambiguous: assign an owner, apply the fix that BeyondTrust prescribes and keep the evidence that it was carried out. If BeyondTrust Cloud answers, the record confirms the cloud model. If an unknown portal answers, the first action is to identify it.

A list like this — with the names of specific portals and a separate decision for each one — is what completes the check. It shows which PRA and Remote Support instances are actually observed from the external network, which of them run affected local versions, and where the fix is not yet confirmed.