One of the vulnerabilities we see most commonly in modern-day environments are users who have a too high degree of privileges on their regular domain accounts.
Two of the most common mistakes we often encounter are:
- Regular users who have local administrative privileges on their own device
- IT users who use their regular domain accounts to administer both clients and servers in the environment.
These mistakes usually occur because companies tend to assume that users need administrative access to their own device while this can often be avoided.
Even in the scenarios where they do need this level of access, more often than not they can perform these administrative actions using their regular user account, which in itself is very insecure.
The biggest risk of granting a user administrative privileges over one or more systems is the fact that should an attacker breach this user’s account, they will have the same amount of rights. And as we all know: it’s not about IF you’re going to get breached, but about WHEN you’re going to get breached.
With that in mind, a “defense in depth” strategy is in order, and one of the first orders of business is to ensure nobody has administrative access to their regular user account!
The doom scenario
Imagine: an unsuspecting user opens an e-mail containing a malicious attachment that infects their pc with malware.
If the user has local administrative access on their own machine, the malware nestles deep inside the system and waits for another (IT) user to connect to the user’s machine. To help speed things along, the malware shows the user a warning stating some dangerous error has occurred on their pc.
The user calls IT support and requests help with their problem, so a member of the IT staff authenticates towards the user’s pc to try and solve the problem.
At this point, the malware manages to use its administrative access to hijack the IT user’s domain account while they are logged into the compromised system.
If the IT admin has local administrative access to all systems in the network, the malware now infects these systems with a ransomware strain, halting production and requesting the company pay a hefty ransom fee to get their data back.
This may seem like a far-fetched story, but it really isn’t, and all of this could have been avoided by limiting the degree of access rights of both the regular and IT users in this example. Also consider what would happen if a member of the IT staff were to get phished in this scenario, as everyone is susceptible to a well-constructed phish.
The solution
The main solution for users having too much administrative access is by following the principles of least privilege and segregation of duty.
In essence, it comes down to the following:
- 3 different types of accounts need to exist at a minimum
- A regular user account, which is used to check e-mails and perform regular daily activities
- An administrative account that can only be used to administer a specific system
- A domain administrator account to manage the Windows domain
All of these accounts should be named and unique for each user (meaning “admin” is not a valid name, but “admin_john” could be), and users should only be given administrative accounts if they absolutely require it. The passwords for all of these accounts should be different from each other and should never be shared, with the passwords of administrative accounts being randomly generated and long and stored in a secure password manager or password vault. Domain administrative access should also be limited to 1 to 3 named accounts at the most for the entire environment, and these accounts should only be used to manage the domain controller itself (any other administrative tasks should always be performed with different admin accounts);
To ensure an even higher level of security, any account with administrative access can be managed by a PAM (Privileged Access Management) solution to ensure the account is disabled when not in use and to make sure that all usage of the administrative accounts can be easily logged and monitored for unexpected behavior.
Authenticating to this PAM solution (or, at a minimum, to a password manager) should always require multi-factor authentication to take place so the user knows when their admin account is being used and needs to approve it separately, this way an attacker cannot as easily elevate their privileges from the regular user account.
By applying these restrictions, if an account were to get compromised the attacker will never have instant administrative access, heavily limiting their capabilities post-initial access. Even if an IT user were to get compromised, the attacker or malware would not have administrative access to any device and would be much more limited in what they/it can do wrong at that stage.
