Let’s start with the theme of the previous day – really 😊

After an admittedly somewhat lengthy introduction, let’s get down to business.

In Active Directory, there are both standard permissions and historically grown misconfigurations that an attacker can exploit. First, we will briefly explain how permissions work in AD, then we will describe why this well-known topic is still relevant today, and finally we will present our solution approach.

What are AD ACLs / ACEs?

Every object in Active Directory has an Access Control List (ACL). Just like in the NTFS file system, the ACL describes “who can do what”. The ACL is composed of individual Access Control Entries (ACEs) that define an atomic permission. This then looks like this:

The user object “Andy” has an ACL that is composed of 32 ACEs. To give some examples:

• • The group “Account Operators” has the right “Full Control”
  • The group “Cert Publishers” has the right to read and write the “UserCertificate” property
  • The group Service Desk has the right “Reset Password

How ACLs can be exploited (examples)

Bloodhound visualizes the (known) exploitable ACLs in so-called Edges:

In this example, the Helpdeskadmins group can add members to the Serveradmins group. Since Andy is a member of this group, he also has this right. The Serveradmins group in turn has the “Generic All” right = full access to a server named “Adminserver01”.

The “Full Access” right can be exploited in several ways:

1. 1. 1. If the client uses LAPS, the attacker can read the password of the local administrator
      2. A sshadow credential attack that steals the TGT or NTLM hash of the object
      3. A Resource Based Constrained Delegation attack that authenticates an arbitrary user against the object

Why are ACLs still a security issue today?

ACL based attacks are not new, but misconfigurations are something we encounter in virtually every environment.

We have identified 4 reasons why we think this is the case:

1. 1. 1. ACLs are complicated.
         The default security descriptor defines the permissions that each newly created object has. For example, if a pentest report showed that an attacker had exploited the “full control” permission described above, one might think that removing the permission would solve the problem. In reality, however, any newly created object will contain this ACE again and thus be exploitable again.
         Besides the Default Security Descriptor there is also the AdminSD Holder process. This protects the objects that are worth protecting from Microsoft’s point of view and overwrites changes to the permissions. To stay with the example of the pentest report, if one were to adjust the permission of a protected object after the pentest, the change would be reversed after one hour. Unfortunately, not all relevant objects are protected by the AdminSD Holder process.
      2. New attack paths are still being found that are all based on ACLs. Here is an example of what has been added to Bloodhound alone since 2017:
      3. The number of ACLs and relationships to other objects is mind-boggling. In the following Bloodhound Enterprise screenshot from a relatively small environment with ~4500 users, it can be seen that there are 360,000 ACLs or ~480,000 relationships.

These are orders of magnitude far beyond what can be manually tested.

What can we do now?

One solution, and the one we favor, is to introduce a tiering structure and protect assets based on their need for protection. One aspect and core topic of the Troopers talk / this article is to build a protected OU structure as a basic framework for tiering. We have already blogged about some of the other measures (LINK1, LINK2), with more articles to follow.

We strongly recommend NOT adjusting permissions in existing OUs (except for isolated quick wins). Instead, a new OU structure should be created, provided with the appropriate permissions and filled.

The recommendations for permissions are based on a Best Practice Guide from 2011 😊. This 12 year old source is still valid and, we are not currently aware of a newer valid reference. If anyone has a newer source, they are very welcome to contact us. We would also donate an ice cream 😊.

Define roles and responsibilities

First, the question of who should do what must be answered. What sounds simple is often very difficult to answer. Companies often don’t know who should do what. Or there are statements like – everyone in team XY has to be the local administrator on all servers. But it doesn’t work that way. It’s tedious and painful, but it’s imperative to get rid of this legacy. Here is a snippet of what a definition might look like:

Building a new OU structure

Microsoft recommends a division into Tier0, Tier1 and Tier2 in the ESAE model. This can look like this, for example:

Of course, the structure can be adapted to the needs of each organization.

To make it easier for our readers, we have published a script for creating the OUs:

https://github.com/teal-technology-consulting/New-TealTierOUs

The OUs are defined via an XML and created via script. Simply take our suggestion, or adapt the XML.

Set permissions

Next, the permissions from the Best Practice Guide must be set on the newly created OUs. We have published a script for this as well: teal-technology-consulting/Set-TealTierOUAcl: Sets secure permissions on a tiering OU structure (github.com)

It stops inheritance at the top level (Administration OU in the example above), sets the desired permissions, and removes all direct permissions on child OUs.

It leaves inheritance on the child OUs, so delegations are inherited as usual.

Move highly privileged groups

The Best Practice Guide states that the default groups “Domain Admins”, “Schema Admins” and Enterprise Admins should be moved to the secured OU structure.

From our point of view, this is not enough. In addition to the groups mentioned above and the groups protected by the Admin SD Holder process, it is now known that other built-in groups can be exploited.

Microsoft has documentation on which groups can be moved, but in our opinion the documentation is flawed and not always helpful:

Therefore, we recommend moving all groups from the “Users” OU AFTER you have tested the effect in your own environment.

Set permissions regularly

Now we are actually ready to move the remaining assets to the correct OUS. We mentioned above that new objects get the ACLs from the default security descriptor. This gives Account Operators full access to users and group objects that are newly created within the protected OU structure:

“The Account Operators group grants a user limited account creation privileges. Members of this group can create and modify most types of accounts, including accounts for users, local groups, and global groups. Group members can log on to domain controllers locally.”

In general, we recommend that you do not use account operators, but this does not prevent an attacker from exploiting the permissions. Therefore, we have written a script that runs periodically, e.g. every 15 minutes by a scheduled task, which removes the account and print operators from the ACLs of all objects in the protected OU structure.

The script can be found here:

teal-technology-consulting/Remove-AccAndPrintOpsFromOU: A script to remove the Print- and Account Operator groups from all objects in an OU structure. It is meant to run in a scheduled task. (github.com)

An alternative is to change the default security descriptor. Since we cannot exclude the possibility that this may cause unintended page effects, we prefer the scripting variant.

New objects, delegate and move

The OU structure is now ready for use and assets can be moved into the structure. Depending on the size of the organization, this can be a lengthy process.

It is recommended to start with the new objects to be created first and train the administrators on how to use the new structure.

If existing objects are moved, the permissions must be checked, since directly set ACEs are also moved. By the way, this also applies to group policy objects that are linked to the new OU structure.

To enforce tier separation of accounts, Kerberos Authentication Policy Silos should be set up. But that is a topic for another post 😉.

Conclusion

These changes can go a long way toward improving IT security. Some of the activities shown are complex and tedious, but they are definitely worth it. For one thing, after implementation, you will have defined who has what responsibilities and cleaned up outdated permission structures. The whole thing can be done without expensive detection and response solutions – so it doesn’t cost any licenses, but “only” the effort of existing IT resources. Don’t get me wrong, detection and response tools do add value, but often you have multiple tools in use, some of which do the same thing. This is where you could save money and instead spend the time and budget on eliminating the legacy. If you have any questions, please contact us.

Off Topic

At this point a big thank you to our Alex for preparing this talk and presenting it at Troopers. As soon as the talk is online, we will link it. Until then, here are some impressions from Troopers, including a fire alarm in the middle of the night 😊.

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting)

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting)

LATEST POSTS