Most access in an organisation is granted to groups, not people, so whoever controls a group's membership controls everything the group can reach. D3-UGPH User Group Permissions is the MITRE D3FEND countermeasure that covers access decided through user groups. It sits in the Isolate tactic as a child of Access Policy Administration, the ontology models it as restricting the User Group artefact, and D3FEND gives "Role Based Access Controls" as its synonym. This card explains what the technique covers, the single ATT&CK relationship D3FEND's ontology records, where group-based permissions are implemented, how to verify membership and nesting, and the failure patterns that turn groups into an escalation path. It is written for identity engineers, directory administrators and detection teams. For the parent technique, see the MITRE D3FEND Access Policy Administration Implementation Guide.
Key takeaways
- Group membership is a permission in its own right. Adding an account to a privileged group is often the quickest way to escalate, so the right to change membership needs the same control as the rights the group grants.
- D3FEND's data for D3-UGPH is thin. The definition text describes attribute-based access control while the synonym is role-based access control, and only one ATT&CK relationship exists in the ontology: T1069 Permission Groups Discovery.
- Nesting hides real access. Effective rights come from the full chain of nested groups, which reviews based on direct membership miss.
- Membership change auditing is cheap and high-value. On Windows, the Security Group Management subcategory records every add and remove with distinct event IDs per group scope.
- Verify by effective membership, not group names. Expand every privileged group recursively and compare the result with an approved list.
D3-UGPH at a glance
| Field | D3-UGPH User Group Permissions |
|---|---|
| D3FEND ID | D3-UGPH |
| Tactic | Isolate (via the parent Access Policy Administration, which enables Isolate) |
| Parent technique | Access Policy Administration, D3-APA (siblings: Domain Trust Policy, Local File Permissions, User Account Permissions) |
| Digital artefact | User Group (D3FEND: the technique "restricts" a User Group) |
| Synonym in D3FEND | Role Based Access Controls |
| D3FEND reference | NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security |
| What it changes | Which resources a set of accounts can reach, by granting rights to groups rather than individuals |
| Typical verification data | Recursive group membership exports, group change audit events, access review results |
| Main limitation | Anyone who can change membership can bypass the design; nesting and stale members widen access silently |
How it works
D3FEND's definition reads "Access control where access is determined based on attributes associated with users and the objects being accessed," and its knowledge base article describes attributes such as location, time of creation and access rights. That is the language of attribute-based access control, while the synonym and the name point to role and group based control. In practice both apply: a group is an attribute of the user, and the permission attached to it is evaluated against the object. NHI Mgmt Group reads D3-UGPH as the practice of granting access through groups and roles, and keeping those groups accurate. The choice between role, attribute and relationship models is covered in the Authorisation Models Guide.
The OT reference fits: in industrial environments, operator, engineer and administrator roles on HMIs and engineering workstations are usually implemented as local or domain groups, and shared accounts are common. Group design is how per-role access is enforced there.
Three properties decide whether group-based permissions actually isolate anything:
- Who can change membership: group owners, delegated administrators, provisioning systems and anyone with write rights on the group object.
- How groups nest: a group placed inside a privileged group gives all its members the privilege, often without the owners of the inner group knowing.
- How membership is kept current: joiner, mover and leaver processes that remove access on role change, and reviews that catch what they miss.
Privileged groups in Active Directory
Microsoft's guidance on privileged accounts and groups names the groups that matter most. Enterprise Admins, Domain Admins and the built-in Administrators group are effectively equivalent, because a member of one can manipulate the directory to join the others. Schema Admins can compromise the whole forest when the schema is writable. The operator groups carry narrower but still powerful rights: Account Operators can administer domain user and group accounts, Backup Operators can back up and restore files regardless of permissions, Server Operators can administer domain controllers, and Print Operators can load and unload device drivers. Microsoft states that Domain Admins membership should be needed only in break-glass scenarios and Enterprise Admins only for forest-wide changes.
| Group | Why membership matters | Suggested target state (NHI Mgmt Group example) |
|---|---|---|
| Enterprise Admins | Forest-wide changes, member of every domain's Administrators group | Empty except during approved forest changes |
| Domain Admins | Full control of the domain and local admin on every domain-joined computer | Break-glass accounts only |
| Administrators (built-in) | Rights on the directory and domain controllers | Default members plus break-glass |
| Schema Admins | Schema modification | Empty except during approved schema changes |
| Account Operators | Administer user and group accounts | Empty; use scoped delegation instead |
| Backup Operators | Back up and restore files regardless of permissions | Only the backup service identities that need it, reviewed |
| Server Operators, Print Operators | Administer domain controllers; load drivers on them | Empty |
ATT&CK techniques D3FEND relates to D3-UGPH
Relationship type: inferred only. The D3FEND ontology relates one ATT&CK technique to the User Group artefact: T1069 Permission Groups Discovery, which enumerates User Group. The D3-UGPH technique page (D3FEND 1.6.0, checked November 2026) displayed no ATT&CK rows. The table also shows the sub-techniques, checked against ATT&CK v20; the last column is NHI Mgmt Group's assessment.
| ATT&CK ID | Technique | D3FEND relation | What D3-UGPH changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1069 | Permission Groups Discovery | Enumerates User Group (ontology) | Minimal on discovery itself; tight, simple group design reduces what discovery reveals as useful |
| T1069.001, T1069.002, T1069.003 | Local Groups, Domain Groups, Cloud Groups | Sub-techniques of T1069 | As above, per scope |
The bigger defensive value of group control is against techniques D3FEND relates to the sibling D3-UAP rather than to D3-UGPH, chiefly Account Manipulation (T1098), where an attacker adds an account to a privileged group. See the T1087 and T1069 Account and Permission Group Discovery Defensive Guide and the MITRE ATT&CK T1098 Account Manipulation Guide.
Where it is implemented
| Platform type | Group mechanism | What to control |
|---|---|---|
| Directory services | Security groups with domain local, global and universal scope | Membership of privileged groups, write rights on group objects, nesting into privileged groups |
| Operating systems | Local groups (Administrators, Remote Desktop Users), Unix groups used in sudoers and file permissions | Local admin membership, groups granted sudo, groups that own sensitive files |
| Cloud IAM | IAM groups and role assignments to groups | Policies attached to groups, who can add members, external or guest members |
| Identity providers and SaaS | Directory groups mapped to application roles, dynamic groups driven by attributes | Rules on dynamic groups, which attributes users can edit, group-to-role mappings |
| OT systems | Local or domain groups for operator, engineer and administrator roles | Shared accounts, group membership on engineering workstations |
Dynamic groups deserve a note: if membership is calculated from an attribute that users or a weakly controlled system can edit, changing that attribute becomes a privilege escalation route.
Implementation steps
- Inventory groups that grant access. List every group with permissions attached, the systems it reaches, its owner and its nesting.
- Expand membership recursively. Produce the effective member list for each privileged group, including nested groups and non-human accounts.
- Restrict who can change membership. Limit write rights on privileged groups to a small admin set or the provisioning system, and remove group ownership from individuals where a workflow can do it.
- Flatten risky nesting. Remove general-purpose groups nested inside privileged groups. Pilot removals with the affected team and keep the old membership list to restore if something breaks.
- Turn on membership change auditing. On Windows, enable Success auditing for the Security Group Management subcategory, which Microsoft recommends for domain controllers, member servers and workstations.
- Tie membership to joiner, mover and leaver events. Remove access on role change, not just on departure, and review privileged groups on a fixed schedule. See the Access Reviews Guide.
How to verify it works
Group design is verified by comparing effective membership with an approved state and by catching changes as they happen.
| Windows event ID | Meaning | Group scope |
|---|---|---|
| 4732, 4733 | Member added to, removed from a security-enabled local group | Local (including domain local and built-in groups such as Administrators) |
| 4728, 4729 | Member added to, removed from a security-enabled global group | Global (for example Domain Admins) |
| 4756, 4757 | Member added to, removed from a security-enabled universal group | Universal (for example Enterprise Admins, Schema Admins) |
| 4735, 4737, 4755 | Security-enabled local, global, universal group changed | All scopes |
| 4764 | A group's type was changed | All scopes |
| 4799 | A security-enabled local group membership was enumerated | Local (useful as a T1069 signal) |
- Change tests: in a test domain or with an approved test account, add and remove a member of each privileged group and confirm the alert reaches the SOC.
- Baseline comparison: export recursive membership daily and diff it against the approved list.
- Permission tests: confirm that accounts removed from a group actually lose access, allowing for token refresh (on Windows, a new logon is needed for group changes to apply to a session).
| Metric | What it shows | Target direction |
|---|---|---|
| Effective members of each privileged group | Real privilege surface | Falling to the approved list |
| Groups nested inside privileged groups | Hidden access paths | Falling toward zero |
| Privileged group changes without a matching request | Drift or attacker activity | Zero, each one investigated |
| Groups with no owner | Membership nobody is responsible for | Falling toward zero |
| Leavers and movers still in access groups after the target window | Lifecycle process gaps | Falling toward zero |
Limits, bypasses and failure patterns
- Write rights on the group object: an account that can modify a privileged group can add itself; the group's own permissions are part of the control.
- Nesting drift: a helpdesk or project group nested into an admin group years ago grants admin to everyone who later joins it.
- Service accounts in privileged groups: service accounts added to Domain Admins or Backup Operators for convenience become high-value targets. See How to find service accounts with Domain Admin rights.
- Editable attributes behind dynamic groups: membership rules based on attributes users can change.
- Removal that does not take effect: existing sessions and tokens keep old group claims until they are refreshed or revoked.
- Defaults that admit everyone: tools that allow all authenticated users until a group is configured.
Framework mapping
| Framework | Reference | Relationship to D3-UGPH |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2, AC-3, AC-5, AC-6 | Account and group management, access enforcement, separation of duties, least privilege |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined, managed, enforced and reviewed |
| MITRE ATT&CK | M1018 User Account Management, M1026 Privileged Account Management | NHI Mgmt Group mapping: mitigations covering group membership control |
| NIST SP 800-82 Rev. 3 | OT access control guidance | The reference D3FEND cites for D3-UGPH |
Practitioner checklist
- List every group that grants access and give each an owner.
- Expand privileged group membership recursively and compare it with an approved list.
- Restrict write rights on privileged groups to a small admin set or the provisioning system.
- Remove general-purpose groups nested inside privileged groups.
- Keep Enterprise Admins and Schema Admins empty outside approved changes, and Domain Admins to break-glass accounts.
- Enable Security Group Management auditing and alert on privileged group changes.
- Check dynamic group rules for user-editable attributes.
- Remove access on role change and review privileged groups on a fixed schedule.
Standards and references
- MITRE D3FEND: User Group Permissions (D3-UGPH)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- Microsoft: Privileged Accounts and Groups in Active Directory
- Microsoft: Audit Security Group Management
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1069 Permission Groups Discovery
Related NHI Mgmt Group resources: MITRE D3FEND Access Policy Administration Implementation Guide · D3-UAP User Account Permissions · Authorisation Models Guide · Access Reviews Guide · MITRE D3FEND Guide