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.
In the case of the Backup Operators group, it has the following two privileges assigned by default:
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 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 -showSecurityDescriptorUI
This will open a window where you can add thmuser2 and assign it full privileges to connect to WinRM:
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.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /t REG_DWORD /v LocalAccountTokenFilterPolicy /d 1
If you check your user's group memberships, it will look like a regular user. Nothing suspicious at all!