Depending on our execution vector, the context our code is running in when we first gain access to a target may be at a privilege level that blocks us from doing things or obtaining information. That means that we'll need to pair our execution vector with another "exploit" to get us to the privilege level we need.

Challenge 10: In this challenge you will be given background information that describes a vulnerability (known and unpatched by Microsoft) that allows you to bypass UACUser Account Control (go from User level privileges to Administrator level privileges without notifying the user). Use your new-found knowledge of the vulnerability to have your User privileged code gain Administrator privileges.

Background Information

UAC Bypasses: When working with UACUser Account Control Bypasses for Windows 7+ there are a couple of requirements for the target machine. The first requirement is that the user your code will be running as is an Administrator user (not limited, and not a guest), The second requirement is that the UACUser Account Control (User Account Control) level must be at default or below. You will note that both these things are true on the CTFCapture the Flag VM.







Auto-Elevated Processes: Since Windows Vista, Microsoft made modifications to the security process in an attempt to reduce the number of UACUser Account Control prompts. One of the ways it did this was by allowing some processes to be automatically elevated. These auto-elevated process were limited to a select few Microsoft processes. These process must be signed by a specific Microsoft certificate, must specify auto-elevation in their manifest, and must reside in a specific set of locations. When executed by the user, the processes automatically are given Administrator privileges. The user calling the process does not get a return handle to the process it just created (they didn't want to make it that easy).

Artillery



To implement the Artillery UACUser Account Control Bypass (In-House name) we take advantage of the Windows Update Standalone Installer (wusa.exe). This is an auto-elevated process provided to us by Microsoft in System32. The wusa.exe allows for command line options, one of which allows you to extract a CAB file to an arbitrary location. With a little research, we have also discovered that if printui.exe (another auto-elevated process) is moved from System32 to another directory, it has a vulnerability in its DLLDynamic Link Library loading process. When looking for CryptBase.dll the auto-elevate process looks in its local directory first before looking in System32.



Putting this together we know we can do the following to get the auto-elevated process to load our shim DLL:

Write our shim to a user accessible location Write a copy of printui.exe to a user accessible location Call makecab to put each of these files into a cab format Call wusa.exe to extract both files to System32\MUI Call System32\MUI\printui.exe







Now, to complete the challenge:

Download a copy of the "Shim" DLL

Embed the shim in your tool - Keep it as a byte array in a header file (Melomy) or in your binary's resources (Raptor)

Using your knowledge of the vulnerability, move the shim and any other required files to there appropriate locations

Execute the privilege escalation to see your flag.

PrivEscShim.dll