User Account like a Castle

[Andy Ful]

What is User Account with UAC? It is like a castle.
Is the castle a security? It was in the medieval ages.
What is Standard User Account (SUA) with UAC? It is a castle in the medieval ages.
What is Administrator Account (AA) with UAC? What a stupid question. It is a castle in the 21st century!

Why AA with UAC is not a security?
1. Microsoft says, that UAC is not a security, but only a security component.
2. Microsoft says the truth, AA with UAC can be easily bypassed in many ways.

Remark.
Microsoft officially says that UAC is not a security. I understand this official statement, as a statement about default UAC usage, which is mostly AA with UAC.

Example (works only in Windows 8.1+).
Run command prompt on AA as standard user and copy/execute the below commands:
reg add HKCU\Environment /v windir /d "cmd /K reg delete hkcu\Environment /v windir /f && REM" /f
schtasks /Run /TN \Microsoft\Windows\DiskCleanup\SilentCleanup /I
reg delete hkcu\Environment /v windir /f
echo "Finished"

You can see the second command prompt window, running as administrator without UAC prompt!
You can repeat this on SUA, and you will see that the second command prompt will be run as standard user!

Can you make UAC more secure on AA? Yes.
1. You can choose 'Always notify' UAC setting.
2. You can use hidden UAC setting to elevate only executables that are signed and validated:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ValidateAdminCodeSignatures"=dword:00000001

But, even those secure settings will not prevent some UAC bypasses like from our Example.
Those baypasses can be blocked when using some other methods like Software Restriction Policies, whitelisting, blocking some system executables (see Excubits Bouncer blacklist). For example, blocking 'reg.exe' will stop the bypass from our Example.

Let's come back to medieval ages.
Why SUA (with UAC as an integral security component) is a security boundary?
1. It is recommended by Microsoft.
2. It is a security boundary from the administrator standpoint (user does not know the administrator password).
3. It is a security boundary, when preventing malware infections. Over 80% 0-day malware samples (including exploits) fail on SUA.

Can you make SUA even more secure? Yes.
You can use the same hardening settings as on AA, or disable elevation of privilege as a standard user, by the reg tweak:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorUser"=dword:00000000 ---> no elevation on SUA
"ConsentPromptBehaviorUser"=dword:00000001 ---> prompt for administrator credentials on SUA

See also the excelent articles about user accounts & UAC:
Tyranid's Lair: Reading Your Way Around UAC (Part 1)
Tyranid's Lair: Reading Your Way Around UAC (Part 2)
Tyranid's Lair: Reading Your Way Around UAC (Part 3)

 

[Andy Ful]

Something is wrong with my thread. I cannot post the full text because of an error. Please do not reply because 75% of text should be still added! The original text has some examples of commands, and this is probably the issue.

Edit
It is OK now. I had to add and next edit the commands in parts.

 

[Daniel Keller]

Thank you very much for this post. It is very educating, as usual!

 

[Andy Ful]

Thanks for reading it, and the kind comment.
This thread may be controversial for some forum members.

 

[Windows_Security]

@Andy Ful

I know a hardening tool to upgrade the security of Windows : GitHub - AndyFul/Hard_Configurator: GUI to Manage Software Restriction Policies and harden Windows Home OS

Keep up the good work mate

 

[Andy Ful]

Yes, I know it, too.

 

[Andy Ful]

I did not notice, that I made a terrible mistake.
The right registry values should be as follows:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorUser"=dword:00000000 --> no elevation on SUA
"ConsentPromptBehaviorUser"=dword:00000001 ---> prompt for administrator credentials on SUA

I have a question to the MalwareTips forum Staff: Can I edit my first post to avoid misguiding the readers?

 

[SHvFl]

I did not notice, that I made a terrible mistake.
The right registry values should be as follows:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorUser"=dword:00000000 --> no elevation on SUA
"ConsentPromptBehaviorUser"=dword:00000001 ---> prompt for administrator credentials on SUA

I have a question to the MalwareTips forum Staff: Can I edit my first post to avoid misguiding the readers?

Either annoy a few staff members this way @Umbra @Jack @BoraMurdar or report the post with what you want changed so they can do it when they check reports. I guess i did the annoying part but you can do the report method also if you wish.

Btw if i use uac hardening #2 that you mentioned with uac at max level will MS stuff auto elevate like with uac normal level but without the security risk that comes with uac default level?

 

[Andy Ful]

Thanks for the correction to the MalwareTips Staff.

 

[Andy Ful]

Either annoy a few staff members this way @Umbra @Jack @BoraMurdar or report the post with what you want changed so they can do it when they check reports. I guess i did the annoying part but you can do the report method also if you wish.

Btw if i use uac hardening #2 that you mentioned with uac at max level will MS stuff auto elevate like with uac normal level but without the security risk that comes with uac default level?

Thanks for the help.
If you meant the below hardening:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ValidateAdminCodeSignatures"=dword:00000001
then it is safe when considering actual MS stuff used by Windows system. But, I noticed that older versions of Microsoft not digitally signed executables, cannot be elevated with this hardening. For example the actual wscript.exe can be elevated, but wscript.exe from the older version cannot.

 

[brambedkar59]

Wow, you almost described the UAC & SUA in layman's terms. Nice 'Castle' analogy. Thanks for the good read.

 

[Andy Ful]

The one important question should be asked, too.
Is there a way to execute applications with an elevation on 'SUA with no elevation tweak'?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorUser"=dword:00000000 ---> no elevation on SUA

If the execution is performed directly from SUA, then maybe it is possible, but I do not not how. If someone knows, please post the solution here.
Yet, there is a known way to bypass no elevation tweak using programs, that can log on as administrator. For example, one can execute runas (Microsoft commandline tool) from SUA, log on as administrator using administrator credentials, and run (from Administrator Account) any application that requires elevation.

 

[Andy Ful]

One can harden the system, using additional credentials protection:
; Default value CachedLogonsCount = 10 must be changed to 0 (restart the system).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"CachedLogonsCount"="0"

 

[Andy Ful]

The last question (maybe). How is it possible, that system scheduled tasks and Windows Updates can work, when the user is logged on 'no elevation SUA'?
The answer is very simple. They do not use SUA, at all. For example, many scheduled tasks use Windows built-in 'NT\AUTHORITY\SYSTEM' account. So, it is also possible to create by the user, some scheduled tasks started as administrator. Those tasks may operate in the background (with administrative rights), when the user is logged on 'no elevation SUA'. Some applications (like Google Chrome) can use scheduled tasks to autoupdate with higher rights, and this works too, on 'no elevation SUA'.

 

[Andy Ful]

Some words about the CachedLogonsCount=0 setting:
1. It is related to passwords in Active Directory Domains (AD Domains).
2. The computer with Windows Home can be connected to AD Domain, so it can use folders, files, applications, and printers located anywhere on the network.
3. The computer with Windows Pro (Ultimate) can be joined to AD Domain, so can be centrally managed using Group Policies and Active Directory.

In home networks, using the AD Domain is an unusual solution. The standard Home networks use HomeGroup to share files and printers.

 

[Andy Ful]

Recently, I tested Mimikatz. This is a well known hack-tool, often used for passwords harvesting. It seems, that most Mimikatz modules require administrative rights, so they will fail on SUA. One of those modules is Sekurlsa, that can extract passwords, keys, pin codes, tickets from the memory of LSASS. There is not well known, hardening reg tweak, for Windows 7 and Windows 8.0, that prevents the "clear-text" (reversibly encrypted plaintext) passwords from being placed in LSASS memory:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest]
"UseLogonCredential"=dword:00000000
The above works only with hotfix KB2871997 (Microsoft Security Advisory 2871997).
From Windows 8.1 this tweak is not necessary, because such "clear-text" passwords are not stored in memory. But, the simple registry modification: UseLogonCredential = 1, can be made by malware to force "clear-text" passwords to be stored in memory again (also in Windows 8.1 and Windows 10).

 

[Andy Ful]

Tested on Windows 8 32-bit in a virtual machine (one default admin account with password).
Installed hotfix KB2871997. Mimikatz commands:
privilege::debug
sekurlsa::logonpasswords

Without the reg tweak, Mimikatz showed my log-on password to admin account, under the wdigest position in Mimikatz console. After applying the reg tweak and logging-off/logging-on, Mimikatz showed the last log-on session with a (null) admin password under the wdigest position, and the previous log-on session with a visible admin password. So, Windows stopped writing "clear-text" log-on paswwords to memory, but did not clear the previous sessions from memory (system restart required).

 

[TairikuOkami]

I am just dropping in to say thank you for "ValidateAdminCodeSignatures" and the rest.
I did not like it at first, since many exe do not work, but I have found a way around it using bat.

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "ValidateAdminCodeSignatures" /t REG_DWORD /d "0" /f
start "" "E:\Software\Temp\Soft\Rapr.exe"
start "" "E:\Software\Temp\Soft\UpdateTime.exe"
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "ValidateAdminCodeSignatures" /t REG_DWORD /d "1" /f

 

[Andy Ful]

It is a good and practical solution.
Yet, some things should be remembered:

1. When one of the applications, started in a batch, will hang the system, it will restart with ValidateAdminCodeSignatures = 0.
2. The user cannot block execution of 'reg.exe'.
3. The ValidateAdminCodeSignatures setting is especially strong on SUA. When using the local Administrator Account, every UAC bypass will also bypass this setting, so additional security is welcome, for example default deny solution.

 

[Andy Ful]

I am just dropping in to say thank you for "ValidateAdminCodeSignatures" and the rest.
...

The first notion about this reg tweak, I found in some of @Windows_Security (or @Kees1958) posts on Wilderssecurity forum, but it has a long story, back to 2006 year:
[MS-GPSB]: User Account Control