Prepared by: Brecht Snijders, Principal Offensive Consultant
Introduction
During a recent Red Team exercise, the Triskele Labs team discovered a trivial privilege escalation flaw in the Forcepoint One Endpoint DLP software version <25.05 that allows any user with write access to the C:\ root (every authenticated user by default) to trivially escalate their privileges to NT AUTHORITY\SYSTEM.
Discovery
During the engagement, we found ourselves with code execution in the context of a regular user account on a Windows host. Our aim for this particular host was to elevate our privileges, so we set out to perform the usual checks such as surveying the software installed. We retrieved the available installers, deployed them on a dedicated test Virtual Machine and started looking for easy wins to get us closer to our objectives.
Part of performing red teams is keeping things simple - if a straightforward privilege escalation gets you to your intended goal, there is no need to overcomplicate. With this in mind, we deployed ProcMon, enabled Boot Logging and rebooted our test workstation:
After the reboot, we applied the excellent PrivEsc ProcMon Filter [link: https://github.com/CERTCC/privesc] provided by CERTCC and dug through the results. After applying some extra filtering, the following stood out like a sore thumb:
The above indicates that the EndPointClassifier.exe process is attempting to load a config file (openssl.cnf) from a linux-style directory on Windows. It also tells us the path wasn’t found and that it’s trying to load the file with SYSTEM-level privileges. Given that every authenticated user (by default) can create new folders in the C:\ root, it’s trivial for us to exploit this search path vulnerability.
This result ticks all the Easy Privilege Escalation boxes:
From here, it’s as simple as creating the folders and placing the openssl.cnf file with contents similar to this:
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
cmd = cmd_section
[cmd_section]
engine_id = cmd
dynamic_path = c:\\usr\\local\\ssl\\exploit.dll
init = 0
Create the DLL containing your code in the “dynamic_path” section (c:\usr\local\ssl\exploit.dll in this case) and Bob is your elevated uncle. The service needs to be restarted before it will load our custom config file and DLL, which is something regular users do not have the permissions for. Luckily, a reboot does the trick as well. During the assessment itself, we simply waited for the scheduled reboot and ultimately received our elevated beacon.
This privilege escalation vector is not new and several other popular software vendors have had similar vulnerabilities in the past:
This is also not the first time we've found a fairly trivial but extremely useful privilege escalation vector in enterprise security software and should serve as a reminder for both attackers and defenders to never make any assumptions about software based on their reputation or function.
Mitigation
Forcepoint have released a new version (25.05) and an associated advisory on 22 May 2025. These details can be found at https://support.forcepoint.com/s/article/Security-Advisory-Privilege-Escalation-and-Arbitrary-code-execution-in-F1E-Endpoint.
