13th March 2026

As part of MDSec’s R&D work, we often discover vulnerabilities and develop exploits to support our red team engagements. When researching widely used software, it is often only a matter of time before the same vulnerability is discovered by other researchers and reported to the vendor. Two weeks ago we outlined an Elevation of Privilege vulnerability in Windows 11 that we had been leveraging in red teams but decided to report to the vendor ourselves.

Ironically, today we’re documenting another Elevation Of Privilege vulnerability that was so elegant in its indicators, we kept it internal and used with great success across red team engagements since January 2025. For what will become obvious reasons, we named this vulnerability RegPwn and it affected Windows 10 and 11, as well as Windows Server 2012, 2016, 2019, 2022, and 2025. This vulnerability was fixed this Patch Tuesday and we believe is tracked as CVE-2026-24291.

The Windows Accessibility features are a collection of built-in capabilities in Microsoft Windows designed to make the operating system usable for people with disabilities or specific usability needs. These features provide alternative ways to interact with the system through keyboard input, voice, screen narration, visual adjustments, and assistive technologies.

The list of installed accessibility features is defined in following registry key:

“`
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionAccessibilityATs
“`

When some of these Windows accessibility features are used (ex: narrator, on-screen keyboard etc) the following registry key is created and grants full control to a low privilege user:

“`
HKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilityATConfig
“`

This registry key will also be populated with the configuration related to accessibility feature used, in this example On Screen Keyboard:

These configurations are then copied to the following registry key in **HKLM** which is created by _winlogon.exe_ during the login process and grants the logged in user write privileges:

“`
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySessionATConfig
“`

Windows accessibility features execute in the user context, albeit with **High Integrity** due to the **UIAccess** flag. The obvious question then becomes, how can this be abused to obtain **SYSTEM** privileges?

The answer lies in the **Secure Desktop**. The primary distinction between the secure desktop and the user desktop is that only trusted processes running as **SYSTEM** are permitted to execute there. In other words, no processes running with the user’s privileges are present on the secure desktop.

When a user creates a secure desktop session by either locking the workstation or running process via the “ _Run as administrator_” option two **atbroker.exe** processes are started, one running in the current user context and one running as the **SYSTEM** account.

The **ATbroker.exe** process running as the low privileged user will once again copy all configurations from `HKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilityATConfigosk`

to

`HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySessionATConfigosk`

The **ATbroker.exe** process running as the **SYSTEM** account will proceed to copy values from `HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySession1ATConfigosk`

to

`HKU.DEFAULTSoftwareMicrosoftWindows NTCurrentVersionAccessibilityATConfigosk`

Finally an instance of the **osk.exe** process running as **SYSTEM** is started and copies values from `HKU.DEFAULTSoftwareMicrosoftWindows NTCurrentVersionAccessibilityATConfigosk`

to

`HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySessionATConfigosk`

As the `HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySessionATConfigosk` registry key is writable by the current user and the configuration values are copied from a user-controlled registry location, this behaviour can be abused to achieve an arbitrary registry key write in the context of **SYSTEM** by leveraging registry symbolic links.

In order to win a small time window between **osk.exe** starting and writing into the registry key, an opportunistic lock is placed on `C:Program FilesCommon Filesmicrosoft sharedinkfsdefinitionsoskmenu.xml` ,when the oplock is triggered the `HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySessionATConfigosk` registry key is replaced with a symbolic link pointing to an arbitrary registry key.

`HKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilityATConfigoskkey and add an arbitrary registry value.` `C:Program FilesCommon Filesmicrosoft sharedinkfsdefinitionsoskmenu.xmlfile.` `LockWorkstation()API.` `HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAccessibilitySessionATConfigoskregistry key with a registry link to arbitrary registry key.`

In the proof of concept below we overwrite **ImagePath** of the **msiserver** service and start the service by creating an instance of the MSI COM object:

Our exploit code for this vulnerability is available here.

This post was written by Filip Dragovic.