Active Directory Reconnoissance with User Permissions

Not a lot of people may know this, but even someone with only “Domain User” credentials can read a whole lot of information about Microsoft Active Directory from their personal machine without any sort of administrative credentials. The machine doesn’t have to belong to the domain in order to do this – all that’s needed is a valid domain user account with any level of domain access. This can be used to a malicious attacker’s (or malicious employee’s) advantage if they are attempting to glean account, password, or personal information stored in Active Directory.

Setting up a Test Environment

I would not recommend poking around a real environment where you lack permission to do so. Windows Server 2016 trials are freely downloadable from the Microsoft website, and a free tool like VirtualBox is a good way to set up a Server 2016 machine that you can mess with (and even break) with no repercussions.

I’ve set up a dummy AD environment on a freshly installed and patched Server 2016 build. I’ve spun up a Windows 10 VM that is not a member of the domain, but does have IP connectivity to the domain controller and is using the DC as its DNS server. I’ve downloaded a copy of ADExplorer, part of the PSTools suite from Microsoft’s own website. The tool is completely free, hasn’t been updated since 2012, but still works fine on a modern Server 2016 domain.

I’ve logged in to to the tool using my basic domain user account.

Exploring User Accounts

Immediately we can see that I’m able to view a lot about the Active Directory environment. I can see Organizational Units (OUs) and objects. Anyone who has managed Active Directory using ADUC before will be immediately familiar with this. It’s scary that I’m able to see this much information as a user.

Let’s expand the San Francisco OU and view its users. Here we have an account called Amy Kim. Under description we can see that Amy can’t be bothered to change her password like regular users, so she’s asked that it be set to not expire. An administrator, doing what the CEO tells him, good security practices be damned, has noted here that “Password Never Expires” should never be unchecked, probably to warn other admins.

We can also see a lot of personally identifiable information about her. This can include things like her address, extension (often times this isn’t public information for high level employees), cell phone number, etc. If the AD Schema has been extended, we may be able to see other things as well, but this is just a base 2016 install. Personal information like this could possibly be used in a spear phishing attack.

We can also see that next to memberOf, she’s a member of several groups including Corporate Users. I would imagine that users that are part of that group have some elevated privileges, so her or someone else in that group may be worthy targets. Let’s see what other groups there are.

Exploring AD Group Membership – Identifying Administrative Accounts

If we expand the Users OU (the default OU where Groups are stored), we can click on the Domain Admins group, and see that both the John Kathryn account as well as the default Administrator account are both members of this group. If someone had been crafty and attempted to change the default Administrator account name to something else, we could still see it here.

The John Kathryn account may have more information that might be valuable to us. Let’s look for that.

Let’s expand the New York OU and view its users. There’s John Kathryn. We can see that the description field lists him as the network administrator. We can also verify under the memberOf field that he is indeed a member of Domain Admins. Note that we can also see when his password was last set.

This information might not matter too much for a user who practices good security and is forced by policy to change their password frequently, but it can be valuable information to identify service accounts that might not have had passwords changed in years. These accounts are typically good ones to target, and having control of one means that we will be able to retain access likely for long periods of time without having to worry about a password being changed on us. Service accounts usually have a high level of access to the domain (often times full administrative access), so they are juicy targets.

In fact, let’s see if we can’t identify a service account.

Service Accounts and the “Notes” Field

It’s a very common practice for administrators to put notes in the “Notes” field of a user account or group within AD. This information can easily be read by someone with only user level credentials. I’ve seen things like “User has asked that the password for this account doesn’t expire,” “This is a service account, the password is XXXX. Do not change,” etc.

As we can see here, this account looks like an account used by a backup application. Often times there are a bunch of these accounts and they are rarely ever changed, since the password has to be synced between the software and AD. Accounts like this typically have weak passwords too, as someone will set it up with the thought of “I’ll just get this working quick right now and go back and make it secure later.” They typically never do.

Conclusion

This tool has been around a long time, and when I was in my Windows Administrator career window, I never saw much use in it. Everything that’s seen here could be viewed and manipulated by an administrator with native tools, so things like this never crossed my mind. When you start looking at things from a different perspective though, a tool like this makes sense in the eyes of someone who is prying in to things that they otherwise wouldn’t (and shouldn’t) have visibility in to.

I do plan to explore this too a lot more and see what other great information can be gleaned from it in this same scenario. I will post my findings in a future post.