The Security Risk Posed by a Security Privilege Escalation based Attack on Microsoft Active Directory

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

Comrades, in this post, I will briefly share with you the security risks posed by a successful Active Directory Privilege Escalation attack on an Active Directory based Windows deployment.

To understand the security risk associated with a malicious insider successfully launching an Active Directory Privilege Escalation attack it is best to ask one question -

      Q. What is the impact of the compromise of a Domain/Enterprise Admin account?

The answer to that question will give you the answer to the security risk associated with this attack.

Basically, if someone is able to successfully carry out an Active Directory Security Privilege Escalation based attack in your environment, in worst case scenario ...

Complete Systems Compromise / Data Center Security Breach

 

... all your organization's IT resources could be compromised, all your corporate identities stolen, all your data divulged, and your entire Microsoft Windows Server IT infrastructure, debilitated.


That's because, a Domain Admin has full-control over the entire system, and with the help of automation, could easily compromise the security of all domain-joined systems, all the data stored on them, all the identities in the Active Directory, all applications that rely on Active Directory, and all systems that rely on Kerberos for authentication and authorization. Of course, company-wide email, Intranet connectivity, Internet connectivity and access to data can also all be taken out.

This is a very serious security risk and its consequences can be catastrophic.

Спасибо

Active Directory Security Privilege Escalation By Exploitation of Delegated Access Rights/Grants in AD

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

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 –

1. Nikolai Khrushchev   –  Domain Admin account
2. Boris Mikhailov         –  Delegated Admin with Account Management rights
3. Natalya Zelyaeva       –  Delegated HelpDesk Operator with Password Reset Rights

There is also one attacker, who has regular (non-administrative) AD domain user account -

1. Vladmir Neskey – He is on temporary contract as local IT admin at Leninsky location office

Attacker, Mission and Target

1. Attacker: The attacker is Vladmir. He is not a company employee, but a temp contractor.
2. Mission: Vladmir’s mission is to escalate privilege to that of a Domain Admin account.
3. 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.
 

  

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 –

1. Enumerate list of all Domain Admin accounts from Active Directory.
2. 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.
3. 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.
4. Find out which computer one of these individuals on the Delegated Admins II list logs on to.
5. 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.
6. 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.
7. 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.
8. 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 –

 

1. Vladmir, the attacker, now an insider (temp contractor) logs on using his domain user account

2. 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.

3. 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.

4. 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. 

5. 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.

6. 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. 

7. 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.

8. 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. 

 

9. 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.)

10. 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.

11. Then he just waits for Natalya to login. As soon as she logs in, the script runs and immediately resets Boris’s password.

12. The attacker Vladmir then immediately logs on using Boris’s account.

 

  

13. 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.

14. 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.

 

Спасибо

Active Directory Security Privilege Escalation Using Impersonation with Password Hashes

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

In this post we will look at the second way to escalate privilege in Active Directory, which is easier than guessing a password to escalate privilege but more difficult than resetting a user's password to escalate privilege. (Resetting a domain/delegated admin's password to escalate privilege in Active Directory is the easiest way; more on that in the next post.)


Active Directory Security Privilege Escalation Using Hash Impersonation  - Overview & Pre-Conditions

This method involves obtaining the password hash of a target user and then passing the hash to Active Directory to impersonate that user, thus, in effect escalating your privilege to that user.

Although this method sounds easy to carry out, and is not difficult to carry out, it relies on two pre-conditions being met -

1. You have to be a Local Admin on the machine from which you wish to carry out the attack
2. The user whom you wish to impersonate must perform a logon on this machine.

If either of the two conditions are not met, you cannot carry out this attack.

The first condition is necessary because you need certain privileges to obtain password hashes from the machines' Security Accounts Manager (SAM) database, and the second condition is necessary because unless the user has logged on to your machine, his/her hash won't exist on your machine, so there will be no hash to obtain!

This is a very important point, because in contrast to the method of resetting a user's password to escalate privilege (which does not require either of these pre-conditions), unless these two pre-conditions are met, no matter how easy this may be to carry out, you will not be able to carry it out.



Active Directory Security Privilege Escalation Using Hash Impersonation - Tools Needed

To escalate your privilege in Active Directory using this method, you will need a pair of tools - one to obtain hashes, and one to pass the hash to Active Directory.

One of the most commonly used tools to obtain hashes is called lslsass.exe which is developed by a company called TrueSec. Other alternatives include pwdump, gsecdump etc.

The second tool you will need is the one that will be used to pass the hash to Active Directory is called RunhAsh.exe, which is also developed by TrueSec.

• WARNING: I should mention that TrueSec provides NO assurance as to the security of these tools, so they could very well be used to compromise your own security.

Active Directory Security Privilege Escalation Using Hash Impersonation - The Setup

To see how this method works, we will at a minimum need one Domain Controller (DC) and one domain-joined machine. We will also need to use at least two administrative accounts, one being a Domain Admin / Enterprise Admin / Delegated Admin domain user account and the second being a local administrative account on the domain-joined machine.

So here is my setup -

Active Directory Privilege Escalation - Impersonating with Password Hashes - Setup

Note that the second account could also be a domain user account, but it need not be. The only thing is that it does need to be a Local Admin on the machine, which it could be based on membership in the Local Admins group on that domain-joined machine

As you can see, the domain is khrushchev.local, within one domain controller (DC) nevsky.khrushchev.local and one domain-joined machine nikolai.khrushchev.local.

 

There are also two user accounts in play here. The first one is a local administrator account on the domain-joined machine nikolai, so it is nikolai\administrator, and the second account is the target of the privilege escalation attack, and it is thus a domain admin account, named, well domain admin for illustrative purposes, so it is khrushchev\domainadmin.

 

We will be escalating privilege on the domain-joined machine, and escalating privilege from the local administrator account on that machine to the domain administrator account.

 

• NOTE: Again, the assumption here is that the domain admin has logged on to the domain joined machine. Without this pre-condition in place, this attack CANNOT be carried out. (Unlike this attack vector, the attack vector involving the use of password resets does not have any pre-conditions.)

  

Active Directory Security Privilege Escalation Using Hash Impersonation - Step-by-Step

 

1. The first step is to logon to the domain-joined machine as an administrator on the machine.

 

Local Administrator on Domain-Joined Machine

 

 Before proceeding, it is helpful to ensure that we do not have access to the DC, and we can do a simple net use to the default administrative hidden-share c$ on the DC, Nevsky, to see that the local administrator account does not have the required access on the DC.

 

net use to c$ on DC fails

 

This way we know that we do not have admin access on the DC to begin with.

 

To doubly ensure that we do not have access, let us use LDP to connect to the domain (an LDAP connect operation does not require credentials) and then bind using the Bind as currently logged on user option (since LDAP binds do require credentials).

 

LDAP connect to domain succeeded

 

LDP - Using Bind as currently logged on user opton

 

LDP - LDAP Bind as Currently Logged on User Fails

 

As we can see, we were unable to get authenticated to the AD using the local administrator account.

 

nikolai. We do not have any domain admin privileges just yet.

 

 

 

2. Next, we proceed to obtain the hashes from the SAM on the machine, by using lslsass.exe

 

Using lslsass32.exe to obtain password hashes from SAM

 

Aha, notice that we were able to locate and dump the hashes stored in memory, including that of the Domain Admin, as he has logged in to this machine in the recent past. So now we have a hash of the Domain Admin's password!

 

 

3. So, we then proceed to pass the has to the AD by using runhAsh.exe.

 

Using runhAsh32.exe to pass/impersonate the hash to Active Directory

 

 Aha, as you can see, runhAsh seems to have succeeded in impersonating the Domain Admin!

 

Let us test this by trying to connect to C$ again.

 

net use to c$ on DC nevsky successful

 

We see that this time around we net use does succeed and we do have access to the c$ on the DC!

 

To ensure that this passed, let us perform a simple directory listing of the c$ share on the domain controller nevsky.

 

Directory Listing on C$ on Domain Controller nevsky succeeds

 

That succeeded too. Now, to doubly ensure that we do have access, let us use LDP again to connect to the domain and then bind again using the Bind as currently logged on user option.

 

Connecting to Active Directory using LDP
 

  

 

LDAP Bind from LDP Using Bind as Currently Logged in User Succeeds Verifying Elevated Domain Admin Creds

Viewing the Active Directory Domain Admin's Account using LDP

As we can see, we were able to get authenticated to the AD so we have certainly elevated our privilege to that of a Domain Admin! Once you're a Domain Admin, you can do whatever you wish, for you are the master of the domain now!

 

 

 

Active Directory Security Privilege Escalation Using Hash Impersonation - Risk Mitigation

 

This specific risk can be mitigated by employing the use of a new feature in Microsoft Windows Server 2008 R2, called Authentication Mechanism Assurance. I will not go into the details, as they are described in sufficient detail on Microsoft's website and other sources on the net. In addition, as a Domain Admin, one can also minimize the risk of being victimized by avoiding the use of Domain Admin credentials on machines you do not own/manage/trust.

 

lslsass, runhash and ldp Download, Trial and Additional Info

 

For more info and download points, checkout - lslsass32.exe,  runhash32.exe.

• WARNING: I should mention AGAIN that TrueSec provides NO assurance as to the security of these tools, so they could very well be used to compromise your own security. The use of such tools is not authorized in most organizations, so you could also lose your job if your employer has policies in place to prevent the use of such tools in their environment.

 

In the next post, we will see how to use the easiest way to escalate privilege in Active Directory, which is via the use of Active Directory Password Resets.

Спасибо