PsExec

PsExec Security
You should be aware of several ways in which PsExec interfaces with Windows security. By default, the process you execute on the remote system impersonates the account from which you run PsExec on the local system. Impersonation is somewhat restricted from the perspective of security—the remote process doesn't have access to any network resources, even those that your account typically would be able to access. If the account in which you're running doesn't have local administrative privileges on the remote system, the process you want to run requires access to network resources, or you want to run a process in a different account, then use PsExec's -u switch to provide an alternative account name. For example, you could enter the command

psexec \\remote

-u remote\administrator

-p adminpass ipconfig

to run Ipconfig under the Administrator account on the remote machine. Use the -p switch to enter the password for the account you specified with the -u switch. If you omit the -p switch, PsExec prompts you to enter the password (for security reasons, PsExec doesn't echo the password you enter to the screen).

If you specify alternative credentials, the remote process runs with those credentials and will have access to network resources that the alternative account can access. To run in a different account, PsExec must use that account to log on to the remote system. PsExec therefore requires the password on the remote system and sends the password in clear text from the local system. You need to be aware of this fact if unauthorized network sniffers could intercept traffic between the local and remote system.

You can also run the remote process in the System account, under which Windows services and core Windows processes, such as Winlogon and the Local Security Authority Subsystem Service (LSASS) are executed. The System account has powerful privileges. Some file-system and registry resources have default security settings that permit access only from the System account—examples are the HKEY_LOCAL_MACHINE\SAM registry subkey and the \System Volume Information directory that's present on each volume of all Windows 2000 or later systems.

For example, if you've ever been curious about the contents of the SAM subkey, which appears empty in regedit because regedit can navigate the subkey only under the System account, you can use PsExec similarly to the way you use the Runas command (which is available on Win2K and later) to run regedit under the System account. The command is this:

psexec -s -i

c:\windows\regedit.exe

Note that the command doesn't include a remote computer name and does include the -i (interactive) switch. When you enter the command, regedit will appear on your desktop running in the System account, and you'll be able to look inside the HKEY_LOCAL_MACHINE\SAM and HKEY_LOCAL_MACHINE\SYSTEM subkeys. The -i switch is what causes regedit to appear on the console desktop, and it's typically useful only when you want to run a GUI application on the local system where you can interact with it.

A last security note relates to viruses. Several viruses use PsExec to propagate within a network, and as a result, several major antivirus products flag PsExec as a Trojan horse program or a worm. Remember that PsExec works on remote systems only if it runs within an account that has administrator group membership on the remote system. In other words, unless the account from which you run it has administrative access to a remote system, PsExec won't be able to execute a process on the remote system. In addition, PsExec's functionality can be achieved in other ways; thus, PsExec is only a convenience for virus writers, who could otherwise easily implement the functionality that PsExec provides.

Inside PsExec
PsExec starts an executable on a remote system and controls the input and output streams of the executable's process so that you can interact with the executable from the local system. PsExec does so by extracting from its executable image an embedded Windows service named Psexesvc and copying it to the Admin$ share of the remote system. PsExec then uses the Windows Service Control Manager API, which has a remote interface, to start the Psexesvc service on the remote system.

The Psexesvc service creates a named pipe, psexecsvc, to which PsExec connects and sends commands that tell the service on the remote system which executable to launch and which options you've specified. If you specify the -d (don't wait) switch, the service exits after starting the executable; otherwise, the service waits for the executable to terminate, then sends the exit code back to PsExec for it to print on the local console.

End of Article

   Previous  1  [2]  Next