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.

Спасибо
  

Active Directory Security Privilege Escalation Using L0phtCrack 6

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

In this post, we will look at the first way to escalate privilege in Active Directory, which is the most difficult way launch an Active Directory Security Privilege Escalation attack.

This way involves guessing the target user’s password, or cracking the target user’s password (; cracking refers to the process of recovering a user’s password that has been stored in or transmitted by a computer.)

Since most Active Directory deployments use basic security protections like Account Lockout, only amateurs use password guessing as a means to obtain an domain user account’s password. Also, because most AD deployments also have basic auditing in place, amateurs using password guessing are very likely to get caught in the act.

So, since password guessing is virtually not a realistic option in a decently protected Active Directory (and because its for amateurs) I will bypass it and talk about more interesting password cracking approach to get to a domain user account’s password.

The main tool used for password cracking is a tool called L0phtCrack, now in version 6. L0PhtCrack is primarily a password cracking tool and has five main ways in which it cracks passwords –

1. UserName Crack - L0phtCrack 6 checks to see if any accounts have used the username as a password. This crack is performed in every audit.
2. Dictionary Crack – L0phtCrack 6 tests all the words in a specified dictionary file against the password hashes. The dictionary crack tries words up to the 14 character length limit.
3. Hybrid Crack – L0phtCrack will modify existing dictionary words to generate additional password attempts, based on dictionary words slightly modified with additional numbers and symbols.
4. Precomputed Crack – L0phtcrack will compare user password hashes with pre-computed password hashes specified in a hash-file.
5. Brute Force Crack - L0phtcrack will attempt every combination of characters it is configured to use to attempt brute-forcing of password.

Using L0phtCrack for Active Directory Security Privilege Escalation

Now for launching a Active Directory Security Privilege Escalation attack, L0phtCrack 6 can be used to get the clear-text password of any domain user account, such as those of Domain/Enterprise Admins, and once you know their passwords, you can login as them and by doing so you escalated your privilege in Active Directory.

But did you really escalate privilege? Or did you just show that you don't know much about Windows Security?

Here’s what I mean - To use L0phtCrack 6 to crack domain user account passwords, you need administrative privileges on a Domain Controller (DC), but if you already have administrative privileges on a DC, you are already are a God-like administrator, but if you don’t already know that, you don’t know much about Windows Security.

Note: L0phtCrack6 has a new capability called Remote Password Retrieval, but if you read the documentation, it clearly states that a) you need Administrator Privileges on the remote Domain Controller, specifically the Debug Privilege, and b) the machine also needs to be able to be remotely administered.

Anyway, many default builtin groups in Active Directory, such as Server Operators, Backup Operators and Print Operators already have administrative privileges on Domain Controllers, so technically any member of any of these groups could use L0phtCrack to obtain access to hashes and then get to clear-text passwords.

But like I mentioned earlier, members of these groups already has enough power to be a Domain Admin, but if they don’t know that, it is their ignorance, and there’s no greater risk than having ignorant administrators who possess God-like privileges.

However, if someone who has managed to get administrative access on a Domain Controller, but has no idea that they now already have God-like Power or have no idea how to use it, then L0phtCrack can certainly help them find out the password of a Domain Admin, so they can then login as a Domain Admin.

So, if you can manage to get administrative access on a Domain Controller, and have no idea that you already have God-like powers, here is how to use L0phtCrack 6 to escalate your privilege in Active Directory –

How to Escalate Privilege in Active Directory by Using L0phtCrack

Step 1- Configure L0phtCrack Session Options

You should first specify the set of Session Options for L0phtCrack 6 to use.

I highly recommend referring to the product manual for the details, as it can impact how long the cracking process will take and what resources it will use.

Step 2 – Obtaining a copy of the Password Hashes from Active Directory

1. Launch the L0phtCrack Wizard

2. If you are logged in on a DC, select Retrieve from the Local Machine, otherwise select Retrieve from a Remote Machine

3. Choose an auditing method. Select from amongst – Quick Password Audit, Common Password Audit, Strong Password Audit, or Custom

4. Pick a Reporting Style. Options include Display passwords when audited, Display encrypted password ‘hashes’, Display how long it took to audit each password, Display auditing method, and Make Visible Notification when auditing is done.

Step 3 – Cracking Active Directory Domain User Account Password Hashes

1. Click on Finish to begin cracking Active Directory Domain User Account Password Hashes

That is all you need to so. Once L0phtCrack6 has done its job, if everything goes fine, you should be able to see the password(s) of one or more Domain Admins in your Active Directory.

Once you know the password of a Domain Admin account, you can use it to login as the Domain Admin. Once logged in as a Domain Admin, what you do with that power is limited only by your expertise. (Some of our comrades can bring entire network down in minutes.)

There are other password cracking tools available as well such as John the Ripper, pwdump7 and others, but they all require administrative privileges to begin with, so they cannot strictly be used to elevate security privileges in Active Directory or Windows.


L0phtCrack Download, Trial and Additional Info

For additional info and to download free L0phtCrack 6 trial, click here.

In the next post, we’ll see how to use a real way to Escalate privilege in Active Directory via the use of Password Hashes.

Спасибо

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.

Спасибо

Государственный гимн Российской Федерации

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

Today, as Americans celebrate July 04, I too feel proud of my country, so I thought I will share our great national anthem (with translation) with you.



More on Security Privilege Escalation in Active Directory in next post.

Спасибо

Delegated Access - The Key to Privilege Escalation in Active Directory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An Example

Let me give one example -

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо

Nikolai.