# Groups in AD

### What are Group in AD?

***

Group are collections of user account, computer account or other groups that can be grant permissions to access resources and delegate AD administrative tasks. Commonly groups contains users, computers or other groups but it is not limited to these objects. Any object inside AD that has security principals can be a part of a group. Group can be nested like [OU](/notes/active-directory/ad-objects-and-ous.md#organizational-unit-ou).

Security principals is anything that can be authenticated and given permission cause these have [Security Identifier](/notes/active-directory/ad-objects-and-ous.md#security-identifier-sid) (SID) where permissions are granted. Simply, anything that can be given permissions can be a part of group. When a new user is added to the group, the pre-assigned permissions to the group are inherited by that user immediately.&#x20;

Pre-assigned permission to the group? Yes, groups are treated like security principals so group have their own SID that receives the permissions. You don't assign permission to every SID of the user in the group, instead you assign permission to the SID of the group itself.&#x20;

Inside a [security group](#security-groups) when a user logs in, window builds an access token that contains user's SID and all the group's SID he belongs to. So when user tries to access a resource such as shared folder, windows check if the user's access token contains the SID of the group that has permission to access the folder. If yes, user gets the access granted.

{% hint style="info" %}
When you compromise a user, first thing to enumerate is what group the user belongs to because permission are inherited instantly. A user can belongs to any group that has near-DA (domain admin) level access such as `account operator` or `backup operator` even though they are not in Domain Admin group. That is why whenever i compromise a user, i run sharphound to collect the data again to check on bloodhound if there is any hidden privilege paths.

Near-DA level access basically are tier 0 adjacent privilege means accounts or groups that can be abused to escalate into full domain admin control.
{% endhint %}

But isn't it similar to OUs? yes similar not same.

### Groups vs OUs

***

As i mentioned earlier, group can only contains those objects that can be granted permissions. While OUs can contain any object in AD, including printers or resources within the same network.

Groups are used to grant acces to resources such as files, folders, apps, or printers. Technically assign permission and rights to access them. While OUs are used to organize and manage objects, apply group policies and delegate administrative control.

* Policies - These are rules such as applying rule on OU to disable USB port. It will get applied on every object that has USB port within the same OU.
* Permission - These are access and rights to use shared folders, files or applications within the groups.

{% hint style="info" %}
Groups are part of access control lists (ACLs) which is why groups are primary targets in ACL abuse.
{% endhint %}

| Features      | Groups                                                 | OUs                                              |
| ------------- | ------------------------------------------------------ | ------------------------------------------------ |
| Purpose       | Assign permissions or access control                   | Organize objects and apply policies (GPOs)       |
| Primary roles | Security management                                    | Administrative & Structural management           |
| Used for      | Grant access over resources                            | Organize and manage objects                      |
| Contains      | Any object with SID that can authenticate.             | Any object.                                      |
| Example       | HR\_Group have rights and permission to acces HR files | HR OU that have applied policies to their users. |

#### Few Clarifications:

* An Organizational Unit (OU) cannot be a group and a group can not be an OU.
* Group can contains other groups and OU also can contain other OUs.
* OU can contain groups but group cannot contains OUs.
* When a new member is added to a group, that member immediately inherits all the permissions that are pre-assigned based on group membership.
* When a new member is added to an OU, that member receives policies (GPOs) applied to that OU. Policies applies during login and periodic refresh which can be of 90 minutes. These periodic refresh happens in background so the user wont need to login again at every refresh. Unless there a policy update in the OU.
* Permission on group means control access over a resources such as you access that file or folder and are handled by ACL.
* Policies on OU means control system behaviour or configurations such as USB port disabled for blocking hardware usage and are enforced by  Group Policy engine.
* A user can be part of both OU and a group obviously. Both OU and group works differently so they can co-exists with each other. Example: a user cannot user USB port to connect a pendrive or any hardware device but it can access shared folder, printer or any resource within the network.
* Groups has their own SID cause they are security principal. While OU does not cause they are not security principal.

### Types of Group

***

Active directory has two types of groups:

* Security groups - Used to assign permission to shared resources.
* Distribution groups - Used to create email distribution lists only.

#### Distribution Groups

Distribution groups are used only to send email to collections of users using a email application like Microsoft exchange or outlook. These are not security enabled so you can't include them in DACL. Distribution groups cannot be used to assign permission to resources in any way.

{% hint style="info" %}
The only thing i can think of abusing distribution groups are by phishing or social engineering recon. DL or distribution list can be a part of an attack chain but standalone there is nothing about DL i have encountered so far. Yea they can be helpful during enumeration only if they are misconfigured which is very unlikely.
{% endhint %}

#### Security Groups

Security groups are used to to assign access rights and permission to resources on the network.

1. Assigning user rights to security groups - User rights define what actions a user can perform within the scope of a domain or forest. Example: If a user you added to the Backup Operators group in AD, they can back up and restore files because those rights are already assigned to the group.
2. Assigning permission to security groups - Permissions define what resources users can access such as read, write or full control. These are applied to resources like files, folders, printers, etc to access them. These permissions are managed through DACLs.

Either it be a user rights or permissions, they are assigned to the SID of the group so if you add the user in the group that has assigned user rights, the group's SID gets include in the user's access token, allowing user to instantly inherit those rights. Same with the group that has assigned permission, the user will inherit all the applied permissions that are assigned to group.

{% hint style="info" %}
Most abuse happens occurs due to misconfigured group permission or rights through ACL abuse.

* If you compromise an account and found yourself in a group that has read permission over a shared folder or file that contains sensitive information, that can result in privilege escalate.&#x20;
* If you have permissions like WriteMember on a group, you can modify group membership and add yourself to privileged group such as Domain Admins means immediate privilege escalation.
* Bloodhound is used to map out every path from compromised account to privileged account using ACL abuse by showing who has what permission or rights over what account.
* Enumeration is the key here, better enumeration = better exposure.
  {% endhint %}

### Group Scope

***

The scope of a group defines the area of the network where permission can be granted for the group. Each group has a scope that identifies the extent to which the group is applied in the domain tree or forest. Its all about where members can come from and where permission can be applied.

There are three group scopes:

* Universal Group - It is used when you need to group users or groups across multiple domain in the same forest. (works in entire forest)
* Global Group - It is used to collect user from the same domain based on role or function. (Can be used in its own domain and other domain as well)
* Domain Local Group - It is used to assign permissions to resources within one domain.(Limited to its own domain)

These groups practically has no limit of how many you can create them within its own territory. These groups can be security or distribution groups.&#x20;

| Group        | can contain                                                                                                                                                                      | can grant permission                                                          | can be member of                                                                                                                                                                                        |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Universal    | <ul><li>User accounts from any domain in the forest.</li><li>Global groups from any domain in the forest.</li><li>Other Universal groups also.</li></ul>                         | <ul><li>Any domain the same forest.</li><li>Trusting forest.</li></ul>        | <ul><li>Other Universal groups in the same forest.</li><li>Domain Local groups in the same forest or trusting forest.</li><li>Local groups on computers in the same forest or trusted forest.</li></ul> |
| Global       | <ul><li>User accounts from same domain.</li><li>Other global groups from same domain.</li></ul>                                                                                  | <ul><li>Any domain in the forest.</li><li>Trusted domain or forest.</li></ul> | <ul><li>Universal groups</li><li>Other global groups.(Same domain only)</li><li>Domain local groups.</li></ul>                                                                                          |
| Domain Level | <ul><li>Accounts from any trusted domain.</li><li>Global groups from any trusted domain.</li><li>Universal groups</li><li>Other domain local groups.(Same domain only)</li></ul> | <ul><li>Only within the same domain.</li></ul>                                | <ul><li>Other domain local group in the same domain.</li><li>Local groups.</li></ul>                                                                                                                    |

Local groups are security groups that I have mentioned earlier. The local groups exists on single computer or single machine such as `Remote Desktop Users`.

To understand these group there is a rule called AGDLP:

```
AGDLP
Accounts -> Global -> Domain Local -> Permissions
```

Meaning:\
1\. User accounts added to Global group.\
2\. Global group added to Domain Local group.\
3\. Domain Local group assigned resource permissions.

This is how admins supposed to structure the access, knowing this can help in enumeration.

{% hint style="info" %}
Domain Local group - See what resources can you access.

Global group - Compromising an account that belongs to global group can give forest wide access.

Universal group - The membership of universal group is stored in Global Catalog (GC), means you can use single query to reveal information or path using bloodhound. Its replicated across all domains, so it become easier to enumerate from anywhere in the forest.

Enumerating AGDLP isn't just about groups, its about identifying where the privilege escalation and lateral movement paths are hidden within that structure.

For example: you compromised an account, look for what role you have using `whoami /groups` and find out what global group you belong to. Use this global group's SID  to find which Domain Local group your group is nested with using `Get-DomainGroup`  and finally check the ACL for specific permission you have to escalate further. Or Using bloodhound you can skip this manual enumeration which will show you the path directly with visuals.
{% endhint %}

### Default Built-in Privileged Groups

***

These built-in groups exists in every AD environment by default. These groups already have powerful rights assigned by Microsoft and they are considered Tier-0 targets in red teaming. Technically, membership in any of the following group is either a direct path to Domain Admin (DA) or significant escalation.

| Group                | What they can do                              | Why target them                                                                                                                            |
| -------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Domain Admins        | Full control over a domain                    | Direct path to complete domain takeover. Members can control DCs, reset passwords, modify GPOs, dump NTDS.dit and more.                    |
| Enterprise Admins    | Full control over the entire forest           | Full domination. Membership in this group has control access to every domain in the forest including trust relationship and child domians. |
| Schema Admins        | Modify the AD schema                          | Rare but you can alter schema objects for a long term backdoor.                                                                            |
| Backup Operators     | Backup/restore files, log on locally to DCs   | Membership in this group means we can extract password hashes offline, copy NTDS.dit or bypass file ACLs.                                  |
| Account Operators    | Create / modify most user and group accounts  | Can add user to privileged groups, create admin accounts or abuse misconfigured delegation path.                                           |
| Server Operators     | Log on to DCs , manage services, backup files | Can modify services on DCs to escalate privilege and execute code as SYSTEM on DCs.                                                        |
| Print Operators      | Manage printers, log on locally to DCs        | Exploitable for DC escalation by installing modified printer drives which may enable privilege escalation.                                 |
| Remote Desktop Users | RDP access to machines                        | Important for lateral movement. It provides interactive access to servers resulting pivoting, harvest creds and expand foothold.           |
| DNSAdmins            | Manage DNS                                    | Can load arbitrary DLLs into the DNS service running as SYSTEM on DC.                                                                      |

### Nested Group & It's Abuse

***

Groups can contain other groups, that is called nested group. When a group is nested inside another group, all members of that nested group inherit the permission of the parent group immediately.

For example:

```
Wolf is a member of IT_HelpDesk group.
IT_HelpDesk group is a member of IT_Admins group.
IT_Admin groups is a member of Domain Admins(DA).
```

IT\_Admin inherits permissions of DA, then IT\_HelpDesk inherits permissions of IT\_Admin, and lastly every member who is part of IT\_HelpDesk inherits the permissions of IT\_HelpDesk. So effectively wolf is a Domain Admin through nested group membership. But if you check the Domain Admin groups directly, it won't show Wolf's name. This is exactly what makes useful for attackers. Wolf becomes shadow admin here who is not Domain Admin directly but have privileges.

It is not a misconfiguration that Domain Admin wont show Wolf's name or any vulnerability but AD itself is designed to show Direct membership of a group. Why? If AD stores every inherited member then large organization or company would explode in size. Then what will remain the meaning of Nested Group? It would become inefficient.

{% hint style="info" %}
This is one of the most common privilege escalation paths. A user that looks completely low-privilege on the surface can have a 4 or 5 hop to Domain Admin through nested group. Manual enumeration would become messy if you gonna enumerate each group one by one, you may miss any account that could be potentially helpful in privilege escalation. That is why bloodhound exists. Using sharphound to collect all the data regarding groups and bloodhound maps the full path from low level to privileged account visually. Again re-run Sharphound after every compromised account to check if there is any hidden privilege path.
{% endhint %}

### Shadow Admins

***

Shadow admins are users who has administrative privilegese through direct Acces Control Entries (ACEs) rather than explicit group membership. Technically, they are not a member of Domain Admins (DA) directly or through nesting, but has the power to become one because of ACLs. During enumeration on ACL you may find `GenericAll` over DA which basically means you can perform task as DA.

For example: If you have `GenericAll` over DA group object itself, you can add yourself to DA at any time. You wont appear in DA or any privileged group but you can effectively control DA.

These are created by misconfigured delegations. forgotten ACL entries or intentionally by attackers.

{% hint style="info" %}
When bloodhound maps out path, look for `GenericAll`, `GenericWrite`, `WriteDACL`, `WriteOwner`, `ForceChangePassword` on high privileged object. By ACL abuse modify the group or reset a password or DCSync directly.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://kaizoku.gitbook.io/notes/active-directory/groups-in-ad.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
