Windows 10 PLUGScheduler Elevation of Privilege

24/05/2024 - Téléchargement





Fixed Version(s)


Affected Version(s)

Windows 10 21H2 and 22H2

CVE Number



Guillaume André



RUXIM (Reusable UX Integration Manager) is a component used by Windows Update on Windows 10. PLUGScheduler is a scheduled task, part of RUXIM, located in \Microsoft\Windows\WindowsUpdate\RUXIM and that runs as SYSTEM.


The PLUGScheduler.exe binary performs file operations such as deletion and renaming as SYSTEM, in a directory where standard users have partial control. This leads to arbitrary file write as SYSTEM.


Date Description
2024.01.22 Advisory sent to MSRC
2024.02.01 Vulnerability confirmed by MSRC
2024.05.14 Vulnerability assigned CVE-2024-26238 and patched in KB5037768
2024.05.24 Public release


Technical details


When triggered, the PLUGScheduler scheduled task runs the C:\Program Files\RUXIM\PLUGScheduler.exe executable as SYSTEM. The latter creates the C:\ProgramData\PLUG\Logs folder if it does not exist. Afterward, it deletes the RUXIMLog.050.etl file and proceeds to rename all the files with the RUXIMLog.XXX.etl format. More specifically, the RUXIMLog.049.etl file is first renamed to RUXIMLog.050.etl, then RUXIMLog.048.etl to RUXIMLog.049.etl, and so on until RUXIMLog.001.etl is renamed to RUXIMLog.002.etl. Eventually, it starts an event tracing session into the RUXIMLog.001.etl file.

The C:\ProgramData\PLUG\Logs folder is configured with permissive ACLs for standard users. In particular, built-in users can:

  • Create files inside Logs.
  • Create folders inside Logs.
  • Write attributes of the Logs folder.

The ability to write attributes of the Logs folder allows a standard user to add a junction point so that Logs redirects to the \RPC Control object directory. Afterward, two Object Manager symbolic links can be created:

  • \RPC Control\RUXIMLog.049.etl -> C:\path\to\attacker\controlled\file
  • \RPC Control\RUXIMLog.050.etl -> C:\eop.txt

The next time PLUGScheduler.exe is executed, the RUXIMLog.049.etl file will be renamed to RUXIMLog.050.etl. Because of the previously set up links, the attacker-controlled file will be moved to C:\eop.txt, achieving arbitrary file write as SYSTEM.

However, for a junction point to be added to the Logs directory, the latter must be empty. The issue is that the files inside Logs cannot be deleted by standard users (only SYSTEM and Administrators have the necessary privileges). Before renaming a file, PLUGScheduler.exe uses the GetFileAttributesW function to check if the path corresponds to a file. If this is not the case, it does nothing and continues to the next file. Therefore, if RUXIMLog.001.etl is a directory, it will not be renamed to RUXIMLog.002.etl. Let us consider the following content of the Logs directory:

|__ RUXIMLog.001.etl (directory)
|__ RUXIMLog.002.etl (file)
|__ RUXIMLog.003.etl (file)

After an execution of PLUGScheduler, the directory will look like:

|__ RUXIMLog.001.etl (directory)
|__ RUXIMLog.003.etl (file)
|__ RUXIMLog.004.etl (file)

After 47 executions of the task, the directory will look like:

|__ RUXIMLog.001.etl (directory)
|__ RUXIMLog.049.etl (file)
|__ RUXIMLog.050.etl (file)

On the next execution of the task, the RUXIMLog.050.etl file will be deleted and the RUXIMLog.049.etl file will be renamed to RUXIMLog.050.etl. It is thus possible, through this behavior, to run the task enough times so that all the files included in the C:\ProgramData\PLUG\Logs directory are removed.

The last remaining issue is creating the RUXIMLog.001.etl directory, since the RUXIMLog.001.etl file cannot be deleted by standard users. There is a small time window between the moment the RUXIMLog.001.etl file is deleted and the moment it is re-created as the event tracing file. It is therefore possible to create the directory between these two actions. The race condition can be won easily in a few attempts by creating a scheduled task as the current user, that is triggered on each logon. The scheduled task will attempt to create the RUXIMLog.001.etl directory in an infinite loop until it succeeds. It was discovered that, in order to reliably win the race, the program needs to be compiled as a graphical Windows application instead of a console application (probably because a cmd window is displayed for a console application).

The PLUGScheduler scheduled task is triggered at each logon and also once a day at a fixed time. The standard user can therefore trigger it by logging off and logging in again. The exploitation strategy is thus the following:

  1. Set up a scheduled task as the current user, with a trigger at each logon. This task will attempt to create the RUXIMLog.001.etl directory in C:\ProgramData\PLUG\Logs. Log off and log on until the race condition is won and the directory is created (usually a few attempts are needed).
  2. When the directory is created, log off and log on until there is only one entry in C:\ProgramData\PLUG\Logs: the RUXIMLog.001.etl directory.
  3. Remove the RUXIMLog.001.etl directory.
  4. Set up the C:\ProgramData\PLUG\Logs -> \RPC Control junction point.
  5. Set up the Object Manager symbolic link \RPC Control\RUXIMLog.049.etl -> C:\path\to\attacker\controlled\file.
  6. Set up the Object Manager symbolic link \RPC Control\RUXIMLog.050.etl -> C:\eop.txt.
  7. Log off and log on: the attacker controlled file was moved to C:\eop.txt.


This vulnerability is an arbitrary file write. It can be used to execute code as SYSTEM by writing a DLL file in C:\Windows\System32\SprintCSP.dll and triggering the SvcRebootToFlashingMode method of the StorSvc service (as detailed in…). Note that this is only an example as to how the file write vulnerability can be leveraged to achieve elevation of privilege, and there are many other ways to do so.


Define a stricter ACL for the C:\ProgramData\PLUG directory and its child objects. Only privileged users must be able to write inside.