Windows 7 UAC Exploit

Migration planned

"Sysprep DLL search order hijacking" - 60.000 Google Search results and hackers can't hear the end of it!

This is - by far - the best-known UAC exploit in the world. It was by the time that Windows 7 introduced different UAC levels and in this instance a very serious logic issue that goes beyond this particular exploit. Windows Vista kept nagging with UAC dialogs so users deactivated it completely. Then Microsoft came up with a way to keep security up to a certain level whilst sparing users continuous popups. Both at the same time and the way it was implemented did just not work out.

How it works

By any means, if you know this exploit, you may very well skip this section!

Because putting research effort into the UAC inevitably leads you to learn about this exploit. Hell, I was searching for additional information and kept scrolling until there was no "sysprep" on my screen anymore! And what's even more surprising: Microsoft did not fix this for Windows 7! And this makes it particularly interesting. I wouldn't have invested time into implementation and publication otherwise. Note, that Windows 8 and above, indeed, are patched.

DLL search order: When a process loads a DLL, there is a specific order of directories to look for it. First, the application directory is searched. Then, the current directory and then the system directory, which is usually C:\Windows\system32. The rest of the list is currently not of interest.

auto-elevate: The UAC now has two distinct modes (the third one is just optimized for slow graphics cards). "Always notify", as the only choice Windows Vista users had, pops up a consent dialog every time, elevated privileges are requested. Due to negative user feedback (what a surprise), we now have "Default - Don't notify me when I make changes to Windows" in addition. This basically means, that some programs, such as the Task Manager - and sysprep! - elevate without user's consent. A binary with a manifest that specifies "autoelevate" and is both signed by Microsoft and stored in a secure location (like system32) can now automatically elevate, unless UAC is set to "Always notify".

Privileged file copy: You cannot directly write into system32, Program Files, etc. But did you notice, that Windows Explorer can - and without a consent prompt? The IFileOperation COM object is used instead of WinAPI's CopyFile. Since Explorer can and we don't, let's inject a DLL into explorer.exe. We can inject a DLL from a medium integrity process into another one, unless it is elevated. So, we just force the running process of explorer.exe to load our first DLL. This DLL will run in a thread of Explorer and using IFileOperation, we indeed can write into system32. However, we cannot overwrite existing DLL files, since they are owned by Trusted Installer. Something which by the way some users try to delete off their systems, for reasons I cannot comprehend.

Now combine those three facts

So, Microsoft grants themselves the license to kill elevate! Some system executables skip the UAC dialog and this is what makes them vulnerable. Any high integrity process that you can tamper with from a medium integrity process in order to ultimately load your DLL file will execute your arbitrary code in its own context - and in high integrity.

Now, luckily (or unfortunately), sysprep is located in a subdirectory of system32 - C:\Windows\System32\sysprep\sysprep.exe. So, placing a DLL file next to the executable that usually loads a DLL with this name from the system32 directory will cause the executable to directly load our DLL instead and instantly execute it. So, after excluding Known DLL's, which are always loaded from system32, we are left with a couple of options. Let's pick cryptbase.dll.

Now, let's sing:

  1. Inject DLL #1 into explorer.exe
  2. DLL #1 will use IFileOperation to copy DLL #2 to C:\Windows\System32\sysprep\cryptbase.dll
  3. Execute sysprep.exe
  4. sysprep.exe now runs with high integrity and loads DLL #2
  5. We do our job, whatever that is, delete leftover files to keep the system stable and use ExitProcess to terminate sysprep.exe

</Done skipping>


UAC Level

This exploit as well as most other local privilege escalation exploits will not work with the UAC level at "Always notify". This is because auto elevation only works on the default UAC level, which is what it was designed for. However, I wouldn't dare to suggest increasing the UAC level, as you are then left with a security concept that is just painful. Remember Vista's UAC shit storm? Happy new year 2007, then...

Local Administrator Group

The user must be in the local administrator group. Otherwise, any privileged operation will require a standard user to enter the administrator user's credentials. Compared to the UAC at "Always notify", this means the user cannot elevate anything unless they enter the administrator user's password. It is widespread practice in company networks to provide standard user accounts to most employees which not only prevent LPE exploits from auto elevating, but furthermore prevent any privileged operation whatsoever.

"Not a security boundary"

Not this again... But it's kind of true. If you are experienced with security, you will not just execute a file that you don't trust in the first place. So, stick with keeping malware away rather than hoping for security mechanisms to prevent damage. Also notably, malware can do a lot event with user rights. Don't underestimate this! Anything that you can accomplish yourself from the Windows desktop can be done by malware as well. Now look into your webcam and agree ;)

Impact and risk

This and similar exploits may be hard to find, but they are easy to comprehend. I already explained this to people who had little knowledge of computing and they understood it perfectly. Also, describing trivial exploits like this one to someone capable of implementing them requires just a couple of words. "sysprep auto-elevate DLL search order" is all a hacker needs to hear and without further ado will be able to implement it. This applies to many other exploits as well - finding one is hard and gets harder, implementation happens overnight.

UAC bypass exploits are basically what ransomware is made of. Ransomware that encrypts your entire hard drive to press money from you is bad enough. However, adversaries who want to encrypt the files need to get rid of the shadow copies or else files can be easily restored. Deleting them requires elevated privileges and that's why UAC exploits are commonly used by this kind of malware. And currently it looks like people discover one UAC exploit after the other.

This particular exploit was fixed on Windows 8 and Windows 10 by simply hard-coding absolute paths to these DLL's in the executable's embedded manifest, which is effective. But it's only effective for one specific vulnerability and hell, it's not fixed in Windows 7, yet. It was spotted around the RC and I have the feeling it is there to stay.

This means, the UAC in Windows 7 is basically useless. And even on current versions of Windows, people still find creative ways to tamper with privileged processes. It's an ongoing cat-and-mouse game. But in the end, the operating system hosts both high and medium integrity applications in literally one and the same place. Do you think it's trivial to keep these separated? It's not. There is a point of intersection and this is point is the exact definition of a vulnerability for local privilege escalation.

Implementation - source code and binaries

Since this exploit is very well known and everyone seems to like it, I thought why not implement a variant myself. Neither did I come up with the concept nor do I have to re-invent it. Implementation took a couple of hours tops. And don't call me gray for publishing it based on the previous section. This exploit can be found literally everywhere on the internet. Any black hat can and will use it - and most definitely knows that it's there. No one except Microsoft can fix it. And they don't seem to care, at least not for Windows 7.

  • Windows7UacExploit.exe: When executed without command line arguments, escalates privileges and spawns an elevated cmd.
  • Command line arguments: Optional. The first one is the executable that will be run elevated. Any following arguments are forwarded to this executable.
  • Deployable: With these 3 files, any payload executable can be auto elevated. No .NET or Visual C++ Redistributable dependencies are required. Everything is written in C++ and compiled with /MT.
  • As-is: Windows7UacExploit.exe will do exactly this and nothing else - this is not malware on its own. The binaries precisely reflect the source code that is provided as well.
  • Works: Windows 7 is not patched, while this exploit is well known since years.