Здравствуйте!
In this post, we will look at the theory behind the third and final way to escalate privilege in Active Directory which involves finding holes in delegated access rights grants, and then using them to escalate privilege by performing one or more Active Directory password resets.
(In next post, we will see how to use this method to easily escalate privilege in Active Directory, from a Delegated Admin to Domain Admin, from Domain Admin to Enterprise Admin, and from basic domain user account to Domain/Enterprise Admin.
Theory Behind Using Delegated Access Rights to Escalate Privilege in Active Directory
It is helpful to understand the theory behind this way of escalating privilege in Active Directory because the ability to find holes in delegated access rights in Active Directory is useful not only to escalate privilege but also to understand how an attacker could potentially compromise other things as well, such as security groups, computer accounts, OUs and of course user accounts.
The concept is simple -
In most Active Directory networks, Active Directory Admins (e.g. Enterprise Admins, Domain Admins etc.) delegate at least some level of administrative access to other admins, and this delegation is done in Active Directory. For example, account management, group management, password resets, and audit functions are the most common ones that are delegated.
In addition, many apps that use service accounts require access to Active Directory content, or the use of a domain security group, etc, so admins also end up provisioning access for these accounts.
The problem is that while it is fairly simple and straight-forward to delegate access rights in Active Directory, it is very cumbersome and complicated to find out who is delegated what access rights.
The thing is that most admins think finding out who has what permissions is the same as who has what delegated access. Turns out this is the mistake they make, and this is what opens the door for privilege escalation in Active Directory, because who has what delegated access depends on who has what effective permissions, not on who has what permissions, and the difference is huge.
I am not going to go into details of the difference, but if you are interested, you should learn more about Effective Permissions in Active Directory.
Anyway, the point is that the Active Directory permissions model is byzantine, and admins almost always provision access based on the mistaken concept above, so they end up introducing many holes in delegated rights, which can be easily exploited if one can find these holes.
An Example of Using Delegated Access Rights to Escalate Privilege in Active Directory
Maybe it is best to show you example. In this example we will see how someone could exploit delegated access rights in Active Directory to escalate privilege and easily become Domain Admin.
The Setup
In this simple example, there are three Active Directory administrative user accounts, that will be compromised –
There is also one attacker, who has regular (non-administrative) AD domain user account -
Attacker, Mission and Target
Note that even though Vladmir is contractor, like everyone else he has a domain user account that he uses to logon to the domain, for email, intranet access etc., so he also has full read access to the AD. He will make full use of this account and the read access it has to carry out this attack.
Finding a Security Privilege Escalation Path in Active Directory
Before the attacker (Vladmir) can carry out this attack, he must first find a privilege escalation path, then exploit it, which can be done as follows –
If this seems a little confusing, see example below, which should clarify this method.
A Real Example
In this way, he just escalated his privilege from a regular non-admin domain user account to an all-powerful Domain Admin account within minutes, using Microsoft provided tools, and just a little knowledge.
Analysis - The Easy and The Difficult
As we have seen, in order to find all this out, no special access was needed.
Anyone with a domain user account already has full read access to Active Directory. Also, logging on is easy, and resetting passwords is also very easy because Microsoft provides the tools via the Windows Server 2003 Administration Tools Pack or the Remote Server Administration Tools pack.
The only difficult part here is the analysis of all the security permissions in Active Directory ACLs to try and find out who can reset whose passwords. Once you have figured that out, the rest is simple.
Initially, it seems easy, but when you start analyzing an ACL, especially in the Active Directory Users and Computer Snap-In user interface, you realize very quickly that it not easy at all.
It is not easy mostly because you cannot look at a given single permission and assume that the access it grants is indeed allowed. There could be permissions that could be denying the same or more access to the same people, either directly or if you're unlucky, then via nested memberships.
For example, if you see the permission Allow HelpDesk Operators Reset Password in the ACL on a user account, you cannot assume that all members of this group can reset the password of this user account because there could be another permission such as Deny All Contractors All Extended Rights in the same ACL, and a member of the HelpDesk Operators group that is also a member of the All Contractors group would end up NOT having this ability on this account.
So, as we have seen, the most difficult part in this method of attack turns out to be calculating who has what effective permissions on Active Directory accounts. Once you have figured out how to find out what has what effective permissions in Active Directory, and you understand how Active Directory security permisions work, you can very quickly find many exploitation paths.
For instance, if you can find out which delegated admins have effective permissions to modify the Domain Admins group membership in Active Directory, you can reset that delegated admin's password and then add yourself to the Domain Admins group.
It is also interesting to note that when you analyze Active Directory ACLs no one will really know because you are only reading data and read access is almost never audited, so you can carry out the entire analysis at your pace, without anyone coming to know.
A Note on The Effective Permissions Tab in Active Directory
There is an Effective Permissions Tab in the Active Directory Users and Computers Snap-In, which can be accessed by clicking on Security, then on Advanced, then on Effective Permissions.
However, the problem with it is that is not reliable, so it is virtually useless, and as a result, you must do your own analysis to determine effective permissions on an object. Depending on it will only give you wrong results and waste time.
The other BIG problem with it is that you can only view it to analyze the effective permissions granted to a specific user, whose identity you have to enter, and that can make it very cumbersome if you have say even 100 admin accounts in the Active Directory.
A Helpful Active Directory Permissions Analysis Tool
[ Please read WARNING below before you use this advice. ]
As I mentioned earlier, it is very difficult to get a clear picture of Active Directory ACLs with the Active Directory Users and Computers Snap-In UI, so it becomes very difficult to analyze them for the purpose of determining effective permissions in Active Directory.
There is a free tool called LIZA that can be used to make this process little easier, because it makes it much easier to view the ACL, and delivers a partial break-down of all the permissions in an ACL -
In case you wish to try it or use, you can download it from here.
WARNING - Please note that as with any FREE tools, you may be taking a risk, and the tool itself could potentially be harmful, as its EULA clearly states that -
"This software is provided "as is" and use of the software is at your own risk."
I have heard that many companies are starting to add this tool to their black-list because like other hacking tools (e.g. lslsass.exe, runhash.exe) it could be used by a malicious insider to compromise security. Also, because it is FREE and unsupported, its use by the company's admins could very well potentially compromise the admin's accounts.
With that security warning out of the way, in addition to making AD ACL analysis easier, one more benefit is that it does not have an installation package, so you just download it and run, so it may be difficult for companies to prevent its installation.
I did find that there was no digital signature, and that the last update was done on January 16, 2011, which is almost 1.5 years old since no update, so it does not seem to be supported or updated.
SO, please be warned that YOU COULD LOSE YOUR JOB by using this tool in your corporate environment. That said, it can certainly help make it easy to analyze permissions, so whether you wish to use it is your decision to make. Purely theoretically speaking, it is a decent Active Directory Permissions Analysis Tool.
Conclusion
In this entry, we saw how holes in delegated access rights in Active Directory could be used to find privilege escalation paths that could then be exploited to gain powerful administrative access.
We also saw that once these paths are found, their exploitation is rather easy because it only involves password reset operations, for which Microsoft already provides the admin tools.
We learnt that it is quite painful to use Microsoft's ADUC UI to analyze permissions, and that its Effective Permissions Tab is unreliable, so it is best to use your own Active Directory Permission Analysis Tools to analyze Active Directory ACLs.
We also learnt that the process of analyzing Active Directory ACLs only involves read access and most organizations (99.9%) do not audit read access, so it is quite safe to analyze AD permissions, and because everyone has read access by default, this read-access to AD is not unauthorized.
Finally, we saw that escalation paths in Active Directory can be used to gain very high levels of administrative access, and this access could be used to gain access to everything protected by AD.
In my research, I have found that finding these paths however is quite painful and could take days, although with the recent availability of new tools that automate such analysis, it may now be possible to find such escalation paths in minutes, instead of days.
Next Post
In the next post, we will look at how to easily try and find privilege escalation paths in Active Directory using one such automated tool which I recently came across in my research.
In this post, we will look at the theory behind the third and final way to escalate privilege in Active Directory which involves finding holes in delegated access rights grants, and then using them to escalate privilege by performing one or more Active Directory password resets.
(In next post, we will see how to use this method to easily escalate privilege in Active Directory, from a Delegated Admin to Domain Admin, from Domain Admin to Enterprise Admin, and from basic domain user account to Domain/Enterprise Admin.
Theory Behind Using Delegated Access Rights to Escalate Privilege in Active Directory
It is helpful to understand the theory behind this way of escalating privilege in Active Directory because the ability to find holes in delegated access rights in Active Directory is useful not only to escalate privilege but also to understand how an attacker could potentially compromise other things as well, such as security groups, computer accounts, OUs and of course user accounts.
The concept is simple -
In most Active Directory networks, Active Directory Admins (e.g. Enterprise Admins, Domain Admins etc.) delegate at least some level of administrative access to other admins, and this delegation is done in Active Directory. For example, account management, group management, password resets, and audit functions are the most common ones that are delegated.
In addition, many apps that use service accounts require access to Active Directory content, or the use of a domain security group, etc, so admins also end up provisioning access for these accounts.
The problem is that while it is fairly simple and straight-forward to delegate access rights in Active Directory, it is very cumbersome and complicated to find out who is delegated what access rights.
The thing is that most admins think finding out who has what permissions is the same as who has what delegated access. Turns out this is the mistake they make, and this is what opens the door for privilege escalation in Active Directory, because who has what delegated access depends on who has what effective permissions, not on who has what permissions, and the difference is huge.
I am not going to go into details of the difference, but if you are interested, you should learn more about Effective Permissions in Active Directory.
Anyway, the point is that the Active Directory permissions model is byzantine, and admins almost always provision access based on the mistaken concept above, so they end up introducing many holes in delegated rights, which can be easily exploited if one can find these holes.
An Example of Using Delegated Access Rights to Escalate Privilege in Active Directory
Maybe it is best to show you example. In this example we will see how someone could exploit delegated access rights in Active Directory to escalate privilege and easily become Domain Admin.
The Setup
In this simple example, there are three Active Directory administrative user accounts, that will be compromised –
- Nikolai Khrushchev – Domain Admin account
- Boris Mikhailov – Delegated Admin with Account Management rights
- Natalya Zelyaeva – Delegated HelpDesk Operator with Password Reset Rights
There is also one attacker, who has regular (non-administrative) AD domain user account -
- Vladmir Neskey – He is on temporary contract as local IT admin at Leninsky location office
Attacker, Mission and Target
- Attacker: The attacker is Vladmir. He is not a company employee, but a temp contractor.
- Mission: Vladmir’s mission is to escalate privilege to that of a Domain Admin account.
- Target: The target is my domain user account (khrushchv\Nikolai) since I am Domain Admin
Note that even though Vladmir is contractor, like everyone else he has a domain user account that he uses to logon to the domain, for email, intranet access etc., so he also has full read access to the AD. He will make full use of this account and the read access it has to carry out this attack.
To carry out attack and ultimately compromise my account (a Domain Admin account) attacker Vladmir will first compromise Natalya Zelyaeva's account, then compromise Boris Mikhailov's account. To learn why and how, see below.
Before the attacker (Vladmir) can carry out this attack, he must first find a privilege escalation path, then exploit it, which can be done as follows –
- Enumerate list of all Domain Admin accounts from Active Directory.
- Analyze ACL of one or more Domain Admin accounts and make a list of all Delegated Admins who have sufficient rights to reset the password of the selected Domain Admin(s) accounts.
- Analyze ACL of all such Delegated Admins and make a list called Delegated Admins II of all admins who have sufficient rights to reset the password of one of these Delegated Admins.
- Find out which computer one of these individuals on the Delegated Admins II list logs on to.
- Compromise that computer using one of many ways known today, then place a simple VB script that would run when that individual logs on. This script will be programmed to reset the password of the Delegated Admin whose password this individual has sufficient rights to reset.
- When this individual logs on, the script will reset the Delegated Admin's password to the value you specified in the script, and do so as that individual, i.e. authorized to reset that password.
- Once that password has been reset, you login as that Delegated Admin using that password, and immediately proceed to reset the password of a Domain Admin.
- Then, login as the Domain Admin.
If this seems a little confusing, see example below, which should clarify this method.
A Real Example
With above theory in mind, here is a complete example that shows how to escalate privilege in Active Directory by exploiting delegated access rights in Active Directory –
- Vladmir, the attacker, now an insider (temp contractor) logs on using his domain user account
- He then downloads and installs the free Windows Server 2003 Administration Tools Pack, then launches the Active Directory Users and Computers Snap-In to view AD data.
- He also uses the Active Directory Users and Computers Snap-in to enumerate the membership of the Domain Admins group, which he can view because Authenticated Users have read access.
- He then picks one Domain Admin account, in this case, mine (Nikolai Khrushchev) and then proceeds to analyze the ACL on my account and determines that Account Operators has Full Control on my account.
- So he enumerates the membership of Account Operators group and finds that Boris Mikhailov is a member of this group, so he knows that Boris can reset my password.
- So, he then proceeds to analyze the ACL on Boris’s domain account, and determines that the HelpDesk Operators group has Reset Password rights on Boris’s domain account.
- So, next, he enumerates the membership of the HelpDesk Operators Group and finds that Natalya Zelyaeva is a member of the HelpDesk Operators group, so he now knows that Natalya has the rights needed to reset Boris's domain account's password.
- So using his default read access in Active Directory, he does a little more digging and finds that Natalya’s office is located just down the hall from his office in Leninsky Office, Cubicle N and that her computer is Natalya-Desktop.
- Luckily for him, he incidentally happens to be Local Desktop Admin at the Leninsky location so he already has admin access to Natalya’s desktop. (Even if he did not, there are several known ways to easily gain access to her machine with just having physical access, such as this.)
- So, he writes a little VB script, such as this, designed to reset Boris’s password to a value of his choice, such as P@ssw0rd1, and places it in Natalya’s logon script directory.
- Then he just waits for Natalya to login. As soon as she logs in, the script runs and immediately resets Boris’s password.
- The attacker Vladmir then immediately logs on using Boris’s account.
- He then instantly launches Active Directory Users and Computers Snap-in, and since he is now logged in as Boris, he proceeds to reset my (Domain Admin) account’s password to one of his choice, such as P@ssw0rd2.
- He then immediately logs off, and instantly logs on using my account and the new password he set, and now he is a Domain Admin!
In this way, he just escalated his privilege from a regular non-admin domain user account to an all-powerful Domain Admin account within minutes, using Microsoft provided tools, and just a little knowledge.
Analysis - The Easy and The Difficult
As we have seen, in order to find all this out, no special access was needed.
Anyone with a domain user account already has full read access to Active Directory. Also, logging on is easy, and resetting passwords is also very easy because Microsoft provides the tools via the Windows Server 2003 Administration Tools Pack or the Remote Server Administration Tools pack.
The only difficult part here is the analysis of all the security permissions in Active Directory ACLs to try and find out who can reset whose passwords. Once you have figured that out, the rest is simple.
Initially, it seems easy, but when you start analyzing an ACL, especially in the Active Directory Users and Computer Snap-In user interface, you realize very quickly that it not easy at all.
It is not easy mostly because you cannot look at a given single permission and assume that the access it grants is indeed allowed. There could be permissions that could be denying the same or more access to the same people, either directly or if you're unlucky, then via nested memberships.
For example, if you see the permission Allow HelpDesk Operators Reset Password in the ACL on a user account, you cannot assume that all members of this group can reset the password of this user account because there could be another permission such as Deny All Contractors All Extended Rights in the same ACL, and a member of the HelpDesk Operators group that is also a member of the All Contractors group would end up NOT having this ability on this account.
So, as we have seen, the most difficult part in this method of attack turns out to be calculating who has what effective permissions on Active Directory accounts. Once you have figured out how to find out what has what effective permissions in Active Directory, and you understand how Active Directory security permisions work, you can very quickly find many exploitation paths.
For instance, if you can find out which delegated admins have effective permissions to modify the Domain Admins group membership in Active Directory, you can reset that delegated admin's password and then add yourself to the Domain Admins group.
It is also interesting to note that when you analyze Active Directory ACLs no one will really know because you are only reading data and read access is almost never audited, so you can carry out the entire analysis at your pace, without anyone coming to know.
A Note on The Effective Permissions Tab in Active Directory
There is an Effective Permissions Tab in the Active Directory Users and Computers Snap-In, which can be accessed by clicking on Security, then on Advanced, then on Effective Permissions.
However, the problem with it is that is not reliable, so it is virtually useless, and as a result, you must do your own analysis to determine effective permissions on an object. Depending on it will only give you wrong results and waste time.
The other BIG problem with it is that you can only view it to analyze the effective permissions granted to a specific user, whose identity you have to enter, and that can make it very cumbersome if you have say even 100 admin accounts in the Active Directory.
A Helpful Active Directory Permissions Analysis Tool
[ Please read WARNING below before you use this advice. ]
As I mentioned earlier, it is very difficult to get a clear picture of Active Directory ACLs with the Active Directory Users and Computers Snap-In UI, so it becomes very difficult to analyze them for the purpose of determining effective permissions in Active Directory.
There is a free tool called LIZA that can be used to make this process little easier, because it makes it much easier to view the ACL, and delivers a partial break-down of all the permissions in an ACL -
In case you wish to try it or use, you can download it from here.
WARNING - Please note that as with any FREE tools, you may be taking a risk, and the tool itself could potentially be harmful, as its EULA clearly states that -
"This software is provided "as is" and use of the software is at your own risk."
I have heard that many companies are starting to add this tool to their black-list because like other hacking tools (e.g. lslsass.exe, runhash.exe) it could be used by a malicious insider to compromise security. Also, because it is FREE and unsupported, its use by the company's admins could very well potentially compromise the admin's accounts.
With that security warning out of the way, in addition to making AD ACL analysis easier, one more benefit is that it does not have an installation package, so you just download it and run, so it may be difficult for companies to prevent its installation.
I did find that there was no digital signature, and that the last update was done on January 16, 2011, which is almost 1.5 years old since no update, so it does not seem to be supported or updated.
SO, please be warned that YOU COULD LOSE YOUR JOB by using this tool in your corporate environment. That said, it can certainly help make it easy to analyze permissions, so whether you wish to use it is your decision to make. Purely theoretically speaking, it is a decent Active Directory Permissions Analysis Tool.
Conclusion
In this entry, we saw how holes in delegated access rights in Active Directory could be used to find privilege escalation paths that could then be exploited to gain powerful administrative access.
We also saw that once these paths are found, their exploitation is rather easy because it only involves password reset operations, for which Microsoft already provides the admin tools.
We learnt that it is quite painful to use Microsoft's ADUC UI to analyze permissions, and that its Effective Permissions Tab is unreliable, so it is best to use your own Active Directory Permission Analysis Tools to analyze Active Directory ACLs.
We also learnt that the process of analyzing Active Directory ACLs only involves read access and most organizations (99.9%) do not audit read access, so it is quite safe to analyze AD permissions, and because everyone has read access by default, this read-access to AD is not unauthorized.
Finally, we saw that escalation paths in Active Directory can be used to gain very high levels of administrative access, and this access could be used to gain access to everything protected by AD.
In my research, I have found that finding these paths however is quite painful and could take days, although with the recent availability of new tools that automate such analysis, it may now be possible to find such escalation paths in minutes, instead of days.
Next Post
In the next post, we will look at how to easily try and find privilege escalation paths in Active Directory using one such automated tool which I recently came across in my research.
Спасибо
I am the developper of the Active Directory ACL Analysis tool LIZA, and i just wanted to mentioned: LIZA is pure READ-ONLY, so an administrator cannot damage it's own directory by using it. There is no official support for this tool, however, you can report bugs or request new features on this website: http://community.ldapexplorer.com/. LIZA is still under development, but there was no need to change anything recently...... :)
ReplyDelete