Coming from a primarily network security background, I’ve never really been too involved in the Windows/Active Directory side of things. Sure, I know bits and pieces, but given this is pretty key to most organisations, not as much as I’d like. So I’ve been on a bit of a quest recently to hit the books hard and improve my knowledge! You can’t adequately protect what you don’t really understand.

This post is part one of a few that aim to look at some of the common problems and exploitation methods associated within your typical Windows enterprise environment and some of the things you can do to resolve it.

A little history

Whilst things have started to change in more recent years, Active Directory is still pretty ubiquitous amongst enterprise networks. It is used to centrally manage users, computers and servers under an organisation’s administrative domain. In some cases these Active Directory environments have been around in some guise for decades! This in itself presents a challenge - sometimes improvements can be difficult to implement in these older environments. No one wants to be the person responsible for outages and other negative operational impacts either.

Whilst there have been numerous improvements to Active Directory and Windows security over the years, it is still relatively fair to say that Active Directory and the entities it manages won’t just be secure out of the box - you have to put some effort in. And Active Directory can be a bit of a minefield, with a million different knobs you can tune, support for legacy protocols and new features that are often misunderstood and can cause issues.

There are numerous problems and risks associated with an enterprise Active Directory deployment, but I am going to focus on a select few in this post to keep it short:

  • Privileged local users
  • Risky use of highly privileged accounts
  • Excessive privileged accounts

Unfortunately, combinations of these have a habit of coming together to make an attackers life much easier and have been seen in breaches time and time again.

Local administrative access

Ok, let’s start with local users on your workstations. Hopefully most users are logging into their workstations with a domain user account that is not a member of highly-privileged groups such as Domain/Enterprise Admin groups - good start right?! Yes, true. But are they a member of the local administrators group?

Whilst part of this local group, the user can effectively do whatever they like on their own machine. Install software, change security settings, delete critical files. This presents a number of different challenges in its own right without even throwing attackers into the mix, but the aspect I want to focus on for today is the ability to access local hashed credentials.

Whenever you interactively logon to an Active Directory machine, it stores a hash of your password in memory (either in the form of an NTLM hash or a Kerberos Ticket Granting Ticket - we’re not getting into that today!). This is required in order to implement single-sign-on behaviour so that you don’t spend your whole working day typing your credentials to access different domain resources. Whilst this “hash” or “ticket” may sound secure, they are functionally equivalent to a cleartext password as they can be used to carry attacks such as “pass the hash” and “pass the ticket” without knowing your actual password. This allows an attacker to impersonate you and potentially move laterally within your environment.

A compromised machine

If an attacker manages to successfully compromise your machine and you are logged in as a standard domain user (without local administrative rights), then the attackers lateral movement efforts are going to be hampered. The attacker may be able to view and make use of your own cached credentials through a number of techniques, which is obviously not great, but hopefully these are relatively limited in use and value. They shouldn’t be able to view other credentials as you’re not a local administrator. That is of course, as long as you’re not running your day-to-day work account as a Domain/Enterprise admin or another highly privileged account. If you are, then you’re in for a bad day - the attacker may have just gotten hold of your credentials and can probably do what they like in your organisation. DON’T DO THIS!

But let’s assume you’re not sending emails and watching cat videos with your Domain Admin account. Even as a non-Domain Admin you may still be a member of the local administrators group. If this is the case then the attacker may actually be able to view your cached credentials and any others on that machine - both cached in memory (more on why that is an issue shortly) and any locally configured users such as the built-in “Administrator” account.

Technically, it isn’t quite as clear-cut as I’ve made out. By default an account that is a member of the local administrators group runs with what is known as a “split-token” approach, whereby they run in a non-privileged mode most of the time and get prompted by User Access Control (UAC) if a process wants to elevate to admin level. You’ll have no doubt seen prompts like this over the years:

User Access Control

UAC goes some way to preventing an attacker from unknowingly elevating a user’s session to an administrative session, but it is far from perfect. Microsoft has stated over the years that they do not consider UAC to be a security boundary and you only need to Google “UAC bypass” to realise that there have been lots of way around this over the years. How many times would a UAC prompt have to be flashed at your average user before they just click “yes” to get rid of it? The best approach is still to not provide local administrator rights and/or separate accounts where they are really required for trusted users.

Back to what I was saying… let’s say the attacker has gotten around any UAC and is now running with an “admin” level token, so what? They can only damage your PC right? Well no, not quite. They can now view whatever they like. This includes your local SAM database which contains hashes of other local account passwords - local accounts such as the default “Administrator” account. This won’t be a huge issue though, because you’re definitely not re-using the same local administrator account across all your machines are you… oh you are… ah! Well now the attacker can move laterally with a pass-the-hash attack to other machines or look at cracking the hash and logging in interactively elsewhere.

Oh yeah, and remember what I said an administrator can view all hashes in memory… what else may be in there?

Privileged domain accounts

We now know why running your day-to-day account as a Domain/Enterprise admin is a horrendously bad idea (seriously if you are - go and think about changing this please), but what about if your administrators are using separate day-to-day and administrative accounts? Definitely an improvement, don’t get me wrong, but it really depends on what they are connecting to with those privileged accounts and how they are connecting. Remember that if you perform an interactive logon to a Windows box (such as sat at the keyboard or over RDP), then by default you’re going to end up having your credential hashes/tickets stored in memory to implement single-sign-on behaviour.

Let’s say your helpdesk admin, Karen, connects to Bob’s workstation over RDP to fix a problem he is having.

  1. Karen logs in with her Domain Admin account (which by default has local admin to all machines in the domain) fixes the problem, then disconnects.
  2. Bob then goes on to download “cat_pictures.jpg.exe” which turns out to actually be malware and his machine ends up compromised with a remote access trojan (RAT) - uuh ohh.
  3. Unfortunately (or fortunately for the attacker!) Bob is also part of the local Administrators group. As we know from the previous section this means that if the attacker can elevate their session to that tasty admin token then they can dump ALL credentials from memory…
  4. Oh look… a domain admin account! Game over.

Game Over

The problem here is that a high-privilege account logged on to a lower-privilege/higher-risk machine, credentials got cached and then stolen.

“But I’ve got AV/NGAV/EDR/whatever installed”

Excellent! Good endpoint security software is going to hopefully stop a lot of the above happening, particularly when it comes to commodity malware, but security should be a defence in depth approach - new attacks and vulnerabilities are discovered all the time. You shouldn’t rely solely on these products to minimise the risk involved in credential theft and excessive permission use.

Layering a solid approach to credential management on top of these solutions gives you the best chance of protecting your organisation.

“My admins need domain admin to do their job”

No they don’t. Seriously - the chances are they really don’t!

Yes, there are certain tasks that specifically require the use of an account that belongs to “Domain Admins”, but they are few and far between. Your Domain Admin group should be largely empty until an actual Domain Admin-level task needs performing, at which point an account should be temporarily added, the task performed and then the account removed from the group.

What I think tends to happen is that the Domain Admin group gets used as an easy/lazy way to grant administrators access to servers and/or workstations without the need to mess around with GPOs and without really thinking through the risks involved.

You’ve got to remember - members of Domain/Enterprise Admins are some of THE most highly-privileged accounts in your Active Directory - if any one of these gets popped you’re going to be in for a reeeeeally bad day! You need to minimise their use.

Even if you’re not adding users to local administrator groups and you’re not using your Domain Admin account as your day-to-day login, you still really want to be looking at highly-privileged Active Directory Groups such as Domain Admins, Enterprise Admins, Schema Admins, Administrators (plus others) and minimising their use.

Summary

I’ve talked a lot about problems in this post, and not much in the way of solutions! In subsequent posts I’m going to be looking at some of the built-in features you can use to start closing these gaps and talking about Microsoft’s tiered administrative model as an organisational approach to privilege separation.

Images by Gino Crescoli from Pixabay