Intro
(warning this post if quite long)
UACMe is a demonstrator tool initially developed following WinNT/Pitou research. It contains set of User Account Control (UAC) bypass methods, where most of them initially extracted from ITW malware.
 |
Pic 1. Typical UAC window (IFileOperation).
|
More about UACMe and Microsoft way of fixing "not a security boundary" (and side effects of these fixes) you can read at kernelmode.info archive. Since initial release in the December 2014 a total number of added UAC bypass methods counted 63. It maybe astonishing number at first glance but keep in mind that around ~20% of these methods are combinations of each other, any change made by Microsoft to fix designated method will ruin not only this method but also automatically everything where it was used. A perfect example is methods based on ISecurityEditor undocumented autoelevated interface used by Win32/Simda (previously wide-spread malware family with Russian origin). When Microsoft altered this interface forcing it to work only with file objects this ruined not only original Simda method but also method that used Application Verifier dll planting (later this method was also used in some ITW malware). However this does not mean UACMe doesn't have measures against these fixes where they are available. Several methods have different ways of execution depending on current Windows version where they expect original implementation to be fixed or unavailable by different reasons. Anyway - don't take UACMe methods counter as an indicator of anything.
With these number of methods codebase has ridiculously grown and because it late 2020 it was decided to drop everything that does not work or have been fixed on current mainstream Windows version.
Microsoft fixes to UAC, while there are plenty of them, almost never been backported to previous Windows versions. Only exceptions are: generic fuckup in media (like in case of some APT causing MS drop UAC fix as part of their bulletin) or as part of big rollup update (Windows 7). Just keep in mind that UAC become "not a security boundary" when it was fucked up by Microsoft marketing specialists with Windows Vista.
Currently Windows 10 pushing major updates 1-2 times per year. As for now, Windows 7 and 8/8.1 out of the box settings render their UAC almost transparent to threats due to fundamental design flaws revealed in the UAC implementation over time. Not surprisingly all methods that bound on Windows 7 are dropped in UACMe 3.5+. It is time to move on.
The last major UAC update in Windows 10 was in RS1 release (14393) where they massively updated appinfo (UAC service with implementation inside appinfo.dll) and reviewed several other things. Since that time they released only some sporadic updates targeting some specific methods. However this does not mean they do nothing. Not at all.
Windows Defender to the rescue
This Microsoft aggressively imposed "product" that ships with Windows 10 (now even Server) and it general purposes are:
1. Massively affect PC performance;
2. Imitate protection from threats by detecting open source projects, collections of out-dated malware and various script-kiddie junk;
3. Have an option to work as selective backdoor (hello Kaspersky GRU mode 🙀);
4. Take a share on AV global market.
Windows Defender is the thing you don't need at all. At least if you capable of being a master of your PC not slave of it installed program. Fortunately, despite the Microsoft attempts to harden WD presence, you still can remove it completely from system without side effects.
Regarding to UACMe Windows Defender works as "that guy" who is fixing what OS devs doesn't want to fix. Yes, they selectively and very carefully signatured lots of unfixed UAC bypass methods and UACMe program and it components. However even there MS for some unknown reason leaving wide open window for malware constantly ignoring a very popular methods used ITW and at the same time detecting some of really rare (if even used). On the other side WD installed and updated on systems that has no fancy UAC fixes built-in so it working as the only available lazy fix here 😉
How does it detect it? Windows Defender has a real-time behavior monitoring feature that can catch system events by a bunch of kernel mode filters and callbacks (most of them inside WDFilter.sys driver). A user mode client subscribed to these events and judging on their combinations can predict program behavior thus giving WD ability to check it against set of rules stored in the signatures called "Behavior" in their AV database. There are hundreds of such rules in their database and this number always grows. And of course they have a lot of them regarding possible UAC bypasses.
Examples of such behavior detection:
The filter reports registry write at specific key which is hardcoded in the WD database. Some program want to change @Default value of current logged user Software\Classess\mscfile\shell\open\command key. Determinate a caller application (if it is an indirect registry write - attempt to locate its initiator). Revert registry change, remediation - check and kill initiator, notify user through message balloon, write logs, quarantine the initiator, if required. Take a hint, this is all done in real-time, involving a lot of highly ineffective code, with a race condition state so if system lags a lot WD actually can miss the moment when initiator effectively launch payload and despite achtung balloon UAC bypass will "pass".
 |
Pic 2. Windows Defender detection with behavior signature (nothing quarantined, its just a WD bullshit).
|
Another example of same kind. We have same registry write event, but our detection rule is more complicated. Now we also check if there is a specific process launch registered - sdclt.exe (Microsoft binary). If so, we are looking for its parameter (it can't be obfuscated as we doesn't control sdclt.exe behavior this way). If this parameter is /kickoffelev - bingo, you got a balloon "Threat detected Behavior:Win32/UacBypassExp.K!sdclt"
Et cetera. There are more than 40 behavior detection signatures targeting UAC bypass attempts at the moment of this writing and this count will highly likely increase. Some of them giving cross detection capabilities.
Does this effective enough? It depends on how much space for maneuver the particular method has. If you out of space and different approach is impossible - WD have won.
However, you should not overestimate WD team capabilities. While they are indeed carefully signatured some of the known methods and combinations in various malware, they are doing this in a way missing any creativity in mind. Or maybe they are incapable of it. So if the method is still technically working on latest Windows 10 and WD has behavior signature for it - it is highly likely we can bypass it by altering method in a way WD does not expect it to work.
Below we will take a tour to the UACMe 3.5 remaining methods, figure out how they can be fixed from OS dev point of view and how WD can be improved to block them completely as "lazy way fix".
UAC Bypass Exploits
Everything below tested against full patch Windows 10 (2004), clean install with default settings and fully updated Windows Defender as of 26 September 2020.
💥Method #22
(herein and below numbers are method ids in UACMe list).
1) Description
This is a dll hijacking method based on internal Windows dll redirection feature called DotLocal (or .local) and relying on IFileOperation autoelevated interface to plant payload files/create required subdirectories structure inside Windows system32 protected directory. It is similar to #21 with different target application, in that case it is consent.exe - this thing is responsible for UAC credentials dialog and launched every time when you start anything that require an elevation (even if it is has autoelevation capabilities). Except providing GUI for UAC this program also responsible for checking autoelevated interfaces to be in special whitelist introduced in the Windows 10 RS1 and called COMAutoApprovalList. If checked interface is not in this list it won't be elevated. UACMe creates a required subdirectory structure in system32 and plants it special module called Fubuki under name comctrl32.dll. Next when consent.exe started this dll loads into consent address space as common controls library, executes payload and terminate consent. Resulting payload will run with LocalSystem (NT Authority\SYSTEM) account rights because consent.exe spawned from UAC service that also runs as LocalSystem.
2) WD detection
Microsoft has a behavior signatures for this method. Their idea here is to catch the moment when you create subdirectories for planting payload and moment when attacker code moves payload from temporary folder to the target subdirectory in system32. This is strange and incomplete detection as it doesn't cover different scenario when nothing moves anywhere and there is a direct write to this directory from memory.
3) WD detection bypass
Since IFileOperation creates an admin owned directories in system32 we can abuse that fact, create subdirectories as usual and then reset DACL for final subdirectory to allow us write access without elevation. This can be achieved by combing IFileOperation with ISecurityEditor which has been a subject of incomplete fix after Win32/Simda where MS banned it usage for anything else than file objects, previously it was nice autoelevated Set/GetNamedSecurityInfo wrapper.
4) Lazy fix for WD
Obviously you must catch a moment when a file is created inside this DotLocal subdirectory structure. However this can be not enough, as attacker code can use renaming operation, so better solution will be catch both cases and if there is ANY file present (or there is an attempt to write here) in this DotLocal substructure show detect. It is a bit more complicated then what they actually have.
5) Possible fix
When consent.exe started by appinfo service it maybe be started with process mitigation binary policy "Microsoft Signed Only" applied. This even won't require any IFEO keys etc. I've no idea why they didn't bothered to implement this from the beginning. This is especially fun because #21 targeting sysprep.exe was fixed by MS in that way.
💥Method #23
1) Description
This is dll hijacking method based on fact that PkgMgr.exe (whitelisted by UAC service in g_lpAutoApproveEXEList internal list) is being deprecated and works just as launcher for Dism application which is located in system32 subdirectory "Dism". When the Dism application has started, it will search for its dependencies in the system32 as first, then from its home directory. Attacker can plant a payload dll as dismcore.dll to the system32 and then trigger Dism launch by calling PkgMgr.exe with special parameters.
2) WD detection
Windows Defender has several signatures to detect this, their exact dedicated signature called Win32/Disemer and has several variants. They detect it by various things - starting from dismcore.dll file in the system32 (which indeed achtung and red alert as it never happens on real system), and ending up with pkgmgr.exe parameters containing specific tokens.
3) WD detection bypass
First of all, since I was this one who made this method public I'm quite surprised that for a few years of it existence no one actually look on it deeper. It seems both malware and AV industry blindly adapted what was posted on kernelmode.info. If we can trust crowdstrike (dubious security company sometimes serving as a proxy in West info wars campaigns) - even some "APT" used it as is. Actually you can do this bypass in a different way. There is no need in any additional files (packages) to be dropped anywhere and supplied as parameter to pkgmgr. You can just give it complete junk and use something else not only dismcore.dll. However this method has not so much space for maneuvering and can be completely signatured.
4) Lazy fix for WD
Pkgmr execution with ANY parameters following executable code planting as file in the system32.
5) Possible fix
Remove deprecated PkgMgr.exe from appinfo g_lpAutoApproveEXEList. There is no sense in keeping it here. Instead, PkgMgr may have manifest with requested execution level set to "requireAdministrator" and autoelevation blocked or unspecified.
💥Method #30
1) Description
Strictly speaking this is not a true dll hijack, it is more like abusing undocumented feature where this it seems completely for internal debugging. Method based on Wow64 subsystem logger dll. The first public mention about this Wow64 mechanics has been posted more than 10 years ago by lhc645 here. There also was posted wow64log dll source skeleton. The target dll - wow64log.dll must be placed to the system32 folder. Every wow64 application when started will load it and execute dll entry point, thus you can inject this dll to the autoelevated binaries from syswow64 folder. The logger dll must be native otherwise there will be a crash in the target application. This method has a lot of disadvantages and not that much room to maneuver in case of active counteraction from WD. UACMe uses IFileOperation to plant module named Akatsuki - payload dll as wow64log.dll in the system32 folder. This dll is not native and this is done on a purpose. When target application attempts to load this dll it will crash causing launch of WerFault application which is also will be 32 bit but started as LocalSystem. Thus Akatsuki will propagate to WerFault instance(s) and grant payload code NT Authority\SYSTEM access rights.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed, see above.
4) Lazy fix for WD
Block wow64log.dll loading by default.
5) Possible fix
Block wow64log feature by checking corresponding registry value (lets say REG_DWORD "EnableWow64Logging") somewhere in HKLM with default state set to FALSE(0).
💥Method #32
1) Description
This method implements UAC bypass by window hook set from dll hijacked UIAccess application. As target it abused OSK.exe copied from Windows folder to the %ProgramFiles%\Windows Media Player folder (created if not exist) with help of IFileOperation. This is done for creating conditions required for dll hijack. Target directory selected because it is inside appinfo g_lpIncludePFDirs secure directories whitelist. Next Fubuki planted in the same folder as duser.dll or osksupport.dll depending on Windows version. When OSK.exe starts - variant of this dll loaded and Fubuki code runs on Medium+ integrity level from UIAccess allowed application which enables it dll injection via windows hooks. As target of final injection it uses eventvwr.exe launcher application.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed, see above.4) Lazy fix for WD
Easiest and obvious - block dlls planting by folder and name. However there can be different targets and dlls. Ultimate solution would be preventing dll injection at final stage to the high IL process from Medium+ IL as it clearly not something you can expect from such UIAccess applications.
5) Possible fix
UIAccess applications should include manifest with hardened loadFrom elements thus preventing dll hijacking as dll dependencies that are not in KnownDlls will be loaded from manifest specified paths. Microsoft did this in the past with Sysprep.exe (unfortunately this was incomplete fix and it took them few more years to finally harden sysprep from dll hijacking) and for inetmgr.exe.
 |
Pic 3. Sysprep.exe manifest as example.
|
💥Method #33 (#62)
1) Description
This is a registry key manipulation type bypass. It is similar to infamous Enigma0x3 "mscfile fileless" bypass and the only difference in a key and target application. It abuses fact that Windows Shell will first lookup given class items in the current user registry hive and only after that in local machine. Thus you can control key that later Windows will attempt to parse and execute command from it. Method 33 and 62 has the same code base in UACMe, the only difference is the target applications they involve. It was requested by some of the UACMe users and I didn't mind to fulfill that request.
2) WD detection
Because this is similar to Enigma0x3 methods and widely used ITW by malware Windows Defender has behavior detection signature Behavior:Win32/UACBypassExp.T (with variants). Part of rule including write event to the current user Software\Classes\ms-settings\shell\open\command @Default value and following process execution (fodhelper.exe or computerdefaults.exe - both are Microsoft binaries).
3) WD detection bypass
Windows Defender capable of detecting write event to the hardcoded registry key either direct or indirect using for example reg.exe or Powershell. In fact it doesn't matter, it will detect all writes, indirect write through registry symbolic link or registry transaction. It detects 😉
How this can be bypassed? We will use the fact that WD is:
A) incapable prevent registry key creation and B) only inspect @Default value change of the last key in the registry path chain.
Our goal is to redirect key read for Windows Shell from WD inspected key to our fake key with all planted data. To do this we will set registry symbolic link to the "command" registry key in path chain and redirect it to our controlled "command" key somewhere else. WD will read original key and will be happy as it will have the same unmodified @Default value. Windows Shell will reparse registry key when accessing "command" and will read data from "our" key instead. Everybody happy.
4) Lazy fix for WD
Block symbolic link creation for entire registry entry elements, or follow symbolic link and inspect resulting key instead of just reading hardcoded one ignoring reparse. More hardcore solution would be is to block write access at all to these shell keys.
5) Possible fix
Create default empty keys for users and protect them with security descriptor. Windows Shell is over-complicated bullshit so there can be side effects and this require more investigations which is simpler to do when you have all source code.
💥Method #34
1) Description
This is AlwaysNofity compatible method. It abuses environment variables and Microsoft DiskCleanup scheduled task. The idea behind this method is to set your own controlled %windir% environment variable to the registry and then force scheduled task take it resulting in command line injection. Quotes for payload command are required part here as they need for successful command line injection since executable path in scheduled task is not quoted.
2) WD detection
It detects the fact of scheduled task startup and does this by comparing command line of schtaks.exe to have \Microsoft\Windows\DiskCleanup\SilentCleanup substring. If found - then achtung you got Behavior:Win32/SilentCleanupUACBypass
Note they also prepared for possible other sources - this signature speaks for itself PossibleSchedTasksUACBypass (checks for \Microsoft\Windows sub-string).
3) WD detection bypass
Just don't use schtasks. No one actually forced you to do so. This method is perfect illustration when everybody just simple copy-pasted original. You can do the same what schtasks does with help of Task Scheduler interface objects such as ITaskService, ITaskFolder and IRegisteredTask.
4) Lazy fix for WD
Detect %windir% environment variable modification for current user.
5) Possible fix
Get rid of environment variables for DiskCleanup scheduled task or use quoted path. That %windir% actually was a ridiculous idea.
💥Method #36
1) Description
This method is from infamous SandboxEscaper from those times when he was not yet what he(she/it whatever) is now. Like almost everything from this guy it is based on NTFS reparse point feature and state of race condition. It abuses Wusa behavior which creates hidden temporary directory in the root of the current drive with default security descriptor when processing msu (cab) files. Wusa extracts contents of processed cab file to that temporary directory looking for further instructions inside these files. By setting reparse point on that directory you can redirect Wusa write to specified target directory.
2) WD detection
There is no specific detection signature for this method. However since one variant of it uses Dism hijack similar to method #23 WD detects file planting to the system32 folder with Win32/Disemer signature.
3) WD detection bypass
Similar to #23
4) Lazy fix for WD
Similar to #23
5) Possible fix
Wusa should set security descriptor when creating temporary directory. Something like similar fix has been implemented for method #26 by MS in the past.
💥Method #37
1) Description
It is combination of DotLocal, Wusa race condition methods (#21, #22, #36). It uses Wusa race condition to create DotLocal directory structure and copy file to the system32. Instead of comctrl32 it abuses GdiPlus with target set to DCCW.exe
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed, see above.
4) Lazy fix for WD
Similar to #22 and #36
5) Possible fix
Dccw.exe autoelevation removal.
💥Method #38
1) Description
This method uses appinfo command line parsing spoofing. This requires talking to appinfo via RPC as Windows Shell always build correct command line request when used ShellExecute(Ex). This can be achieved through AicLaunchAdminProcess hook or by direct RPC call. You have to prepare your MMC snap-in and embed in it Shockwave Flash Object which will execute supplied HTML script located somewhere on disk. This HTML code will eventually run your payload through ExecuteShellCommand method.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed, see above. 4) Lazy fix for WD
This method require file drops. Both fake management console snap-in and html run script can be detected when dropped to the disk. However this is not really reliable. Perhaps you can catch the moment when mmc.exe got started with fake snap-in.
5) Possible fix
Obviously appinfo command line parsing need a tweak so it won't skip arguments in command line without actual check of them.
💥Method #39
1) Description
This is NET Code Profiler method. It entirely rely on setting very specific current user environment variables and registering fake profiler dll which must be dropped to the disk. Then you must select dotnet origin target. In our case it is EventViewer GUI - slow & ridiculously over complicated piece of crap.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed, see above. 4) Lazy fix for WD
Can be entirely prevented by WD inspecting environment variables regarding CorPofiler path.
5) Possible fix
mmc.exe should not allow loading of non Microsoft binaries in it address space when run with High IL.
💥Method #41
1) Description
Based on ICMLuaUtil autoelevated COM interface which provides a set of methods that can be used to bypass UAC. It allows running arbitrary executable with High IL, deleting and setting arbitrary registry entries with elevation and more.
2) WD detection
WD has multiple behavior signatures for initially presented script based attacks, for example: Behavior:Win32/CICmstp, Behavior:Win32/UacCmstp, Behavior:Win32/SuspParentLaunchingLOLBin, Behavior:Win32/CmstpSuspParent and variants of them. Unfortunately they are completely incapable of preventing this method when it used as it should be. They only signatured script-kiddie junk. Why is that read next. Meanwhile this method is somewhat popular in malware because of it simplicity in raw mode.
3) WD detection bypass
No needed.
4) Lazy fix for WD
This interface is a backdoor by design. It is fully controllable by attacker with attacker defined components and huge space for maneuver. It is hard to trace behavior as it can be various and unpredictable. You can however trace when this interface used for legitimate purposes, log it behavior and compare this trace with occurred event. It doesn't look very reliable however.
5) Possible fix
Remove this interface from COMAutoApprovalList. This will force UAC to show dialog each time this interface called.
💥Method #43
1) Description
This method is a combination of #41 which is used to write arbitrary data to the Windows Registry and another undocumented autoelevated interface called
IColorDataProxy. Main idea here - write custom calibrator setting to the HKLM\Software\Microsoft\Windows NT\CurrentVersion\ICM\Calibration @DisplayCalibrator and then run it by calling autoelevated IColorDataProxy interface method LaunchDccw. Interface will read custom calibrator value and start this program via ShellExecuteEx call doing that on High IL.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed. 4) Lazy fix for WD
Detect write to HKLM\Software\Microsoft\Windows NT\CurrentVersion\ICM\Calibration at value @DisplayCalibrator. May cause problems if this feature used somewhere legitimately.
5) Possible fix
This won't work without writing to the registry which is provided by ICMLuaUtil interface. Removing it from COMAutoApprovalList will automatically block this method too.
💥Method #52
1) Description
This method currently popular ITW because of it simplicity so even zero skill malware authors may embed it to their elite dotnet droppers. Idea behind it is to abuse appinfo design flaw where Win32 API GetLongPathName due to it specific is converting supplied fake security directory path to the real one thus passing further internal check against secured directories whitelist. There at least two variants of these method used ITW - original and my - involving reparse points, exactly it is used by WastedLocker ransomware. They mostly copy-pasted it as is from UACMe with their set of ridiculous additions.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed. 4) Lazy fix for WD
Detect directory creation, mount point creation. It should not be that hard as this method require trusted directory name abuse.
5) Possible fix
This needs to be patched in appinfo. Get rid of Win32 API when converting file path. It is ridiculous combination having Win32 API path conversion for path check.
💥Method #53
1) Description
This method is similar to #33. The only difference is the target key and application. Target key here is HKCU\Software\Classes\Folder\shell\open\command @Default value (+DeletegateExecute as usual) and trigger is sdclt.exe
2) WD detection
WD is capable to detect this. Dedicated signatures named Behavior:Win32/UACBypassExp.F!sdclt(2)(3)(4)(src). Writing (direct or indirect) to that key default value triggers detection.
3) WD detection bypass
Similar to #33
4) Lazy fix for WD
#Similar to #33
5) Possible fix
#Similar to #33
💥Method #55
1) Description
It is UIPI bypass with UIAccess application primary token duplication. Duplicated token next modified to have Medium IL and used to create second stage process. Because this process created with token that has UIAccess flag set this process will be able to circumvent UIPI. As second stage process UACMe uses Fubuki unit modified in the runtime to be standalone executable. When started Fubuki will spawn msconfig.exe at Tools page. Next it will identify ListView window and use SendInput API to navigate to the "cmd.exe" entry in the tools list and simulate button click. After that it will wait for console window and type specified command to it running actual payload. This is a complex method that is not really reliable in the real life and was added just for fun as I really liked the concept.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed. 4) Lazy fix for WD
I would detect all kind of Medium IL processes running with UIAccess flag set as malicious just because it against Windows behavior as normal UIAccess application always has >= Medium+ integrity level.
5) Possible fix
Remove UIAccess from token if it duplicated from Medium+ IL from a process with Medium IL. This need actual investigation as there could be unexpected side effects.
💥Method #56
1) Description
This method is similar to #33. The only difference is the target key and application.Target key here is HKCU\Software\Classes\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\shell\open\command @Default value (+DeletegateExecute as usual) and trigger is wsreset.exe
2) WD detection
WD is capable to detect this. Dedicated signatures named Behavior:Win32/UACBypassExp.F!wsreset(2)(3)EF. Writing (direct or indirect) to that key default value triggers detection.
3) WD detection bypass
Prepare target key structure somewhere else and rename it key component to actual name before running target.
4) Lazy fix for WD
Additionally to #33 detect rename key event.
5) Possible fix
#Similar to #33
💥Method #58
1) Description
Based on IEditionUpgradeManager autoelevated COM interface. This interface has method called AcquireModernLicenseWithPreviousId. During execution it starts Clipup.exe process from (what it suppose) windows system32 folder. It uses %windir% environment variable(sic!) to build path to that executable. Thus you can set your own %windir% variable and this code will use it to build a path with your controlled location in it.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed.
4) Lazy fix for WD
Same as #34
5) Possible fix
Cheap and easy fix - get rid of environment variables from Win95 era and build a proper path to clipup.exe by using, surprise - surprise! GetSystemDirectory.
💥Method #59
1) Description
This method abuses debug objects to achieve elevation through appinfo direct talking via RPC. It is complex and non trivial. While it is using same RPC request as #38 it is completely different in implementation and bug/feature it abuses. At first stage we create non elevated process with RPC request and supplying DEBUG_PROCESS flag in process startup parameters. When appinfo processes our launch process request it uses CreateProcessAsUser API which automatically will create debug object if DEBUG_PROCESS is specified in process startup flags. The handle for this debug object will be stored inside TEB reserved field. All processes created by the same thread will share the same debug object. Note that appinfo uses thread pool so it could make sense to spam it with requests to fill it all. We capture debug object with NtQueryInformationProcess(ProcessDebugObjectHandle) call, detach debugger with NtRemoveProcessDebug and kill our first process - it was only needed to allocate debug object on appinfo side. On the next stage we run autoelevated process again with help of direct RPC call and set thread debug object to our saved one. Next we process standard debugging message loop looking for CREATE_PROCESS_DEBUG_EVENT. Once hit we capture process handle from event and duplicate it with PROCESS_ALL_ACCESS desired access rights. Then resulting handle used to create final payload process with help of CreateProcess and PROC_THREAD_ATTRIBUTE_PARENT_PROCESS.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed.4) Lazy fix for WD
Detect parent process creation.
5) Possible fix
This need a fix on appinfo side. Perhaps you could ensure that there is no debug object set when creating a High IL process by request from Medium IL.
💥Method #61
1) Description
This method is similar to #33. The only difference is the target key and application. Target key here is HKCU\Software\Classes\Launcher.SystemSettings\shell\open\command @Default value (+DeletegateExecute as usual) and trigger is slui.exe which is started with runas verb.
2) WD detection
WD is capable to detect this. As detection it will show you one of the previously highlighted behavior signature names used in similar methods as they cross check this method. Writing (direct or indirect) to that key default value triggers detection.
3) WD detection bypass
#Similar to #33
4) Lazy fix for WD
Similar to #33
5) Possible fix
Similar to #33
💥Method #63
1) Description
This method is relatively new. It uses dll injection to the Windows Native Image Cache (NIC), forces it to be used and then exploits by running Windows Firewall MMC snap-in. Files in NIC are accessible to Administrators group so we can reset their security permissions (by using ISecurityEditor autoelevated COM interface) and after that overwrite file contents with your payload. Required target file for overwrite located by searching in installed assemblies and comparing MVID (Module Version Id) of files.
2) WD detection
Not capable (as of 26 Sep 2020).
3) WD detection bypass
No needed.4) Lazy fix for WD
Detect write event to NIC from Medium IL process.
5) Possible fix
Administrator group should not have write access to NIC directory and it contents.
P.S.
Of course the best and lazy way to circumvent everything from above is not use Administrator group account at all. I'm not talking about AlwaysNofity UAC setting because as proven by time it is useless. However I would like to point that current Windows eco system evolved from Windows XP times with deep rejection of UAC since Vista fuckup. Thus, no matter what you tell or want, default account still will have administrator group. Idiotic shield icon doesn't help a lot too giving people sort of placebo. Nothing from above is a rocket science or require millions of dollars for fix. Fix your leaky shield.
As of UACMe 3.5 I've no further plans to fight WD next wave of signatures by giving them free help. I have no doubt they will implement more and more measures against UAC bypasses in future, not necessary against mentioned methods or in the mentioned ways. It doesn't really matter and personally I don't care. What I wanted to show - is that if someone want to bypass WD behavior signature - it will highly likely do this without significant problems.
If something new, creative and working will be discovered - it will be added in UACMe 3.5+ versions. Old 3.2.7 branch will be still available but without any further support from my side. Speaking about new, creative and working methods - see P.P.S. next.
P.P.S. Comedy Section Bonus
Every year you can find a lot of junk noise about yet another "uac bypass" involving something with Open/Save/Print what ever dialogs. It is when "hackers" runs some elevated process, then clicks somewhere in it menu, spawns shell dialog and runs programs from it through menu. Woohoo, Windoze Byp@$$3d M1cr0$0ft SuXx! Or another example is some modification in system that must be triggered by manual clicking somewhere in target application running at High IL.
Nothing from this is UAC bypass as it require massive user interactions with UI
and target applications have High IL preventing GUI hacking. That doesn't mean you can't do GUI hacking at all - method #55 proves it is possible, however NONE of these elite hackers are even close to something like that, because it is simple not their level. Any
of such posts are just attention whoring and nothing else. If you can't
automate your "bypass" it is not a bypass otherwise I'm giving you
ultimate UAC bypass working with AlwaysNotify - select an
executable file on disk, right click on it - press "Run as
Administrator", when UAC window popup - confirm it. Ultimate "bypass"
done, probably needs a video to be recorded, ROFL.
Another kind of attention whore scam release their ultimate "private" tools (together with snot with bubbles) claiming old well known methods as something they used "privately" for "years" and now "released to the public", because they, you know, "s3curity r3s3arch3rs" (just like that funny guy who managed to copy-paste from everywhere without understanding what he copy-paste).
Microsoft
has determination of what they consider security boundary and what is not. UAC as you guess - is not a boundary, we can go to usual demagogy here, but
that is the fact. This is one side of the medal. From the other side,
malware usually need this not only as a some bonus but as critical for it viability.
So you have a dilemma - some broken mechanics you don't consider as
worth looking at and real malware taking this as essential part. Because
of that you always will have a lot of noise around UAC. Unfortunately
most of this noise will come from typical internet idiots (included in target audience of malware and most of malware developers).
Unfortunately both types of mentioned guys does a lot of white noise each year which makes it harder to find real methods as you have to filter out tons of such trash. Don't be like them. While maybe not that sophisticated and complicated UAC is still part of Windows and integrated to the system. It is not about OpenDialog. The better you understand Windows internals the better you understand how UAC works and it weakness (and the more you laugh at yet another idiot with OpenDialog). Aside of this some of these bypasses are usually accompaned by various different mechanics, algorithms and internals that need to be researched.
There is a still a lot of possible real UAC bypasses undiscovered since this system mechanics is entirely broken in many ways and these methods are just waiting to be exploited.
References
All the links to the original authors descriptions are provided at UACMe page and inside source (where available). Make sure to visit and view original authors content if you like their methods. Also note that actual UACMe implementation of their methods maybe different from original.
1. UACMe - https://github.com/hfiref0x/UACME
