Back when I was pen testing with the wonderful PowerView, I was using it to pull user information from Active Directory. At the time I was more interested in gathering group membership and then using that info to hop around a network. Anyway, AD contains sensitive data about employees, some of which really should not be available to everyone in the organization. In fact, there is an equivalent to the “everyone” problem in Windows file systems for Active Directory that can also be exploited by insiders and outsiders alike.
But before we explain the privacy issues and ways to mitigate, let’s take a dive into the data found in AD.
Get the Free Pentesting Active
Directory Environments e-book
Active Directory is Facebook for the corporate world
But where you’ve friended everyone! Maybe you’re not learning about your coworkers’ favorite movies, books, and restaurants, but AD does contain sensitive contact data and other fields that can be exploited by hackers and even non-tech savvy insiders.
Sys admins are, of course, familiar with the screenshot below. It’s the Active Directory Users and Computers (ADUC) interface where they set up and edit user information and assign users to appropriate groups.
AD contains employee name, address and phone number fields, and so it is like a phone directory. But there’s so much more! In the other tabs, there’s also email and web addresses, employee direct reports, and descriptive notes.
Does everyone in the organization need to see this information, especially in the age of OSINT surveillance where every extra detail makes finding additional background even easier?
Of course, not! The problem is magnified when your corporate executives are exposed this way.
PowerView for everyone
This is where PowerView comes into play. It provides a very cozy PowerShell interface to the underlying (and messy) Win32 functions that access AD. In short: it makes getting AD fields as easy as typing in a very short cmdlet.
Let’s take the example of dumping info on my favorite employee, Cruella Deville, who’s a C-level. It’s a matter of using PowerView’s get-NetUser cmldlet:
It is not a major challenge to install PowerView — check out its github page! And more importantly you don’t need elevated privileges to run many of the PowerView commands, such as get-NetUser. So a motivated but not very technical employee can start poking around AD with little effort.
You can see from the above screenshot that an insider can quickly learn a lot about Cruella. If you noticed there’s revealing information in the Info field about personal habits and passwords, then give yourself an Inside Out Security blog CPE credit!
This is not a theoretical possibility. In chatting with pen testers, I’ve learned that they do in fact look at AD specifically for plaintext passwords, and often they are — unfortunately — successful. They know that companies are careless when it comes to AD information, and generally not aware of the next topic, AD permissions.
Active Directory has its own ACLs
Here’s the big “take-away” from this post: the AD Users and Computers interface does have a way to set permissions on AD objects. There are ACLs, and admins can assign or deny access.
If you’re playing along at home, you’ll need to click on “Advanced” under ADUC View menus, and then when you pop a user, you’ll see the Security tab, which is where you set the ACLs.
In my scenario with Cruella, I didn’t want everyone — Authenticated Users — to be able to see her private information, so I denied them read access :
And now an ordinary user would see this if they tried PowerView’s Get-NetUser:
I was able to remove the obviously exploitable information from prying eyes. To keep it within “the family”, I set up another ACL to allow members of the VIP group — Cruella and her other follow C-levels — to access this sensitive data. In other words, I implemented role-based AD permissions, thereby making it unavailable to most employees, including insiders who might become threats.
You’re asking, no doubt, can I set ACLs on AD fields on a group basis to save having to separately go into each member of the VIP group?
And the answer, as far as I can tell, is no! It needs to be done programmatically. Sigh. If I find a good script used by admins (or create one), I’ll share in another post.
However, you can make group membership invisible to snoopy users by setting the ACL in an AD group object. That does help in terms of privacy and security.
In my now epic pen testing series, I showed how it was possible to jump around a system by exploring group memberships using PowerViews’ Get-NetGroupMember. In my scenario, I restricted read access to VIP group membership. You see before and after effect this change had:
I was able to hide Cruella and Monty Burns membership in the VIP group, making it harder for hackers and insiders to snoop around the system.
Let’s call it a day!
This post was meant to force you to look more closely at your AD fields and the permissions associated with them. I hope this got you motivated. AD is a great resource, but think how you’d want to share sensitive contact and personal information, particularly from high-level executives and managers in critical areas.
