Post cover image

November 3, 2026

How Scanning for Patches can result in complete System Compromise

Details about ManageEngine Endpoint Central CVE-2026–77697

By Sandro Poppi

6 min read

In a private engagement I was working on a penetration test for ManageEngine's Endpoint Central tool on Windows. It provides companies insights into their digital inventory including missing patches, vulnerabilities etc. through a central console.

It includes a feature called Patch Scan which checks for missing patches in the computer's installation base and provides feedback to the central console. While this feature helps in getting an overview to enable IT administration find outdated software, it introduced a way for local vertical privilege escalation to NT AUTHORITY/SYSTEM on Windows.

The Patch Scan Issue

A patch scan can be triggered manually by a local user, or is run on a regular basis automatically. It is scanning the whole file system for outdated software or libraries, where the latter also includes Java archive (.jar) files.

JAR files are zip containers for compiled Java classes. They additionally have a manifest file which stores metadata about the archive, its contents, and how the Java Virtual Machine should run or handle the code in the META-INF sub folder, among others. For details about the file format check this out.

Tests showed that only specific JAR files are taken into account, namely log4j-a.b.c.jar where a.b.c is a three-digit version number to scan for the infamous Log4Shell vulnerability.

When patch scan finds such a JAR file, it calls 7za.exe (command line version of the 7zip tool) and extracts the JAR file including META-INF/MANIFEST.MF to a newly created sub folder named ExtractVmpDriveScan in the same folder the JAR file resides. This is done by the patch scan process running in NT AUTHORITY/SYSTEM context.

If the folder ExtractVmpDriveScan already exists, it is used without recreation or file permission changes as-is.

This behavior can be abused for vertical local privilege escalation.

The Exploit Theory

As a prerequisite, the exploit needs to be executable by a non-admin user. Therefore, the solution requires some tricks e.g. to create symbolic links as low privileged user.

Native NTFS symbolic links cannot be created by non-admin users. But there is a workaround first documented by famous James Forshaw of Google Project Zero who used the so-called Object Manager Namespace for creating a so-called pseudo-symbolic link. For details about object manager symbolic links (symlink) see the corresponding chapter here.

Windows also supports so-called NTFS junctions for the NTFS filesystem, which is the default used in Windows for quite some time. A junction can be seen as a link to a directory, and it can be created by users without administrative permissions.

In short, such pseudo-symlinks require to create a junction to the object namespace named RPC Control and then set a symlink in it to a destination file. No specific permissions are required for that.

Luckily, James Forshaw already provides the required toolset here.

Because of the requirement to have a junction first to create a symlink as non-privileged user — which is in contrast to real NTFS symlinks — we need to have a folder to be extracted so we can use it as the junction. This is why using META-INF comes in quite handy 😉

Since a patch scan walks the whole filesystem including non-admin user writable locations, we can plant our fake JAR file in any such accessible folder.

The exploit uses META-INF as the junction to RPC Control and hijacks the extraction of the JAR file. It is providing a renamed DLL as META-INF/MANIFEST.MF in a fake log4j-2.0.1.jar. By using the pseudo-symlink ExtractVmpDriveScan\META-INF\MANIFEST.MF pointing to the destination DLL name, we can create arbitrary files in locations a non-admin user normally can't write to.

For the destination file in this proof-of-concept I used C:\Program Files\Common Files\microsoft shared\ink\HID.DLL.

HID.DLL was chosen because it can be used for privilege escalation in all current Windows variants. HID.DLL in the given directory is called in SYSTEM context when the on-screen keyboard osk.exe is open while switching to Windows Secure Desktop by hitting Ctrl-Alt-Del (see this ZDI post).

The combination of junction, object manager namespace involvement and pseudo-symlink for this PoC is illustrated below:

None

Any other destination file can be used to plant arbitrary files for elevation of privilege given that the planted file is executed by a privileged process. Depending on the process to be hijacked, this could be another DLL (DLL hijacking attack), an exe file or even a PowerShell script or batch file (command injection) for cases where the privileged process executes such files. One might use local services or scheduled tasks which are often run as SYSTEM.

The Exploit Practice

With the theory above in mind, here are the steps used in reality for a Proof-of-Concept exploit. For this post I'm using folder C:\Temp\ec-test\jar-test as the base folder.

Note that all steps below are done from a non-admin user account:

  1. Create your payload DLL, e.g. by compiling the SystemCmdLauncher project. It opens a SYSTEM terminal when the DLL is loaded.

  2. Open a Windows terminal and create a folder named META-INF in the base folder:

mkdir C:\Temp\ec-test\jar-test\META-INF
  1. Copy SystemCmdLauncher.dll into META-INF and rename it as MANIFEST.MF:
None
  1. Create the JAR file zipping the folder META-INF. It should look like this:
None

  1. Download Google Project Zero's symlink testing tools and compile it using Visual Studio. We're only using CreateSymlink.exe in this case.

  2. In the Windows terminal, change to C:\Temp\ec-test\jar-test, create a subfolder named ExtractVmpDriveScan and switch into it:

cd C:\Temp\ec-test\jar-test
mkdir ExtractVmpDriveScan
cd ExtractVmpDriveScan
  1. In the same terminal run the following command using CreateSymlink.exe from Google Project Zero created in step 5:
“\path\to\CreateSymlink.exe” C:\Temp\ec-test\jar-test\ExtractVmpDriveScan\META-INF\MANIFEST.MF “C:\Program Files\Common Files\microsoft shared\ink\HID.DLL”
Opened Link \RPC Control\MANIFEST.MF -> \??\C:\Program Files\Common Files\microsoft shared\ink\HID.DLL: 000000000000014C
Press ENTER to exit and delete the symlink

This command creates the described pseudo-symlink using object manager redirecting MANIFEST.MF to C:\Program Files\Common Files\microsoft shared\ink\HID.DLL.

To reveal the correct link, you may use Microsoft Sysinternals' winobj64.exe:

None

  1. At this point, the patch scan needs to be triggered, either manually or automatically and wait some minutes until the scan reaches our fake JAR file.

  2. Check the destination folder C:\Program Files\Common Files\microsoft shared\ink for the existence of our injected file HID.DLL.

  3. Using Sysinternals' procmon64.exe the exploit looks like this:

None
  1. Now trigger the load of HID.DLL by opening the on-screen keyboard osk.exe and hitting Ctrl-Alt-Del. This will provide the SYSTEM shell on Windows Secure Desktop:
None
  1. Cleanup: Delete HID.DLL from the folder to not leave a backdoor! For this you need to have administrator rights, so ideally delete it from the SYSTEM shell created above.

Conclusion

This attack exploits some weaknesses of the running privileged patch scan process:

  1. When a privileged process creates temporary folders, it must make sure non-privileged users aren't able to write into it. This can be easily achieved by using Windows API function GetTempPath2w().
  2. Using a hard coded initial temporary folder even when it already exists. Always use a random path name (see above).
  3. Don't reuse existing folders.
  4. Following NTFS junctions should be avoided at all if not absolutely necessary. Using Windows API Profile Mitigation Policy is available exactly for this.

This vulnerability was fixed in Endpoint Central 11.5.2600.19 in February 2026.

A researcher's side note

I personally would have rated this vulnerability with at least high or even critical from an enterprise environment's perspective because ANY user can escalate his privileges to SYSTEM quite easily in this case. This vulnerability would be a "great" opportunity for lateral movement for adversaries.

My CVSS proposal has been: CVSS 8.8 high

ManageEngine's vulnerability policy always rates DLL hijacking with local privilege escalation only as medium risk which one has to respect.

There were some further CVEs that came out of this engagement, all already fixed and published:

Thanks for reading!

Take care and stay secure!