shmu26

Level 83
Verified
Trusted
Content Creator
BeyondTrust Research Discovers that 81 Percent of Critical Microsoft Vulnerabilities Mitigated by Removing Admin Rights
April 24, 2019
BeyondTrust Research Discovers that 81 Percent of Critical Microsoft Vulnerabilities Mitigated by Removing Admin Rights
BeyondTrust, the worldwide leader in Privileged Access Management, today announced the release of its Microsoft Vulnerabilities Report. The research provides the latest insight into security vulnerabilities facing organisations today, as well as a five-year trends analysis to better equip organisations to increase their IT security posture and keep networks and systems safe.

Further analysis indicates that, over the last five years, nearly 88 percent of all Critical Vulnerabilities published by Microsoft could have been mitigated by security teams removing admin rights from users.
"While organisations need to continue to focus on the security basics, the ability to remove admin rights and control applications is no longer difficult to achieve, and least privilege should be considered as part of a proactive security strategy."

The full Microsoft Vulnerabilities Report for 2018 can be downloaded here: Microsoft Vulnerability Report for 2019 | BeyondTrust
 

Nightwalker

Level 17
Verified
Content Creator

Andy Ful

Level 49
Verified
Trusted
Content Creator
Using SUA is not the same as removing Admin Rights, especially for casual users. The second can be done on SUA when the user does not know the Admin password or applying a special UAC setting (by policy or reg tweak).
Anyway, in many cases just using SUA is much safer, because the elevated processes cannot run on SUA, so they do not share the same account as processes running on SUA. For example, the malware cannot use exploits based on auto-elevation of some Microsoft binaries on SUA. Also, many malware will not ask for elevation but will fail to run.
 
Last edited:

bribon77

Level 29
Verified
With the UAC to the maximum and the administrator password, in SUA it seems to me that I am in Linux.
He asks me for the password to execute and I like it because I'm not going to give my password to execute something I do not know I like SUA.:giggle:
 

shmu26

Level 83
Verified
Trusted
Content Creator
There is no need to keep using complicated security setups; SUA + antivirus + chromium browser with an adblocker is always a simple, light and yet reliable security combo.
In addition, it is good to harden the system a little. For instance, by setting Powershell to constrained language. And a few good firewall rules, such as the ones applied by NVT SysHardener.
 

plat1098

Level 10
Verified
I enabled "Drop Rights" in Sandboxie's Default Box since I don't intend to be going back to a Standard User Account because I found it too restrictive in the past. Is this a sop or a tiny nod in the right direction, shmu26, and/or anyone? (I can't doublecheck and research on Sbie site right now b/c it's down. :mad:). I'd appreciate this info. :emoji_pray:
 

shmu26

Level 83
Verified
Trusted
Content Creator
I enabled "Drop Rights" in Sandboxie's Default Box since I don't intend to be going back to a Standard User Account because I found it too restrictive in the past. Is this a sop or a tiny nod in the right direction, shmu26, and/or anyone? (I can't doublecheck and research on Sbie site right now b/c it's down. :mad:). I'd appreciate this info. :emoji_pray:
It's a good tweak for whatever you run inside the sandbox. You still face the risk of executables disguised as simple media files, and of weaponized docs, both of which you might not run inside the sandbox.
 

yarr

Level 2
How to I remove administrator account from the login screen? I think I may have went about changing to standard incorrectly. I used ”net user administrator /active:yes" then "net user administrator 'password' " but now when I use "net user administrator /active:no" to hide the account from login screen the admin prompt that usually has a box to enter a password no longer shows an entry box. I swear I've been able to do this in the passed so I think maybe I scuffed something up along the way.

What are your thoughts?
Did I make a mistake in one of the commands? I'm sure there has to be a simpler way to do this as well but if there is no way to I suppose I don't mind just re-enabling and actually switching to the administrator user account every now and then
 
Last edited:

Windows_Security

Level 23
Verified
Trusted
Content Creator
In the past BeyondTrust offered a demo desktop version of their managed solution. The demo kept working without problems. It really was like sudo for windows only with much more granular options.

Most old nuisance of installing software in another windows profile (when you run as admin), can be overcome to deny per user installations. I have forgotten which registry setting this was. In XP a lot of software was installed for ' just this user', so people ran in the risk that the settings and tweaks you applied only applied to the user which had installed the software (the admin). When the basic user launched that program all settings were on default. When some of those tweaks required admin priveledge you ran in to catch 20-20 situation. But that was before Vista, most software behaves well (installing by default for all users).
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
Chrome and FF browsers can update even when using just a SUA account.... so can malware bypassing it if it's written as such
If I correctly remember Chrome uses the Task Scheduler. The special scheduled task is created when you install Chrome, and this requires Admin rights. Every update starts as an elevated process and it is not running on SUA. This is true also for most Windows system tasks. If you are infected on SUA, then the malware starts with standard rights - this is a big difference.

Edit.
Almost all UAC bypasses rely on the fact that the malware and elevated processes run on the same account - this is the case on Admin account. When you use SUA and do not use Admin password, then the malware cannot steal the admin privileges, because the elevated processes run on another account and are invisible to the malware.
On Admin account UAC tries to isolate elevated processes from not elevated (User Interface Privilege Isolation), but it is impossible to do it right by design, when both elevated and unelevated processes run on the same account.(y)
 
Last edited:

Windows_Security

Level 23
Verified
Trusted
Content Creator
Malware should normally not be able to bypass this update mechanism with elevated tasks. The elevated task was created when admin installed the software (Chrome in this case). Since lower rights objects can not infect higher rights objects, these elevated tasks can't be misused by (un-elevated) medium level Chrome integrity rights processes. With UAC soft border malware could trigger an UAC elevation request when it would be able to break out of LOW-UNTRUSTED-APPCONTAINER sandbox. With SUA this is a hard border, requiring admin to log-in,, so very unlikely to succeed.
 

Local Host

Level 19
Verified
If I correctly remember Chrome uses the Task Scheduler. The special scheduled task is created when you install Chrome, and this requires Admin rights. Every update starts as an elevated process and it is not running on SUA. This is true also for most Windows system tasks. If you are infected on SUA, then the malware starts with standard rights - this is a big difference.

Edit.
Almost all UAC bypasses rely on the fact that the malware and elevated processes run on the same account - this is the case on Admin account. When you use SUA and do not use Admin password, then the malware cannot steal the admin privileges, because the elevated processes run on another account and are invisible to the malware.
On Admin account UAC tries to isolate elevated processes from not elevated (User Interface Privilege Isolation), but it is impossible to do it right by design, when both elevated and unelevated processes run on the same account.(y)
Both browsers are in the user APPDATA anyway, so it doesn't need ADMIN rights.
 
Last edited:

Andy Ful

Level 49
Verified
Trusted
Content Creator
Both browsers are in the user APPDATA anyway, so it doesn't need ADMIN rights.
Google Chrome, Chromium Edge Dev, and Firefox (stable versions) are installed by default in 'C:\Program Files'. All update with Admin rights via scheduled tasks or services.
Some Chromium-based web browsers (like Chromium Edge Canary, Opera, Vivaldi) can install by default in the %Userprofile%. Opera updates via scheduled task but the task does not run with highest privileges.
 
Last edited:

Spawn

Administrator
Verified
Staff member
Has anyone tried to run an Installed Application as "Run as a different user" while being logged in your Admin account? What are the Pro's and Con's, or any Side affects of this action?

Shift + Right-click Application (shortcut) > Run as a different user

For example; if the different user is a Standard user account.
212949
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
Has anyone tried to run an Installed Application as "Run as a different user" while being logged in your Admin account? What are the Pro's and Con's, or any Side affects of this action?

Shift + Right-click Application (shortcut) > Run as a different user

For example; if the different user is a Standard user account.
View attachment 212949
When I tested it two years ago with Mimikatz, the password was stored as a plain text. So, it can make sense to me only when that account is highly restricted (malware trap).