Windows Groups and Nested Group Membership: Effective Rights Modeling

DFIR Incident Response Mental Model

During an intrusion triage, direct group membership represents only the tip of the iceberg.

An adversary does not need to be explicitly listed inside Domain Admins to exercise full administrative control: nested group relationships grant inherited privileges across arbitrarily complex delegation chains:

User → Global Group → Universal Group → Domain Local Group → Permission / Right

Concept

In Windows and Active Directory, a security group is a security principal bearing an immutable SID used to aggregate accounts, computers, or other groups.

A group’s reach across domain boundaries depends on its Type and its Scope:

1. Local Groups (SAM): Confined to the hosting local machine.
2. Domain Global Groups: Aggregate users from the same domain to represent business roles.
3. Domain Local Groups: Used to grant permissions on resources located within the local domain.
4. Universal Groups: Stored in the Global Catalog (GC), capable of containing members from any domain in the forest.

---

Why This Matters in DFIR

Forensic analysis of group memberships reveals stealthy persistence and lateral expansion paths:

• Proving Indirect Privilege Escalation: When a standard user executes an administrative API, responders must reconstruct the transitive group tree to determine which nested link granted the capability.
• Detecting Backdoor Persistence: Sophisticated adversaries create innocuous groups (e.g., Backup_Operators_L2), nest them inside high-privilege groups (BUILTIN\Administrators), and add an unprivileged account to the nested group.
• Cross-Domain Authorization: In multi-domain architectures, a Domain Local group in Domain B can contain a Global group from Domain A, granting Domain A users administrative reach on Domain B without possessing any direct user account in Domain B (see Doc 18: Cross-Domain Group Membership and Foreign Security Principals).

---

How It Works

The AGDLP / AGUDLP Architecture

Microsoft prescribes the AGDLP design pattern to structure permissions:

• A (Accounts): User principals.
• G (Global Groups): Accounts are added to global groups representing their operational roles (e.g., GG_Finance).
• U (Universal Groups): In multi-domain setups, global groups are placed into universal groups.
• DL (Domain Local Groups): Universal or global groups are nested into domain local groups representing a securable resource (e.g., DL_Billing_Folder_RW).
• P (Permissions): Resource DACLs are granted strictly to the Domain Local group.

[User Account (jdoe)]
            │
            ▼ (Member of)
[Global Group (GG_Finance)] (Domain A)
            │
            ▼ (Nested in)
[Domain Local Group (DL_Billing_RW)] (Domain B)
            │
            ▼ (DACL / ACE)
[Secured Shared Directory (\\FS01\Billing)]

Logon Token Construction

At authentication time, LSASS and the KDC recursively resolve all direct and transitive memberships:

1. The KDC resolves domain global and universal groups.
2. The target host resolves domain local groups and local SAM groups.
3. All resolved SIDs are embedded into the Groups array of the caller’s kernel Access Token.

---

What Is Possible

• Nesting Global Groups in Local Groups: A domain global group can be nested into a host’s BUILTIN\Administrators group.
• Multi-Tier Privilege Inheritance: An account inherits privileges through unlimited levels of nested group links.
• Live Inspection via whoami /groups: This utility reveals all active group SIDs embedded within the current process token.

---

What Is Not Possible

• Cross-Domain Members in Global Groups: Global groups strictly reject members originating from outside their parent domain.
• Assigning Domain Local Groups Across Foreign Domains: A domain local group cannot be placed into a resource DACL outside its home domain.
• Real-Time Token Updates Without Re-Authentication: Adding an account to a group while it has an active session does not alter the active access token. The user must log off and log back on to rebuild the token.

---

Forensic Artifacts

EventID: 4728 # Member Added to Global Security Group
TargetUserName: GG_Support
MemberSid: S-1-5-21-111111111-222222222-333333333-1145
SubjectUserName: Administrator

EventID: 4732 # Member Added to Local Security Group
TargetUserName: Administrators
MemberSid: S-1-5-21-111111111-222222222-333333333-1080 (GG_Support)

---

Key Takeaways

1. Effective access rights depend on transitive group nesting, not direct membership.
2. Standard LDAP memberOf queries omit nested groups: always execute recursive lookups.
3. Group membership alterations require a new logon session to update access tokens.
4. Monitoring Event IDs 4728 and 4732 is essential to detect group manipulation.

---

Cross References

• Doc 02: SID, RID and Windows Identity
• Doc 06: Windows Access Tokens and Security Context
• Doc 18: Cross-Domain Group Membership and Foreign Security Principals