Windows 10 UAC Bypass Uses Backup and Restore Utility

https://www.bleepingcomputer.com/ne...0-uac-bypass-uses-backup-and-restore-utility/
​

Only applies to Win 10.

 

Yes, setting UAC to Always notify usually breaks the bypass. Maybe it should be set up like this by default?

 

Probably blocked on SUA , since you can't modify the registry from there.

It is what every users should do...but you know some people can't stand 3 UAC prompts a day..so...because of them UAC was made more "convenient" (aka weaker) after vista.

 

Yes, I assume it is blocked by using a SUA, but the problem you will have that will stop most people from using it is that with a SUA when you are hit with a UAC prompt you have to enter a logon and password each time. MUCH more work than just clicking a button. At work it's my job so I do it. At home... I don't wanna.

 

You might want to read the TechNet article referenced in Bleepingcomputer.com link:

https://technet.microsoft.com/en-us/library/2009.07.uac.aspx#id0560031​

 

Sure, but i don't see the problem if you don't happy click on everything and you care to use your brain before allowing any elevation prompt.
The malware mentioned on this topic needs to write the registry, which is, i believe, hampered in SUA.

That is the point... if people are willing to sacrifice security for convenience, it is their choice...If they get compromised, blame themselves.
All my accounts (even admin one) require password, it doesn't annoys me much since i do barely just one admin task a day; so one prompt a day is ok to me

 

Actually the point here is that the key being changed is in the HKEY_CURRENT_USER area which even a standard user has access to and can modify without admin rights as it is their 'own hive'.

No UAC Prompt, even users who have set Group Policy to Auto Deny user elevation are affected by this one in so far as allowing the registry change by default. It's just yet another fail for MS in the chain of auto-elevating their own tools.

Update: Did a test and the good news seems to be that even though the registry change can be made regardless, with UAC set properly you guys are correct that the payload can be avoided if people aren't click happy. Jives with what he said:

 

People keep confusing activity capability versus privilege access rights.

Windows account status sets activity capability . For example, a SUA is restricted from perform certain activities such as installing software since those activities require a higher access level i.e. privilege.

Privileges on the other hand determine what capability a process has in accessing and modifying entities within Windows e.g. files, registry, etc.. Privileges are assigned to the previously mentioned entities based on predetermined rules by the Windows OS.

When a process starts up execution, it will ask for a certain level of privileges. If the privilege level requested is higher than that given by current Windows account status, a user account control(UAC) alert will be displayed. The user can then allow or deny the privilege escalation request.

Windows however allows for select number system processes to run at an administrator privilege level without any UAC prompt. This is referred to as "AutoElevate" or hidden elevation. These processes run at administrator level regardless of logon account status i.e. SUA or LAA. However if UAC is set to "always notify," a UAC alert will be generated when these hidden processes attempt to run.

See the 'Auto Elevation' section of the previously posted TechNet article link for reference.

 

Agree on this.

It is why i keep advising using UAC at max in the first place. but guess what ? it is annoying for some... especially happy clickers
Anyway for 99% of prevalent malware, users must execute it.

Indeed, i still don't understand why they still implement auto-elevation....guess it is for convenience again...standard users want play the admin? click the UAC prompt. That should be it.
In past eras, i can understand, but today with those crafty malware writers, it should be removed.

 

Below are excerpts from the prior reference TechNet article. I have highlighted the important points. I recommend that people thoroughly read the UAC sections a couple of times so they thoroughly understand the content within. The "bottom line" is it is this auto elevation capability that has resulted in the recommendation from all knowledgeable security experts to always set UAC at the maximum level.

 

Who cares about UAC anyway? It shouldn't be relied upon for true security, it's not only easy to bypass it via malware (standard setting), it's even easier to bypass it via the user who is going to click on yes anyway. It's basically fake security.

 

it what i kept saying.

Those who understand it.

Dumb users deserve their fate.

It was not even designed to be a security boundary, it was only designed as a convenience feature to allow admin tasks in SUA without the needs to shift accounts.

 

I have always had my UAC set to high. Burt as you guys know there is another thread here on bypassing it. Doesn't the article say the UAC setting doesn't matter?

 

Setting it to high prevents bypass:

 

Yes, Dridex(non-AtomBombing ver.) noted here: https://www.flashpoint-intel.com/blog/cybercrime/blog-dridex-banking-trojan-returns/

As given in my "Auto Elevation" excerpt posted in reply #10, Windows auto elevates w/o UAC valid system executables in the C:\Windows\System32 or C:\Windows\SysWOW64 directories. Reason is fairly obvious.

Exact details of this UAC bypass are:

 

but there were two others at bottom of page.

"Nelson and another researcher, Matt Graeber, have previously found two other UAC bypass techniques, one that abuses the Windows Event Viewer, and one that relies on the Windows 10 Disk Cleanup utility."

 

This can be prevented with UAC set to highest level.

This one cannot. Employs technique similar to Dridex.

Note this was reported to Microsoft in July, 2016 who "dissed" it just like they "dissed" the atombombing POC. Guess what? Dridex malware authors exploited both vulnerabilities in recent attacks.

Microsoft FUD:

 

As noted at the end of article:

MS fixing bypass would be great also.

 

There is a way to stop this "crap."

Just use a security solution with a HIPS that monitors file creation\modification in the C:\Windows\System32 or C:\Windows\SysWOW64 directories. Most do this but you have to test your security solution for effectiveness. If it doesn't work as expected you can create manual rules to do the same. Note you only initially want to monitor those two directories and not any existing subdirectories since Windows is constantly updating those. This is where it gets tricky since Dridex created a new subdirectory. Also if you create manual rules, you will be bombarded with alerts after a Win update since Win installers are updating those directories. You can minimize those by switching the HIPS to training mode prior to a Win update.

 

Assumed in the Dridex UAC bypass attacks that the banks that got nailed had their endpoints configured in effect as SUA's by employing appropriate software restriction policies(SRP) and the like. Again, advanced malware will elevate to the access level it requires to do its "dirty work."

 

Congrats, you are a pure example of one of the people who clearly do not understand it properly, because if you did, you wouldn't be here calling it "fake security". It's great when it's used correctly. Obviously if a user clicks yes anyway then that is their problem, but in no way is it "fake security".

It's not full proof, just like nothing in this world is... Of course. And before you tell me that malware which doesn't require UAC exists, I know this too. But if UAC is configured properly and used properly and the user isn't click happy with alerts, then it can be very useful.

It's not supposed to auto-block malware like your primary protection. It won't be able to differentiate between what is clean or not. It wasn't designed too, either.

 

Told him many, many, many times but before he replies and we will go again on a new "UAC heated timeloop debates" let me explain @Rasheed187 opinions about UAC:

You need to know that @Rasheed187 is the main UAC (and Windows native built-in security) disliker in Wilders, really dislike it (annoyance issue because he runs Window in admin mode and use very very frequently tools that need elevation (Process Explorer is one of them). I wonder how much elevation requests he has a day because i barely get more than 2.

Rasheed arguments are mainly oriented about his specific system (he clearly told me he doesn't care of others situation) because he relies mostly on his HIPS software, so for him, UAC (and the rest) is useless because his HIPS will catch the malware before UAC (which is true).

Also his attitude over UAC is a bit deformed because he considers UAC as a security feature (which is not, see the quote) so since UAC is bypassable if the user is dumb, Rasheed consider UAC as weak security feature hence his mistaken opinion.

Now that you get the background , you will understand most of his firm-stood PoV; you can save saliva and we can avoid another UAC debates.

@Rasheed187 i think i describe your position well enough (fell free to correct me if i was wrong)

 

it is user vulnerability exploited because he executed the malicious file

Yes indeed.

yes HIPS, SRP, anti-exe , etc...

Dridex latest is blocked by Appguard (confirmed), however no idea with Applocker.

 

Yes there is probably nothing that will 100% protect users or systems from advanced malware and targeted attacks. If someone would try to employ 100% security it would probably end up with useless and unmanageable system. Also each counter measure will be, at the end, bypassed by new evasion technique. So IMO some protection is still better than none at all.

 

You have a link on this? If you're referring to blocking dropper execution from a Word doc., I would agree. After that point, I need to see proof.