search

Persistence through Group Membership

If we want to persist through group membership, we may need to get creative regarding the groups we add our own accounts to for persistence:

  • IT Support groups can reset passwords, which may help spread access across workstations, even if privileged accounts are restricted.

  • Local administrator rights from network support groups can provide unnoticed persistence, allowing future domain compromise.

  • Indirect privileges (e.g., control over Group Policy Objects) can be just as valuable as direct admin rights for persistence.

hashtag
Nested Groups

Nested groups are subgroups of other groups. Companies use nested groups for permission inheritance or to recreate the company’s structure in an external user directory.

While group nesting helps to organise AD, it does reduce the visibility of effective access. Take our IT Support example again. If we query AD for membership of the IT Support group, it would respond with a count of three. However, this count is not really true since it is three groups. To get an idea for effective access, we would now have to enumerate those subgroups as well. But those subgroups can also have subgroups. So the question becomes: "How many layers deep should we enumerate to get the real effective access number?"

As an attacker, we can leverage this reduced visibility to perform persistence. Instead of targeting the privileged groups that would provide us with access to the environment, we focus our attention on the subgroups instead. Rather than adding ourselves to a privileged group that would raise an alert, we add ourselves to a subgroup that is not being monitored.

hashtag
Nesting Our Persistence

Let us simulate this type of persistence by creating some of our own groups. Let's start by creating a new base group that we will hide in the People->IT Organisational Unit (OU):

Create another group in the People->Sales OU and add our previous group as a member:

We can do this multiple more times by adding the previous group as a member. Let's now add that group to the Domain Admins group:

Lastly, we add our low-privileged user to the first group we created

Verify this by SSH'ing to our user in THMWRK1 and list the the directories and files of the DC

Cool, it worked. Let's verify that our group was added to the DA group

PreviousPersistence through SID HistoryNextCredentials Harvesting

Last updated