3

I am considering the security risks to have a standard user added to the Administrators group on an enterprise Windows 10 machine that is dedicated to that user. This is related to security only, so breaking the OS of a wrong manipulation, installing unlicensed programs or similar administrative tasks is out of scope of my question.

The only one I found so far is that such rights allow for that user account to dump the authentication hash of someone having had interactively connected to that machine (via mimikatz for instance). This can be prevented via Credential Guard or other mesures limiting the use of wider admin accounts.

All the other risks I can think of are applicable to a normal user anyway:

  • execution of programs that will extract data (with the user rights - so data the user has access to anyway).
  • attempts to map the surroundings of the machine looking for lateral moves
  • persistence through scheduled tasks
  • communication to a C2

Are there other security concerns to be an administrator of one's machne as part of one's normal, everyday account?

EDIT: following up on a comment - I do assume that the user can be compromised. What I am trying to understand is what the fact that they are an administrator of their own machine changes in the risk landscape

Note: a similar question discussed the ability to add admin rights to users but I could not find anything related to additional risks beyond the ones a normal user introduces anyway (besides "best practices" and legal constraints which do not apply in my case).

There is of course an xkcd strip about that, which I add for completeness

WoJ
  • 8,957
  • 2
  • 32
  • 51
  • This is a well-known area of discussion that's been had for a couple of decades and I'm not sure that you've referenced the ideas mentioned in those long-standing discussions. The primary issue being that local admin rights allow administration of the machine. Any binary run by the account has admin rights. A drive-by infection, a malicious email attachment, a maliciously corrupted program could alter the OS... – schroeder Nov 06 '20 at 09:10
  • @schroeder: yes, I understand all this. The point I was trying to make is how the effects of such activities are different, in practical terms, from those of a normal user. Data can be exfiltrated, other machines attempted to be infected etc. The long term infection of the OS is something I cannot really quantify in terms of actual dangers (again - versus what an infected user could do). I am well aware that this is a long-standing discussion, I am trying to get some tangible elements. Please let me know how I could make the question clearer. – WoJ Nov 06 '20 at 09:25
  • A bit of a X-Y answer, but at work we resolve this by installing a non-domain-joined VM on that box (using Hyper-V) for the user. You can then put the VM on a different VLan, so it can't directly access the intranet. We have an FTP server in the DMZ for such VMs to exchange files with the corporate network. – billc.cn Nov 06 '20 at 15:02
  • First, security is not only confidentiality, but also availability and integrity. The more power users have, the most damage they can do by (willingly or not) changing protected data or breaking system related area. This is one reason for the least privilege princip. – Serge Ballesta Dec 06 '20 at 18:52

2 Answers2

1

Credential Guard does not protect against theft of domain cached credentials or the local SAM database containing password hashes of local users, because these things are stored on the hard drive. The latter is not a problem if you are using LAPS. The former is not a problem if all accounts are using secure passwords (or if you set the maximum number of cached credentials to zero, which may not be advisable depending on your requirements).

However, best practices are best practices for a reason. It's the principle of least of privileges and the concept of defense in depth that can prevent damage in case another vulnerability arises. New techniques could come to light, or a bypass against Credential Guard could be found in the future. After all, Mimikatz is just one exploit of the fundamental problem that whoever controls the computer also controls the users that are logged onto it. For example, I'm not sure if Credential Guard protects against token impersonation.

Volker
  • 1,243
  • 8
  • 12
  • *However, best practices are best practices for a reason* I absolutely do not want to be adversative here but I want to understand the "why" of these best practices (best practices come and go, user-oriented passwords being an example). Your example of bypassing CG and possibly dump the token of a previously connected admin is one. (I now highlighted the fact that the user is alone on the machine, the local admin in managed though LAPS) – WoJ Nov 06 '20 at 13:14
  • Well, the user may be compromised in a number of ways. You're right that if we assume that the user never gets compromised and always has the best intentions, then everybody can be admin without any risk. But seeing how many companies are hit by ransomware these days, this is assumption is false too often to not call this wishful thinking. – Volker Nov 06 '20 at 14:40
  • No, I absolutely do assume that the user can be compromised. My question is about what having admin right to his own machine changes, in practical terms (besides the point I mentioned in my question). – WoJ Nov 06 '20 at 15:26
1

Admin rights allows an attacker to capture details about the user's machine and account that are not normally available, such as stealing machine private keys (used for some domain authentication) or the user's own password (many users reuse passwords, so this might be valuable in situations where the user's login token or password hash are not useful). Local admins (including attackers who have compromised a user with local admin rights) can also override domain administrator controls and group policies, so any controls you have in place (such as Credential Guard, especially if not using the UEFI lock), audit logging, and so on could be disabled.

There are also some things you mentioned that a standard user can't actually do, but an admin could. For example, a standard user has limited ability to launch network attacks, whereas an administrator can use ARP spoofing, arbitrary ICMP packets, TCP and UDP packets that lie about their source, and so on. An admin also has many more, and stealthier, options for persistence.

CBHacking
  • 40,303
  • 3
  • 74
  • 98