Why is it possible to manage services through the SMB protocol in Windows?
The SMB protocol is made for managing network shares (files and directories) and printers, so what mechanism in the protocol makes it possible to interact with services?
From the sysinternals article:
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.
It's a very creative hack. psexec uses SMB to copy its own EXE to the target machine. Then uses the Windows Service Control Manager API (different protocol) to start the exe on the remote machine. The missing deail is the exact API that launches psexec on the remote machine. I did some digging and discovered that the OpenSCManager API is what facilitates this. Once a handle to the remote machine's service control manager is obtained, APIs such as CreateService and StartService can be used to start the remote process.
So it's not the SMB protocol per se. More specifically, it's the Windows Service Control Manager that makes it possible to do things similar to psexec.