PsExec works only with "runas /netonly", not with -u and -p parameters

Question

What I mean:

If I...

1. run runas /netonly /user:computername\username cmd

2. enter the password for the local admin account "username"

3. then type psexec \\computername cmd

I now have a working shell and can run commands as the local admin user on the remote machine.

However, trying to run this without the runas... and instead with the username and password arguments of psexec returns an access denied error.

Example below:

psexec \\computername -u username -p password cmd

Access Denied

Note: Others seem to also have this issue. My refined questions:

• Is this intended behavior?
• Why even have the -u and -p?

I have also tried disabling the firewall on both my machine and the target machine, and adding the registry key listed here.

Attest

Answer 1

When you initiate a connection with PsExec.exe, it tries to use the credentials you are currently authenticated with to copy the PSEXESVC to the \\$machine\ADMIN$\System32 share VIA SMB, which enables the communication with your PsExec.exe and the $machine's service.

If your currently logged in user account does not have access to \\$machine\ADMIN$\System32 and the ability to install/start services, then this won't work.

I'm assuming if you have access with your user account that this would work.

Here is a very interesting article from 2004 on reverse-engineering of the original implementation. I am pretty sure it has changed in that time with Windows 7 & Windows 10.

Dallas

I see. That would explain why using runas works. But why then is there an option to pass local usernames and passwords along with psexec? – Attest

@MinimumEntropy I really don't know, but I went through this same problem that wasted a lot of my time a couple weeks ago. – Dallas