Data privacy issue in Active Directory

Data privacy issue in Active Directory

I have been doing penetration testing using PowerView and used it to extract user information from Active Directory (hereinafter referred to as AD). At the time, my emphasis was on collecting security group membership information and then using that information to navigate the web. In any case, AD contains sensitive data about employees, some of which really shouldn't be available to everyone in the organization. In fact, in Windows file systems there is an equivalent "Everyone" problem, which can also be used by both internal and external attackers.

But before we talk about privacy issues and how to fix them, let's take a look at the data stored in AD.

Active Directory is corporate Facebook

But in this case, you've already made friends with everyone! You may not find out about your colleagues' favorite movies, books, and restaurants, but AD contains sensitive contacts.
data and other fields that can be used by hackers and even insiders without special technical skills.

System administrators are of course familiar with the screenshot below. This is the Active Directory Users and Computers (ADUC) interface where they set and edit user information and assign users to the appropriate groups.

Data privacy issue in Active Directory

AD contains fields for the employee's name, address, and phone number, so it's like a phone book. But there is so much more! The other tabs also have an email and web address, immediate supervisor, and notes.

Does everyone in the organization need to see this information, especially in an age of OSINTwhen every new detail makes finding more information even easier?

Of course not! The problem is exacerbated when the company's top management data is available to all employees.

PowerView for everyone

This is where PowerView comes into play. It provides a very convenient PowerShell interface to the underlying (and obfuscated) Win32 functions that access AD. In short:
this makes getting the AD fields as easy as typing a very short cmdlet.

Let's take the example of gathering information about an employee of Cruella Deville, who is one of the company's executives. To do this, use the PowerView get-NetUser cmdlet:

Data privacy issue in Active Directory

Installing PowerView is not a major problem - see for yourself on the page github. And more importantly, you don't need elevated privileges to run many PowerView commands like get-NetUser. This way, a motivated but not very tech-savvy employee can start poking around AD effortlessly.

It can be seen from the screenshot above that an insider can quickly learn a lot about Cruella. Did you also notice that the "info" field reveals information about the user's personal habits and password?

This is not a theoretical possibility. From dialogues with other pentesters I found out that they scan the AD for cleartext passwords, and often these attempts are unfortunately successful. They know that companies are sloppy with information in AD and are generally unaware of the next topic, AD permissions.

Active Directory has its own ACLs

The AD Users and Computers interface allows you to set permissions on AD objects. ACLs exist in AD, and administrators can assign or deny access through them. You need to click "Advanced" in the ADUC View menu and then when you open the user you will see the "Security" tab where you set the ACL.

In my Cruella scenario, I didn't want all Authenticated Users to see her personal information, so I denied them read access:

Data privacy issue in Active Directory

And now a normal user will see this if they try Get-NetUser in PowerView:

Data privacy issue in Active Directory

I managed to hide obviously useful information from prying eyes. To keep it accessible to relevant users, I created another ACL to allow members of the VIP group (Cruella and her other high-ranking colleagues) to access this sensitive data. In other words, I implemented role-based AD permissions, which made sensitive data inaccessible to most employees, including insiders.

However, you can make group membership invisible to users by setting the appropriate ACL on the group object in AD. This will help in terms of privacy and security.

In his series of epic pentests I showed you how you can navigate the system by inspecting group memberships using PowerViews Get-NetGroupMember. In my scenario, I have restricted read access to membership in a specific group. You can see the result of running the command before and after the changes:

Data privacy issue in Active Directory

I was able to hide the membership of Cruella and Monty Burns in the VIP group, which made it difficult for hackers and insiders to scout the infrastructure.

This post was meant to motivate you to take a closer look at the fields
AD and related permissions. AD is a great resource, but consider how you would
wanted to share confidential information and personal data, especially
when it comes to the first persons of your organization.  

Source: habr.com

Add a comment