UNCONFIGURED ACL PERMISSIONS – From Regular User To Domain Administrator In 5 Minutes.

unconfigured ACL permissions

UNCONFIGURED ACL PERMISSIONS – In domain environments, NTFS permissions and folder sharing permissions are widely used, but no domain administrator can deny that they are often misused. This is the process with which we often find ourselves in the domains of our clients:

  1. The domain controller was configured with all its security groups assigned to the different folders on the servers to share resources with users.
  2. The company’s head of operations calls the system administrator who was hired a couple of months ago to give five employees access to a folder on the network.
  3. The system administrator accesses the server where the folder is located and adds these five users to the security permissions and the share permissions to complete the task.

From these three points come the following questions:

What happened to the security groups that were assigned on the domain controller for cases like this?

Answer: The new system administrator had no idea about these security groups.

But if when you added the users one by one you could see that the groups were there, why didn’t you go to the domain controller and do it correctly?

Answer: Believe it or not, because it did not occur to him, because he wanted to do it quickly, because I think it was good, because he is not interested in me, there are multiple answers to this question.

And why did you add users with ALL permissions and not just read or write permissions?

Answer: Because you just did not want to discuss the situation with the operations manager. They both somehow think that if the employees have access to the folder everything is fine.

These are precisely the settings that make systems vulnerable. After years of doing this same poorly performed procedure, the ACL permissions on the domain controller, servers, folders, and NTFS have gotten out of control and all we see is a spaghetti of misconfigured permissions.

After this introduction let us move on to our point of interest:

Some of the Active Directory permissions that need to be treated very carefully and constantly monitored, because attackers are very interested in them are:

  • GenericAll: Gives full rights to the object in question (add users to a group or reset the user’s password)
  • GenericWrite: Updates the attributes of the object.
  • WriteOwner: You can change the owner of the object to a user controlled by the attacker who takes over the object.
  • WriteDACL: Modifies the object’s ACEs (Access Control Entry) and gives the attacker full control over it.
  • AllExtendedRights: Add users to a group or reset password
  • ForceChangePassword: Allows you to change the user’s password
  • Self (Self-Membership): Add yourself to a group

Now, let us analyze how these permissions can affect a domain to the point of totally exposing it:

When was the last time you analyzed the NTFS permissions of your “Domain Administrators” group?

In this case, it was never done, and an old administrator added “USUARIO X” to the NTFS permissions of the Domain Administrators group with write permissions and it was forgotten:

Unconfigured ACL permissions – Anatomy of an internal attack



As we can see, the members of this group are perfectly configured in the NOTANSEGURO.COM domain; therefore, no one would suspect that the system is at great risk.

So, “USUARIO X”, who is still an employee of the company, one day opens a phishing email, or connects an infected USB to his computer, or neglects his password giving direct access to an intruder to the internal network, this is when the problem begins:

The attacker, having control of the “USUARIO X” profile, begins the enumeration of the domain, not discovering anything interesting about the profile of the compromised user. This belongs to the user group, without extra permissions:

C: \ Users \ alexander.castillo \ AppData \ Local \ Microsoft \ Windows \ INetCache \ Content.MSO \ 35AF8856.tmp

But just a little more enumeration reveals the vulnerability; Using a PowerShell module called PowerView.ps1 the attacker discovers that the “USUARIO X” profile has privileged permissions on the domain administrators’ group:

From here, the attack process is trivial, but also extremely damaging. Using the PowerShell version of RSAT (Remote Server Administration Tools) called ADModule, it is possible for this same user to add himself as a domain administrator; in this case the attacker takes advantage of this attack vector easily:

To add user “USUARIO X” to the group of “Domain Administrators”:

View from domain controller:

To finally access the domain controller via UNC path or using PowerShell Remote:

As we can see again, there are misconfigurations that are not easy to discover in a domain that can be the cause of a big problem where domain security, reputation, and company assets are at stake. RedDefense Global pays attention to these insecure configurations in order to give you a solution before someone else takes advantage of them.

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

In RedDefense Global we have 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. Our intention is to provide a real solution to internal vulnerabilities that antivirus cannot identify.