Using psexec (split from wifi thread)

[Isaac]

@Gaztech

I'm trying to run some psexec commands (beginner at it). I noticed in this thread you are using psexec. I wondered if you had any experience yet with using it on the local machine, to run an executable and use that executable to open a file. (for example, to fire up excel.exe and open an .xlsx). AND I want to impersonate other credentials (like runas).

I had some luck incrementally, but my commands stopped working as soon as I added the file path after the executable path. I'm sure I just don't quite understand the syntax, have been studying a few tutorial websites but came up short.

This works (fires up Notepad.exe, just a blank one)

"C:\Users\UserName\OneDrive - OrgName\Desktop\RunAs Test\psexec.exe" -i -u domain\UserName -p Password C:\Windows\system32\notepad.exe

So by this time I know my syntax for:

• referring to psexec path
• interactive switch
• username & password for the account
• referring to notepad exe path

...are all correct.

This does nothing (except pop back with the standard, 3-line boilerplate copyright stuff....but with NO mention of ANY return/result/error code (whereas the successful one above, does come back with "C:\Windows\system32\notepad.exe exited with error code 0."

"C:\Users\UserName\OneDrive - OrgName\Desktop\RunAs Test\psexec.exe" -i -u domain\UserName -p Password "C:\Windows\system32\notepad.exe \\server\data\mpsc-users\UserName\Test\sadf.txt"

 

[Gaztech]

@Gaztech

I'm trying to run some psexec commands (beginner at it). I noticed in this thread you are using psexec. I wondered if you had any experience yet with using it on the local machine, to run an executable and use that executable to open a file. (for example, to fire up excel.exe and open an .xlsx). AND I want to impersonate other credentials (like runas).

I had some luck incrementally, but my commands stopped working as soon as I added the file path after the executable path. I'm sure I just don't quite understand the syntax, have been studying a few tutorial websites but came up short.

This works (fires up Notepad.exe, just a blank one)

"C:\Users\UserName\OneDrive - OrgName\Desktop\RunAs Test\psexec.exe" -i -u domain\UserName -p Password C:\Windows\system32\notepad.exe

So by this time I know my syntax for:

• referring to psexec path
• interactive switch
• username & password for the account
• referring to notepad exe path

...are all correct.

This does nothing (except pop back with the standard, 3-line boilerplate copyright stuff....but with NO mention of ANY return/result/error code (whereas the successful one above, does come back with "C:\Windows\system32\notepad.exe exited with error code 0."

"C:\Users\UserName\OneDrive - OrgName\Desktop\RunAs Test\psexec.exe" -i -u domain\UserName -p Password "C:\Windows\system32\notepad.exe \\server\data\mpsc-users\UserName\Test\sadf.txt"

Hi,

I'm not sure what the admins think of this diversion from the subject thread - should be bumped to another post really - but I'll continue just to answer your query...

First of all, whilst psexec is a very powerful little program, there are many other ways to start programs. Using psexec is a bit like a hammer to crack a nut.

I only use psexec when there is no other way to do it. There are a few caveats to use: psexec MUST be somewhere on the main system path. The system must be able to "see" the program no matter where you are. If you don't want to add its location to the main path then simply put is somewhere like the system32 folder. Windows can always see that. As an aside, you can always put other executables there if you use them routinely and they will run right away.

If you are running psexec from within a batch file, then do all the main "donkey work" such as setting directories and paths before psexec is run. This makes the psexec command line much shorter and makes it less prone to errors. I think you are starting from a place which is too complex to debug this. Start by checking to see if psexec runs a simple program (without any options like opening files as well) and gradually expand it to more complex locations like opening file and other operations. At some point it won't work - then debug why. When you find out, move on to the next bit.

We all know that syntax is a fickle thing and just a dot or comma can break it. Start simple and you'll get to where you need to be.

For instance, you state "C:\Windows\system32\notepad.exe" in part of your command line. This is correct but if your paths are set up correctly you should be able to simply write "psexec notepad.exe" as the notepad program is also in the system path. Putting things you need in the system path often helps to clean up scripts. Of course, don't put too much in there as you don't want to create too much clutter but it does help to script things if you can just call the application.

If you want to use psexec to elevate permissions, this is where you will find some issues. There are ways around it but it's best not to create scenarios where you need to elevate.

I would use a batch file to do what you need. You can enter very specific commands into it, including psexec and much can be achieved without making things too complex. Try using START within the batch to run things instead of psexec. It's not as powerful but in a batch it can be very useful. CALL can also be useful but is not used now as often as it used to be.

I'm sure others can add some more input to this but any more posts here will probably flag admin to move this elsewhere.

I wish you luck. PM me if you get stuck.

 

[Isaac]

There are a few caveats to use: psexec MUST be somewhere on the main system path. The system must be able to "see" the program no matter where you are. If you don't want to add its location to the main path then simply put is somewhere like the system32 folder. Windows can always see that

I appreciate the comment, but I am using it successfully from my desktop (as a sample/explorative move) by simply referring to its full path - see my code bit prefaced by the title "this works".

I think you are starting from a place which is too complex to debug this. Start by checking to see if psexec runs a simple program (without any options like opening files as well) and gradually expand it to more complex locations like opening file and other operations. At some point it won't work - then debug why. When you find out, move on to the next bit.

That's precisely what I am doing (see the bit of code I posted prefaced by "this works" - it's just opening Notepad, without opening a file as well) ...
I already got things working incrementally and when adding the file name, that's when it stopped working.

First of all, whilst psexec is a very powerful little program, there are many other ways to start programs. Using psexec is a bit like a hammer to crack a nut.

I only use psexec when there is no other way to do it

From my research, psexec is perfect for this task. Keep in mind that, like I mentioned in my post, I am needing to use psexec to change permissions--that's my whole point. Regular command line stuff in the cmd window will not work to fully pass all credentials to another account, but psexec will.....hence using psexec.

If you're not sure what is wrong with my current psexec, which is only a single line...I'll keep hunting....either way thanks for looking & taking the time to respond.

 

[cheekybuddha]

Looking at the documentation, this signature is:

psexec [\\computer[,computer2[,...] | @file]][-u user [-p psswd][-n s][-r servicename][-h][-l][-s|-e][-x][-i [session]][-c executable [-f|-v]][-w directory][-d][-<priority>][-a n,n,...] cmd [arguments]

You look like you have passed cmd plus its arguments as a single string.

Did you try:

"C:\Users\UserName\OneDrive - OrgName\Desktop\RunAs Test\psexec.exe" -i -u domain\UserName -p Password "C:\Windows\system32\notepad.exe" "\\server\data\mpsc-users\UserName\Test\sadf.txt"[code]

(You can probably omit a lot of the quotes, they are really only needed when there is a space in the string)