Rootkit-Based Adware Wreaks Havoc Among Windows 10 Users in the US

I was asking about second test (Petya - Red) which was run as administrator and didn't manage to compromise system. You've used an option to run as administrator but you didn't get authentication prompt. Instead sample was run under SUA (as shown in task manger). If I did similar on my system I would get authentication request. If I submitted credentials, process would run under Admin.
If I failed to provide them, process would not start (and wouldn't start under SUA, as in your video). That's why I asked how you configured your SUA and behavior for elevation prompt for SUA.

 

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

 

Yes, but in that test (you can check video on Youtube) there was no elevation request and also no elevation performed (malware was run under SUA credentials even though Run as Administrator option was used). I'm just curious how's that possible.

 

Well, in this UAC bypass they "hijached" a .dll. And running UAC at highest level is not a mitigation to this one: https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/

 

https://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/

 

Yes, but that doesn't explain lack of prompt which is intriguing to me. You can check Youtube video that cruelsister mentioned. "Interesting" part starts at 1:20.
Also your examples show how UAC can be bypassed - meaning elevating from limited Admin to full admin without UAC prompt. If you're logged in as SUA, UAC bypass can't work this way, since your account can't be elevated to full Admin. You have to log in with another account to do it. That's why MS is saying that UAC is not security boundary and SUA is. Again IMO not bullet-proof.

EDIT: I might have a clue what happened in video, but will have to test it tomorrow. It might involve Fast user switching and being logged in under both SUA and Admin acoount at the same time. Or maybe I'm wrong

 

When you create a task using scheduled tasks snap-in and set it to "run with highest privileges," a UAC prompt will not be generated.

There are additional ways also. For example, programmatically:

-or-

https://stackoverflow.com/questions/24284704/automating-cleanmgr-exe-silently-using-powershell

 

That might only work under restricted Admin. It doesn't work under SUA - I just tried it. It asks for Admin credentials when you try to create it.

 

Correct. However, your question was how could cleanmgr.exe run w/o generating a UAC prompt and this is one way to do it. Malware creators will search for like processes and then try to exploit those.

Also, one should always create a logon password for their limited admin account; even if they are the only user of the device. If malware can acquire limited admin or above privileges and create a scheduled task, it will not be able to assign highest privileges to the task. This is because task manager will require entry of that limited admin password to do so.

 

A cumulative reference for UAC bypasses in here: https://github.com/hfiref0x/UACME . Almost all work in Win 7. Some work in Win 10 depending on the version.

 

No that was not my question. My question was how cruelsister could do what she did in her video. Being logged in as SUA, right click sample and use Run as Administrator, getting no UAC prompt to enter credentials for Admin and instead malware is run under SUA. Seems like option Run as Administrator had no effect at all.

 

Try this: https://www.tenforums.com/tutorials...shortcut-without-uac-prompt-windows-10-a.html . Should work for any task requiring elevation running as SUA.

 

Thnx itman. I've used similar tricks in past, but this doesn't seem to answer my question. To be frank, it's not that important to me, I was just curious. Thnx for your suggestions, though

 

And not surprisingly, to even create that kind of Task...

...taken from the link. I'm every bit as skeptical as @Minimalist.

 

Min- I guess some explanation is needed. The purpose of this video was to show the difference between the initial Petya and what amounts to a 5th generation variant (NotPetya). Referring to the video note that there are 3 parts to it:

Part 1 is the original Petya run as an Admin without UAC or password. This was done just to demonstrate what infection from Petya would look like for those that may not be familiar with it.
Part 2 was running the original Petya on a Standard User Account also WITHOUT UAC being enabled or having an admin password. I thought that this would be clear as directly running the malware as the Admin did not result in an UAC popup. But no matter- SUA was able to protect the system even in the absence of UAC being enabled at any level (the original Petya does indeed need Privilege Elevation to work, so by my enabling it would take away from demonstrating the basic protection afforded by SUA for this malware strain).
Part 3 showed the more advanced variant (NotPetya) run in a SUA system WITH UAC being set at max as well as admin pword, and how it cut right through such protection.

Hope that clarified.

 

Thnx cruelsister for explanation. I thought that part 2 and part 3 had the same configuration.

 

Some further details:

https://forum.rehips.com/index.php?topic=2032.555

Original source article:

https://www.carbonblack.com/2017/06/28/carbon-black-threat-research-technical-analysis-petya-notpetya-ransomware/?cn-reloaded=1

 

Additionally from the Carbon Black article on Petya/NotPetya:

I really can't fathom why folks who want to protect networks would be using a security solution w/o IDS protection. Below are screen shots from my Eset configuration that not only prohibits any connection to admin shares but also disables prevalent remote access attacks methods:

 

THANK YOU itman for those screen pics!! I just set my Eset config to the same values. Should checked them long long ago.

 

I reread Carbon Black analysis. In analysis there is no mention of computing base bypass of UAC being used. Googled about it and didn't find much info also.
I then watched Cruelsister's video again and noticed that in that test fast users switching was used and that administrator account was signed in when malware was run under SUA. IDK if that helped malware to gain privileges it needed and what would happen if only one account was in use at the time. Personally I always disable Fast User Switching and use "proper" Log off, Log on options.

 

It can't use SeTcbPrivilege to elevate from SUA to Admin or System account, because processes executed by SUA don't have SeTcbPrivilege.

 

Read @cruelsister comments in this thread: https://malwaretips.com/threads/notpetya-and-standard-user-account.73399/

 

A few other refs. to the SUA bypass:

https://www.bulletproof.co.uk/blog/age-of-ransomware

Even Microsoft has an analysis:

https://cloudblogs.microsoft.com/microsoftsecure/2018/02/05/overview-of-petya-a-rapid-cyberattack/

Cloudstrike has a very detailed analysis of not Petya here: https://www.crowdstrike.com/blog/pe...e-encryption-mft-encryption-credential-theft/

 

I read them, but I don't think they are accurately describing infection process.
Yes, Cloudstrike has good analysis.

 

I don't know whether Fast User Switching is safe, but the worst thing in video was clicking "Run as administrator". This way in the same login session there are processes from two accounts (admin and SUA). These processes can have some interaction between them, because they are in the same login session and Windows were designed to allow some interactions between them.
Not to mention credentials are cached by OS. NotPetya has module for credential theft.