by Ed Skoudis
Over the weekend, I was thinking about the wonderful psexec capabilities of tools like Metasploit, the Nmap Scripting engine smb-psexec script, and the psexec tool itself from Microsoft Sysinternals. It's my go-to exploit on Windows targets, once I have gained SMB access and admin credentials (username and password, or username and hash for pass-the-hash attacks). It works on a fully patched Windows environment, giving you code execution with local system privileges of a program or Metasploit payload of your choice. That's especially helpful in a penetration test once you gain access to an internal network that is relatively well patched. We talk a lot about how to leverage this capability creatively and effectively in my SANS SEC560 course on Network Penetration Testing and Ethical Hacking.
During my class, this lesson sinks in with some students faster than others. Where it doesn't sink in, target crashing inevitably ensues as people try other service-side exploits to hammer a target. To help make the lesson of the usefulness of psexec a little more memorable, I've created the following Despair-like poster, titled "A Penetration Tester's Pledge":
*Photo credit: Wiki Commons, User Grj23
Don't get me wrong: I love service-side exploits as much as the next guy. But, some of them could crash target processes or even entire systems. Further, psexec is so wonderful because it comes in handy once you've compromised one target (perhaps with a client-side exploit), escalated privileges, grabbed some juicy-licious admin credentials, and are looking to spread to more prey. Now, you can target other fully patched Windows systems in the environment with psexec, your new besty-best friend forever.
The psexec capability just completely rocks, and we have several different variants to choose from:
- If you want super flexibility in making the target machine run a Metasploit payload of your choosing, such as the mighty Meterpreter, use Metasploit's psexec module (windows/smb/psexec), which also supports pass-the-hash for authentication (no need to know what the password is; instead, just set SMBPass to the LM:NT hashes). You can also choose a custom RPORT besides TCP 445, so you can port-forward pivot other ports through to your ultimate target's TCP port 445.
- If you want to run something at scale across a large number of machines you've scanned, consider using Ron Bowes' psexec Nmap Scripting Engine script on targets where you've found TCP port 445 open, which also supports pass-the-hash sweetness.
- If you are in an environment that prohibits you from running third-party attack tools like Metasploit or Nmap (oucha, I know), you might want to use Microsoft SysInternals' own psexec program, which typically doesn't flag anti-virus tools because it comes from Microsoft itself and is regularly used for system administration. This version doesn't explicitly support pass-the-hash, but you can use Hernan Ochoa's excellent Windows Credentials Editor (WCE) to inject your hashes into your Windows machine's memory, and then use Sysinternals psexec with the new credentials.
Regardless of the variant you use, psexec leverages your credentials to make an SMB connection to the target machine, writes into its file system some code you want to execute, creates a service on the box, and uses the service to execute your code. If you use the Metasploit or NSE versions of psexec, it then cleans up after itself, by deleting the service and removing the code from the file system (both the service and code have a pseudo-random name in Metasploit and NSE). Yaaaayyyy, Metasploit and NSE! Thanks for doing it right.
Important note: the Microsoft Sysinternals psexec program doesn't remove the service that it creates. Thus, as a penetration tester, you'll either leave behind an installed service on the machine, or you'll need to remove it after you are done. I like to remove it, restoring the environment to what it was like before I was there, lest I slightly increase the attack service of the target machine by leaving behind the psexec service and its related code. You can remove it using the Microsoft service control (sc) command, as follows:
C:\> sc \<RemoteTarget> stop psexesvc
C:\> del \<RemoteTarget>\admin$\psexesvc.exe
C:\> del \<RemoteTarget>\admin$\system32\psexesvc.exe
C:\> sc \<RemoteTarget> delete psexesvc
And, one more SUPER IMPORTANT NOTE: The Sysinternals psexec has an option to allow you to specify a different user and password other than your current credentials (the -u <user> and -p <password> command flags). If you don't use the -u <user> and -p <password> option with the Sysinternals psexec, the tool uses whatever Microsoft Windows authentication your client and the target support (such as NTLMv2), passing through your existing credentials via a challenge/response protocol. However, if you use -u and -p with Sysinternals psexec, it will PASS THROUGH THESE CREDENTIALS IN CLEAR TEXT (as described brilliantly by Mike Pilkington here and in Section 4 of this article by Jean-Baptiste Marchand here). That's why I recommend you NEVER use -u and -p with psexec, unless you are comfortable passing through admin-level creds in cleartext. Your best bet it so use it without the -u and -p options.
So, there you have it. Psexec? a great capability and trusted friend, along with a few notes on its safe usage.
I'll also be teaching SANS SEC560 at SANS Network Security 2016 in Las Vegas, September 12th through 17th. You can sign up for that one here: https://www.sans.org/event/network-security-2016/course/network-penetration-testing-ethical-hacking
Or you can take it anytime, OnDemand (Online - Video)
SANS Institute Fellow
Counter Hack Challenges Founder