# Owns

## Configuring

### Prerequisite

{% content-ref url="page-2" %}
[page-2](https://ad-lab.gitbook.io/building-a-windows-ad-lab/vulnerabilities-and-misconfigurations-and-attacks/active-directory-attacks/acl-abuses/page-2)
{% endcontent-ref %}

### Configuring

Nothing need to be configured to abuse this since we set the Owner of the object during the attack in the "Write Owner" section. If you would like to configure this it can be configured the same way as we configured "Write Owner".

## Attacking

### How it works

If you are "Owner" of a object, you can change the DACL of the object. Meaning you can give any object "GenericAll" or any other specific permissions.

### Tools

* [PowerView](https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1)

### Executing the attack

1. We will continue the attack from where we left off from the page "Write Owner".

{% content-ref url="page-2" %}
[page-2](https://ad-lab.gitbook.io/building-a-windows-ad-lab/vulnerabilities-and-misconfigurations-and-attacks/active-directory-attacks/acl-abuses/page-2)
{% endcontent-ref %}

2\. We just made the user `sa_sql` owner of the computerobject `DATA01`. The next step is to write to the DACL of the computerobject and give `sa_sql` genericall permission. This can be done with PowerView and the cmdlet `Add-DomainObjectAcl`.

```
Add-DomainObjectAcl -Domain secure.local -Credential $creds -TargetIdentity DATA01 -PrincipalIdentity sa_sql -Rights All -Verbose
```

![](https://1033393870-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPqGbN7FCY7Xh4OkOtvin%2Fuploads%2FyKgglEdaGcbKgy56uQ6g%2Fimage.png?alt=media\&token=ba046121-303b-4429-a5ab-cf11366dbd81)

3\. PowerView gives some errors but it seems like it found the correct information and tried to set the ACL's. We can check this by running BloodHound again or querying the Domain Controller for all ACL's from DATA01 and filter. First we have to get the objectsid from the user `sa_sql` and then we can use the cmdlet `Get-DomainObjectACL` to query all the ACL's for `DATA01`.

```
Get-DomainUser -Domain secure.local -Credential $creds -Server 10.0.0.100 sa_sql | Select-Object samaccountname, objectsid
Get-DomainObjectAcl -Domain secure.local -Credential $creds -Server 10.0.0.100 -SamAccountName data01 | ? {$_.SecurityIdentifier -eq "S-1-5-21-1498997062-1091976085-892328878-1106"}
```

![](https://1033393870-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPqGbN7FCY7Xh4OkOtvin%2Fuploads%2Fiih2Tifrdfj2Fn777ULj%2Fimage.png?alt=media\&token=f7aff5c2-efb8-4de2-abd3-20a5276129d5)

From the output we can see that the user `sa_sql` has GenericAll permission on `DATA01`. Since we own the lab we can also check it out on the Domain Controller, the same way as we configured the Owner permissions. And it has all the permissions:

![](https://1033393870-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPqGbN7FCY7Xh4OkOtvin%2Fuploads%2FhDxfknJRTadfnoAiop9P%2Fimage.png?alt=media\&token=bb288193-bdf6-4c23-829a-bfaa8aa51739)

4\. The next step to abuse the GenericAll permissions page which will send you to two more pages. To abuse the privileges for `DATA01` the computeraccount takeover attack should be executed:

{% content-ref url="genericall" %}
[genericall](https://ad-lab.gitbook.io/building-a-windows-ad-lab/vulnerabilities-and-misconfigurations-and-attacks/active-directory-attacks/acl-abuses/genericall)
{% endcontent-ref %}

{% content-ref url="../delegation-attacks/resource-based-constrained-delegation/computeraccount-takeover" %}
[computeraccount-takeover](https://ad-lab.gitbook.io/building-a-windows-ad-lab/vulnerabilities-and-misconfigurations-and-attacks/active-directory-attacks/delegation-attacks/resource-based-constrained-delegation/computeraccount-takeover)
{% endcontent-ref %}

### Cleanup

1. Login to `DC03` as `Administrator` with the password `Welcome01!`.
2. Open "Active Directory Users and Computers" and open the "Computers" section and open the "Properties" for the computerobject `DATA01`. Make sure the "Advanced Features" are enabled.
3. Open the "Security" tab and click on "Advanced". Change the owner to the group "Domain Admins" 
4. Delete the `sa_sql` user from the permission entries. Then add it again and give it the permissions "Modify Owner" like we did in the "Write Owner" section to configure the vulnerability. So its ready to be abused again. (Which is easier then deselecting everything)

![](https://1033393870-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPqGbN7FCY7Xh4OkOtvin%2Fuploads%2FkArZoYKnvbjaEa8y3HOW%2Fimage.png?alt=media\&token=d06c0f86-c001-4b2e-a0fc-c0c360da54da)

## Defending

### Recommendations

### Detection

## References

{% embed url="<https://bloodhound.readthedocs.io/en/latest/data-analysis/edges.html#owns>" %}