App Review NotPetya and Standard User Account

[cruelsister]

This video highlights a form of process elevation by malware which not all may be familiar with.

 

[AtlBo]

Great video. I guess it would have run if you were only logged in the SUA too. Well, that will be a patch from MS soon if it hasn't already been patched. Super helpful info.

 

[Windows Defender Shill]

Seriously awesome video CS

For those few of us interested in these questions, your videos are incredibly enlightening.

 

[Andy Ful]

Thanks for a very interesting video. It seems that NotPetya on SUA, initially drops perfc.dat to 'C:\ProgramData' (or 'C:\Documents and Settings\All Users\Application Data'), because it has not got the privileges to write into the Windows folder. Finally, the malware uses system executables (sctasks.exe, shutdown.exe) to create a scheduled task for restarting the system. Using sctasks.exe requires the SeTcbPrivilege (or higher, if I remember correctly).
On Administrator account, NotPetya uses SeDebugPrivilege, which allows dropping the malware perfc.dat directly to Windows folder.
I have a question, how did your malware sample get the tcb privilege on SUA?

 

[509322]

Thanks for a very interesting video. It seems that NotPetya on SUA, initially drops perfc.dat to 'C:\ProgramData' (or 'C:\Documents and Settings\All Users\Application Data'), because it has not got the privileges to write into the Windows folder. Finally, the malware uses system executables (sctasks.exe, shutdown.exe) to create a scheduled task for restarting the system. Using sctasks.exe requires the SeTcbPrivilege (if I remember correctly).
On Administrator account, NotPetya uses SeDebugPrivilege, which allows dropping the malware perfc.dat directly to Windows folder.
I have a question, how did your malware sample get the tcb privilege on SUA?

There are various online sources going all the way back to 1999 about using trusted computing base to bypass.

 

[Andy Ful]

There are various online sources going all the way back to 1999 about using trusted computing base to bypass.

I know that. I'm curious what method was used by the sample from the video.

 

[cruelsister]

Andy- specifically it uses SeTcbPrivilege. The ease of how this is done is why anyone that knows malware will refrain from any conversations concerning UAC or Admin vs Standard accounts. Actually the reason for this video was the number of sites that suggested using SUA and password protected Admin accounts as a way of protection for this malware.

Looks like you really can't believe everything you read on the Internet.

 

[total]

exactly
The problem is not adware, scriptkiddie trojans and other junckware. The problem is highly-sophisticated malware such as paswordstealer, ransomware, banking trojans that can cause financial loss and loss of important data. For such type of malware windows settings do not mean anything essential to performing the operation for what they are created.
The damage caused by adware and other junckware is in the worst case resolved by windows refresh .... the question is how to repair the damage caused by the real malware and how to get painless from it.

 

[Andy Ful]

...
The ease of how this is done is why anyone that knows malware will refrain from any conversations concerning UAC or Admin vs Standard accounts. Actually the reason for this video was the number of sites that suggested using SUA and password protected Admin accounts as a way of protection for this malware.
...

Bad news.
I noticed that the malware ran on Windows 7 in the video. Is it possible to bypass UAC in this way on Windows 10 ? The Windows 7 UAC has many known loopholes.

 

[cruelsister]

Andy- Yeah, it was on Win7. I did this for 2 reasons:
1). Non-Win10 systems are still used by half of all Windows users, and
2). The upcoming Win10 release will dramatically improve Win10 security-wise, so any type of test on the current build would be counter-productive.

I will say that from what those in the know have told me, a stepping up of how the new Win10 will handle credential management will totally suppress the actions of this malware. And as you have said, Win 10's UAC is indeed better out of the box than previous versions (especially at the low end where system files are protected even if a person sets UAC to Never Notify.

What does sadden me is that so many did not take advantage of the free Win10 upgrade become of privacy rants made by the lunatic fringe (OH My God! Microsoft is tracking me!!!!). This is a pity as now those that were so easily led by those that knew the least must pay for a superior operating system.

 

[Arequire]

What does sadden me is that so many did not take advantage of the free Win10 upgrade become of privacy rants made by the lunatic fringe (OH My God! Microsoft is tracking me!!!!). This is a pity as now those that were so easily led by those that knew the least must pay for a superior operating system.

You can still get Windows 10 for free through their accessibility website (although I'm not sure how ethically sound it is to lie about needing assistive technologies but the offer's available to anyone willing):
Accessibility at Microsoft

 

[Andy Ful]

...
I will say that from what those in the know have told me, a stepping up of how the new Win10 will handle credential management will totally suppress the actions of this malware.
...
.

Very impressing example of privilege escalation on SUA, even when not working on new Windows 10.
Thanks for sharing.

 

[EASTER]

Very worthy demo indeed.

Is that same procedure to elevate on a Windows 7 system equally effective for Windows 8.1?

Seems I am one of a very few who is been big on Windows 8. FWIW went straight from XP to 8 (skipped 7 entirely)

I assume the end result would turn out the same. Doubt there was much if any additions in the way of prevention against it which would be any different than the video.

I may have to run this same test on a snapshot just to ease the curiosity.

 

[Andy Ful]

...
I may have to run this same test on a snapshot just to ease the curiosity.
...

The simplest method to silently elevate malware on SUA is stealing the administrator's credentials from the cache. So, some system hardening will be necessary:
; Default value CachedLogonsCount = 10 must be changed to 0 (restart the system).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"CachedLogonsCount"="0"

Edit.
SUA is pretty safe when used with 'no elevate' UAC setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
"ConsentPromptBehaviorUser"=dword:00000000

With this setting, nothing started as standard user can elevate on SUA. All administrative work must be done on different (administrator) account.

 

[Daniel Keller]

Thank you very much for the Video. Great as usual. And thanks to Andy and CS for the background information as well!

 

[AtlBo]

The simplest method to silently elevate malware on SUA is stealing the administrator's credentials from the cache. So, some system hardening will be necessary:

@Andy Ful. Is there a good reason why logon information is cached? I didn't know this is true if I understand correctly.

SUA is pretty safe when used with 'no elevate' UAC setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
"ConsentPromptBehaviorUser"=dword:00000000

Is this a blanket no UAC prompts just blocks policy? That would be really extreme but I guess it could work in some workplace environments.

 

[Andy Ful]

@Andy Ful. Is there a good reason why logon information is cached? I didn't know this is true if I understand correctly.

It may be convenient when connected to Enterprise network, but I am not a specialist in this area.

Is this a blanket no UAC prompts just blocks policy? That would be really extreme but I guess it could work in some workplace environments.

No UAC alert, just information that execution has been blocked by administrator. This is the most secure SUA, but if you read the articles from my previous post, even such SUA can be bypassed in theory (not seen in the wild).
I think, that NotPetya from @cruelsister video, could be stopped on such secured SUA - if it is stealing administrator credentials to elevate.

 

[ParaXY]

The simplest method to silently elevate malware on SUA is stealing the administrator's credentials from the cache. So, some system hardening will be necessary:
; Default value CachedLogonsCount = 10 must be changed to 0 (restart the system).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"CachedLogonsCount"="0"

Edit.
SUA is pretty safe when used with 'no elevate' UAC setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
"ConsentPromptBehaviorUser"=dword:00000000

With this setting, nothing started as standard user can elevate on SUA. All administrative work must be done on different (administrator) account.

Thanks for these registry tweaks!

I have disabled cached logons since my machine isn't a member of a domain and I only use local accounts to login.

I am assuming if you set ConsentPromptBehaviorUser to zero then UAC stops working altogether and then the only option to do anything that requires admin credentials is to logoff and back on again with an admin account?

 

[Andy Ful]

Thanks for these registry tweaks!

I have disabled cached logons since my machine isn't a member of a domain and I only use local accounts to login.

I am assuming if you set ConsentPromptBehaviorUser to zero then UAC stops working altogether and then the only option to do anything that requires admin credentials is to logoff and back on again with an admin account?

UAC still works, but in a different way: no UAC alert, and no possibility to elevate processes started as standard user. If the malware is started by the user or it exploited an application ran as standard user, then the malware cannot elevate on such protected SUA.
This is not the same, as no possibility to run processes with higher rights. Some processes, like many scheduled system tasks, do not require elevation to start with higher rights - they start from built-in 'NT Authority\System' account.
If you happen to be infected via kernel exploit, then the malware is installed with system rights (no elevation), and SUA cannot save you.
It is true, that users have to log on as administrator, to execute their applications via 'Run as administrator' from Explorer context menu, or when performing software installations and application updates. With default UAC settings, those tasks require admin credentials on SUA.
Look also, at an Example in my thread :
User Account like a Castle

Edit.
One can bypass 'no elevation' SUA using tools that can log on as administrator (for example runas Microsoft tool). So, additional system hardening is necessary to protect administrator credentials:
; Default value CachedLogonsCount = 10 must be changed to 0 (restart the system).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"CachedLogonsCount"="0"