☑️Windows User Privileges
Privileges Overview
User and group privileges are stored in a database and granted via an access token when a user logs on to a system. Privileges are used for Authorization in AAA. Privileges can be enabled or disabled. Every time a user wants to perform a privileged action the access token is checked against the database. Most privileges are disabled by default. Some can be enabled by opening an administrative cmd.exe or PowerShell console, while others can be enabled manually.
Windows Authorization Process
Security principals are anything that can be authenticated by the Windows operating system. They can be users, processes, groups etc.
At a high level, the decision of whether a subject can access an object it based on the security token of the subject (which includes their user SID, SIDs for any groups they are members of, privilege list, and other access information) which is compared against Access Control Entries (ACEs) within the object's security descriptor (which contains security information about a securable object such as access rights granted to users or groups).
Windows Rights and Privileges
Groups can give lots of privileges to accounts and users. Some of these groups are listed below:
Group
Description
Default Administrators
Domain Admins and Enterprise Admins are "super" groups.
Server Operators
Members can modify services, access SMB shares, and backup files.
Backup Operators
Members are allowed to log onto DCs locally and should be considered Domain Admins. They can make shadow copies of the SAM/NTDS database, read the registry remotely, and access the file system on the DC via SMB. This group is sometimes added to the local Backup Operators group on non-DCs.
Print Operators
Members can log on to DCs locally and "trick" Windows into loading a malicious driver.
Hyper-V Administrators
If there are virtual DCs, any virtualization admins, such as members of Hyper-V Administrators, should be considered Domain Admins.
Account Operators
Members can modify non-protected accounts and groups in the domain.
Remote Desktop Users
Members are not given any useful permissions by default but are often granted additional rights such as Allow Login Through Remote Desktop Services and can move laterally using the RDP protocol.
Remote Management Users
Members can log on to DCs with PSRemoting (This group is sometimes added to the local remote management group on non-DCs).
Group Policy Creator Owners
Members can create new GPOs but would need to be delegated additional permissions to link GPOs to a container such as a domain or OU.
Schema Admins
Members can modify the Active Directory schema structure and backdoor any to-be-created Group/GPO by adding a compromised account to the default object ACL.
DNS Admins
Members can load a DLL on a DC, but do not have the necessary permissions to restart the DNS server. They can load a malicious DLL and wait for a reboot as a persistence mechanism. Loading a DLL will often result in the service crashing. A more reliable way to exploit this group is to create a WPAD record.
User Rights Assignment
Depending on group membership, and other factors such as privileges assigned via domain and local Group Policy, users can have various rights assigned to their account. This Microsoft article on User Rights Assignment provides a detailed explanation of each of the user rights that can be set in Windows as well as security considerations applicable to each right. Below are some of the key user rights assignments, which are settings applied to the localhost. These rights allow users to perform tasks on the system such as logon locally or remotely, access the host from the network, shut down the server, etc.
SeNetworkLogonRight
Administrators, Authenticated Users
Determines which users can connect to the device from the network. This is required by network protocols such as SMB, NetBIOS, CIFS, and COM+.
SeRemoteInteractiveLogonRight
Administrators, Remote Desktop Users
This policy setting determines which users or groups can access the login screen of a remote device through a Remote Desktop Services connection. A user can establish a Remote Desktop Services connection to a particular server but not be able to log on to the console of that same server.
SeBackupPrivilege
Administrators
This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system.
SeSecurityPrivilege
Administrators
This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user assigned this user right can also view and clear the Security log in Event Viewer.
SeTakeOwnershipPrivilege
Administrators
This policy setting determines which users can take ownership of any securable object in the device, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.
SeDebugPrivilege
Administrators
This policy setting determines which users can attach to or open any process, even a process they do not own. Developers who are debugging their applications do not need this user right. Developers who are debugging new system components need this user right. This user right provides access to sensitive and critical operating system components.
SeImpersonatePrivilege
Administrators, Local Service, Network Service, Service
This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user.
SeLoadDriverPrivilege
Administrators
This policy setting determines which users can dynamically load and unload device drivers. This user right is not required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers run as highly privileged code.
SeRestorePrivilege
Administrators
This security setting determines which users can bypass file, directory, registry, and other persistent object permissions when they restore backed up files and directories. It determines which users can set valid security principals as the owner of an object.
We can list the privileges and rights of our current user with whoami /priv command. We might see some privileges that are there but disabled. We cannot use them. This PowerShell script which can be used to enable certain privileges, or this script which can be used to adjust token privileges.
So naturally, we would see more privileges granted to users as they are part of more and more groups.
Detection
This post is worth a read for more information on Windows privileges as well as detecting and preventing abuse, specifically by logging event 4672: Special privileges assigned to new logon which will generate an event if certain sensitive privileges are assigned to a new logon session. This can be fine-tuned in many ways, such as by monitoring privileges that should never be assigned or those that should only ever be assigned to specific accounts.
SeImpersonate and SeAssignPrimaryToken
In Windows, every process has a token that has information about the account that is running it. These tokens are not considered secure resources, as they are just locations within memory that could be brute-forced by users that cannot read memory. To utilize the token, the SeImpersonate privilege is needed. It is only given to administrative accounts, and in most cases, can be removed during system hardening. An example of using this token would be CreateProcessWithTokenW.
Legitimate programs may utilize another process's token to escalate from Administrator to Local System, which has additional privileges. Processes generally do this by making a call to the WinLogon process to get a SYSTEM token, then executing itself with that token placing it within the SYSTEM space. Attackers often abuse this privilege in the "Potato style" privescs - where a service account can SeImpersonate, but not obtain full SYSTEM level privileges. Essentially, the Potato attack tricks a process running as SYSTEM to connect to their process, which hands over the token to be used.
We will often run into this privilege after gaining remote code execution via an application that runs in the context of a service account (for example, uploading a web shell to an ASP.NET web application, achieving remote code execution through a Jenkins installation, or by executing commands through MSSQL queries). Whenever we gain access in this way, we should immediately check for this privilege as its presence often offers a quick and easy route to elevated privileges. This paper is worth reading for further details on token impersonation attacks.
SeImpersonate Example - JuicyPotato
Let's take the example below, where we have gained a foothold on a SQL server using a privileged SQL user. Client connections to IIS and SQL Server may be configured to use Windows Authentication. The server may then need to access other resources such as file shares as the connecting client. It can be done by impersonating the user whose context the client connection is established. To do so, the service account will be granted the Impersonate a client after authentication privilege.
In this scenario, the SQL Service service account is running in the context of the default mssqlserver account. Imagine we have achieved command execution as this user using xp_cmdshell using a set of credentials obtained in a logins.sql file on a file share using the Snaffler tool.
So after connecting to the MSSQL using mssqlclient.py we enable xp_cmdshell and check the privileges:
The command whoami /priv confirms that SeImpersonatePrivilege is listed. This privilege can be used to impersonate a privileged account such as NT AUTHORITY\SYSTEM. JuicyPotato can be used to exploit the SeImpersonate or SeAssignPrimaryToken privileges via DCOM/NTLM reflection abuse.
To escalate privileges using these rights, let's first download the JuicyPotato.exe binary and upload this and nc.exe to the target server. Next, stand up a Netcat listener on port 8443, and execute the command below where -l is the COM server listening port, -p is the program to launch (cmd.exe), -a is the argument passed to cmd.exe, and -t is the createprocess call. Below, we are telling the tool to try both the CreateProcessWithTokenW and CreateProcessAsUser functions, which need SeImpersonate or SeAssignPrimaryToken privileges respectively.
We will recieve a shell after that as NT AUTHORITY\SYSTEM.
PrintSpoofer and RoguePotato
JuicyPotato doesn't work on Windows Server 2019 and Windows 10 build 1809 onwards. However, PrintSpoofer and RoguePotato can be used to leverage the same privileges and gain NT AUTHORITY\SYSTEM level access. This blog post goes in-depth on the PrintSpoofer tool, which can be used to abuse impersonation privileges on Windows 10 and Server 2019 hosts where JuicyPotato no longer works.
SeDebugPrivilege
This right is given to Administrators by default and sometimes normal users are given this privilege instead of putting them in the Admin group. This privilege can be assigned via local or domain group policy. Any account that is assigned it will have access to critical operating system components. Developers might need to have this privilege in their day-to-day work so we should be aware of that when prioritizing accounts that we can access.
We can use ProcDump from the SysInternals suite to leverage this privilege and dump process memory. A good candidate is the Local Security Authority Subsystem Service (LSASS) process, which stores user credentials after a user logs on to a system.
This is successful, and we can load this in Mimikatz using the sekurlsa::minidump command. After issuing the sekurlsa::logonPasswords commands, we gain the NTLM hash of the local administrator account logged on locally. We can use this to perform a pass-the-hash attack to move laterally if the same local administrator password is used on one or multiple additional systems (common in large organizations).
Suppose we are unable to load tools on the target for whatever reason but have RDP access. In that case, we can take a manual memory dump of the LSASS process via the Task Manager by browsing to the Details tab, choosing the LSASS process, and selecting Create dump file. After downloading this file back to our attack system, we can process it using Mimikatz the same way as the previous example.
RCE as SYSTEM
We can also leverage SeDebugPrivilege for RCE. Using this technique, we can elevate our privileges to SYSTEM by launching a child process and using the elevated rights granted to our account via SeDebugPrivilege to alter normal system behavior to inherit the token of a parent process and impersonate it. If we target a parent process running as SYSTEM (specifying the Process ID (or PID) of the target process or running program), then we can elevate our rights quickly. Let's see this in action.
First, transfer this PoC script over to the target system. Next we just load the script and run it with the following syntax [MyProcess]::CreateProcessFromParent(<system_pid>,<command_to_execute>,""). Note that we must add a third blank argument "" at the end for the PoC to work properly.
First, open an elevated PowerShell console (right-click, run as admin, and type in the credentials for the jordan user). Next, type tasklist to get a listing of running processes and accompanying PIDs.
Here we can target winlogon.exe running under PID 612, which we know runs as SYSTEM on Windows hosts.
So we run:
We could also use the Get-Process cmdlet to grab the PID of a well-known process that runs as SYSTEM (such as LSASS) and pass the PID directly to the script, cutting down on the number of steps required.
SeTakeOwnershipPrivilege
This privilege assigns WRITE_OWNER rights over an object, meaning the user can change the owner within the object's security descriptor. Accounts with this right can take owner ship of any securable object. Administrators have this right by default. It may also be assigned a few others such as SeBackupPrivilege, SeRestorePrivilege, and SeSecurityPrivilege to control this account's privileges at a more granular level and not granting the account full local admin rights.
It is worth understanding in-depth, especially since we may also find ourselves in a scenario in an Active Directory environment where we can assign this right to a specific user that we can control and leverage it to read a sensitive file on a file share.
Notice from the output that the privilege is not enabled. We can enable it using this script which is detailed in this blog post, as well as this one which builds on the initial concept.
Example
Lets say we find a company share where there are both private and public shares. We can access them all as a standard domain user. But one particular share gives us access denied, a file named creds.txt. We try to find more information about this file:
We can see that the owner is not shown, meaning that we likely do not have enough permissions over the object to view those details. We can back up a bit and check out the owner of the IT directory.
We can see that the IT share appears to be owned by a service account (sccm_svc) and does contain a file cred.txt with some data inside it.
Taking Ownership
Now we can use the takeown Windows binary to change ownership of the file.
We can confirm ownership using the same command as before. We now see that our user account is the file owner.
Modifying the file ACL
We may still not be able to read the file and need to modify the file ACL using icacls to be able to read it.
Let's grant our user full privileges over the target file.
If all went to plan, we can now read the target file from the command line, open it if we have RDP access, or copy it down to our attack system for additional processing (such as cracking the password for a KeePass database.
When to Use?
Some local files of interest may include:
We may also come across .kdbx KeePass database files, OneNote notebooks, files such as passwords.*, pass.*, creds.*, scripts, other configuration files, virtual hard drive files, and more that we can target to extract sensitive information from to elevate our privileges and further our access.
Last updated