Tip: Run process in system account (sc.exe)

I have recently been doing some research on windows services, and have been working on some command line parsing, so while experimenting I thought of a nice little trick to run a process in the System account (And have the window be displayed) without using PsExec -sid


Involves:
1. sc.exe - Manages windows service
2. net.exe - start windows service
3. cmd.exe - Runs the application


Command (Copy and paste in command prompt or the run dialog) - This will run calc.exe

cmd /c sc create -- binPath= "cmd /c start calc" type= own type= interact & net start -- & sc delete --

A path with quotes: The \" = a quote (quotes would be needed for paths with spaces, but this is just an example)
Note: Copy and paste this one into cmd.exe or a batch(.bat) file, because the run dialog will not translate the \" escape chars.

cmd /c sc create -- binPath= "cmd /c start  \"\"  \"C:\windows\regedit.exe\" " type= own type= interact & net start -- & sc delete --

So how does it work?
1. The & symbol tells cmd.exe to parse treat the text that follows as if it were a new line in a batch file (It basically is a new line delimiter which allows multiple commands to be combined into 1 line)

To break it down:

• Create Service - sc create -- binPath= "cmd /c start calc" type= own type= interact
• Start Service net start -- (This could also be done with: sc start --)
  
• Delete Service sc delete --
  

2. Variables:

• Service Name: --
  
• App to run: calc

3. How it works:

• cmd /c - allows us to pass in parameters to cmd (Without this initial part, it will work if you copy & paste in cmd.exe, but not in the Run Dialog. So this fixes it)

• sc create binPath= - Since cmd.exe does not respond to service commands, when the SCM runs the app in binPath (Reg = ImagePath) then it will terminate it, when not responding in a timely fasion, therefore cmd.exe cannot be used. It has to call something else which in this case is calc.exe

• sc create type= This one took a while to figure out. The inital problem is the Window Station in which cmd.exe is launched in (which in turn is inherited by calc.exe (its child process)). Luckily after reading Mark's Windows Internals e4, I was able to solve it by specifying the service as being Interactive. (Experimenting, it actually has to be BOTH interactive(256) and own(16) (256|16 = 272) . Basically what this allows is for the windows to run in \WinSta0\Default (The current user's desktop, allowing the window to be displayed.) After some research from being frustrated that sc would not accept type =own|interact, I found out that it allows us to specify it again, and instead of overwriting Type (dword) it bitwise-ORs it (Adds it). Problems Solved!

• net start - start the service (probably calls StartService)

• cmd.exe runs with the command line (CL) of start [File] in which start probably calls ShellExecute (Its ashame that MS didn't allow start to specify a SW_* commands (like hide). Although it does allowing us to min/max windows. cmd.exe opens the app/file, the SCM terminates cmd.exe for not responding in a timely fashion to its commands, and the window is now shown to the user.

• sc delete - Finally we clean up our path by removing the service
  

This is just a useful trick I thought I would share. Feedback is welcome.
Feel free to give it a shot and copy & paste that command in the run dialog. (Check the process's account either using TaskMgr or PE :P)
I wonder if in vista this makes UAC mad, haha.

-Matt


Update:
To make this work on paths with spaces, the start command needs to be changed from start calc to start "" calc. The other way works but as soon as you give start a path with spaces in it, it will not properly work, and I forgot about that until now.

The other day I finally solved that nagging problem  by using start /? and studying its commands. Apparently start's first parameter is the CreateProcess's WindowTitle parameter, inwhich if you specify a path like "C:\Documents and Settings\app.exe" a console windows will open with the title C:\Documents. To Fix this we must specify start "" "C:\Documents and Settings\app.exe"
(Yes start requires quotes be supplied for paths with spaces)

The problem is the 2 quotes within those quotes for binPath is not playing nice with cmd.exe. Usually you can use the ^ symbol to have cmd print in that special character but for some reason it is not working. I will try to figure this out later, perhaps by setting a variable or something.


Update 2: (11-30-08)

To use quotes in the path, I wasn't thinking straight and you can use the C-language escape sequence \"

Ex:
binPath= "cmd /c start \"\" \"calc\""

Which will translate to having an image path of:
cmd /c start "" "calc"


Enjoy!
-Matt


Edited by Matts_User_Name - 18 June 2009 at 9:26am

Thank you. I felt like I needed to get that out of my head so I remembered it (Usually when I write something out it sticks in better)

Ah yes I have been working with similar things.
An application in VB6 that I created to run an application as a different user and in a different desktop.

I initially created it because of this RAT tool used to help others with comp problems called Radmin. It uses this "Telnet" which it opens cmd.exe on their side and waits for commands. The problem was that fact that I needed to change the desktop, if I wanted to run an application and display it to the user while not specifically controlling their mouse.  The WinStation was not WinSta0, so I implemented some code I saw a while back that worked on impersonation. An Amazing feature.

Its called UR (UserRun)
Basically it works on various concepts like CreateProcessAsUser, Thread impersonation, Token DACL modification, Process username searching, ShellExecute with App/File & CmdLine parsing. A work of art I am creating =] I currently somewhat consider it a little more powerful than PsExec.

Works great, but I am trying to make it perfect, haha. Maybe if I get some time to clean up the code Ill post it here.

Hey there. I did receive your PM/Email, and yes you probably should have created a different thread and referred to this one, but no worries, this works too.

Hmm okay so the problem is CreateProcessAsUser is returning ERROR_DIRECTORY.

I did a lot of research on windows security back in May 08 so hopefully I can still help.
If I recall correctly, that typically is not the error that is spit out if its a permissions issue, but just to be sure, you need to do the following.

CreateProcessAsUser MUST have
The Token-Specific permission called: TOKEN_ASSIGN_PRIMARY
It ALSO MUST have a process token privilege SE_ASSIGNPRIMARYTOKEN_NAME ("SeAssignPrimaryToken")
(This permission does not have to be enabled, since CPAU is actually kind enough to do that for us, as long as it exists in our token).

In most situations "SeAssignPrimaryToken" is only given to processes running under the system account so therefore we would need to implement a fix. The only way to add a removed privilege to a process's token is by modifying a kernel data structure (_EPROCESS). This is known as DKOM, but is much easier said than done.
The other solution is to re-run our app in a different security context (user account) or have another process do the dirty work for us (such as a service)

Here are possible solutions:
1. Use thread impersonation (This means we can magically change the security context of a thread inside our process to run in the security context of another process (Ex: Winlogon) This by far is my favorite method!
Just note: To use ImpersonateLoggedOnUser, the token which we open, we must be able to have the TOKEN_DUPLICATE Token-Specific access right in order for it to work.  Luckily this never really is a problem (Ex: If we want to impersonate Winlogon's token.) Just ensure that you have SeDebugPrivilege enable. This can be quickly done by calling RtlAdjustPrivilege(20, 1, 0, 0) in ntdll or the other method in kernel32.dll using AdjustTokenPrivileges

2. Create a service and have it run applications in our Desktop.

3. Create a DLL to inject(map) into some other process, in which it would execute CreateProcess call(s) in its DllMain




But like I said, I am not sure if the issue you are having is permissions, yet the only other thing I can think of which would cause this is the CreateProcess behavior with its CommandLine parameter: It requires that it is in a variable, and not be passed as a literal string (which is constant).
For some reason, it internally modifes and then changes back to normal this param, and that means if you pass it something like "cmd.exe" instead of some var like sApp, then it will fail for sure.
Also ensure you are passing StartupInfo and Process_Information properly (pass by reference, meaning pointers to them)
Note: SI and PI dont require any setup EXCEPT: SI's 1st member "cb" MUST be given a size.

The last thing I can think of is that you either declared CreateProcess (Or CreateProcessAsUser) improperly in C# (I am assuming it is like VB and isn't magically imported by headers like in C/C++) or that you not giving it a null string for the App Path, and possibly instead giving it a 0?

(On a side note not related to your problem, remember the close the hThread and hProcess in PI after you get your CP call working to avoid a handle leak if they are being constantly called)


I somehow doubt I helped solved your problem (but hopefully you found this of some value once you get CP bulletproof)
I would try looking around google for: CreateProcess ERROR_DIRECTORY

I found this, but looking over it, it doesn't seem too helpful
 http://social.technet.microsoft.com/Forums/en-US/vcgeneral/thread/bab4fc1d-e26b-4b4c-bf10-494199012f8d


If this is of any value here is a function I made in VB a while back which allows me to run a process as any specified user (As long as I am logged on as admin) Note: This is just the function, not the whole source :P
I guess if anyone really is interested in the source you can PM me.

Public Sub RunAsEx(ByVal sApp As String, ByVal sData As String, ByVal ra As eRunAsData, si As STARTUPINFO)     ' --Purpose: Runs a process within the context of another user that is currently logged onto the machine.     ' --Custom functions used: ModifyPTokenAccess, FindUserProcess, FindAnActiveUser, NS (vbNullString), CloseH, OpenPTokenPID     Dim hToken As Long              'Handle - Token     Dim lPID As Long                'PID (Found from user input)     Dim lPermissions As Long        'Token permissions     'Dim si As STARTUPINFO          'CP Required param     Dim pi As PROCESS_INFORMATION   'CP Required param     '----         If ra = ra1PID Then lPID = Val(sData)     If ra = ra2User Then lPID = FindUserProcess(sData)     If ra = ra3FindUser Then lPID = FindUserProcess(FindAnActiveUser)         'lPermissions = TOKEN_ALL_ACCESS     lPermissions = TOKEN_QUERY Or TOKEN_DUPLICATE Or TOKEN_ASSIGN_PRIMARY     Call ModifyPTokenAccess(lPID, lPermissions, True)                           'Modify token permissions - Enable TOKEN_DUPLICATE & TOKEN_ASSIGN_PRIMARY     hToken = OpenPTokenPID(lPID)                                                'Open process & token     Call ImpersonateLoggedOnUser(hToken)                                        'Change the context of this thread to the other process' modified thread (Inherit its permissions and access rights)         si.cb = Len(si)     Call CreateProcessAsUser(hToken, NS, sApp, ByVal 0, ByVal 0, 0, 0, NS, NS, si, pi)  'Run the process (using our newly acquired security context)     Call RevertToSelf                                                                   'Stop thead impersonating (Change our thread's context back to normal)         Call CloseH(hToken)                                 'Close token     Call CloseH(pi.hProcess):  Call CloseH(pi.hThread)  'Must also close the process and thread handle         '---------     'Notes:     '   1.  ImpersonateLoggedOnUser will work if the token just has TOKEN_DUPLICATE. CreateProcessAsUser is what requires the TOKEN_ASSIGN_PRIMARY access right. Obviously TOKEN_QUERY is needed to get the token informaiton.     '       CreateProcessAsUser also requires the AssignPrimaryToken privilege (SE_ASSIGNPRIMARYTOKEN_NAME), but luckily it is nice enough to enable it for us, if it is disabled.     '     '   2.  When CreateProcess is called, the return data (PI) has 2 handles (process & thread) that need to be closed. (Found with PE - Process Explorer)     '     '   3.  Uses: 1. Run a process in the System account.       2. Run a process within the contexts of another user     '     '   4.  By default, the access rights that an admin user has to processes running in the System account context, have the      Token Rights --> TOKEN_: Query, Execute, & Read.    and Standard Rights --> READ_CONTROL & WRITE_DAC     '           Because of this, ModifyPTokenAccess needs to be called inorder to enable TOKEN_DUPLICATE & TOKEN_ASSIGN_PRIMARY (This is possible because the St-Right: WRITE_DAC, which allows us to change the DACL of the token)     '           Discovered with: ATI - Acciess Token Information (Custom tool writen to view Process Token access rights)     '     '   5. This function probably poduces similar behavior to SHCreateProcessAsUserW (not implemented in XP)     '--------- End Sub

Maybe this will help you or anyone else reading this. (Even though it is in VB6)

Even though I do not know C#, I am starting to learn C++ so I might be able to figure out the similar syntax and provide any suggestions to where I think the problem might be in.
Perhaps you could post the declare and the call to CreateProces/CreateProcessAsUser.

Also, thinking about it now, have you ever tried CreateProcess in a C# app, and if so were the results the same or did it work?




Edited by Matts_User_Name - 22 January 2009 at 12:36am

Here's what you need to do in order to run a program as SYSTEM:

1. LogonUser with NT AUTHORITY\SYSTEM
2. NtSetInformationToken - set the session ID of the token to whatever you need it to be
3. CreateProcessAsUser while setting Desktop in the ProcessInformation struct to Default\WinSta0

That's it, except for the fact that LogonUser requires TcbPrivilege and CreateProcessAsUser requires AssignPrimaryTokenPrivilege. That means you'll have to run the program as a service first. SYSTEM has both these privileges, but only TcbPrivilege is enabled by default. That means you'll have to enable AssignPrimaryTokenPrivilege.

You only need to change the DACLs of the Window Station and Desktop if you're running the program as something other than SYSTEM - SYSTEM should have full rights to them already.


Edited by wj32 - 22 January 2009 at 2:10am

Isn't LogonUser for the SYSTEM account a little overkill when it is already logged on (Processes like winlogon.exe are running under its account and security context)?
I would assume Thread Impersonation would possibly be best instead of logging on the user.

Indeed normal (administrator) account do not have the SeAssignPrimaryToken and SeTcbPrivilege meaning all process tokens will have these removed, although we can readd them into our token of 1 thread in our process by use of impersonation.

Through AdjustTokenPrivileges, you can enable a disabled privilege, disable an enabled privilege (you can't disable a privilege that's enabled by default though), or remove any privilege permanently. You can't add privileges to a token, so removing a privilege cannot be reverted.

Hmm, I am not sure about that one. In my experience (Running in an Administrator account on XP) using ATP you can modify (Disable, Enable, Remove) any privilege held in a process' token (Meaning those that are "Enabled by Default" --> Meaning the process started with this Privilege enabled)


Also, I am not sure where I ment to imply that having a privilege is a permission and having it enabled is a privilege but I ment:

1. To have a privilege: The privilege is contained  inside our process token. We can Disable, Enable, or remove it.
2. To have a privilege enabled: We are able to take advantage of its powers (Ex: Once SeDebugPrivilege is enabled, it allows us to bypass all permission checking when opening processes and threads)
Tokens are process-specific while Permissions are object-specific (meaning processes, tokens, threads, files etc)



@doug
With method 2 or 3:
You can have the Service or Injected dll call CreateProcess and specify the specific Window Station and Desktop (Ex: Default is WinSta0\Desktop) for which to run the process in. (When started it will then inherit all the token privileges from the calling process)

Ill try to post some code on that when I get home (at school now, arg!)



Edited by Matts_User_Name - 22 January 2009 at 6:21pm