Delegated Access - The Key to Privilege Escalation in Active Directory

Здравствуйте!

In this post, we will cover the concept of delegated access in Active Directory, which is the key to privilege escalation in Active Directory.

As we had seen in previous posts, all the critical components of security in a Microsoft Windows Server network are stored in the Active Directory -

1. Domain User Accounts + their passwords
2. Domain Security Groups + their memberships
3. Domain Computer Accounts + their security policies
4. Group Policies + their definitions

Now of course, in any environment with more than a few users, companies cannot have a small number of administrators manage all of these components.

It would not be possible for 10 admins to manage 10,000 accounts, computers and groups, so Active Directory lets administrators delegate responsibilities for various administrative tasks to other less powerful administrators.

For example, account creations and deletions, password resets and security group changes, can all be delegated to lesser powerful admins, such that these admins can only perform the tasks that are delegated to them and in the scope of the delegation.

The scope of a delegation is typically either a specific Active Directory object, or an Organizational Unit (OU) full of user and computer accounts, and security groups and other OUs, or it can even be the entire domain.

Active Directory offers a very powerful delegation ability wherein administrators can very precisely delegate who has what powers in what scope.

This is done by specifying complicated permissions on Active Directory objects. Permissions can be specified for an individual user, a group of users, or a group of groups, so that these admins can easily grant the access they want to grant.

Once granted, delegated administrators can easily perform the duties that they have been delegated. This is made possible by the permissions that are on the objects in the scope of the delegation.

NOW, the problem is that Active Directory's security mechanisms (i.e. types of permissions, group nestings, inheritance of permissions, permission effectiveness, Schema rules etc) are so complicated that while it is easy to precisely delegate access, it is almost impossible to find out who has been delegated what access, unless you have PhD in subject.

To add to problem, many admins have privileges to modify delegations at any time, and over time, they do so, often without informing each other, so this further complicates the delegations.

So basically there are many delegated admins who have many powers in the Active Directory, but no admin knows who actually has what powers. Because of this, almost always, people who should not have certain powers, have these powers, and this is what creates the opportunity for hackers and disgruntled insiders to elevate privilege in Active Directory.

An Example

Let me give one example -

Assume my comrade Dmitri is a Domain Admin, and that Sergei is a Level-II delegated admin, and that Natalya is just another ordinary user in the system with no admin access.

Also assume that Dmitri's account is in OU Admin Accounts, which is in OU Moscova, and that Sergei is member of Level-II Admins group and this group a member of Level I Admins, and Level I Admins group is delegated account management on Moscova OU.

Because of above delegations, there will be inherited security permission in Dmitri's account which will be like Allow Level-I Admins Special permission on User objects.

Now it will not be easily clear what is in the Special permission, but if you click and see, it will show All Extended Rights, which will mean also Reset Password.

Because of these permissions, and because of inheritance and nesting, Sergei actually has enough powers/privilege to reset Dmitri's account's password and immediately login as Dmitri, but but either Dmitri or Sergei or anyone looked at the permissions, this would not be clear.

But if someone knew how to look at these permissions in detail, then they could find out that Sergei could reset Domain Admin Dmitri's password. This is very valuable security intelligence, because it means that if you can compromise Sergei's account, then you can in 2 more minutes compromise Dmitri's account, and become a Domain Admin, in effect, elevating your privilege!

So, if Natalya knew even little about how to analyze Active Directory permissions, she could also find this out and use this intelligence to elevate privilege and compromise security.

Similarly, with right tools that can analyze Active Directory, any user with a domain account could very quickly start looking for such weaknesses and then misuse them to elevate privilege.

Of course, once you are Domain Admin, well, and you know what to do, the organization is in your back pocket.

In this manner, Natalya could exploit delegated access in Active Directory to easily compromise the Active Directory and get Domain Admin privileges.

Note that you only need to learn a little about Active Directory permissions to exploit delegated access in Active Directory, and there are many free tools like adfind, dsacls, ldp etc. that can be used to analyze Active Directory permissions.

So, as we have seen, delegated access rights in Active Directory are the key to privilege escalation in Active Directory, and present one of the easiest ways to compromise security.

In the next entry, we will look at how to use some tools to do some Active Directory analysis to find such weaknesses in an Active Directory

Спасибо

Nikolai.

Active Directory - The Heart of a Windows Server Network

Здравствуйте!

In this post, I will share with you why Active Directory is the heart of a Windows Server based network. Understanding this is critical to understanding why privilege escalation in Active Directory is so powerful.

We all know that there are just 3 basic things that help secure all the data in an environment -

1. Identity - Every user in the system is identified by a unique identity
2. Resource Authorization - Access to all resources is authorized based on group memberships
3. Host Management - The computers on which resources are stored need to be managed

Basically, every system needs way to identify its users, let them prove their identity with passwords, then protect the IT resources by letting admins configure who has what security permissions on them, and lastly to manage and protect the computers on which the IT resources are stored.

Of course, certain things like ability to have distributed authentication, authorization and auditing are also required, and exist to facilitate secure access for all users to all resources.

If you look at Active Directory simply, it is just one directory, and not of much interest because after all how interesting could a directory be? But if you look at Active Directory from angle that it contains all the 3 pieces requires to provide security in network, then it looks very important and in fact it is very important.

It is commonly known that all the user accounts are stored in Active Directory. In addition, the passwords of all these user accounts are also stored in the Active Directory. Furthermore, the management of these accounts is also delegated in Active Directory, meaning for example, that the information of who can reset the password of a user's account is also stored in Active Directory.

By similar token, all the security groups that are used to grant or deny some level of access to all files on file servers, databases on database servers and applications on application servers are also all defined, configured and managed in Active Directory. In particular, the membership of all such groups used across the network is stored in and controlled in Active Directory. Also, information about who can change the membership of these groups is also stored in Active Directory.

Also by similar token, all the policies that are used to protect all the computers in the network are also defined in and automatically pushed out from the Active Directory. Furthermore, data about who can change these policies and who can push them where is also stored in Active Directory.

So, from this angle, it is logical that Active Directory is the heart of a Windows Server based network. That is why lot of companies put in lots of resources to try and protect it as much as they can.

The interesting thing about Active Directory is that it lets powerful admins delegate specific operations (tasks) to specific delegated admins, thereby creating a hierarchy of power in the network.

This is very important for privilege escalation, because as we shall see in following posts, the ability to escalate privilege one by one in hierarchy starting from bottom and aiming for top is very valuable.

From the view of privilege escalation, Active Directory is a treasure box of information, because it is THE place where all the responsibilities for the management of all of these 3 things are delegated and controlled.

So if you are interested in learning more about how to escalate privilege in Windows networks, you should become familiar with Active Directory hierarchical and security model. Once you are familiar you can start experimenting yourself based on following posts on how to find and use privilege escalation opportunities to go from basic authenticated user to domain admin with just little effort.

In my next post, I will cover some details about Active Directory's storage and security model, to help you understand how to experiment with this concept in your test environment.

Спасибо