Windows 10 UAC Bypass Uses Backup and Restore Utility

Hum ...............

Something didn't set quite right with me with the Dridex UAC bypass that btw was done on Win 7. That is the creation of a directory in C:\Windows\System32. So I did my own test on Win 10 x64 1607 w/UAC set at max. level running as limited admin. Guess what? I received a UAC prompt! Someone running on Win 7 will have to do the same but I believe you will not receive an UAC alert.

Also I advise anyone who has upgraded from Win 7 to Win10 that there is a high likelihood that your file permissions are "borked." There are numerous web postings to this. I know mine were "borked." I used TweakUI to reset them to default values.

Finally as far as privilege escalation goes there are many ways malware can do it. Below is PowerShell script code to do so:

Ref.: https://www.autoitscript.com/forum/topic/174609-powershell-script-to-self-elevate/

​

 

As far as this method goes: https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/ , it is a .dll hijack within a normally trusted process with a higher privilege .dll. That is hijacking dism.exe that runs from %AppDataLocal%/Temp. As such, no direct UAC bypass was needed or employed.

 

Exactly, and you did a reasonably good job explaining why I call it fake security.

There's nothing great about it. Most people don't bother to switch to SUA and use UAC at medium level, that's like 90% of the world. This automatically means that all of these people can easily be owned by malware capable of bypassing UAC. In many cases malware don't even have to bypass it, because 99% of the time all of these alerts are triggered by the user themselves, so there is no reason to click on "no", after all they do want to run the app, right? It's better to rely on AV/AE.

 

@itman Ask @Lockdown, he tested it and since i'm very close to him (even before he works for BRN), i know i can rely on his test result.

so from what i remember his results: to be put simply Dridex use cmd and powershell to download the malicious file, once the downloaded sample hits AppData\Local\Temp it will be blocked by AppGuard. (because it is user space)

If launched as Guarded , gksagd.exe will be blocked

 

People make it a security boundary , not MS. People assimilated it as one because malware often ask elevation.
To be fake security , it would mean that MS created it as a security feature which was never interpreted by them as one.

Their fault if they don't think carefully. can't blame the mechanism if it is wrongly used.

 

To be specific, the Dridex atombombing ver. only downloaded the payload to AppData\Local\Temp. It did not run from that location. Dridex loaded the payload into unallocated memory and ran it from there. Additionally, the Dridex payload was disguised as a signed Win .dll. See this link for further details: https://www.wilderssecurity.com/thr...atombombing-update.392391/page-2#post-2657656

So frankly, I don't see how AppGuard could have detected it.

Appears he didn't use the Dridex atombomding sample that IBM detected. Most likely another Dridex variant. The only .exe associated with the IBM sample was ff.exe per VirusTotal.

 

Yes, correct. It is not a security feature, but UAC can help.

 

I will let @Lockdown give more details, after all he knows the situation better than me.

 

There is one major problem with UAC. That is the alerts it generates. For the average and even advanced users, the alerts do not provide enough data to make an intelligent decision.

For example in the test I performed in reply #26, the alert I received was for "File Operation." The only other data provided was that the offending process had a vaild Microsoft code signed certificate. What was missing was:

1. The source process information; name, location, etc..
2. The object targeted; type, name, location, etc..
3. The specific file operation attempted; create, modify, delete

Based on the previous UAC alert data noted, I would assume most users would have allowed the activity. Only someone with Windows permissions knowledge would realize that this type of alert is generated when the source process certificate permissions are not at a level high enough to perform the attempted activity against the targeted object.

 

Would process logger service log the info you are looking for itman? Or would it after the infection? Guessing since it is using unallocated memory, it would not log it.

here is an example:

[Process Creation]

03/19/2017 14:36:36
Process: [5668] C:\Windows\System32\dllhost.exe
Username/Domain: xxxx/xxxxxxxx
CommandLine: C:\WINDOWS\system32\DllHost.exe /Processid:{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}
MD5 Hash: C9B6A2C3D4EF7A3C838F79F957F9E520
Bitness: 64-bit
Publisher: Microsoft Corporation
Description: COM Surrogate
Version: 6.2.15061.0
Integrity Level: Medium
Signer: Microsoft Windows
System Process: False
Protected Process: False
Metro Process: False
Parent: [492] C:\Windows\System32\svchost.exe
Parent CommandLine: C:\WINDOWS\system32\svchost.exe -k DcomLaunch

 

I believe you are referring to this "Process Logger Svc is a service-only software application that monitors for processes executed in the system and saves events to a custom log file."

You don't really need this since you can just switch to Task Manager or Process Hacker/Manager and see what is running prior to responding to an UAC alert. Of course, the average user isn't going to do this. Also you have to have the smarts to identify malware that is not easy if running from a shell, etc.. Also doesn't help if a hijacked valid process is the source unless you open every executing process looking for a hijacked .dll for example.

 

@guest I see what you mean now... Well each to their own, eh!

 

True. Enabling command-line auditing helps, but it is still missing a lot, then again, MS does not consider UAC as anything of value and MS never finishes, what it starts, like polishing its apps.

 

Indeed , i agree on that. More infos will be a good thing.

But remember that if an elevation is requested while you did nothing that would triggers it surely means the request is suspicious.

 

Yes and no. Yes - you, I, and most Wilders folks know that. No - the average user would be clueless as how to answer the alert.

 

yes, that is the same old dilemma.