ADMINCOUNT = 1 | From Regular User To Domain Administrator WITH PERSISTENCE In 5 Minutes.

admincount

ADMINCOUNT = 1 – Protected groups and their members are marked in Active Directory using an AdminCount attribute, which is set to a value of 1.

This attribute is assigned automatically every time a user is assigned to a protected group and WILL NOT BE MODIFIED AGAIN, EVEN IF THE USER HAS BEEN REMOVED FROM THE GROUP.

To understand more about this non-secure configuration, we would like to mention which are the protected users and groups in Active Directory. For that we will use the following Microsoft technical chart:

Since Windows 2000, Active Directory has a mechanism to ensure that members of protected groups have standardized and controlled security descriptors. The process is complex and there are many moving parts that are worth exploring and defining. That is exactly what we will try to do in this post.

First, what that number 1 means is that the user account was modified in its permissions in the Access Control List (ACL) through a process performed by the AdminSDHolder container.

This container is a template that has certain elevated permissions that are replicated every 60 minutes through SDPROP to protected user accounts and protected groups. The only task of SDPROP is to replicate the permissions of the AdminSDHolder template.

So, the vulnerability is generated when:

  1. The domain administrator creates a user and places it in a protected group.
  2. AdminSDHolder assigns an AdminCount of 1 to the user who is in the protected group through a process that fires every hour through SDPROP in order to replicate the permission template in AdminSDHolder.
  3. Over time, the domain administrator removes the user from the protected group, but the AdminCount attribute remains 1 in the user’s profile.

So, the question is: what does this all mean and what is the extent of the vulnerability?

This means that the user will not have the AdminSDHolder template permissions applied again; however, the user likely has a version of the AdminSDHolder permissions still set by inheriting his permissions as a carryover from when he was a protected user.

The vulnerability resides in that, if an attacker discovers a regular user who has an AdminCount of 1 that is not in a protected group and if the attacker has access to this profile, he could execute actions on the domain controller, quite dangerous actions … let’s see…

ADMINCOUNT = 1 – Anatomy of an internal attack

In this case, the user “USUARIO X” was removed from a protected group and was left with an AdminCount of 1:

ADMINCOUNT = 1

ADMINCOUNT = 1

“USUARIO X” is compromised through a phishing email, an unprotected password, or through a USB attack giving unauthorized access to the attacker.

The attacker proceeds to enumerate the permissions of “USUARIO X” and he turns out to have the permissions of a regular user in the domain:

BUT, it has an AdminCount of 1:

In this way, the attacker decides to add the profile of his victim “USUARIO X” to the permissions of the AdminSDHolder container, assigning himself (because ultimately he is executing the actions through the violated user) ALL the permissions, as we can see in the first command.

It should be noted that all these actions must be executed with elevated privileges because a persistence process is being created on the domain controller. As we can see in the second command, “USUARIO X” has already been replicated to the group “Domain Administrators” and the attacker is managing this profile.

As a result, the attacker has had persistence in the domain and a backdoor that is difficult to detect and all due to a number 1.

As we can see, “USER X” was added to the AdminSDHolder container with all the permissions and replicated to the group of “Domain Administrators” through the SDPROP process.

Confirming privilege escalation from the attacker’s perspective:

The persistence of the process is that if the domain administrator removes “USUARIO X” from the group of domain administrators, he will be in the same group after 60 minutes.

From this point on, the domain was completely compromised and the attack wreaked havoc because having access to the domain administrator’s permissions takes minutes to create persistence on all computers and servers using Group Policy, PowerShell, or Windows Tasks.

Only the total reconstruction of the domain and/or forest could solve an attack of this type affecting the production and the reputation of the affected company.

It is tremendously important that these types of vulnerabilities are considered. RedDefense Global constantly recommends that its clients monitor protected groups. Continuous monitoring of the ACL permissions of the AdminSDHolder container is also necessary.

One of the necessary practices to mitigate this insecure configuration is the timely detection of all users who do NOT belong to protected groups and who have an AdminCount of 1, in order to proceed with the modification of the corresponding attribute.

How RedDefense Global can help me keep my domain free from internal vulnerabilities?

RedDefense Global has paid attention to the real situation of the domains. We understand that domain administrators often do not have time to study and search for vulnerabilities as dangerous as this one because they are busy supporting employees, creating new users or replacing computers. If that is the case with your technology department, we invite you to contact us so that we can tell you about our NON-INVASIVE procedures. 

https://www.reddefenseglobal.com/services

https://seguridad-ofensiva.com/nuestras-soluciones-y-servicios