Vendor : Microsoft Corporation Affected Product : Windows 7 x86 and hopefully Vista too Author : Souhardya Sardar and Rohit Bankoti Contact : https://www.linkedin.com/in/souhardya-sardar-82b57b140 / https://in.linkedin.com/in/rohitbankoti Email : Souhardya@protonmail.com Tested on : Windows 7 Ultimate x86 6.1.7601 Service Pack 1 Build 7601 Overview : dwmapi.dll which is a part of Desktop Window Manager (DWM, previously Desktop Compositing Engine or DCE) is the window manager in Windows Vista, Windows 7, Windows 8 and Windows 10 .. is located in system32 Almost all executable installers (and self-extractors as well as "portable" applications too) for Windows have a well-known (trivial, trivial to detect and trivial to exploit) vulnerability: they load system DLLs from their "application directory" (or a temporary directory they extract their payload to) instead of "%SystemRoot%\System32\" hence dwmapi.dll is supposed to be called from system32 directory only But the case here is opposite if a attacker places a dll with the name of dwmapi.dll in the same directory of say software abc.exe .... when abc.exe is executed the malicious dll is also executed with it If an attacker places malicious DLL in the user's "Downloads" directory (for example per "drive-by download" or "social engineering") this vulnerability becomes a remote code execution. Proof of concept :- 1. Create a malicious 'dwmapi.dll' file and save it in your "Downloads" directory. 2. Download say a vulnerable software say abc.exe from abc.com 3. Execute abc.exe from your " Downloads " directory 4. The malicious dll 'dwmapi.dll' file gets executed instead of the original dwmapi.dll which is located in "%SystemRoot%\System32\dwmapi.dll" To make things worse: executable installers (and all DLLs they load) are typically run with administrative privileges, either due to their application manifest (specifying "requireAdministrator") or the "installer detection" of Windows' "user account control" (see <https://technet.microsoft.com/en-us/library/dd835540.aspx#BKMK_InstDet>): "protected" administrators are prompted for consent, unprivileged standard users are prompted for an administrator password. References of our discovery :- https://cxsecurity.com/issue/WLB-2018010011 https://cxsecurity.com/issue/WLB-2018010008 https://cxsecurity.com/issue/WLB-2018010010 https://cxsecurity.com/issue/WLB-2018010009