Object owners retain the ability to modify object security descriptors, regardless of permissions on the object’s DACL.
This clip shows an example of abusing this edge:
To change the ownership of the object, you may use the Set-DomainObjectOwner function in PowerView.
To abuse this privilege with PowerView’s Set-DomainObjectOwner, first import PowerView into your agent session or into a PowerShell instance at the console. You may need to authenticate to the Domain Controller as the user with the password reset privilege if you are not running a process as that user.
To do this in conjunction with Set-DomainObjectOwner, first create a PSCredential object (these examples comes from the PowerView help documentation):
$SecPassword = ConvertTo-SecureString 'Password123!' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('TESTLAB\\dfm.a', $SecPassword)
Then, use Set-DomainObjectOwner, optionally specifying $Cred if you are not already running a process as the user with this privilege:
Set-DomainObjectOwner -Credential $Cred -TargetIdentity "Domain Admins" -OwnerIdentity harmj0y
Now, with ownership of the object, you may modify the DACL of the object however you wish. For more information about that, see the WriteDacl edge section.
This depends on the target object and how to take advantage of this privilege.
When using the PowerView functions, keep in mind that PowerShell v5 introduced several security mechanisms that make it much easier for defenders to see what’s going on with PowerShell in their network, such as script block logging and AMSI. You can bypass those security mechanisms by downgrading to PowerShell v2, which all PowerView functions support.
Modifying permissions on an object will generate 4670 and 4662 events on the domain controller that handled the request.