Skip to content

AD - Vulnerabilities

1. Users having rights to add computers to domain

In a default installation of Active Directory, any domain user can add workstations to the domain. This is defined by the ms-DS-MachineAccountQuota attribute which is by default set to 10.

This means that any low privileged domain user can join up to 10 computers to the domain. Ok, probably not great, but what’s the big deal?

The problem is that this settings allows any user to join their our own, unmanaged computer to access the corporate domain with the following advantages:

  • No Antivirus or EDR solution will be pushed onto their machine
  • No GPO settings or policies will be applied to their system
  • Allows them having Administrative rights on their system

In corporate environments, users should never have local administrative privileges on their machines. This is one of the fundamental security controls which should be applied universally.

If users have administrative privileges on their machines, they can perform privileged operations on the network such as craft raw network packets, perform network scans, run exploits from their machine to attack other systems on the network and many other things.

Users should therefore be never allowed to join computers to the domain.

2. AdminCount attribute set on common users

The AdminCount attribute in Active Directory is used to protect administrative users and members of privileged group such as:

  • Domain Admins
  • Enterprise Admins
  • Schema Admins
  • Backup Operators
  • Server Operators
  • Replicator
  • etc.

The inner workings related to it is quite a complex topic involving AdminSDHolder object and SDProp process which periodically modifies such accounts. To make long story short, the AdminCount attribute should never be set on common users, because it can give them unnecessarily high privileges.

For instance, this can prevent users from having applied corporate Group Policies and ACL modifications, or on the other hand it can result in assigning them with high privileges In any case, this represents a risk of having “backdoor” users in the organization without knowing about it.

The problem is that the AdminCount attribute is set to 1 automatically when a user is assigned to any privileged group, but it is never automatically unset when the user is removed from these group(s).

This can result in having common low privileged users with AdminCount set to 1 without being members of any privileged group.

3. High number of users in privileged groups

This vulnerability is about having an excessive number of users in privileges groups such as:

  • Domain Admins
  • Schema Admins
  • Enterprise Admins

Having a high number of users in privileged groups unnecessarily increases risk of domain compromise, because if some of those users gets compromised, it means total compromise of the domain.

It’s not only prudent, it is truly essential to follow principles of the least privilege and assign membership to these groups only when absolutely necessary, which is ideally never.

We have seen AD deployments with zero users in these groups and they worked just fine. It can be done.

4. Service accounts being members of Domain Admins

The idea behind service account is to designate a specific user account with specific set of privileges to run a specific service (or an application), without requiring to provide it with full administrative privileges.

The problem is when these accounts get assigned exorbitant privileges and/or memberships, like being added to the “Domain Admins” group for example.

Such practice introduces a critical risk into the infrastructure, because service accounts typically have passwords set to never expire and so their passwords are rarely changed, if ever.

This means that if such vulnerable service account got compromised, it would allow the attacker to have full control over the AD domain. And for a long time probably.

5. Excessive privileges allowing for shadow Domain Admins

This vulnerability is more complex. It’s about misuse of Active Directory Rights and Extended Rights, a.k.a. Access Control Entries (ACEs).

The problem is when some of these rights are given to a low privileged user (or a group) to allow changing something important on a higher privileged user (or a group).

Some of the typically misused rights include:

  • *ForceChangePassword* – Ability to reset password of another user
  • GenericAll – Full control over an object (read/write)
  • GenericWrite – Update of any attributes of an object
  • WriteOwner – Assume ownership of an object
  • WriteDacl – Modify the DACL of an object
  • Self – Arbitrarily modify self

These things can have critical impact and often times lead to Domain Admin privileges. Users with such excessive privileges are thus called shadow Domain Admins (or Hidden Admins).

6. Service accounts vulnerable to Kerberoasting

Kerberoasting is very popular attack vector aimed against service accounts in Active Directory.

The problem is when these service accounts have weak passwords and when there is weak Kerberos RC4 encryption used for encrypting their passwords.

7. Users with non-expiring passwords

Mostly due to a convenience, some organizations have domain accounts configured with the DONT_EXPIRE_PASSWORD flag set.

This is typical configuration of service accounts, but also can be sometimes seen on more privileged domain accounts.

What this means is that their passwords will never expire. Although it is useful / convenient in some situations, it can also be quite damaging.

High privileged domain accounts with non-expiring passwords are ideal targets for privilege escalation attacks and are common “backdoor” users for maintaining access e.g. by APT groups.

8. Users with password not required

Another interesting flag in Active Directory is the PASSWD_NOTREQD flag. If a user account has this flag set, it means that the account doesn’t have to have a password.

This doesn’t mean that the user account doesn’t have a password, it simply means that it doesn’t have to have one. It means that any kind of password will be just fine – a short one, a non-compliant one (against domain password policy), or an empty one. Simply any.

This is of course a huge security risk and no user account ever should have this flag set.

9. Storing passwords using reversible encryption

Some applications require user’s password in plain text in order to perform an authentication and this is why there is support for storing passwords using reversible encryption in Active Directory.

Storing passwords this way is essentially identical as storing them in plain text. It is a horrible idea, but it’s reality.

The only mitigating factor here is that an attacker would have to be able to pull password data from the domain controllers in order to read the password in plain text. This means to have either:

  • Rights to perform DCSYNC operation (e.g. via Mimikatz)
  • Access to the NTDS.DIT file on a domain controller

10. Storing passwords using LM hashes

Another vulnerability that typically surfaces after the Active Directory compromise is the storage of passwords as LM hash, instead of NTLM.

LM hash is an old deprecated method of storing passwords which has the following weaknesses:

  • Password length is limited to 14 characters
  • Passwords that are longer than 7 characters are split into two and each half is hashed separately
  • All lower-case characters are converted to upper-case before hashing

Due to these weaknesses, LM hashes are extremely easy to crack. Anyone who has access to them, e.g. highly privileged insiders (domain administrators), can easily crack them and obtain plain text passwords.

11. Service accounts vulnerable to AS-REP roasting

This vulnerability is very similar to Kerberoasting, but in this case the attack abuses user accounts that do not require Kerberos pre-authentication.

Simply speaking, it affects domain users with DONT_REQ_PREAUTH flag set.

12. Weak domain password policy

Password policy is a topic that keeps evolving by time. There are many different views on it and opinions how an ideal password policy should look like.

Some organizations enforce long and complex passwords, changing them frequently. Some are more benevolent and some can even almost disregard enforcing strong password parameters altogether and just focus on strengthening their compensatory controls in their internal environments, holistically, so that an account compromise has only a very little impact.

Each approach certainly has its advantages and disadvantages, but as penetration testers we should stick to something prudent and generally accepted, even though the clients might ultimately make their own call.

13. Inactive domain accounts

This vulnerability is about having active user accounts without being used for a long time, according to their ‘Last logon date’. These accounts are typically belonging to:

  • Employees that left the company
  • Temporary accounts
  • Test accounts

Having unused domain accounts in the domain increases attack surface of the organization, because it provides opportunity to compromise these accounts, for example via login attacks.

There should be a mechanism (a policy) in place to disable or delete these accounts based on periodic checks, e.g. after 30 days of inactivity. Mileage can vary of course here.

14. Privileged users with password reset overdue

This vulnerability is about having high privileged and administrative users configured with one password for a very long time, e.g. for half a year or more.

Why is this a problem?

Privileged accounts are likely targets for attackers (e.g. APTs) and if their passwords are not changed periodically, it gives the attackers sufficient time to successfully brute force their credentials.

As mentioned earlier, all privileged accounts and service accounts should have their passwords changed on regular basis.

15. Users with a weak password

Despite having strong corporate password policy and matured environment, there still can be domain accounts with weak passwords.

In fact, this is very common issue, especially in large Active Directory environments.

16. Credentials in SYSVOL and Group Policy Preferences (GPP)

This vulnerability is about storing credentials in SYSVOL network share folders, which are folders on domain controllers accessible and readable to all authenticated domain users.

SYSVOL folders are typically used to store corporate Group Policies, configuration files and other data that are pushed to the users upon logon and so on.

Storing credentials in SYSVOL folders is something that administrators sometimes do or chose to do at some point in time, in order to solve some configuration problem. For instance, starting an application on client machines upon logon which requires administrative privileges.

Needless to say, this is something that should never be done, because any domain user can access the SYSVOL shares and find the credentials.

Typical examples are:

  • Group Policy Preferences (GPP) with cPassword attribute (MS14-025)
  • Hard-coded credentials in various scripts and configuration files

Source

  • https://www.infosecmatter.com/top-16-active-directory-vulnerabilities/