Anti-Tamper Bypass in BeyondTrust Privilege Management for Windows

A medium-severity vulnerability has been identified in BeyondTrust Privilege Management for Windows versions <=25.7. Under certain conditions, a local authenticated user with elevated privileges may be able to bypass the product’s anti-tamper protections, which could allow access to protected application components and the ability to modify product configuration.

Privilege Management for Windows - Elevation of Privilege

Prior to version 25.4.270.0, a local authenticated attacker can manipulate user profile files to add illegitimate challenge response codes into the local user registry under certain conditions. This allows users with the ability to edit their user profile files to elevate their privileges to administrator.

Privilege Management for Windows - Elevation of Privilege

Prior to 25.4.270.0, when wmic.exe is elevated with a full admin token the user can stop the Defendpoint service, bypassing anti-tamper protections. Once the service is disabled, the malicious user can add themselves to Administrators group and run any process with elevated permissions.

Privilege Management for Windows – Elevation of Privilege

Prior to 25.2, a local authenticated attacker can elevate privileges on a system with Privilege Management for Windows installed, via the manipulation of COM objects under certain circumstances where an EPM policy allows for automatic privilege elevation of a user process.

An issue was discovered in BeyondTrust Privilege Management for Windows before 24.1. When an low-privileged user initiates a repair, there is an attack vector through which the user is able to execute any program with elevated privileges.

Privilege Management for Windows < 24.1 Information Leak

Prior to version 24.1, a local authenticated attacker can view Sysvol when Privilege Management for Windows is configured to use a GPO policy. This allows them to view the policy and potentially find configuration issues.

The Challenge Response feature of BeyondTrust Privilege Management for Windows (PMfW) before 2023-07-14 allows local administrators to bypass this feature by decrypting the shared key, or by locating the decrypted shared key in process memory. The threat is mitigated by the Agent Protection feature.

BeyondTrust Privilege Management prior to version 21.6 creates a Temporary File in a Directory with Insecure Permissions.

BeyondTrust Privilege Management for Windows and Mac (aka PMWM; formerly Avecto Defendpoint) 5.1 through 5.5 before 5.5 SR1 mishandles command-line arguments with PowerShell .ps1 file extensions present, leading to a DefendpointService.exe crash.

In BeyondTrust Privilege Management for Windows (aka PMfW) through 5.7, a SYSTEM installation causes Cryptbase.dll to be loaded from the user-writable location %WINDIR%\Temp.

An issue was discovered in BeyondTrust Privilege Management for Windows through 5.6. When adding the Add Admin token to a process, and specifying that it runs at medium integrity with the user owning the process, this security token can be stolen and applied to arbitrary processes.

An issue was discovered in BeyondTrust Privilege Management for Windows through 5.6. If the publisher criteria is selected, it defines the name of a publisher that must be present in the certificate (and also requires that the certificate is valid). If an Add Admin token is protected by this criteria, it can be leveraged by a malicious actor to achieve Elevation of Privileges from standard user to administrator.

An issue was discovered in BeyondTrust Privilege Management for Windows through 5.6. An attacker can spawn a process with multiple users as part of the security token (prior to Avecto elevation). When Avecto elevates the process, it removes the user who is launching the process, but not the second user. Therefore this second user still retains access and can give permission to the process back to the first user.

An issue was discovered in BeyondTrust Privilege Management for Windows through 5.6. When specifying a program to elevate, it can typically be found within the Program Files (x86) folder and therefore uses the %ProgramFiles(x86)% environment variable. However, when this same policy gets pushed to a 32bit machine, this environment variable does not exist. Therefore, since the standard user can create a user level environment variable, they can repoint this variable to any folder the user has full control of. Then, the folder structure can be created in such a way that a rule matches and arbitrary code runs elevated.