[Juggl3r]

Hello,
first of all I want to say thanks to provide the source code at one place, it really helped me a lot during my research.
I tried to comprehend all methods and from the logical perspective everything is fine. I also managed to make all steps manually to bypass UAC with the different methods but failed with one.
Can somebody help me why this one method is not working for me when doing it manually?
It's about the AppCompact/Gootkit method.
I'm using the Application Compatible Toolkit (GUI) with the /x parameter and then create manually a redirectEXE rule to redirect cliconfg.exe to cmd.exe.
If I start cmd.exe as administrator and then install the shim using "sdbinst.exe test.sdb" it says that it was successfully installed.
However, if I start cmd.exe normally (without admin) it just does not print any message when I do "Sdbinst.exe test.sdb" and it's not working (cliconfg.exe starts instead of cmd.exe).
Therefore I can't bypass UAC because I already need an admin cmd to install the shim. Can you tell me why your application does not need an admin shell? In your code you just do the same by calling sdbinst.... The only difference is that you create the shim within the code and not in the GUI. Is there a special flag in the .sdb file? Also in the talk http://www.securitytube.net/video/8534 the guy says that you can only install shims with admin privileges. Why can you install then a shim to bypass UAC?

ps: I had quit much fun reading this thread

[EP_X0FF]

What is your Windows version?

sdbinst was autoelevated application before windows 10 last builds, so it don't need elevation, but need admin as user. Of course from normal user it won't work without admin rights.

[Juggl3r]

Yeah I already read that in the forum.
I'm administrative user (same user which can execute the uacme tool). Here's a screenshot:

http://www.pic-upload.de/view-26608789/picUAC.png.html

There are 3 "sessions", every sessions is surrounded by a red box.

Left upper: You see that I run as normal user and the result is that the normal cliconfg starts.
Left bottom: You see that I'm running as administrator (started cmd with run as admin) and the result as expected is a new cmd as administrator
Right: Running again as normal user and now starting the uacme tool (exactly the version which can be downloaded on github) and the result is a shell as admin.

I don't understand why it's not working when I do it manually (left upper). I also don't get a message that it was successfully installed when I call sdbinst (see screenshot).

My test system is an old Windows 7, Version 6.1 (Build 7600) SP0.

[EP_X0FF]

Answer is simple. You are running x64 version of cliconfg.exe, because cmd.exe shell is native x64 application.

There is no RedirectEXE shim for x64 apps, it is only available in 32bit, actually this was stated on the UACME page describing methods used.

[Juggl3r]

It's x86 OS.

[EP_X0FF]

Then after sdbinst.exe stage, go to ACT and check is database installed or not.

[EP_X0FF]

UACMe updated with newest WinNT/Gootkit method, d/l https://github.com/hfiref0x/UACME

[EP_X0FF]

Another fresh and easy to use UAC bypass is using GWXUXWorker.exe from KB3035583 (Windows 10 upgrade program).

It has "autoElevate" ability and "requireAdministrator".
It remains in standalone directory %systemroot%\System32\GWX which makes it exploitation trivial.
It is signed with embedded Microsoft certificate, sha1/sha256 (ends July 2015).
There is a perfect dependency SLC.dll with one imported symbol - SLGetWindowsInformation.

Method 1.
Check if KB3035583 installed. If yes then copy your dll with help of wusa/IFileOperation to the %systemroot%\System32\GWX under name "SLC.dll" with SLGetWindowsInformation export. Run GWXUXWorker.exe -> silent autoelevate to full admin on default recommended UAC settings.

The disadvantage of this method is it short life time because Windows 10 planned on this summer and required KB3035583 preinstallation.

Method 2.
You can use copy of GWXUXWorker.exe with your autoelevator and just drop it to the windows directory together with hijacker dll.

The above MS fuckup mean they do not consider autoelevating malware as something important and give no additional attention to the risky autoelevated applications they blindly making up to date. However this reaction is a bit strange. Sometimes there is a feedback - sysprep for Windows 8.1/sdbinst for Win7-10/shcore for Win10.

Currently keeping UAC on middle level for malware is the same as just turn it off. There are few ways to globally fix malware autoelevations even without removing "autoelevate" option. Global point of them - do not allow write access from unauthorized code to the protected system directory such as Windows and it subdirectories.

1) First and most obvious - remove "autoElevate" from WUSA.exe. If you want to deliver update - then force user to agree and allow this.
2) Two backdoor interfaces IFileOperation/ISecurityEditor must be completely removed or reimplemented. They were made for lazy reasons and represents "security through obscurity" principle. They need to be reworked.
3) Every autoelevate application must have embedded manifest with dll redirection to the trusted location where all required files must exist. Additionally autoelevated code must NOT call LoadLibrary dynamically or should do a dll verification before attempt to load anything not in KnownDlls (hello backdoored cliconfg.exe). This can be done inside application or inside Windows loader internals.
4) Explorer.exe child processes must be untrusted and work in sandbox. There must be an exception for valid signed binaries or for executables that launched with user direct permission. This will help with autoelevation based on dll injection and globally with injector type malware.
5) Every autoelevated application must be verified with dll profiler to exclude delay load dll hijacking. Currently there is no such test - sysprep on Windows 10 build 10130 is AGAIN fucked up with newly added dbgcore.dll delay load dependency.
6) AppInfo "whitelisted" applications all must be hardcoded with full path symbolic links not only their names. There should be no situation when you can just copy autoelevated executable to different directory and exploit it there (hello bthudtask and H1N1 malware loader).
7) Replace this god damn ugly UAC shield with sieve which is more suitable for this system mechanism as it implemented starting from Windows 7 up to 10.

But I think painting shitty icons and fucking up with build numbers is more fun and profitable for the *new* Microsoft full of noobs.

[vaber]

Now the adware-UACME-Hibiki is spread by virmakers:
7166268F5C6A02D51C80E0AB3348725B
85884D9C5A66E3B4BD953FFDEB791F04

[EP_X0FF]

@vaber

can you attach any of these?