What are the security risks to have admin rights for a user account on Windows 10?

Question

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}

Answer 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.

Answer 2

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.