It appears that there is an exploit out there that allegedly allows you to bypass the UAC on Windows 7 computers and gain administrator access. I was wondering if this exploit is still a dangerous vulnerability on the average Windows 7 box or if it is already widely patched. I haven't looked too closely at the exploit, so it may not work at all. It seems to be legitamate C programming with win32 from just skimming through it. I've seen different sites that claim this is a valid exploit.


  • What, do you mean like worry in general? Dunno, how many average Windows 7 boxes do you have and how much do things worth worrying about depend on them? We can't answer this. What kind of a site would we be, if we told you what you should or shouldn't worry about? For anything more conclusive, please provide detailed information on what type of assets you're trying to defend, whom from, and what measures have you taken to assure their safety.
    – TildalWave
    Mar 28, 2014 at 4:38

4 Answers 4


I will provide you the technical details of the exploit you are talking about and then let you decide yourself whether you should worry or not.

The bypassUAC exploit exploits a bug (or rather a feature) of Windows operating systems where processes signed by the Microsoft code signing certificate don't prompt the user when it escalates its privileges to SYSTEM. This is known is privilege elevation in the Microsoft text. The issue was first identified by Leo Davidson back in 2009. If you look at the targets of this exploit, you will find that Windows 7 is vulnerable even though Windows Vista which came before Windows 7 is not vulnerable. The reason for this is because Microsoft deliberately downplayed the security of Windows 7 in order to provider a better user experience. Any Vista user is going to tell you the unlimited number of UAC prompts every time they performed a task. To minimize those prompts, Microsoft decided that all those applications that Microsoft signs with its code signing certificate should be trusted for auto elevation of privileges and so this vulnerability was born.

The way this vulnerability is exploited is that there is an exe file in C:\Windows\System32\sysprep\ directory called sysprep.exe which loads a DLL file CRYPTOBASE.DLL. Since the sysprep.exe don't load this DLL using its full path, you can put a malicious DLL with the name CRYPTOBASE.DLL in C:\Windows\System32\sysprep directory and the sysprep.exe will load the malicious DLL file when executed. This technique is known as DLL hijacking. Suppose the malicious DLL starts notepad.exe which is signed by Microsoft code signing certificate, inject another DLL in it such as metsrv.dll which is the Meterpreter dll file and then request for privilege elevation, the process will silently gets SYSTEM privileges without any UAC prompt because that is how it is designed in the default state on Windows 7. This vulnerability also exist in Windows 8 (although not with the sysprep.exe executable).

Now if you are concerned about this attack vector there are a few steps you can take to make sure bypass UAC don't work. The first thing you can do is not to use Administrator user. This will protect you because injecting a malicious DLL (or any other code) in another process require to have debug privilege on that process. Administrators can have debug privilege to any process that is why bypass UAC require Administrator privileges. Also, there are four UAC protection levels in the graphical console of the UAC in control panel. If you set the protection to Always Notify, no process can silently elevate its privileges. You will always get a UAC prompt just like in Vista and bypass UAC exploit will fail (unless you click Allow).

Now you decide whether you should worry about this vulnerability or not. In most of the cases, if the malicious user has gained code execution with Administrator privileges, its already game over for you. Elevating it so SYSTEM is just a symbolic game nowadays.

  • ...except, isn't System32 one of the access-controlled directories? That is, they have to be authorized to put their DLL in that location, so it wouldn't matter anyways. Mar 29, 2014 at 22:37
  • @Clockwork-Muse the IFileOperation object when called from a process that is signed by Microsoft code signing certificate allow copying/deleting/executing of files on the file system without UAC prompt that is why you can spawn notepad.exe for example, from there call the IFileOperation COM object and instruct it to copy CRYPTBASE.DLL to system32\sysprep directory and it can do that without the UAC prompt.
    – void_in
    Mar 30, 2014 at 13:20
    – pri
    Aug 2, 2017 at 6:11

UAC Was never ment to be a security measure.

Should you worry about it? It depends on what you're doing about it, if you're using the administrator account then yea you should, but if you have the administrator locked with a nice password and you're using a second account then what's to worry about?


This is a local exploit. It means someone must already have access to your computer to use it. For a home user this is not a problem on it's own. The same rules for securing your computer still apply: for example don't run .exe files you don't trust.


UAC is not a security boundary, and as such shouldn't be used as a real protective measure. It's nice to have and a neat idea, but it doesn't protect you.

Should you worry about it? Sure, why not? A bug is a bug. If you're actually looking to provide real protection then don't run things where UAC has to act -- run as a standard user. Any attack that can bypass UAC would have nothing to bypass and will only get privileges of the standard user, not an administrator.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .