Best Active Directory Auditing Tools to Counter Active Directory Privilege Escalation Security Risks

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

Comrades, I have received many queries asking how to prevent Active Directory Privilege Escalation based attacks in your environments, especially those based on exploiting unauthorized password reset delegations in Active Directory.


How to Prevent an Active Directory Privilege Escalation based Attack

Ideally, the best way to prevent Active Directory Privilege Escalation based attacks in your environments is to make sure that there are no privilege escalation paths anywhere in your Active Directory. I say this is the best way because if there are no privilege escalation paths anywhere, then there is nothing to exploit, so there is no way to escalate privilege.




Active Directory Password Resets

However, there is no easy way to detect privilege escalation paths in Active Directory today. By that I mean there is no way to check who all have been delegated ability to do password resets on domain user accounts in Active Directory.

I think the best that we can do today is analyze Active Directory security permissions on all domain user accounts to find out who has what effective permissions on these accounts. You're basically looking to find out who all has effective "Reset Password" extended rights on all the user accounts.

Once you can find out who all has effective "Reset Password" extended rights on all the user accounts, you should have a good idea of who can reset whose password to escalate their privilege in Active Directory.

One note of caution: please make sure you determine "effective permissions", not "who has what permissions", because you're trying to determine who effectively has reset-password rights, and "who has what permissions" will just show you the list of rights, not who can effectively perform password resets.

To perform Active Directory permissions analysis, you do have a choice of a couple of tools including dsacls, acldiag, aducadmin and liza being the most common ones I found.



LIZA.exe - A Good Active Directory Permissions Tool - Hacker's Choice

However, none of these tools can find out effective permissions, so you'll still have to do that on your own. But these tools can certainly help analyze permissions and get you about 10% of the way.

The key is not get disappointed in the face of the jungle of permissions that can be overwhelming even for pros, but to keep looking and focusing on the Reset Password rights. Once you've gotten past figuring out which allows beat denies, and which explicits are not over-shadowed by inherited permissions, and which permissions actually apply on the object., you should be on your way to figuring out who has what effective password reset rights. Also be sure to keep in mind that any Full Control permissions and any All Extended Rights permissions will also contribute to the outcome in most cases. A good group enumeration utility can also help because you'll end up doing a lot of group expansions as you perform this password reset analysis.




Best Active Directory Auditing Tools to Counter Active Directory Privilege Escalation Security Risks

Since the above counter-measure is very difficult to do, the other method is to rely on Active Directory auditing, which can also help us find out who can reset whose passwords but only when someone does reset someones password. So for example, if Dmitri was to reset Ilena's password, it would show up in the audit logs.

The only problem with this approach is that it relies on a person actually attempting to perform a password reset, and so the likelihood of someone performing a password reset of another account is low. As a result, one may be able to uncover only about 5% - 10% of the total number of people who can reset someones password, but its better than no insight.




Active Directory Auditing Tool

With that in mind, if you're looking for an auditing solution, I think the main choices are the following ones -

1. Blackbird Auditor for Active Directory
2. Visual Click Software CPTRAX for Windows
3. ManageEngine ADAudit Plus
4. Netwrix Change Reporter
5. Quest ChangeAuditor

Each of these solutions can be used to find out who changed what in Active Directory, so they can also be used to find out who reset whose passwords, assuming of course you had Directory Services events auditing turned on and you had set Reset Password Audit Success and Audit Failure on all user accounts.

Amongst these 5 solutions, I would tend to recommend Quest ChangeAuditor, as I believe a majority of its coding/support is done on Russia, at Quest Software's Russia operations, and as you know, we Russians are one of the best when it comes to security, hacking, programming and coding.

I believe Quest's ChangeAuditor is also used at major US government installations, so if American government is using it, you certainly can. Solid russian code running on your DCs is hard to beat.

The other ones I don't know so well. I believe Netwrix Change Reporter and Manage Engine's ADAuditPlus are built in India. I'm not sure how reliable they are in terms of quality, particularly coding, but they certainly make for decent cheaper alternatives if you are on a budget. Blackbird Auditor seems to be built in Canada, so they might be a bit more reliable. It all depends on your budget and needs.

I have focused on where these solutions are built more than their features because they all basically do the same thing which is to collect events from audit logs on all DCs in a domain and show them to you in a single unified interface. So, if they're doing the same thing, they're all very similar. The only difference then is in their quality, and where a product is built and by whom is a good indicator of quality.


In that regard, Quest ChangeAuditor, made in/supported from Mother Russia may be the best.



 

Whatever solution you choose to go with, you can use them to audit password resets and based on that data, you can start to find and remove any privilege escalation paths in your Active Directory.

Even if auditing helps you find only 5-10% of the paths, it is better than finding 0 paths. When you consider that a hacker might need only 1 path, even a 10% reduction is a decent amount of reduction in risk.

Of course, the harder longer of trying to find out who can reset passwords can help you identify over 90% of the paths, but very few people have the patience or the time to deal with the jungle of Active Directory permissions.

Спасибо

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.

Спасибо
  

3 Primary Ways to Escalate Privilege in Active Directory

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

In this post, we will look at 3 primary ways to escalate privilege in the Active Directory. (In posts to follow, I will cover each of these in detail.)

Before you begin to escalate privilege, you identify the target of your Active Directory security privilege escalation attack i.e. identify the Active Directory (domain) user account whose identity you wish to compromise.

The objective of the security privilege escalation attack is to elevate your privilege from that of your account to that of another account, and one that usually has more powers (elevated powers) than yours. This domain user account can be that of a colleague, a delegated Active Directory administrator (e.g. a Help Desk Analyst) or a Domain/Enterprise Administrator.

To accomplish this, the primary method of attack is to steal the identity of the target domain user account. In other words, the 3 primary ways to escalate privilege in the Active Directory involving stealing a corporate user’s identity, as their domain user account is basically their identity.

So, the 3 ways to escalate privilege in Active Directory are –

1. Guessing the target user’s password, then logging in using the password
2. Obtaining and then passing the user’s hash to impersonate the user
3. Resetting the user’s password, then logging in with new password

The 3 ways mentioned above are in the decreasing order of effort required.

So the hardest way is to guess a target user’s password, and the easiest way is to reset the target user’s password, even though tools (l0phtcrack) make the actually guessing effort easy.

The second way, falls in between, because it requires less time than the guessing passwords, but requires access to a machine on which the target user may have logged on, but once you have access to such a machine there are now tools available (lslsass64.exe) that can help you find user’s hashes and then use them (runhash64.exe).

The ability to reset a user’s password is the easiest but also the least known / least used method, because the hardest part in this approach is not actually resetting the password, but trying to find out who can reset the target user’s account’s password.

Trying to find out who can reset the password of a domain user account is generally a very difficult task, and it is this level of difficulty that has been a deterrent in the use of this attack vector, but these days, just like there is at least one tool to help brute-force passwords (l0phtcrack), there is also a tool to easily find out who can reset whose passwords in an Active Directory environment. The availability of such a tool now makes it very easy for anyone to try and find out who can reset whose passwords, and use this information to reset a target user’s password, then log in as the target user, in effect successfully escalating privilege in Active Directory.

In the next 3 posts, we will see in detail how to use each of these three methods to escalate privilege in Active Directory, with analysis on how much effort each approach involves, what tools are required and other helpful details.

Спасибо

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.

Спасибо

Understanding the Concept of Privilege Escalation

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

In order to understand what Privilege of Escalation in Active Directory is, it is first helpful to understand the concept of security privilege escalation in general.

Here is the definition of Privilege Escalation from Wikipedia -

Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user. The result is that an application with more privileges than intended by the application developer or system administrator can perform unauthorized actions.

To put it simply, security privilege escalation is the process by which someone can elevate the level of access they have in a security system, by exploiting some weakness of the system, or by using social engineering, to gain more access.

For example, lets say a user Alice only had the access to be able to read files on a file-server, but not to be able to modify the files. If Alice could somehow, i.e. by means of some actions, elevate the level of access granted to her so that she could now also modify files on the file-server, then in effect she would have escalated her privilege in the system to obtain more power.

For instance, Alice could exploit a weakness in the system itself, or discover weaknesses in access rights granted in the system which would allow her to enact some steps and ultimately gain elevated access, then she would have in effect elevated her security privilege in the system.

In other words, privilege escalation is a very powerful concept because it lets someone obtain more privilege in a system than he/she is supposed to have, and its consequences can be very serious, because a skilled individual could do a lot of damage to a system with escalated privileges.

Privilege escalation, when applied to Active Directory, is one of the most powerful ways in which someone could obtain administrative power in a Microsoft network, and potentially use it to cause widespread damage across the network.

In the next post, I will cover why the concept of privilege escalation is so pertinent to Active Directory, and how Active Directory's powerful but complicated security model makes it easy for anyone with read access to Active Directory to find many avenues of privilege escalation.

Спасибо

Notes on Privilege Escalation in Microsoft Active Directory

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

I am Nikolai. I live in Moscova. I am a security researcher, and my recent interest has been in the area of security of Microsoft Windows and Active Directory, with a focus on privilege escalation.

To help fellow comrades understand the concept of privilege escalation in Active Directory, I will share the theortical and practical aspects of the concept, and some ways in which one could try it out in lab environment.

Спасибо