[danielbarla]

The link you posted leads to a more detailed article by the developer, where he mentions some internals:

> 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.

[zxcmx]

PsExec will also most likely freak out your security operations team if it’s not part of your expected workflow (well, and if you have a decent SIEM, and it’s actually monitored...)

[rgray805]

What stuck out to me was the part that said, "A similar attack affected the city’s phone system last year, shutting down automated dispatches for 911 and 311 calls." Clearly what they had didn't catch it (twice) and that's a problem with SIEMs - usually not configured correctly or to log the right things.