For red team engagements (and Windows hardening reviews), the 2NS red team is often tasked with finding potential vectors for privilege escalation. The findings are usually tied to environment specific configurations allowing for exploitation and as such cannot be used outside of the specific target environment. Then again, in some cases the root cause stems from third party software packages that are more generally exploitable. In this post we document an elevation of privilege vulnerability (or vulnerabilities) that were identified during an engagement in 2025.

Red team engagements frequently include an assumed breach workstation, which is then bound to get a fair bit of attention. But as often is the case, these workstations come as blank canvases with default installations, without all that much to dig into. One part that is always of high interest is the MDM solution and the software packages made available by the IT administration. These commonly include organization-specific software packages as well as common third-party tools. Packages available from MDM portals like Company Portal (Intune) and Software Center (Microsoft Configuration Manager) can be configured in a multitude of different ways, but it is common for them to allow users to install software packages as system-wide installs. These installs thus happen as NT AUTHORITY\SYSTEM, making this an area of interest for our research.

In order to effectively research the software package installs it is useful to analyze the installations in a separate test VM.

The following is an analysis of Sublime Text 4 installer package, a commonly used text editor.

Installer analysis

Using PsExec available from Sysinternals Suite, we could execute the software installer as NT AUTHORITY\SYSTEM to more closely simulate the MDM installation process. With a quick analysis using Process Monitor we can see that sublime_text_build_4200_x64_setup.exe creates a subfolder C:\Windows\Temp\is-XXXXX.tmp, then creates a new temporary binary sublime_text_build_4200_x64_setup.tmp inside it and executes it. The .tmp process then tries to locate multiple DLLs starting from the temporary folder, indicating a potential DLL hijack opportunity.

Executing the Sublime Text 4 build 4200 installer as SYSTEM with PsExec: The installer process creates a new .tmp binary in a subdirectory of %TMP% and executes the newly created binary:
The .tmp binary attempts to locate and load multiple DLLs, starting from the current directory:

Usually when these types of installers are executed as admin, the temporary folder is not accessible to other users, but SYSTEM environment variable %TMP% by default points to the C:\Windows\Temp directory, which is user writable.

C:\Windows\Temp folder is generally accessible by a normal user, but notably does not allow BUILTIN\Users to list the directory contents:

As the installer did not change the DACL of the created temporary directory, it created a race-condition. By placing one of the missing DLLs to the temporary directory before the installer binary attempts to locate them, we could load our DLL to the elevated process. The issue is that a normal user does not have Read data/list directory (RD) rights and thus can not list the contents of C:\Windows\Temp to find the newly created temporary directory. As an attacker this leaves us with brute force. With five characters to guess we have practically no chance of winning the race in the very limited time window and have to resort to opportunistic locks to stall the installer. We found that by placing an opportunistic lock on C:\Windows\apppatch\sysmain.sdb we were able to stall the installer at the correct time, when the directory has been created, but the temporary process has not been started yet. By running a simple brute forcing application that attempts to write the DLL to every possible C:\Windows\Temp\is-XXXXX.tmp\ directory, we found that it was possible to win the race in approximately 25 minutes on average. The result was a working proof-of-concept, but with the somewhat heavy drawback of the long brute force time it would take to run.

Uninstall to elevate

After successfully exploiting the race-condition in the installer, not fully satisfied with the usability of the exploit, we took another look at the installation process, this time focusing on the uninstalling part. We found that the uninstaller is spawning a process called _iu14D2N.tmp directly from C:\Windows\Temp. Additionally, the process tries to locate and load multiple DLLs from the directory, making exploitation trivial. This allowed us to skip the brute forcing and merely place our DLL directly in C:\Windows\Temp\ prior to the execution of the uninstaller.

Hijackable DLLs directly inside C:\Windows\Temp\:

Proof of concept exploitation of Sublime Text 4 package available for install from Company Portal (Intune):

In order for the issues to become exploitable the package available from MDM needs to have both installation and uninstallation options available and most importantly install behavior should be set to system:

Root cause, patch review and notes

Investigating the installation we found that the Sublime Text 4 build 4200 installer is using Inno Setup version 5.5.9, published in 2016.

Installer version found in registry: Following the trail for the temporary directory and file creation in the source code repository, it was clear that the default DACL of the SYSTEM temporary directory was not taken into account in the case of either of the issues. Since the issues would not surface unless the installer was executed as SYSTEM they were somewhat less obvious. The issue of SYSTEM temporary directory access controls have since been somewhat mitigated by changing system processes to primarily use secure directory C:\Windows\SystemTemp, see Microsoft announcement. Unfortunately the fix is only valid for when the system temporary directory path is obtained via GetTempPath2 or GetTempPath APIs and the system environment variable %TMP% still points to C:\Windows\Temp.

We also found that both of the issues had been previously discovered and reported in 2022 by Johannes Schindelin from the Git for Windows team. Based on the commit messages and edits, the issues were identified correctly and the fixes work as intended. Uninstaller binary is placed inside a subdirectory in %TMP%, rather than directly in %TMP% and CreateDirectory calls were replaced with CreateSafeDirectory calls with correct DACL based on the executing user. The fixes can be found in commits fa2c741 and adb8bb3, see repository in Github .

Since the vulnerable versions of the Inno Setup installer are still widely used, we reported both of the vulnerabilities via NCSC-FI and a CVE was assigned. Both of the issues are fixed in Inno Setup version 6.2.2. Based on our review of common application packages, it is common for software packages to use rather dated versions of the software installer libraries. In order to minimize these types of issues, it is recommended to favor installations limited to the logged in user.

Timeline

11/08/2025 – Issue reported to NCSC-FI on 11.8.2025

3/3/2026 – CVE-2025-15595 published (https://nvd.nist.gov/vuln/detail/CVE-2025-15595)

Blog post, research and findings by
Anton Keskisaari / Senior Information Security Specialist